My coding philosophy
I am not precious about the first version. I would rather get an idea into something real, prove it works, and then keep cutting away everything ugly until the implementation feels obvious.
Comments
I do not like comments that narrate every line of code. If the code already tells you what it does, the comment should explain the part that is not obvious: why something weird exists, what hardware quirk forced it, or what future-me absolutely should not “clean up.”
yurie; keep pxe stack below runtime while firmware is activeNaming
Low-level code gets ugly fast when every value is tmp, data, or thing. I prefer names that tell me what owns the state and what the state actually means, even if that costs a few extra characters.
Step in my shoes
I usually start by writing the version that proves the idea can exist at all. It might be too long. It might have duplicated logic. It might have a variable name that only makes sense because I have been staring at the problem for six hours.
Then I run it. Break it. Measure it. Read it again. Pull pieces apart. Rename things. Delete half of it. Move state to where it actually belongs. Repeat that until the code stops feeling like a prototype and starts feeling inevitable.
Ownership
A lot of the cleanup after a prototype is figuring out what actually owns what. Shared globals become contexts. Temporary coupling gets cut. The data moves closer to the thing responsible for keeping it valid.
Failure
I would rather a system tell me exactly where it failed than quietly limp forward and pretend everything is okay. Good diagnostics are part of the implementation, especially when you are below the comfort of an operating system.
The loop
Getting something to work tells me the idea is possible. Everything after that is deciding whether I actually want to live with the implementation.
Related
The rest of the story is on the life page.