4 Practical Software Development Skills from Competitive Programming
Shared from my personal experience as a software developer at Volvo Cars.
Hello there!
Welcome to Algorithmically Speaking, where we discuss topics on the intersection of Computer Science, Software Engineering, and life.
Today, I’ll share a unique perspective—the set of skills I honed during my competitive programming years that seamlessly transitioned into my role as a software engineer in a tech company.
Training for these complex competitions for over five years alongside different team members allowed me to develop a sense of teamwork that has always been instrumental in my impact when joining a new team ever since I started getting paid for generating lines of code.
I have discussed the pros and cons of fostering a competitive mindset in computer science students in the past, but today, I’m going to focus only on the positive side and share some insights into both technical and non-technical aspects of software engineering dynamics.
Buckle up!
I can do better code reviews
The first aspect of software engineering directly impacted by my participation in competitive programming contests is my ability to do code reviews surprisingly fast and accurately.
Having spent years debugging code in situations far more stressful than the everyday office job in a modern tech company, I’ve become accustomed to reading other people’s code.
Not many have this skill as soon as they get their first job as a software engineer or similar. It is a fundamental tool in your toolset because most modern software development goes through a phase where other humans need to look at other humans’ code and approve it or provide feedback on why it is not good enough.
One principle that each of my competitive programming teams and I applied was that everyone should try to code as similarly as possible. This is extremely useful, and it is a practice that I still try to promote today in my current team of software developers.
The reason is simple: the more standardized the code in our codebase, the less effort it will take for a new developer to dive into it and make new changes.
The best place to work your way towards a common way of coding is during code reviews. Your suggestions can shape how you and your team write code in the future, allowing you to be more efficient in the long run.
I can be the ultimate teammate
This is my opinion: the team's results outweigh the individual's results.
Of course, when preparing for an upcoming competition, I trained individually. I would spend months solving complex problems in game theory, computational geometry, and other related subjects. However, my individual preparation had one ultimate goal: to contribute as much as possible to the team I was a part of.
If the team required me to take on a specific topic, like dynamic programming or greedy problems, because either I was more inclined towards those topics than my teammates or it made more sense that they would focus on different ones, I would do it. Why? Because it generates the most value for everyone.
Distributing topics among ourselves resulted in everyone knowing their strengths and weaknesses and those of their teammates during live competition. This provided an enormous advantage, as we could quickly assess which of us was more suitable to tackle which problem.
This is still true today. A software development team is no different from my competitive programming team in that it consists of people with various skill sets. Knowing how to distribute the topics among team members and finding where you can be most helpful is crucial to making your team stand out.
I do performance-oriented development
When developing software as a team, there are many aspects to consider when creating a solution to a particular problem. In general, my team and I tend to agree that simple is better than complex, and we focus on the code's readability to make it easier for ourselves when we inevitably have to revisit this piece of code.
Ahh, but sometimes, it's all about performance optimization, and there, I usually have a slight advantage over my peers.
Having spent over five years solving complex optimization problems, this is my natural playground. Solutions that optimize running time or memory consumption come more easily to me than to my colleagues.
You only have to look at an example of the type of problems that usually appear in these competitive events to see that the constraints in time and memory are designed to make the contestants squeeze every inch of their brains trying to come up with solutions that fit these requirements.
Highly performing code is hugely relevant in fields like embedded systems, and mastering the art of optimization can open a few doors in your professional career.
An extra challenge is creating high-performing code without sacrificing too much of other essential aspects of software development, like simplicity and readability.
I am comfortable with pair programming
Pair programming consists of two developers sitting on the same computer working on the same problem. One coder is doing the work, while the other monitors the code closely to detect mistakes or for learning purposes.
This technique is advantageous in modern software engineering, especially when working on critical tasks or sharing knowledge across a team. You compensate for the fact that you are putting two persons to work on the same task by the profit you get when your critical feature is implemented extra carefully or when a team member starts becoming more proficient in specific types of tasks.
This was my everyday life as a competitive programmer. You participate as a team of three contestants but only have one computer to do all the coding. So, while time management was a crucial skill to master so that we could optimize the “computer time,” sometimes we just teamed up around the computer to work together on a tricky problem or just because we wanted to get all the implementation details right for a solution when we were running out of time.
When I started working as a software engineer, I realized people were uncomfortable doing pair programming. Maybe they feel insecure about you judging their coding abilities, or perhaps they are more used to working alone and receiving feedback after having finished some functionality instead of while they are working on it.
I did not have this issue, and I can tell you it makes a huge difference to call someone by your side and explain your thoughts while you generate lines of code. The immediate feedback feels nice. The fact that you can explain your ideas while you code allows you to fully commit to understanding the task you are working on and, ultimately, performing it better.
Conclusions
To summarize:
Code reviews are still a fundamental part of software development, even in the age of AI.
The results of the team should outweigh the results of the individual.
Clear and concise code is excellent. Clear, concise, and highly performant code is even better.
Pair programming is an interesting way of collaborating within a software engineering team. Give it a try.
And that’s it for today!
Did you like this article? Make sure to 🧡 click the like button.
Is there something you want to add? Make sure to 💬 comment.
Do you know someone who would find this helpful? Make sure to 🔁 share this post.
The latest from Algorithmically Speaking
Here is how I can help you further
Are you interested in my book on graph theory? Check it out.
Are you interested in sponsoring this newsletter? Please reach out.
Get in touch
You can find me on LinkedIn and GitHub.
This newsletter is funded by paid subscriptions from readers like yourself.
If you aren’t already, consider becoming a paid subscriber to receive the whole experience!
Please let me know if you want me to cover any specific topics of interest to you. I’m more than happy to do so.
Have a great day 🌞,
Alberto
Great article Alberto! As you said, it can be tricky to do pair programming if you are not used to it, but it can be quite effective if you approach it right.
Thank you for all the tips