I thought I was the only one who did that.
It is scary when something "works the first time", because it probably doesn't.
Over time, everything important gets a full rewrite or four, but only piece by piece.
Generally I assume in an implementation vacuum the long term spec isn't even well defined so I would never just rewrite something immediately.
Sometimes if a module proves difficult to amend I will start over from scratch. But usually by then I have tests and use cases I am confident in.
I love the idea of people doing these rewrite series though... not trying to be evangelical. Just describing a different kind of rewrite.
But those first efforts were indeed awful, and those were preceded by even more false starts; it took 2-3 years of iteration [not full time!] to get to something that was good.
(Simple assemblers are, well, simple. But if you're in an industry where it's common to write a ton of assembly -- like the early gaming industry was -- you start gauging assemblers by the creature comforts they provide, such as a decent macro capability, cross-reference and listing support, performance, and support for chip manufacturer assembly syntax).
I've started over completely, at least 6 times, trying entire new languages, entire new feature sets, entire new hosting paradigms.
Each time I try again, I get closer to something professional. Each time the hacks get a little too messy and realize I'm out of my depth.
But lately less and less changes with each rewrite. I am able to pull entire chunks of code in from a previous iteration and have them work well, with little modification.
The process of writing software that's beyond one's ability is fascinating.
I do that too. And I generally avoid refactoring anything until the pressure it's putting on the rest of the code justifies it. And one of the things I think isn't appreciated is me in the future probably will know better how to rework the code than me now.
Thinking I’m dealing with an Object A when I have object B.
Not realizing that nil is a valid thing to be returned from code that at first glance shouldn’t return nil.
Plus, accidentally writing super slow n+1 queries. And accidentally loading too much data.
Both give you super fast feedback and a lot of issues can be solved before you finally launch your software for the first time. But neither will save you from bad design or misunderstanding your requirements.
It's kind of validating to hear that Joe had a similar workflow to me.
I'm sure I use more than two fingers but even to increase APM I focused on getting more for my keystrokes rather than more keystrokes.
I figured my tendency to start and restart things is just because I'm a terrible programmer. Good to hear I ain't alone :)
I feel like I get more "right" the first time now, but man I still see a better way once I'm done nearly every time.
This may be a gross exaggeration, but I believe we'll look back on programming during the mid to late 20th century like we do for physics in the early to mid 20th century. We'll marvel at the amount of talent alive at the same time.
Dijkstra submitted a letter to the editor of the Communications of the Association for Computing Machinery (CACM) that he titled "A Case Against the Goto Statement".
Niklaus Wirth was editor of CACM at the time, and he changed the title to the infamous "Go To Statement Considered Harmful".
Here's the story in Dijkstra's own hand (scroll to the last page of the PDF):
This is a good reminder that when you read an article with a clickbaity title, don't blame the author, blame the editor.
In a parallel culture timeline it is easy to imagine the announcement of someone soon to die (when possible of course), and all these kind words of appreciation from strangers being passed on to the one dying. On the other hand, I guess that the time is better spent with close family, but regardless, I hope that he somewhat understood his importance to so many people all over the world.
Brave and dignified to the end:
I have never written a line of Enlang, but as I've seen the advantages of loading binaries at run-time as swappable components I get an inkling of the beauty of the idea. It's not near so easy in C# as it appears to be in Erlang.
Also, I nominate the name of programmer Valhalla to be called "Greenfield."
Agreed but I suspect that this home directory as exposed on the NFS might be appropriate.
It's a great loss.