02 | 2024 Tomas Günther, Solution Architect & Full Stack 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 actually somewhat surprising that, including our lunch break, we spent six hours sitting around that table, tossing ideas back and forth. Yet time seemed to fly by, and the discussion could easily have continued in the same spirit for several days. We agreed on many things, but naturally, a few divergent opinions emerged as well.
For instance, omitting comments in code sparked strong emotions, whereas elsewhere it was argued that good code does not require explicit commentary. Another notion that divided opinions, at least initially, was this: The creator becomes blind to the complexity of their own code—rather than the author, the quality of code is best determined by the person reading it.
"It was fantastic how everyone was genuinely present and focused on the discussion."
Spending time on something like this might seem a bit odd in many ways. The company's bottom line takes a hit when experts aren't doing billable work, but are instead philosophizing about the obvious in a meeting room. However, this is likely to pay off in the long run. On one hand, one might view this as a refreshing wellness activity complete with evening sauna. On the other hand, sharing thoughts and experiences builds a sense of community among us, which strengthens the company on multiple levels.
Of course, we discuss these matters on digital channels as well, but a change of context brings knowledge to life and sparks thoughts in a different way. I believe that thinking about and discussing the fundamentals improves our professional skills. In other fields, such as sports or music, basics are valued and practiced even at the top level—or perhaps it is precisely at the top level where their importance is truly understood.
For example, in the TV series The Bear, top Chicago chef Berzatto inherits his brother's neighborhood restaurant. The restaurant's operations are chaotic, finances are in shambles, and the staff is stressed. Berzatto steps in and introduces Michelin-restaurant practices: respect for one's work, colleagues, and customers; the importance of details; a focus on quality; and systematic organization. Getting back to basics in that environment as well produces a calm and inspiring work environment for the employees and a high-quality end result for the customers.
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 again is a brief summary of my personal thoughts on the hallmarks of good code:
purposeful and error-free
comprehensible to the reader and easy to modify
efficient, meaning green
unit testable
* Book recommendation: John Ousterhout - A Philosophy of Software Design
PS. While AI tools are fascinating, the above is organic text crafted in Espoo.