Stop Working In Your Team and Start Working On Your Team

leadership

As Engineering leaders, it’s easy to get swept up by the day-to-day grind of delivering software. Code quality, broken builds, deployments that didn’t go according to plan, 1:1s, conflicts, stakeholders, and all the other things that fight for attention as we try to satisfy the needs of the organisation. This is us, working in our teams. We’re getting into the weeds of what’s going on and helping firefight issues as they come up. But to be really effective in our role, we need to take a step back and think about how we can be working on our teams. To look for, and cut through all the noise and waste. How can we improve our processes to go build more robust software? How can we improve our ways of working to go faster? Where are we missing data that would allow us to make better decisions? If we’re not doing these things and just getting stuck in the details with the rest of the team, what are we really bringing to the table as leaders?

Unseen Work

management / work

We often mistake the job we see managers doing with the job they are really doing. We’ve all asked, at one time or another, “What does my boss actually do?”. We see them go to countless meetings, ask questions, or send around documents. We then equate those activities with the actual job of being a manager. Until I was promoted into the role of my departing boss, the perception I had of what they did was totally different to what I found myself doing. There was all this unseen work going on behind the scenes that led to the countless meetings, that led to the questions and that led to all the shared documents. On-top of that, the un-seen time and thought that went into ensuring the right questions were being asked and the right documents were being created and shared. This is no different to equating Engineers to writing code. There is so much unseen work involved in writing the right code. It’s knowing what technologies to use, it’s knowing what techniques, data structures and algorithms to use, and it’s knowing how to put it all together into building a functioning product.

There is No Debugger For Leadership

leadership / management

When there are bugs in your code, there are many mechanisms for understanding the issue and creating a fix. Your computer will tell you when you’ve made a mistake, give you feedback and await your next command. So as a developer you learn to live in this constant cycle of feedback. Constantly making mistakes, and constantly making changes. It becomes second nature. But it’s through these constant mistakes that we learn what does and doesn’t work. We learn to see patterns and spot errors sooner. These mistakes and what they teach us are what make us grow.

Moving into a leadership role can often feel like the total opposite. There is no fast feedback for your decisions. Sometimes it may take months to know you’ve failed, and sometimes you may never know at all. So you can end up doing everything you can to avoid making mistakes. But just like the developer, you need to make mistakes to grow. It’s uncomfortable, and it’s painful, but you have to make calls when afraid or in doubt. You have to learn to live in the cycle of mostly absent feedback. Sometimes you’ll pick up on the affects of the choices you made, sometimes that feedback will be faint, but it’s only in that faint feedback that you’ll find growth as a leader.

The Other Side of the Fence

leadership / management

As I have gotten older and my career has grown, a lot of my thoughts and opinions on topics around software development, management and leadership have changed. Reading back through some of my posts from ten years ago, I see a lot of the same thoughts and ideas that come up in discussions with more junior team members. And it’s not that they are wrong, but how the effects of experience and having a different vantage point can drastically change your view of things.

Whereas I used to be all for building a custom solution, now I would favour buying off the shelf more. Whereas I used to hate meetings, now I value the high bandwidth communication and alignment they can give when run properly.

A big factor is the difference that being accountable can have on your opinions. Before my promotion I would often rant about how “we have to immediately stop doing X”, or that “we need to really start doing Y before it’s too late”. But now that I’m in the role, all the second-order effects I had not previously considered, start to raise their ugly heads. I had only seen things through the lens of my IC role, now I see them through the lens of someone responsible for the team and how that team can meet wider objectives.

I’m sure that as I grow older still and my career grows, a lot of the thoughts and opinions I have now on software delivery, management and leadership will change. And all the things I’m critical of will look very different when I’m on the other side of the fence.

Applying Your Leadership Style

leadership

When you have sports coaching, whether that be for martial arts or tennis etc, often the coach will look at your technique and say “you’re doing it all wrong!”. And then you find that each coach has their own theory on how it should be done, even claiming other coaches don’t know what they’re talking about. But when you look at all these different theories and techniques, and put them into practice, at that moment where it counts, whether it’s contact with your opponent, or with that tennis ball, they all generally put you in the same, correct position, ready to take your shot.

Leadership is like this. Whether you’re quiet and gentle, or you’re loud and angry. At the moment when it matters, no matter what your individual style is, you have to be in the correct position in terms of vision and trust, ready to lead your team to success.

Learning to learn

self-development

The best developers I have worked with have all been incredible in self-directed learning. And yet a common pattern that I see more junior developers get stuck on is not knowing what to learn to progress their skills as a developer.

I spend a lot of time reading, whether that be blog posts or books, watching talks or listening to podcasts, I have never found myself short of topics to look into more or things to try out. So when I try to picture how someone can feel stuck, I struggle to see where that obstacle is coming from. 

There could be many reasons at play here. A more benign reason being fear and uncertainty: “There are so many things I could learn, what if I pick the wrong one?”. To that, I say start anywhere and see where it takes you. This approach then takes you on a “just in time” approach to learning, where, as you get deeper down the rabbit hole, the topics you need to learn change depending on where you end up. Whereas a more serious reason would be that the individual feels it’s not their responsibility: “My manager should tell me what to learn”. I could see how this way of thinking could be born out of schooling or bootcamps where we are told what to learn. So the responsibility for one’s development has been abdicated. 

Self-directed learning is a skill, but an important one for anyone looking to get ahead. For those that struggle, my advice is to just jump in. Doesn’t matter where and it doesn’t matter how. Pick up a book. Watch a video. Listen to a podcast. But no matter what, put as much of it into action as you can and link the dots. Every step you take will lead to the next, and that next step may require you to change course, but that’s okay, as now you’re learning.

Spring Boot JAXB unable to marshal type error

java / programming

Working with a SOAP API with Spring Boot WS. I was getting the following error trying to create the request.

I was originally directly using the JAXB generated classes to form my requests:

The correct way is to use the provided JAXB ObjectFactory:

But to prevent marshalling errors you need to wrap your object in a JAXBElement object:

No more computing books

books / computing

One of my bad habits is constantly buying computing books. This wouldn’t be so bad if I read them, but I have amassed a huge backlog of books that will most probably never be read and which ends up being a waste of money.

A couple of posts I read recently have led me to the decision that I should stop, or at least drastically cut down on, buying computing books. The first post talked about “learning voyerism” where you are really more interested in the idea of learning new things instead of learning the thing itself and the second talked about spending time going deeper into topics instead of boucing lightly through many different ones.

It is very difficult to stay focused on one thing when there are so many things happening in the world of computing all the time. There are a tonne of new and exciting languages and frameworks being released all the time. And while it would be great to try them all, that can only mean that you’ll never actually become good at one of them.

I have always been a bit of a generalist and while knowing a bit about everything isn’t a bad thing, there is a fine line between knowing a bit of everything while being proficient at some things and knowing not quite enough of everything to be unable to do anything at all.

OpenSSL issues building Ruby 2.2.2 with ruby-install

programming

Trying out chruby and ruby-install and installing Ruby 2.2.2 with ruby-install was giving be the error:

Setting the LDFLAGS env var solved this for me:

 

Stupid coding mistakes

programming / ruby

Made this mistake today while writing some code to delete data out of Redis.

The mistake was in the final method keep_keys. Every check to see if a key should be rejected I was adding an element to the flattened_keys array over and over again, causing my deletion to slow down over time. A simple change to memoize the keep keys made the process go from never finishing to, completing in a few seconds.

Product recommendations in Spree using the Jaccard Index

rails

Being able to recommend products to shoppers is a vital part of any online store. The “Customers Who Bought This Item Also Bought” section can lead to a lot of extra sales if done well. The Jaccard Index is a way of measuring similarity between items. Using some custom SQL we can extract the values we need:

With these values we can then calculate the affinity between sold products: