I received some great feedback on my post about software engineers not practicing. A friend of mine asked what that would actually look like in practice, which I realized I hadn’t explained. Probably because I haven’t totally figured it out myself!
But I’ll share what I’ve tried, and what I think makes sense.
What I’ve tried
One thing I tried was LeetCode. It only lasted for a few weeks. Although I have mixed feelings about it like many other people, I think it can be useful as a practice tool rather than an interview evaluation, since LeetCode offers leveled problems in various languages, making it quite versatile. Just getting teed up with random problems and getting that raw programming practice is helpful.
If LeetCode isn’t your thing, there are plenty of other programming competitions and challenges out there. I haven’t tried it but a lot of people seem to like Advent of Code.
There are also things like CodeAcademy and Exercism, which I have used. I think they’re good tools, but somehow they do feel a bit aimless in my experience.
Another thing I’ve tried is Anki flashcards, but have struggled to make that habit stick – even so, I still believe in its potential. I’m bullish on AI to help me streamline this, and I see some really neat tools (ex: Plato) in the spirit fairly often.
Additionally, I’ve spent a lot of time deliberately practicing typing to improve my efficiency. I like TypeRacer and SpeedCoder.
What I’d do for individuals
Ok, so at the individual level, I think you want to have drills or activities that help you continually improve or maintain your skills, by having you solve problems, or forcing you into retrieval. I imagine you could approach it almost like a bodybuilder: they focus on different muscle groups on different days or incorporate various types of workouts depending on their cycle.
For a software engineer, there are a lot of skills you need to have, but I think you could just try to choose three or four broad ones, almost like the muscle groups: let’s say writing code, reading code, talking about code, and debugging. Or you could do it based on languages: Tuesday is JavaScript day, Wednesday is CSS, and Thursday is SQL. And then within those groups, you would have exercises, like how when you’re working on your chest you might do dips and bench press.
So for example, maybe the skill is Python and you want to know your dunder methods inside and out. Or you want to ensure you can implement various searching algorithms from scratch. I’m just spitballing here but you get the idea.
One key to learning that researchers have found is interspersing, so I’d try to mix it up. I wouldn’t spend all your practice time on say… mastering elegant async code or regular expressions. Instead bounce around a bit.
What I’d do for teams
Alright so how about at a team level? I think that’s even more interesting, because even if it’s not commonplace, I know there are engineers who do a lot of practice individually. I’m not aware of any teams that practice. The vision I have is for engineers to practice together almost like musicians in a band or athletes on a sports team. Like how basketball players have their individual drills, but then have the team ones too.
So for example, a team could do mock exercises that cover different aspects of the job, like design discussions or breaking down theoretical data models. Maybe you practice techniques like user story mapping or event storming with your team. Then when it’s time for the real deal, it’s not like it’s everyone’s first time doing the activity in a year or even at all.
Additionally, you could do those same individual challenges at the team level. You could take a LeetCode exercise and pair-program, or practice those regular expressions or command line fu together. This approach not only motivates everyone but also encourages mutual support, much like a study group.
A team might find greater benefits from this than going through the motions in a daily standup! Who knows.
In conclusion…
So, I admit I don’t have a foolproof plan for putting this into practice – maybe that’s why I didn’t touch on it in my initial post. However, it’s something I’ll be pondering more and hopefully develop a more concrete strategy. If you have any ideas or suggestions, I’d love to hear them. So, that’s all for now. Catch you next time!