This blog post is a collection of advice or rules I’ve learnt to live by as a software engineer.
It’s an accumulation of experiences I’ve gained through working for software organizations of various sizes.
Most of the advice in this post is aimed at software engineers, but some may be applicable to other roles and industries.
Understand the problems you are solving
This isn’t a revolutionary idea. But the very sad reality of life is that it still hasn’t been internalised by so many engineers and organisations that it’s worth reiterating. I can’t stress enough how important understanding the problems you are trying to solve is. I’ve seen countless hours and budgets wasted on “solving” problems that have been completely misunderstood and often actually made worse by taking the wrong action.
Engineers tend to gravitate towards the how and the what instead of the why. The how is more interesting to us because we sense the opportunity of learning something new in jobs that over long periods of time at most organizations get boring. The how is our escape hatch to learning that “new thing”, gain new skills, etc. In my career I’ve learnt this to be ironic in the grand scheme of things as by working on solving problem you’ll inevitably pick up new skills often without even realizing it whilst working from skills to the problem you’ll end up with situations where a lot of engineering time and budget is spent on attempting to solve what may be a genuine problem but ends up missing the mark because the focus becomes the how.
One of the most important goals in your job [as an engineer] is to “seek the truth”. You must do your very best to understand the problems you work on. Sometimes this requires digging in a ridiculous amount of detail before taking any action. More often than not this is easier said than done, but it’s well worth investing your time and effort in it. Otherwise, you’re doomed to either end up in the world of hurt down the line or make someone else’s life miserable by passing your “art” on them.
Keep a log of your work
Over the years of working as a software engineer, I’ve learnt to keep the log of the work I’ve done each day. I don’t do anything fancy. A simple bullet-point list does the job pretty well for me. Every item in the list has a short description of each task/activity I’ve spent my time on with a few comments that add a bit of context:
- approximate amount of time I spent on each task
- was the task done or not and if not then what is the next step
- was working on the task interesting and why or why not
This may seem similar to what engineering teams usually put into their backlogs, but to me it serves a slightly different purpose.
Initially, I started maintaining the log as a way of keeping my sanity in check with the growing size of my TODO list(s). But it turned out to yield other surprising benefits. Tracking what I’ve spent my time on every day helps me
- review what went wrong or right and what needs doing the next day/week
- identify the patterns which lead to finding the areas of improvement
- understand what problems or tasks I actually enjoy working on
- reporting which is invaluable if you lead engineering teams
- prevent recency bias during performance reviews, etc.
I used to use all kinds of fancy and elaborate tools to maintain these logs of activities which would often get my head spinning. Nowadays I simply use the native macOS/iOS Notes app which does the job for me like a charm, though I might revisit this at some point in the future.
Learn to understand product management
Some of the best engineers I’ve worked with throughout my career have been the ones who understood product management process reasonably well. This doesn’t just mean the engineering part of it. As anyone who has ever worked on building [digital] products knows, whilst engineering plays an important role in product development – broken engineering can ruin your product – it usually isn’t the most important part of it. Engineering doesn’t make up for the lack of understanding of your market (users), design, UX, collaboration etc. Obviously, the same applies to product management: broken product management [usually] can not be fixed by brilliant engineering.
Earlier in my career I used to obsess about writing the “cleverest” code, obscuring the critical code paths with the wildest algorithmic optimisations deployed to all kinds of “byzantine” architectures. It took me a while to internalise that more often than not good enough is a great starting point in the product development lifecycle. By good enough I don’t mean you should rush something out if it’s broken by design. Good enough means something has been done in a way that can sustain the viability of the product and can be iterated on in the future.
Whilst I’m still willing to die on the hill of the reasonably well-designed and tested code running in a reasonably well-architected infrastructure, as I’ve progressed through my career I’ve learnt [the hard way] what I believe a great engineer should be like: great engineer is the one who understands where to put the most focus at what point in time during the product development lifecycle to add the maximum value to achieve product development goals.
Understand what matters the most at what stage during the product development lifecycle
Knowing what to focus on requires both a bit of skill and experience. Product development involves collaborating with non-engineering teams e.g. product managers, design/UX, marketing etc. I’ve witnessed many excellent engineers struggle to speak to non-engineering teams and it has always pained me to watch. Investing in learning to work with non-engineering folks should be one of your main priorities if you want to be successful at your job.
Acquiring product development experience is arguably much easier at early-stage companies where you are forced to cover most of the product development roles yourself. Some of the best engineers I’ve worked with have been the ones who have that existential-risk-company experience behind their belt. This is not to say that you can’t get great at product development if you have only ever worked for large corps. You totally can, but from my experience, it requires much more effort, unless you are naturally talented. At large(r) organizations you get exposed to fewer things than you do at the existential risk companies.
This is also one of the reasons why some of the best people I’ve worked with have some experience in running their own companies or building their own side projects: they’ve learnt the hard way what matters the most at any given time. I’ve learntso much about product development from these folks. If you work for larger companies, seek them out!
There are also a lot of interesting books on the topic written by some of the best people this industry has seen. My most favourite book in this category is Build by Tony Fadell. It explains the what, why, when and how of some of the most beloved products Tony helped to develop for Apple and Google. Tony is an engineer himself, which makes this book even more valuable to engineers who want to get better at understanding their jobs at product companies. I can’t recommend this book highly enough.
Learn to be curious
Curiosity is one of the biggest indicators or predictors of your [professional] success. If you develop it well, and yes it’s a learnable skill, it can become a real superpower for you. Whilst being curious is a valuable personality feature in general it is surprisingly useful in your day-to-day job which tends to become a bit of a chore every once in a while. If you learn to be curious there will never be a shortage of interesting things you might find in your job. Curiosity works as an invisible energy source that leads to the path of endless discoveries of interesting problems. By the same token, if you are not curious about the problems you work on the chances of your failing to engage with them rise exponentially and so do your chances at succeeding professionally.
The corollary is the well-known advice: you should strive to work on problems you find interesting. Once you find them go full gas. I can say from my experience that I almost always failed in getting good at things I found dull and had very little passion for. Whilst I’d always try to do my best in these situations the mental penalty incurred fighting the lack of curiosity was too high to pay. This is not to say that if you work on problems you find interesting you will never encounter dull moments: these moments are inevitable to occur, but it’s much easier to deal with these occasional bumps if the problems they’re parts of peek your curiosity.
My rule of thumb for finding things that interest me is how deep I am willing to follow the rabbit hole these problems lead me down. If I go down one and climb back up in a couple of hours chances are pretty high I’ll enjoy working on these problems. Nice side effect of following these rabbit hole is picking up new unforeseen insights which makes solving these problems even more interesting.
If you fail to find your rabbit hole of interest in your job you should speak to your manager or senior engineers to help you find a different area of focus. Most companies usually have an endless list of problems that need solving! If you fail to engage with any problems you work or don’t get a chance to work on the problems you are interested in at your current company my advice for you is to move on.
Learn to articulate problems properly
One of the most important skills you can develop is to explain problems in a clear and concise way. This doesn’t necessarily mean applying the famous Feynman method: explain like I’m 5 (ELI5). When I attempted doing this with some folks more often than not it led to creating more confusion than helping – maybe I really sucked at it or never learnt to do it properly. But one of the tricks I have learnt though is tuning my explanation to audience I speak to. Whilst drawing cute pictures might work for some folks it probably won’t for others.
Needless to say, this requires doing your homework first. This doesn’t just mean thinking about how to explain the problems but also what I mentioned at the beginning of this blog post: you must understand the problems you are trying to explain to others beyond superficial level. If you don’t you’ll just create more problems for yourself and likely for others, too.
What helps me is jotting down some notes in my notepad first. I mean the actual physical notepad. Once I figure out a potential angle of explanation I then write it down occasionally attaching some visual diagrams if necessary. Sometimes I write down multiple versions of explanations each targeting different types of people. Doing this also has a surprising effect of helping me to understand the problems better.
I have a simple process I usually follow:
- describe the problem from a high-level PoV; avoid complicated vocabulary
- explain the issues the problem you’re trying to solve causes
- suggest a potential solution from a very high-level PoV
- dive into implementation details only when necessary
Learning to explain things well to others has the potential to elevate your career [and life] to a whole another level. You’ve no idea how many people get stuck in their progress because they fail at this. Whilst I still have a long way to go to get much better at explaining problems, getting better at it has been absolutely invaluable to me.
Be proactive and get shit done
Learn to get shit done. From the start all the way to the very end and then some. This is still one of the most underrated skills you can acquire. At well-run organizations you are guaranteed to get rewarded for this. In the not so well run ones you will at least get a feeling of accomplishment and a tone of invaluable experiences. Do not underestimate the intangible effects of accomplishing a goal.
There is nothing worse than a person who moans about problems incessantly but never follows up with any action. We’ve all worked with “that person” and if I’m entirely honest I certainly had similar spells early in my career when I ashamedly belonged to this bracket of people. It’s quite easy for humans to fall into this trap: negativity is incredibly infectious. Probably more so than positivity which is why so many organizations are swarming with seemingly miserable people who spent more of their time with moaning than doing.
Over the past few years, I’ve started noticing one of the problems that has infested our industry: LARPing. LARPing has always been present around us but I feel we are now living in its golden era. LARPers have now penetrated so many places that people barely pay attention to them as something unusual. They’ve somehow become accepted as an inevitable course of nature especially in larger organizations. Their defining feature is an almost magical ability to pretend they understand the topic they have strong opinions about, but in reality, they’re incapable of taking any action. So they LARP. And for some reason they even tend to get awarded for it by equally clueless people in charge:
You don’t want to become a LARPer. At least not if you care about doing great work and strive to improve. I’d argue you can only accomplish that on the battlefield of everyday work. If you work for well-functioning organization you will usually be surrounded by great colleagues who have similar ambition – getting things done is the easiest way you can earn the respect of your best colleagues. Heck, you might even turn the miserable ones by becoming a proactive doer. Proactive doers are the people I’ve enjoyed working with throughout my career the most. I learnt to keep off LARPers with extreme prejudice: they’re a real drag and solve nobody’s problems.
Taking action doesn’t necessarily mean writing code or fixing bugs. It can be pretty much anything that helps resolve problems you encounter or do anyhing that gets your team closer to accomplishing its goals e.g.
- documenting the issues at hand so others can understand them well
- organizing people around a solution and following up until the very end
- fixing the issues at hand yourself - you’d be surprised how much you can do!
At some point in the life of most organizations making and delivering things slows down. It’s like they have approached the metaphorical black hole and are being pulled into it. By getting things done you can be the beacon of light that escapes this black hole despite all the physics being laid down against you.
Figure out the trust boundaries
Companies [and projects] are run by people. There is a point when the people in charge can no longer be involved in every single thing that’s being worked on: this does not scale. They also often lack expertise in many areas – this isn’t necessarily a bad thing – it’s one of the reasons why have labor division after all. So they draw trust boundaries somewhere. These boundaries serve as interfaces to groups of people whom the people in charge entrust with managing and delivering some task.
Your job is to figure out who the people behind these trust boundaries are. This is often less obvious than you might think, but it’s in your best interest to uncover them. The effect the trust boundaries have on your success is immense. You can do the best imaginable job but if the trust line is drawn in a way that doesn’t interface with a way that helps you succeed you are basically screwed. It’s as simple as that because these boundaries have an extremely permanent nature which is almost impossible to change especially in organizations that have been around for a long time.
Imagine someone who has very little clue about engineering or the products you work on; or finds the products you work on unimportant as a result of not understanding them. GL; HF changing that. The trust boundaries are the hardest to redraw and barely change. If you find it difficult to succeed under the current trust boundaries you need to cut the losses and move on: pick a different team, different project or a different company. It’s extremely mentally penalising to tread the water and actually detrimental to your career progress.
Control your emotions
This is the problem I personally struggle with the most. If you ever met me you’d likely notice I’m a pretty crazy guy. I have a lot of interests I feel deeply passionate about: technology, sports, travelling, etc. You’d probably struggle to shut me up once I start talking about any of these topics. I feel the same way about the work I do: I often get connected with my work and the company I do it for on a weirdly metaphysical level. It’s hard to explain, but I only have one gear: full gas. In a way I approach my work a bit like Werner Herzog:
If I fail, I will fail so hard I can never recover
Being passionate about something can be great but it has a major downside. Passion often manifests itself with strong emotions…..on opposite sides of the spectrum. One of these is [mostly] good the other side is….not so good.
I get quite frustrated when some things I am involved in aren’t moving fast enough especially when the lack of speed is entirely out of my control. Sometimes these frustrations are legit justified, other times not so much. I usually resort to sarcastic comments and snarky remarks: weird [and flawed] “tactics” I’ve developed whilst living in the UK for several years. Obviously, this isn’t helpful to anyone, so it’s something I am going to invest a lot in the upcoming months of my sabbatical.
Learning to control your emotions in difficult situations, making your peace with the fact you’ve done everything in your power to get things as far as possible and letting go when things are out of your control seems like the hardest of the skills you can acquire. At least to me it does, but it’s a goal worth striving to achieve.
Invest in relationships
This is probably one of the most important things you can do for yourself. Invest in personal relationships. I have to repeat this again because it’s worth internalising: invest in personal relationships. If there is one thing that has paid off in my [not necessarily professional] life it’s building great relationships with people I meet or work with. Sometimes I’m less successful at it than I would have liked but I barely regret doing this.
It’s the friends we make along the way that help us appreciate the journey
Arguably, this is much easier if you work at the office where you frequently bump into your colleagues. I’ve been working remotely over the past 5+ years and I can honestly tell you even if it’s harder, especially at companies that completely fail to grasp the importance the personal relationships play in delivering company goals, it is vitally important for you to work on.
The best way to connect with folks on higher than superficial level it talking to them about non-work related things. Some folks are more private and won’t share much with you but if you open up or follow up on the topics you pick up during non-work conversations building a nice relationship suddenly becomes a real possibility. I do admit, though, I have a cheat code: I’m an extrovert so it’s easier for me than it might be for others. But even if you are an introvert I’d still like to encourage you to find a way to do this.
Being closer to the people you work with beyond the digital avatar and ASCII characters they leave behind pays off immensely. From my experience as a software engineer, the PR reviews and technical discussions become by magnitude easier. Whilst there certainly are other ways to make these activities better for everyone, having closer relationships with everyone involved makes this much simpler. I’ve been a part of a lot of heated discussions with my teammates throughout my career but we always maintained great relationships despite all of this.
Master your craft
No matter what role at whatever level you occupy at any given time you should always strive to reach the next level in your craft. This is usually much easier in some professions like engineering where the abundance of information and opportunities is almost surreal. All you need is the willingness to take the next step in your professional development journey.
Relentlessly pursuing perfection should be one of your essential goals. You won’t reach it because perfection is unattainable but in the process you might get closer to excellence!
Every year I try to pick one thing I want to learn or get better at. Some years I’m more successful than others: life is full of entropy that’s very hard to control. Learning new things or improving and deepening the existing knowledge has always paid off for me. There is just no downside to it. I sometimes take it to comically extreme levels I wouldn’t recommend to anyone so I won’t discuss the details here, but even small changes in your usual routines compound over long periods of time.
Ideally, you work for companies that support your professional growth, but even if you don’t it’s in your best interest to find some way you do. Whilst working a place where you get to work on hard engineering problems helps with this, it shouldn’t be the only thing you root your professional growth in. You should always seek new ideas and new paradigms that either challenge your existing thinking and broaden your area of expertise. Chances are you work with great people and you might not even know about it. Seek them out. Seek great colleagues who challenge you and help you improve.
Working on side projects is also a great way to get better at your craft. In fact based on my personal experience I’d argue it’s one of the best ways. If you can spare some free time try contributing to OSS projects you use on a daily basis or find interesting. Working on OSS has been probably the biggest life changer for my professional career. It has opened so many doors to so many excellent [learning] opportunities and relationships that I can not recommend this more. Besides, OSS is going through a little bit of an identity crisis at the moment and needs anyone who is willing to contribute :-)
Conclusion
The above list is by no means exhaustive. I could go on about so much more, but this could serve you as a good starting point you could build upon. Feel free to leave a comment with the lessons or advice you have found important that could be valuable to anyone working on making their careers more fulfilling and successful.