Ask HN: Why do I feel anxiety when I'm writing code?

1. We are constantly screamed at on sites like HN that there is a right and a wrong way to do something. It's almost always just a fashion trend of some kind, and the reality is: there is rarely a single "best way", the pros mess up all the time, and even the perfect design will grow haggard with age, and that ain't a long time in this business. Perfect is an illusion, so just try to make some reasonable choices.

1.5. Naming things is hard, but there is no perfect name. Pick a single letter and move on! :)

2. You are replacing something that already works. As you begin your planning, you'll start to notice all kinds of little features you'll have to build out.. the boring minutiae that you didn't even notice the first version did.. and then the scope of work changes, becomes less thrilling, and that can be discouraging.

3. It's always difficult to start from a blank page, especially in a software system where the "method of entanglement" of all the moving parts is such a key design decision. Sometimes it's good to just pick some interesting part and write that in isolation. Then you will get some momentum going and you can move on to fleshing out the rest.

4. Anxiousness sometimes comes from not knowing the full scope of the problem. Try sketching on a napkin some pieces of what you have to do. Try to start from large blocks and decompose. This might help you feel more comfortable committing some code.

5. Maybe the project is just way more boring than you thought. :)

I particularly feel this anxiety when writing code for real time safety/automation/process control systems of plant and machinery.

For me this is as the consequences can be quite visible and quite expensive - many tonnes of equipment or megawatts of power may be involved and you can't just reboot it to fix it once the equipment is damaged. Also a lot of peoples jobs may be impacted, so others are relying heavily on you to get it right.

I find that good architecture/data structures go a long way to allowing a feeling of ease as these enable simpler code to be created. That and use of state machines so the behaviors are exhaustively and unambiguously defined and if well structured then debugging is limited to small parts of the code related to a particular state or transition.

There are obviously certain sweet spots in projects where you're at your best. For me, that is after the initial coding on the project, but before going into maintenance mode. Adding big new features to a project is what I like best.

However when I step into an existing project with a huge amount of code, there's a lot of uncertainty. Did I grok the existing architecture? Will I use the existing code to its fullest? Do I make it better instead of worse?