Be flexible

This week I was thinking about some advice I had given a grad earlier in the year. I had told him to be flexible, opportunities come in different shapes and you should be open to challenges. For context, he was asking about what he should specialise in. When I look back on the various jobs I've been I can honestly tell you that I didn't imagine I would do any of that when I left university. If you had asked me a year after I started working as a programmer I still don't think I would have told you the variety of things I have done. I have now worked in 4 countries, lived in 5 and have focused on all parts of the technology stack at different points.

My point here is that it wasn't planned. I didn't have a 10-year plan that encompassed all the things I wanted to accomplish. Sure I had aspirations to at various points about what I wanted to achieve, but they changed as I learnt more, as I discovered and rediscovered what I enjoy doing, and as I met more and more people.

A manager recently said to me "think about what the company needs from you, not what you need from the company." Looking back this is extremely good advice. The opportunities that I jumped on were because the company I worked for at the time needed something done. Often it was something I had not done before and I was willing to fail, learn, fail, learn and so on until I succeeded. I can still remember purchasing John Resig's JavaScript book in 2009, fumbling my way through it in my spare time, writing some pretty horrible looking JavaScript at work, and eventually shipping a library that let the clients embed videos onto their corporate sites without requiring Adobe Flash. Sounds simple enough now, but there were many unknowns at the time and the likelihood of failure was pretty high. Was it something I was aspiring to do at the time? Nope. At that point, I was all about writing backend web services in C#. The reality is that I understood what the business needed from me and I was willing to attempt filling that need.

Not only did I learn a lot about writing JavaScript without jQuery doing that project, but I also became a much better programmer. This brings me on to my next point. Be wary of solving the same problem over and over again. There is value in repetition, you get extremely good at doing a particular thing. However, there is also value in having a variety of experiences, experiences allow you to take the skill you're really good at and adapt it to different problems. If you're thinking about an opportunity I want to encourage you to think about what you will learn from it. Compare that to what you have learnt over the last 3, 6, 12 months. For me doing the JavaScript project in 2009 I learnt a lot about writing performant code and I significantly improved my debugging skills. A lot of this came from taking existing skills I had and trying to apply them the browser landscape at the time. It forced me to question what I knew, it also forced me to develop new skills to augment existing ones.

The other part to being flexible is recognising that opportunities come in different sizes. I feel that I've only recently recognised why this is important so please try and validate this by looking at successful people around you. I see a lot of senior engineers looking for a chunky project to prove their skills, to show everyone that they're capable of hitting it out of the park. Whilst it may be entirely true that they would do an excellent job, they are often disappointed when they don't get the chunky challenges. What I've noticed is that managers have a tendency to bet on individuals and/or teams. I don't think they explicitly do it, I think it is simply down to trust that has been built up doing the small or painful projects. Ultimately the manager is under pressure to deliver, if they are given a new problem that needs a solution then they are going to bet on those that have a track record of getting stuff done. My advice here is to do the small projects and do them well. Taken on challenges that people are shying away from, you will take problems off your manager's plate whilst building respect and trust. It will not be a quick change, but it should pay off in the long run. Of course, I could be entirely wrong here so I urge you to look at the successful engineers in your organisation and what they have delivered over time. 

The final thought builds on the previous but it's about the other side of opportunities that I think engineers often forget about. The people side. It's very easy for us to get lost in the complexity that comes with solving problems using technology. With each of these projects that I've done, I have worked with different people. I have learnt from others, usually outside of engineering, on how to view problems from a different perspective, learnt tactics for influencing people and methods for communicating in a team setting. These skills are all additive to my technical skills, and help me deliver projects. Delivering projects as it turns out is more than just writing code, it's also really understanding why you're doing something and making sure you're aligned to what the company needs. These are things you're only going to get good at by working with others on a variety of problems.

Bit of a ramble, and I hope it helps.