A friend of mine who is earlier in their career recently asked me:
I’ve been curious - how did you learn and improve as a software engineer?
Did you do a lot of learning outside of work?
I thought the answer might make an interesting blog post, so here it goes.
When looking for work, I take the job where I think I can learn the most. As an intern, I was choosing between a full TDD shop using Ruby (my favorite language at the time) and a software consultancy where I would be in different organizations using different tech stacks. The Ruby job paid $5k-$10k more. I chose the software consultancy, where I worked on C#, Excel VBA and PHP. The later two were not glamorous tech stacks, but the projects were amazing and I learned so much. I returned to that company after I finished my undergrad, and continued to work in diverse tech stacks, industries, and organization sizes. After that job, I was not afraid when someone said: "Please get this application running. We have no documentation, no contact with anyone who wrote it, and we don't know the database password."
The next biggest thing I can think of about learning is that I don't care about what I "should" be learning. For example, I was never interested in networking. I found computer architecture and compilers interesting, but networking was just boring for me. So I didn't bother learning it directly, and just picked it up as needs arose. On the other hand, unit testing really gets me stoked. In the Excel VBA project as an intern, I figured unit tests would speed me up. I took four hours to write a minimalist test runner, and started unit testing my VBA. Next week, I took another four hours to add some missing features to the test runner. Those eight hours were on the clock (and billed to the client) because I could justify that it would speed me up. (I had data to show that the manual testing what costly and error prone for me, so the 4-8 hours was mathematically justified.) That's an example of following my curiosity, and of learning on the job.
Recently, I had to learn Angular at work. I've always used React or Preact when I'm doing something that warrants a front end framework, so there are some paradigm shifts for me. There is a specific development tool that my teammates and I wished we had, and I could imagine how to build it in Angular. So instead of watching YouTube videos and doing tutorials, I just built the tool I wanted using Angular. It was slower than if I used React, but it meant I was learning while I built it. It was easy to stay motivated, because each week in our retrospective we noticed how badly we wanted that tool. It was also easy to prioritize what parts of Angular I needed to learn: whatever is keeping me from cranking out the next feature.
We now use that tool daily, and I think my code is garbage because I now know so much more about how I should have done it. That's a great outcome: I've learned the tech stack, produced something useful, and had fun doing it.
There are some things that aren't well suited to project-based learning. Architecture, design patterns, development philosophy, etc. For those things, I read.
Years ago, I created a Twitter account to follow authors of textbooks I liked. I listened to tech podcasts which interviewed authors and other interesting people, and I followed them on Twitter too. Through these channels, I would discover new books as they are being published, and would buy physical copies.
Sometimes, I had no interest in reading text books. Then, months later, I would get stoked about one and read it on the train for a while. In some jobs, I would take 30 minutes in the morning to read at my desk or in the parking lot.
I started writing on Twitter to keep a record of interesting things I was learning. Later, I started this blog. This exercise of summarizing and publishing something about what I'm learning has been helpful. Sometimes, I get some feedback from someone on the internet that helps with my learning. Every time, the process of writing helps clarify my thinking.
It's hard to know in advance what things will turn out to be quite useful and what things will be boring, so I try to not think too much about that and just write about what I'm learning and what I think is interesting.
I'm always on the lookout for opportunities to learn on the job. I'm looking for situations where the fastest way forward is for me to learn. A good example of that is the area of Domain Driven Design -- the social and technical practice of aligning our language and code between customers, developers, and other stakeholders. I first applied it at work by facilitating a "domain modelling" session with myself, the other developer on the team, our manager, and two user experience experts who had just completed some user studies related to the product we were designing. We had a multi-day meeting scheduled for us to review the findings and to brainstorm about the product.
As the discussion progressed, I saw an opportunity to use some of the modelling techniques I had been reading about. I took notes on the whiteboard like I had seen in the textbook. The notes I took helped crystalize the conversation, and we started diagramming together on the whiteboard. The approach led to some really critical questions that we likely would have overlooked if we were just talking. That diagram became one of the key design documents as we went into our development.
There have been many instances like this -- some technical, some interpersonal -- where there is a moment of "crisis" (in the classical sense) where I see an opportunity to suggest something that I have been learning. As much as I can, I take the scary step in those moments to speak up and propose the idea. (Or, as in the anecdote above, just try it out and see if folks like how it's shaping up.)
You can imagine a Venn diagram of things that are good for business and things that I'm curious about. I try to work in the middle area, so my employer pays for my curiosity. It's win-win, because when I'm pursing curiosity I work with an intensity that no compensation could induce. A lot of my career development has been about trying to find alignment between what innately interests me and what someone's willing to pay for.
A lot of these things require getting myself emotionally involved in my work. I have chosen to embrace the fact that I like my work, but I'm wary that I would make my work my life. I think often of that opening scene in Flubber when Robin Williams' character sends a floating digital video screen to represent him at his own wedding because he can't leave his inventor's workshop.
For my whole career, I have kept a timesheet. I use it to make sure I don't overwork. Some days, when curiosity strikes, I work late beacuse I want to. This is the "emotionally invested" part. But then, I make sure to take off early later in the week. When I'm feeling nervous about leaving work early, I review my time tracking report (and occasionally send a screenshot to my boss). "Hey, I've already worked 42 hours this week, I'm going to take off early for the weekend. See you Monday!"
One of the things I look for in a job is that the hours can be a bit flexible so that I can pursue my curiosity when it strikes, and attend to the other areas of my life at different times.
The reason I mention this as part of this post is that I have described lots of "over and above" things I do to learn -- but it's important to know that I offset that by being "under and below" to compensate.
The bottom line for me is that I introspect to see what I enjoy and pursue that. I end up doing a lot of self-directed learning as a result, but it's often driven by curiosity rather than self-discipline. I'm OK with leaving a textbook half-ready or a hobby project unfinished. At work, when I discover that I'm not learning much in my current role, I look to change roles (either internally or in a new organization). When I want nothing to do with computers, I log off early and go do the other things I enjoy instead.
Written 2024-05