I am a good software engineer. I have a good understanding of software engineering principles, I work hard, I learn quickly, and I try not to make the same mistake twice. I am happy working on my own for long periods of time, I can solve puzzles well, and I genuinely enjoy coding.
I am an okay teacher. I know the material of my course well because I myself had to learn how to write Python. The part that I struggle with is explaining conceptual answers to students without just giving them the answer. I also find it difficult to convince students that coding just “clicks” one day without sounding condescending or uncaring. What I am good at, though, is helping students showcase their new skill sets.
Before software engineering, I worked in an administrative government role that had limited growth opportunities and a high bar for entry but a low skill ceiling — after a year or two there I had already mastered all that I was allowed to do. I didn’t enjoy this admin role.
I have been a software engineer for 5 years now. I started off doing a bootcamp that wasn’t especially useful or interesting before joining companies of different sizes, ranging from 1,000 employees to 40 employees. The barrier to entry for coding is quite high but the skill ceiling is also infinitely high. I am by far not the best at what I do and I have a lot to learn. I enjoy coding.
One thing that I can say I have learned from both of these careers is that I want to be good at my job, and I want recognition that I am good at my job. I have always had a hunger to be as knowledgeable, clever, and efficient in my roles as possible. What I have learned recently is that I also need recognition that I am doing well in these roles. While I do not have my own product or company, there aren’t any metrics for success in my role besides an increase in title or salary. While I don’t think this is necessarily a problem (I don’t think anyone can truly say they don’t care about their title or salary), I have had to learn how to advocate for myself in a way that I haven’t done before.
Being able to advocate for myself and show off my achievements is something that I have had to learn how to do. Outside of having outward-facing projects and customer-impacted work, it can be quite difficult to outline where your successes have been. Software engineering doesn’t have a perfect set of metrics that you can rely on (counting commits or pull requests reveals nothing), so you have to investigate and calculate your own metrics of success. As I work in infrastructure and engineering enablement, my focus had to be there. Things like developer efficiency, security, reliability, and cost savings are what define success for my role. Some metrics can be hard to define (no one should notice security, and developer efficiency can be hard to measure), so doing your own investigations is crucial to measuring your impact.
For example, without being too specific, a lot of cost-saving work was being done at a startup I worked at. As several people were working on this, the only metric that we would see was a total reduction in spend. In order to evaluate my contribution to this, part of my effort in the cleanup was to measure the quantity of things that had been removed along with their individual costs. When it came time to evaluate my impact on the project, I was able to produce evidence of my own cost-saving effort.
Obviously this only works if you’re already working as a developer; advocating for yourself as a junior or new developer can be a bit trickier. Here “success” in your role (or lack thereof) is defined much more by your learning and interest. A lot of my work while teaching is related to project work. I would say the majority of students who graduate from coding bootcamps or schools tend to be on the same technical level. What differentiates a good potential engineer from one with poor potential are skills that cannot be taught: interest in coding, a desire to learn, and generally being a nice and interesting person.
When explaining to these students that the quality of their work or knowledge of Python’s tools and libraries isn’t as important as their ability to show it off, I realised that I was doing the same thing. My technical abilities are quite good and my problem-solving has definitely improved over the past 5 years but, without showing it off, no one would really know.
The use of a brag document has been very helpful to me — not only when it comes time for performance reviews but also in order to reflect over the past year. You can see mine here as an example. A thing I have noticed with junior developers (or junior braggers) is being too modest with their CVs or brag documents. These documents are meant to impress people, and humility doesn’t convey well over a single document. This isn’t to say that you should lie or exaggerate but, rather, that you should advocate for yourself the best that you can. Include all the details you can, mention specifics, highlight what you do best.
Additionally, asking for constant feedback from your colleagues and peers is a good way of keeping yourself accountable for your progress. While it is obviously easier to receive good feedback, it is really the “areas to improve” that will inform your direction. Not to be too start-upy about it, but Radical Candor by Kim Scott was quite eye-opening to me because, as quite an emotional person, it was important to separate feedback on your work from feedback on you as a person. Being able to take negative feedback and accept it as a challenge to improve benefited me greatly in my progress as an engineer.
It is important to keep track of how well you are doing. It’s not like playing a video game or chess where you have an elo score to keep track of how well you are doing; you will need to monitor and internalise this yourself. You have to be your own cheerleader because, most of the time, no one else will be.
I’m sure this is the same in most industries and that I am only coming to this realisation now that I am really thinking about my career trajectory. I am really lucky to have a job that I enjoy and that pursuing better titles means that I have more exposure to parts of my job that I am eager to learn. I feel like for some people this might all come naturally, for me it has been a process of reflection on self-reflection (quite naval-gazing).
Everyone is, in a way, working in sales. If you’ve ever heard your friends complaining that their boss is incompetent, lazy, and directionless, it doesn’t make sense that they could reach such senior positions. What these people do have is the ability to sell themselves. They know how to shake hands, look someone in the eye, and tell you why they’re good at what they do. Clearly anyone who reads my blog is an intelligent person, so imagine if you were that good at selling yourself and the product that you were selling was as clever and productive as you are.