Programming: Doing it more vs. doing it better

One prolific programmer who comes to mind from this article is Nikolay Kim, author of the Actix projects in Rust, aiohttp in Python, and many other open source projects. The Actix Project has evolved so much over a short period of time. The author learns by doing, with haste.

> People who want to write "beautiful code" are not role models, don't listen to them. They are vain and not productive.

People who push "mostly working" code are hell on earth. Sure you spend 5 hours less on it right now, but it's going to cost literal days or weeks down the line.

How many times have I seen developers push some "good enough" code that they didn't discuss with anyone because it looks good to have XXX commits for their quarterly feedback. They knew "what" to implement but not "how" to implement it or even "why" implement it in the first place, which ends up in hours of useless discussions that would have been avoided by a 1hr meeting before starting coding. How many times have I seen people going for a DB, stick with it for years because "that's what google/facebook/whatever uses" and end up having to migrate everything to another DB because they went to fast and didn't spend 1/10th of the time on analysing their needs and writing specs.

Do you spend 10 years designing a plane and then 6 months actually building it, or do you spend 6 month planning it and 10 years fixing broken, hacky, "mostly working" parts ? What works for school or hobby projects doesn't work in most professional environments, especially nowadays when developers stays 1-3 years in a company and move to the next job leaving a pile of unmaintainable "mostly working" code.

Coding is the last stage of the process, it's the easy part, a monkey could implement the code if the specs and processes are solid.

People who want to deliver at all cost are not role models, don't listen to them. They are vain and not productive. They might be capable coders but they're not capable engineers for sure.

“Programs are meant to be read by humans and only incidentally for computers to execute.” ― Donald Knuth

Yes, exactly this. If you never really think about your coding seriously, and ponder where you should get better at and then do it - you'll never improve! Simply by acknowledging your own mistakes and how you could fix them in the future, let's you build up skill much better than just churning out code day in day out without giving it a second thought.

I've seen the both extremes, the programmers who are so serious about the style of the code that nothing really satisfies them (and consequently progress happens at snail's pace). Then I've seen those, who'll write the ugliest of hacks just to get the thing working and move on. I think there's a deliberate balance between the two, where you feel you're not wasting time on useless things but actually get something done, which you can then comfortably show to your peers without beginning to blush.

And only way of getting there is practise and being mindful of what you are doing. Similar to sports, music - whatever. To know where and how you did wrong is key, often you'll need a very good teacher to show you that. Criticizing yourself works too, but often you either become too strict to yourself or too lenient.

Just starting to code without worrying if this is the "best practise" or not will allow you get into a flow which is much better than over-thinking your approach. Because once you start to do it, like a good warm-up it allows you to see the problem much clearer as you become aware of the problems as you encounter them. Then if you have time, you might want to refactor your solution or just move on the next most important thing. Sometimes it's better to just write awful code to get to that MVP or other important milestone, only after which you start to review your code. Experience will tell you, when is the right time to move fast and when it's good to slow down and enforce a particular paradigm to your codebase.

I have seen way more damage done by the people "mostly working prototypes in hours or days" than people who want to write beautiful code. I understand that fixation to produce something beautiful can lead to paralysis but this is rarely the case. In most cases the prototype grows cancerously and it becomes impossible to fix in quite short time, my advice, listen to the experienced programmers who screwed up more time than you before, even if they seem to be obsessed with "beautiful code".

I have worked many times on ugly and on beautiful code. What I consider ugly is not always ugly for other developers and the other way around.