How to SWE (introduction & part 1/n)
I’ve been some form of software engineer for 24 years this month. That’s long enough to have seen multiple transformations along multiple different dimensions. Perhaps I should have waited for 25 years to make it a nice milestone number, but I’ve never been one for aligning with or following rules.
Enough time has passed for me to go from a foolish engineer who didn’t know he was foolish to a foolish engineer who knows he’s being foolish but just can’t help it sometimes. Either way, I’ve learned a bunch along the way and thought I should write it down. Even if that ends up with me being an oldster shouting into the void, writing helps me collect my thoughts and forces personal reevaluation and reflection on those thoughts.
I also recognize that there are lots of different roles in tech, and lots of different roles that computer scientists take on. I’ve spent most of my career with some kind of “software engineering” title. I work on teams that build products.
This is also my personal experience, your experience will differ. And, I speak for myself and not my past, present, or future employers.
Part 1 / n: Write (a lot) of Code
If you don’t like writing code, then this might not be the right role for you. This should follow you through different phases of your career; student, apprentice, journeyman, master craftsman.
To be an effective software engineer, you should write a lot of code. Probably more than you want to. AND, you should enjoy writing this code. Maybe not every line, but writing code is the core competency of a software engineer. Even later in your career, having a strong coding background will help you. It’s quite common for very senior folks to only talk about design and architecture, the senior folks with stronger coding background tend to give better designs and guidance to teams.
In a past life, I was a professor of computer science. I observed a lot of students learning to code and their progression through to graduation. I simply couldn’t assign enough code writing assignments due to wall clock constraints, and the fact that students take 5–6 courses per semester. I was also one of those students, both in undergraduate and graduate programs.
My experience both being a student and a professor; as a student you will never write enough code. In a 4 year undergraduate CS program, you will write less code than you should be writing in steady state 2–3 months on the job. That is a huge disparity.
It’s like showing up for your first professional [insert sport here] game, expecting to start and perform well, but only attending 10% of the practices. You may get lucky and score a [goal, run, touchdown], but it’s unlikely.
So, why write a lot of code. It’s our practice. You will get better at it the more you do it.
This is not to say that you have to write and publish a new app / website / library every month. You don’t have to publish it at all.
Or to quote champion CrossFit athlete Mat Fraser:
I’m gonna do today what other people aren’t willing to. So I can do tomorrow, what other people can’t.
It’s the work that you do when no one is looking that makes you great at something. You simply can’t get enough reps in, if you are only working when it counts.
When I was a student, and early in my career, I wrote a lot of code. I practiced, working through hard problems when nobody was looking so that I could solve these problems when it counted.
As I moved through different roles / companies in the 5–10 year post graduation range, this served me extremely well. I was able to adapt to new environments, to new programming languages, and new ways of thought. That is what allowed me to quickly get up to speed and then transition into leadership.
Mid to late career (yes, I’m counting myself as late career at this point), I have continued to write a lot of code. Much of it is for hobby, on my own time. The overal volume is less now, but the aim is the same. I need to keep my skills sharp, allowing me to perform well on game day.
Sure, I spend more time in Google docs than a code editor these days, but I only got there because of the solid base that I build and many many years of practice.
