Raw thoughts - not for kids

Think while eating, think while walking to the office, think while drinking that heavy black mud of cappuccino made by the machine on the desk in the kitchenette, think while watching at the monitor displaying my favorite IDE or code editor with a blinking cursor. The idea materialized in my mind and I see it as clear as a picture sitting in front of me, I start drawing that UML diagram using PlantUML. A few minutes later, I have a simple drawing that is almost identical to the one from my head, but this isn’t going to work, no, it needs some more thinking. Going back to thinking.

Software Engineering is thinking, is reading, is planning how to build that solution that needs to work, to not crash, to be modifiable and understandable by other humans. It needs to be readable because reading code takes more time than writing it, so I plan for an easy readable code. A readable code is divine, but how to determine that a piece of code is readable is a very tough task because every brain thinks differently and sees things differently, everyone filters the information through a very complicated filtering mechanism which is created by all the events in life from the moments they are born. I need to read books, to read open-source code, to read other people’s code solutions on programming challanges. By reading more I can find a pattern of what is more readable and what is less.

I am noticing it’s badly written, it’s complicated to understand, the structure of the code makes me feel silly. Am I silly or the code is bad? Is there an architecture? Of coure there is, every project has an architecture, formal or informal, everyone knows about it or no one knows, but it exists, it’s there, in the code and tools that are used to make the project a real thing. I need to make an effort and understand it first before adding new ideas and patterns. A big project has reasons for having existing bad code, understanding reasons is crucial because it helps at growing the project in the right way. There are tools for digging reasons, I have to use it, git log -S, pickaxe it’s named, because I dig with it, discover, understand. Code archeology ⎯ so to say ⎯ is a very useful technical skill to own.

I’m learning the tools I use daily, I need to use them with ease, and the first thing that gets in the way is touchpad and mouse, it’s the inability to use keyboard to complete a task. Keyboard shortcuts is a must learn for every daily tool: Xcode, VSCode, Thunderbird, Firefox, Simulator, MacOS, Terminal, anything. Knowing shortcuts saves me from using the touchpad which is imprecise, easy to miss the small icons and buttons. I can use the keyboard without looking at the monitor, I can type fast, I can automate my brain to use the shortcuts, this is much more productive than using the mouse.

Back to my thinking, how to make things better, simpler and how to apply the best practices learned other years of practice, apply what authors like Steve McConnel, Martin Fowler, Rober C. Martin is teaching us in their books. Not that million of articles that are 5 minute long read, written poorely and covering just the introduction of a topic. It takes time to get from the initial design to a great design, it takes effort to integrate the new design into the existing one. Making something functional is an achievement, but then, why am I stopping at that first achievement? Why don’t I go further and optimize the functionality, make it better, smaller, easier to understand, why stop at the first? Because first achievement is stronger, it creates stronger emotions making me have a complete day. And it’s a waste of effort to go and improve an already functional thing, what if improvements will break functionality? Yeah, the fear of breaking things is strong enoght to block me from thinking.

I will ask why, then again ask why. Never stop asking. I can even question the most fundamental things that I do for years that I think this is the only way. But things do change. As time passes, new ideas emerges, new technology are developed, existing ones gets outdated. “Change is the only constant”. Changing requires thinking, deciding on a path forward, choosing one way out of many. The life is made up of choosing between trade-offs, and there will never be a good or bad choice, however there is a better choice for the actual situation, for the existing context, my existing knowledge, my friends and coleagues and many others; so I have to think about the choice I am making.

The brain needs to think to remain healthy, I have to give it exercises or challanges. I should not stick to a single practice, a single rule, a place or an object. I have to get out of comfort zone and think how to transform myself to fit in the new environment. Try new things, push myself to the limits, find my limits.

Software engineering is thinking.