Discussion on good code
02 | 2024 Tomas Günther, Solution Architect & Fullstack Developer
A few months ago, in a Slack chat, I half-jokingly threw out the idea that we could have a code philosophy retreat next. The idea struck a chord with several of my colleagues. Later, at the autumn Kipinä Symposium, we talked about future topics such as company trends and artificial intelligence, but also philosophy of code. Some even dreamed that we could make a statement to the world about how software is developed.
In January, we gathered almost half of Kipinä for a day at the boardroom table just to talk about the basics of programming and quality digital development. We collected the topics to be discussed beforehand and narrowed down the day's topics to "The hallmarks of good code 2024" and "The code lifecycle". The discussion flowed on in a good spirit, sharing experiences and ideas, and sharing ideas with others. This is to be expected when people have years of experience in different technologies, industries, customers, projects, successes and failures.
It was a bit of a surprise that we spent six hours, including the lunch break, just sitting around the table, tossing and turning. Still, the time seemed to fly by and the conversation could certainly have gone on for several days in the same spirit. We agreed on many things, but there were a few points of disagreement.
For example, there was a lot of emotion about not commenting on code, while on the other hand it was thought that good code does not particularly need commenting. This idea also divided opinion, at least initially: the author is blinded to the complexity of his code - the quality of the code can best be determined by the person reading it, rather than the author.
"It was great to see how everyone was really present and focused on the discussion."
Spending time on something like this is certainly a bit odd in many ways. A company's bottom line is undermined when experts are not on billable work but philosophising about the obvious in the boardroom. However, this is probably beneficial in the long run. On the one hand, one might think that this is a refreshing tyky activity with an evening sauna. On the other hand, sharing ideas and experiences creates cohesion between us, which strengthens the company on many levels.
Of course, we discuss these issues in electronic channels, but the change of context enlivens the information and stimulates thought in a different way. I believe that thinking and talking about the basics will improve our professional skills. In other fields such as sport or music, fundamentals are still valued and practised at the top. Or perhaps especially at the top, they understand their importance.
For example, in the TV series The Bear, top Chicago chef Berzatto inherits his brother's card restaurant. The restaurant is chaotic, the economy is in the toilet and the employees are stressed. Berzatto steps in and teaches the Michelin restaurant manners: respect for your work, your colleagues and your customers, attention to detail, focus on quality and discipline. Even in that environment, starting with the basics provides employees with a peaceful and inspiring working environment and customers with a high quality end result.
Similar issues are also important in software projects, because we software people are human too. Investing in automated testing gives developers the confidence to make changes to the code. Respect motivates and relaxes towards better results. Appreciating details and creative problem solving improves quality. Clear goals are important. Straightforward communication and professional, sensible practices and tools make it more efficient and easier to achieve goals. At Kipinä, we call this way of working Senior Tech Leadership, where a coaching approach to digital development brings more value to our customers.
Thinking also requires breaks.
Here are my thoughts on the hallmarks of good code:
appropriate and accurate
understandable to the reader and easy to make changes
efficient or green
unit testable
* Book tip: John Ousterhout - A Philosophy of Software Design
PS. As interesting as AI tools are, the above is an organic text from Espoo.