Habits

I think this article is worth reading carefully:

https://spectrum.ieee.org/lean-software-development

I have been dealing with a bunch of infrastructure software lately, and I have been horrified by how awful it has become. I have decided to call it Franken-ware.

It’s a hobbled-together mess of everything. It has a crazy huge number of half-baked features that are poorly glued into place. It reminds me of the awful mainframe software of the 80s that we were going to replace (but never did). That stuff had less features overall but was just as convoluted.

I see this as a problem of degrading habits. Too many people believe that whacking out more features quickly, even when they don’t make sense, is more valuable than quality and engineering. They value speed over understanding.

Code is always a manifestation of its author’s knowledge. Q&A sites or vibe coding don’t change that; they just delay the inevitable. If the code is a mess, the system is a mess. If the data is garbage, the output is garbage. These things never change (but are often ignored or forgotten).

Good Habits:

• Format your code very carefully; pay close attention to readability
• Refine your code, over and over again. It is never ‘done’. Editing is more important than typing it in.
• Dig into how things work below your code. What you don’t understand will always come back to bite you.
• Anticipate all possible errors, however unlikely. They like to occur just when it is inconvenient.
• Make the code easier on the users and harder on yourself. The opposite is cheating.
• Never blindly throw in a block of code. If you don’t fully understand it, you can’t use it. If you check in the code, it implies that you understand how the code works.
• Read a lot. Manuals, tutorials, textbooks, articles, blogs, etc. The most important skill you can learn is to be able to absorb tonnes of knowledge quickly and correctly.
• Control everything you can control. Otherwise, it is out of control.
• Start with everything locked down tightly. Only loosen the locks when you know what you are doing.
• Pay close attention to your assumptions. Knowing what they are will tell you where the most likely problems will occur.
• Spend time to make any interfaces look good. They are how you are presenting your work to the world. If they are ugly ...
• If you don’t know, ask questions. Ask lots of them, even if they are stupid. Write down the answers, so you can try not to ask the same ones over and over again; people find that annoying.
• Beware of shortcuts. Nothing is easy in development, so anyone promising that is up to something. Nothing is fast in development; what gets done quickly will fall apart quickly.
• Always follow suit. Make your code fit into the codebase, your data fit into the database, your interface fit into the software around it. Be as uncreative as possible, save that for actual problem solving, not implementation details.
• Get to know your users. Have empathy for them, talk to them, meet them, etc. The more you understand about the problems they are facing, the better your solutions will be for them. It’s all about them.
• Don’t cave under pressure. Keep an open mind, but once you decide that some specific work needs to be done, and how to do it, do it to the best of your abilities, no matter how much noise surrounds you. Later, reflect on whether it was actually a good choice, since that will help you grow.
• Mastery comes from being able to precisely estimate the work involved and get it done as predicted. If you are experimenting, you have not mastered it yet. It’s software, it is okay to have not mastered it, just don’t fool yourself into thinking that you have; that blinds you to opportunities to improve.

Once you get going, improving your habits is usually far better than lightly learning new technologies. They are long-term abilities that reduce the friction in your career.