The first 18 years of my engineering career were mainly solo. I worked as the “one person IT department during this period.” This included desktop publishing, art direction, and anything else that involved computers. Essentially, whatever no one else could do ended up on my desk. This is both good and bad. The bad is feeling lonely, having no one available to help you out, and identifying yourself as the company’s dumping ground. The good is there were no boundaries in my learning. I often also had no clue what or how to do it, but I often felt I was the only one left to pick up the task. I had no choice but to learn.
During the pandemic at a social hour at Industrial Logic, using zoom, we came to the subject of becoming unstuck when solo-programming as programming is generally considered a team activity. This conversation made me realize that I learned some valuable lessons related to XP during these years.
1. Pairing with a goat works
A big chunk of my time was dedicated to programming. I am not formally trained as an engineer and learned how to code independently. I started in the late ’90s, and the most straightforward “language” to begin with was PHP at the time. By solving problems, I went through the typical evolution of a developer. Starting out with 100% procedural code, at the beginning mixed with HTML, discovering functions and ending up applying design patterns and using OO.
And sometimes, the problems were challenging. Whatever the cause was (lack of knowledge, using a library without grokking it, just being stupid), there were moments when I was totally stuck. Tests kept failing, or worse, became flaky, or I didn’t get something to work. Nowadays, these problems are often solved by discussing the issue with your pairing (or mobbing) partner(s), but being the single engineer in a company, you quickly run out of options. What worked in those situations was walking to the next room where the office manager was. She usually asked why I looked so pained, and I started explaining my struggle. When this didn’t help, I walked outside where a goat was munching grass.
The goat was usually very patient. It listened to me venting my frustration, and once in a while, it raised its head to give me a gentle nod. By explaining my problem to JP the Goat (as I called her, named to the PM of the Netherlands at that time), I often saw the missing bit or the solution to my problem.
2. Writing user stories is useful
Defects were discovered while working on a new feature, and new feature requests were raised. I was the Scrummaster, Product Owner, Engineer, and QA specialist all in one person. Hearing about scrum and agile at a conference around 2008 made sense. I learned about standups, refinements sessions, and sprints… but somehow, this felt awkward when sitting alone in your office all alone on Monday morning. However, what made total sense was using sticky notes to write user stories. I used a whiteboard which evolved over time to a kanban board, with 3 columns (to do, doing, done) and 1 swimming lane. It helped me so much focussing and planning. Whenever a consultant or colleague walked in with a request, I could immediately ask them about the priority and put it on the board for my personal backlog. Breaking up user stories in tasks for myself helped me keep the sense of accomplishment and progress during the more significant stories and keep track of where I was over days.
3. Go slow to go fast
One of the meaningful practices I developed while working soloing was spending time on tooling used by software development teams, even if you work alone. I spent hours setting up Jenkins (Hudson in that time) and trying to get Xdebug code coverage up and running. Reading numerous blog posts on writing unit tests and really investing time in understanding PHPUnit saved my ass many times later. Credit to my colleagues, while they didn’t know why I was spending all that time on tooling, there was a deadline approaching. They quickly learned that when they allowed me to improve my tooling and understanding of concepts, I could deliver code and features quickly when the deadline was approaching.
Bonus
4. Keep the future you in mind to write clear and readable code
Clean code practices are invaluable when you are working alone. Investing time in readability and refactoring is not only applicable when you want to keep your teammates happy, but your future self will also thank you. I usually focused on a single project at a time. As a result, other projects were left alone for months. When I returned to a project after that time, I was so thankful for thinking naming through. Tests usually told me about the class’s functionality, and I forced myself to organize my classes in a relevant project structure. When I applied for my first “real” engineering job, the interviewer was impressed by the readability of the code and all the code being covered by relevant unit tests. He told me he had never seen this before, especially from someone working alone. I told him I had to because there was no one to ask about the code’s intent or nitty-gritty details.
