What I've Got Wrong and Right In My Career

Published in Career - 25 mins to read

I’ve made some huge mistakes in my career so far - things that have cost me learning opportunities, promotions, and sometimes my mental health. Fortunately I’ve also got many important things right - some deliberately and some accidentally. Given I’m looking for a new job (see my LinkedIn and get in touch!), this seemed like the perfect opportunity to reflect on both.

Mistakes I’ve made

Being inauthentic and getting stressed

I’ve improved over time, but I’ve often struggled to be authentic at work - instead presenting some kind of sterile, corporate version of myself, with no fear, shame, or sense of humour. I’ve always had a close-to-pathological desire to be liked and to receive good feedback, so the way I’ve gone about that in my job has been to be as inoffensive as possible.

This has not been a good strategy! Being authentic is a core value of mine, and maintaining this facade has incurred a lot of psychic damage over the years. Not being more open about my feelings and insecurities has meant I’ve found myself so stressed that it’s affecting not only my mental, but my physical health.

My rationale for behaving this way has been that I am looking to get promoted, and I don’t want to appear unable to handle the workload thereby hindering my chances. In practice, I have ended up leaving the company before these promotions anyway, and in retrospect I clearly should’ve communicated my struggles earlier. On the occasions this has happened, there was a chance that my employer and I could’ve course-corrected, and perhaps I would’ve got the promotion in the future anyway; I would’ve been more productive as a happier employee.

In my next job, it is vital to me that I am able to express how I’m feeling with my manager and my colleagues. This is something I’ll be evaluating potential roles for during the interview process.

Trying to deliver perfection rather than value

This is a classic software engineer’s mistake that I also made. I wanted all my code to be elegant and concise, like the optimised solution to a Leetcode problem. There was an immense feeling of satisfaction that came with producing code of that level, and I would spend a long time getting my code there before I shipped it.

Unfortunately, I wasn’t getting paid to write beautiful code, I was getting paid to deliver business value. This was a bitter pill to swallow, but I am incredibly grateful for my former manager at Zoopla for confronting me with it. He was completely right, and since I’ve adopted this mindset, there have been many occasions that it’s helped me feel less frustrated at work, ship more and make greater progress towards my goals.

Not embracing the kaizen approach to learning

In software engineering, people go on and on about constant learning, the need to keep on top of rapidly-moving changes in languages, frameworks and paradigms, and how crucial it is for your career. So naturally, employers take steps to ensure that their employees have the time and resources in order to learn new things and keep their old skills sharp.

Just kidding! Recruiters and hiring managers often make claims along those lines, but in my experiences, they’re empty promises. As above, your job is to provide business value. While spending time learning now might lead to greater business value later, employers are primarily concerned with the problems they need solving today, not hypothetical future ones. Even if your employer does offer some kind of time or resources to improve, there will always be pressure to finish your sprint tasks which will inevitably take precedence over your learning. You are incentivised to ship new features, as this is what your performance review is going to be based on. Often, this is even worse than it sounds; you become the expert on whatever you work on, making it more efficient for you to do future work on it at the expense of working on new and potentially challenging alternatives. This kind of pigeonholing can lead to rapidly diminishing returns on learning in any job.

This can and should be fought. Be clear with your manager that it’s important to you to be constantly improving, and get them to help you achieve that. When feature Y comes up in the roadmap, tell them you want to work on it and explain why. If there is no feature Y on the roadmap, suggest one.

Another strategy I’ve found works is to block out time on my calendar every day devoted to learning - ideally 60 minutes but in a pinch 30 is still fine. There’s a lot you can do in that time; solve a Leetcode problem, write Hello, World in a new language, watch a tutorial about Kubernetes, debug an issue in a personal project. Prioritise this more than your sprint work (but don’t tell your team or manager that I said so), and consider it an investment in yourself. Try to write down something new you learn every day.

Consistently over-optimistic estimations

This is another one that lots of people struggle with, often unnecessarily. As I mentioned, I want people (colleagues, managers etc) to be impressed by me and give me good feedback, so I was often extremely optimistic when giving time estimates for tasks. I would then work hard, and feel stressed, in order to try to meet my ambitious and largely self-imposed deadline. If I succeeded in completing the task on time, my manager was unlikely to be particularly impressed, given all I’d done was meet the expectations I’d set for myself. If I failed, they were usually unimpressed, regardless of the fact that I’d been working hard and might well have still completed the given task within an impressive time frame. Not only was I not achieving my goal, I was creating a situation in which I was necessarily failing.

There is also a narrative among engineers that the nature of software is such that it is close to impossible to estimate accurately - I squarely reject this assertion. Improving your calibration for these kinds of temporal estimates is entirely possible, but most scrum teams miss out a crucial step that would improve their performance. The formula I’ve found works for significantly improving my estimation is;

  1. For a given task, decompose into all the subtasks required to complete the main task.
  2. Write all these tasks down, and estimate how long it will take each one to be completed (this can be done recursively)
  3. Do the main task. Make a note of how long each subtask takes and of any subtasks that you initially didn’t scope.
  4. The missing step - compare what actually happened with what you predicted would happen. Try to think of ways in which you could’ve anticipated any steps that you miss. If you were too optimistic for any given subtask, try to work out why.
  5. Score your predictions - try to understand the delta between your estimates and reality, and use that to inform future predictions.

Not focussing on fun

I really enjoy some parts of software engineering, like system design or writing APIs. However, there are a lot of parts of the job that I don’t particularly enjoy, and at some point I realised those were taking up the majority of my time.

I’d not reflected on this until recently, when I realised I wasn’t sure about continuing to work in software at all. I’d assumed that I would keep being an engineer because I was good at it, had experience and it paid pretty well - but I hadn’t enjoyed much of the work that I’d done so far. It’s been a mistake on my part to not think more carefully about this, instead doing whatever seemed best for my career or promotion chances rather than my happiness. Ironically, the best thing for my career is probably going to be the thing I find most fun, as it’ll keep motivation high.

Fortunately, this is easily fixable. Having written down which parts of the job I do and don’t enjoy (an exercise that I would recommend), I can now use this as a framework for evaluating potential future jobs, and can communicate to my manager about these preferences.

Not deeply understanding my organisation

To provide “business value”, obviously you have to understand what it is that the business values. When joining a new team or company, I’ve felt the need to “hit the ground running” by immediately focussing all my attention on making code changes and building features. But the best senior engineers I’ve known are the ones who do the exact opposite - they join a new team and they don’t commit anything for the first few weeks. They spend all their time asking questions, and seem much more interested in the product manager than the tech lead.

It might slow their velocity down in the short term, but it means that when they do get to the code, they are much more impactful. By having the context for their work - which can take a long time to acquire (it took me literally months to really understand the purpose of what I was building at Zoopla), they are able to add value to the business much more effectively. It’s a bit of a cliché, but I think it’s true; the best engineers are the ones who can say “we shouldn’t build this feature” or “I know what the roadmap says, but we should do this instead”.

Assuming my manager was interested in me getting promoted, by default

When I moved to London from Guernsey, I was a naïve island boy, and it turned out that I was wrong about many aspects of corporate city life. I thought my manager would try to get me promoted almost by default - after all, surely it would reflect well on them if I got promoted? So, I went through a year of working my first London job, and felt like things were going great. I’d had a lot of positive feedback, and been told I was exceeding expectations. I hadn’t explicitly told my manager I was aiming to get promoted, in part as I still felt like I had something to prove to be there in the first place, but given how well everything had gone, by the time promotion announcements came round I assumed I would be among their number.

Writing this now, I must admit it feels incredibly embarrassing to think I ever thought that way. Of course I didn’t get promoted! Companies aren’t going to give out higher salaries for free; they’ll only do it when they have to, and they’ll only feel like they have to when employees advocate for themselves strongly.1 Managers are also risking something when they put their reports up for promotion; they are doing something that would increase the business’ costs, the opposite of one of their main functions! If a promotion gets rejected, it reflects poorly on the manager as who suggests additional outlay without full justification.

The lesson here was simple; make it clear to my manager what my goals are, get them to help me break those goals into actionable tasks, and give me feedback along the way.

Being reluctant to learn certain languages

While not as disastrous as some of the other mistakes on my list, I have at times been reluctant to learn certain languages, usually due to not perceiving them as “modern” or enjoyable to work with. At Zoopla, part of my role involved interacting with a legacy Perl codebase, and I always spent the absolute minimum amount of time figuring out what parts of the language I needed in order to make any given change. This meant that nothing ever really stuck, and every time I needed to work on that codebase again, I felt like I was starting from scratch.

At the time, I had the idea that Perl wasn’t particularly glamorous and therefore learning it wouldn’t further my career goals. In retrospect, this was not only the wrong framing, but also the wrong conclusion even from the incorrect framing that I chose! Learning a small amount of Perl (even the contents learnxinyminutes would’ve been worthwhile) at the beginning would’ve saved me both time and frustration over the long run. Learning new languages - even less modern ones - is not going to be detrimental to my career either. While I would prefer not to take a job where the primary language was Perl, knowing it shows future employers that I am willing and able to pick up new languages if necessary, and the reality of the industry is that there is a lot of legacy code out there. Learning new languages helps understand how languages work at their core, by providing a variety of different abstractions over the underlying mechanisms of programming.

It’s easy to slam some decision choices made in Perl, but their creators invariably made them for a reason. I ought to have figured out what situations Perl’s quirks shined in before dismissing the language as not worth my time.

Naïveté about the corporate environment

Relatedly, having solely worked at smaller companies before moving to London, I’d assumed that my performance reviews would be very closely tied to the quality and quantity of my output. In practice, while that is a factor, it’s far from the only one.

In practice, when companies get large enough to have middle managers, incentives start to become perverse and vulnerable to Goodharting, and internal politics emerges. There is suddenly a game to be played, and being skilled at the game is more important for progression than working hard and producing high-quality output.2 I’m generalising from a small sample size, and recruiters will always claim that their company culture somehow doesn’t have these problems but needless to say, I’m sceptical.

I learned a lot about playing the game in the past few years, but I can’t say I enjoy it, and this is one reason I’m more excited about working for small companies than big ones in the future (at least for now).

Not moving to London sooner

Another extremely non-replicable one, but moving to London has massively impacted my trajectory, and I was quite close to not doing it. The access to opportunities, chances to meet interesting people and simply soak up the atmosphere of people actually doing things have all made the city far better for my career than Guernsey ever was. I wish that I’d set the goal of moving here as soon as I started programming professionally, and it’s hard to remember why that wasn’t my goal. It seems easy to say that I didn’t feel like I was good enough, but I’m not even sure that was true - it mostly seemed like it was too big a change to be seriously considered, and I was too busy trying to solve problems on a smaller scale.

Things I got right

Learning solid fundamentals first

When I joined Indulge back in 2018, I had effectively zero programming experience. I couldn’t write Hello, World in JavaScript - possibly all I could do was write <div><p>Hello, World</p></div> but I certainly couldn’t use CSS to style it.

I was extremely lucky to have a mentor at the time who instilled the important of solid programming fundamentals into me. This mostly meant getting familiar with git and the command line. He could’ve suggest using a GUI for everything so I could get things done as quickly as possible (and help the business achieve its goals), but he chose to make sure I learned how to do things the “right” way, even if it took longer.

Being familiar with these tools has paid dividends innumerable times over my career, so much so that I’m trying to double down on my command line fluency by switching to NeoVim as my code editor.

Doing a bit of everything

I’ve been paid to write production code in JavaScript, TypeScript, PHP, C#, Java, Python, Perl, Go, and various frameworks like React. I’ve built frontends, APIs, CMSes, web scrapers, CICD pipelines, automated tests, observability tools, infrastructure-as-code, cloud and on-prem, microservices and monoliths. I’ve worked for companies worth a couple of million dollars, a couple of billion and a couple of trillion. All this in only 6 years!

There is a tradeoff here, in that I am not a deep expert in any one language or domain. But it has been absolutely worth it - having exposure to so many different aspects of software engineering has given me a sense of what I do and don’t like that will help inform the next 40 years of my career. It also demonstrates to employers that I can quickly learn and add value without a long ramping-up period.

It’s made me realise that actually I enjoy doing a little bit of everything and being a generalist; another reason why I am excited to work at a smaller company in my next role.

Networked in a way that wasn’t awful

I’m an nerd, so the idea of “networking” fills me with dread. Even typing this I feel the familiar sensations of social anxiety and imposter syndrome. I never go to networking events, and avoid anything that might be construed as networking as if it were the plague.

Except I’ve actually done lots of networking, I’ve just never thought of it as such. Back in Guernsey I participated in a Game Jam that was primarily motivated by being able to meet the directors of Cortex, who would later go on to employ me3. I’ve met close to a hundred people at EA Global events at this point, and some of those people have recently recommended me for jobs, or are hiring themselves and I am interviewing with them. I’ve run events for the EA Tech London group and had various people I thought were impressive participate in them. Sometimes I cold email people I think do cool work or might have useful advice for me, and most of the time they’re willing to chat to me, and sometimes their advice is extremely valuable.

Obviously this is all networking, but I’ve never used that label for it, and so it’s never given me the ick. I simply think of it as “meeting interesting people” and hey presto, my limbic system complies.

I think another big part of why this strategy has worked out is that I (hopefully) come across as genuine. I’m curious about the other person, and I’m still relaxed and myself, so it’s less transactional or transparent then a typical “networking” interaction.4 Being curious rather than explicitly wanting something from someone seems helpful too - on many occasions I’ve met with people who I’d previously thought were extremely impressive on paper, and realised they’re actually not that different from me, they often just picked the right path and stuck to it for long enough.

These not-networking-but-secretly-networking interactions can have a cascading effect too. People I’ve met then introduce me to other people, and so my graph grows. Plus, many of these people are now my friends. Regrettably, I can’t endorse networking strongly enough.

Moved jobs at the right time

I’ve moved quite frequently, certainly more often than some would suggest. I think this was the right choice every time, given that each move has yielded one or more of the following;

I’ve only been explicitly rejected for a role for being a “job hopper” once, although perhaps I have been implicitly rejected for this many times. My take on this is that if you pay me significantly below the market rate, don’t give me opportunities to learn (particularly ones that you repeatedly advertise during the hiring process) and make the work environment one that negatively impacts my mental health then what else am I meant to do, if not quit?

Regardless, I haven’t yet encountered any major problems with getting interviews, and when asked I have good reasons for each move. The major drawback here is not having the opportunity to support systems that I’ve built for a few years, and potentially felt the pain of certain design decisions and tradeoffs. When I was still quite junior I don’t think this mattered, but now I am more senior, this is something I’m keen to find in my next role.

Been interested in AI tools and adopted them early

Being a keen chess player, AlphaZero left an impression on me, and convinced me that developments in AI had the power to shift even well-entrenched paradigms. When I became more seriously involved with the EA community a couple of years after its release, I became a believer that AI could dramatically alter many aspects of our society, including our work, and so naturally I wanted to keep on top of developments. I’ve been using tools like Copilot, Claude and the OpenAI APIs since their release, and I’ve found them to be a very significant productivity boost.

This has multiple benefits; I understand what tasks these tools are good and not-so-good at, I understand how to integrate them into my workflow, and I have a good understanding of what the current cutting edge is. The last one seems surprisingly important - my impression is that many people tried to use ChatGPT to write code when it first came out, were unimpressed, and assume it hasn’t progressed since. I think many of these people would be extremely surprised if they were to use it again today.

I’m very uncertain, but I think that in the next 5 years, adoption of this tooling will become a bigger part of software engineering. As the tools improve, the gap in productivity between those who do and don’t know how to use them will widen, and employers will start highly valuing those with familiarity. In these worlds, I want to remain one of the most valuable engineers in the market.

Learned how to communicate well, particularly in writing

To return to the idea that software engineers think their job is to write code; many do not realise the importance of communication, in particular in writing. So many desirable outcomes are downstream of successful communication:

There’s plenty of good advice on communication as an engineer out there, but the trifecta of elements I strive for are clarity, conciseness and compassion. I’ve had positive feedback from previous colleagues about my communication style, and have come to value the same traits in others’ communications with me.

Been ambitious

People have told me to be more ambitious a few times in my life, and it’s the best advice I’ve ever had. Depending on the day, I have a strong tendency towards either humility or plain old low self esteem, and seem to have historically underrated my ability to get certain jobs or make certain projects succeed.

I’ve found ambition and success to be correlated, perhaps causally. Once I have decided to be more ambitious, it has been a lot easier to put in the work in order to succeed in that path, even if it was less likely. Quickly I feel much more excited about it and this keeps motivation high.

Having adjusted my expectations upwards a couple of times and found them met, it’s become a lot easier to believe that I ought to update significantly further in the upward direction, without needing several intermediary steps with feedback. The optimal level of ambition has a high failure:success ratio; if you aren’t getting 20 rejections for every job offer you get, than maybe you ought to be applying for more senior or more challenging roles.

I’d never seriously thought about founding a company before, as inevitably all the reasons it might not work would come to mind first. But now, when I look at what I’ve achieved in my career so far, I feel like I’ve not hit my ceiling yet, and perhaps I’m not even close. Founding seems completely reasonable to me, and is something I am seriously considering.

A big part of the reason I became more ambitious in recent years (and managed to successfully act on that ambition), was thanks to the career advising I received from 80000 Hours. If you have any interest at all in using your career to do good, then I would extremely strongly recommend checking them out. If you do decide to apply for 1:1 career advising them then they have a referral competition running right now that I’d love to win, so if you use my link I promise to buy you a beer/coffee etc.

Applied for 100 jobs, learned 100 things

I’ve already written a whole post about this so won’t go into too much detail, but my strategy of applying for a very large number of jobs during my previous search proved remarkably productive:

It was an extremely stressful period, but it taught me lessons that I’ll make use of for the rest of the career, and so it was worth it.

Been a mentor and sought mentorship

This advice is commonly given, but seemingly rarely actioned. Getting a mentor is invaluable for achieving your career goals, and I found the experience of being a mentor to be so rewarding that it is now one of my career goals to do more of it.

Mentoring someone with less experience than me was eye-opening. I realised I didn’t have a solid grasp of many topics I’d assumed I knew inside-and-out. I found myself spending time outside of our weekly 1:1s making sure I had bulletproof fundamentals for whatever subject we were discussing. Often we’d try several different framings for a given problem, and whenever I saw something click for my mentee, it made me feel a powerful kind of happiness that I’d not experienced as part of my job before. Having experience of mentorship is also something that employers are looking for when hiring senior engineers.

Receiving mentorship has been extremely valuable too - without it I wouldn’t have been hired by AWS, nor do I think I would’ve been able to hack it there. I found mentorship to be somewhat like career therapy; my mentors have helped me view my career decisions more rationally, and have offered me valuable perspective when I’ve been unable to see the forest for the trees.

Finding a mentor can be hard, but I think this post and this other post by Neel Nanda are a great start.

Not worried too much about side projects

I see everywhere the advice that engineers should have side projects they put on their CV “in order to stand out from other candidates”. I suspect this advice is true for some segment of engineers, but for me I don’t think it’s been important at all.

The side projects I have on my CV and Github are pretty unimpressive. All I have is this website (which uses a static-site generator and therefore doesn’t contain any actual code I authored), some advent of code solutions, and Mango, which a) I originally did in a weekend and b) is out of date and probably doesn’t work with the current version of Manifold’s API. One of my friends has an amazing Github full of complex and interesting side projects, but he doesn’t have as much on-the-job experience as I do. Possibly there are other differentiating factors between us, but as far as I can tell, I generally get more interviews than he does, and he’s said to me before that nobody ever asks him about his personal projects during the interview process.

I understood why this is the case when I was speaking to someone who has to review engineers’ CVs as part of their job. They said that if they review 100 CVs, they simply don’t have time to go on every person’s Github and check out their projects. The only exceptions are when they sound especially interesting or they’ve contributed to a well-known open source library.

So, don’t sweat the side projects, and don’t succumb to the hustle culture pressure to spend all your free time coding. If you want to do so, and you think it’ll help you learn, then great - but if you already have some kind of meaningful experience (even a couple of years) on your CV, then the value of side projects is probably overrated.

  1. Incidentally I did leave quite soon after not getting promoted. I do find it quite strange that this company gave me a glowing performance review and said I’d significantly exceeded expectations, but then didn’t offer me any kind of salary increase. Doesn’t the performance review imply that my value to the market is likely to have increased? My guess is this strategy works fine for companies because employees generally feel too much inertia around moving jobs in order to act on it. ↩︎

  2. I realise that this probably comes across as bitter; it is. But that’s why I’ve left my job at a big company, and plan on working at a smaller one next. ↩︎

  3. If either of you end up reading this - thanks! And also, sorry! ↩︎

  4. Since running the tech group, I have found myself having plenty of these too. Often I meet people and they begin reeling off their greatest achievements within the first 30 seconds of meeting me. Presumably this is too impress me, but I don’t care! Something about this feels extremely unauthentic, and I am much more impressed by people who are capable of being authentic immediately with me than those who have three degrees from Oxford or who whose startup just raised seed or whatever. I know I shouldn’t actually throw this person under the bus on the internet, but someone I met recently told me that they were ex-Google within the first minute of meeting me! I suspect this had the opposite effect on me to the one they intended. ↩︎

Previous Post: Is This Water?

Next Post: ZSA Voyager Review