> I believe programming, in this regard, can learn something from writing: when writing the first core of a new system, when the original creator is still alone, isolated, able to do anything, she should pretend that this first core is her only bullet. During the genesis of the system she should rewrite this primitive kernel again and again, in order to find the best possible design. My hypothesis is that this initial design will greatly inform what will happen later: growing organically something that has a good initial structure will result in a better system, even after years of distance from the original creation, and even if the original core was just a tiny faction of the future mass the system would eventually assume.

I thought this paragraph had an interesting point. Does anyone have experience with testing this hypothesis?

I can totally relate to that. That's how I arrived at Abstraction Logic [0]: Banging my head against the wall (no, not literally), until something gave and I could suddenly see the most simple and powerful logical kernel possible.

This kind of development must be carefully balanced though so that you don't forget why you are making your system in the first place. You need to resolve the tension between your user requirements and your simple kernel, and that's hard. It is maybe even impossible for the particular project you are working on, because of economic constraints, time constraints, or because you don't know enough.

Furthermore, the comparison here with writers is very apt: Following this style of development, you are becoming an artist, and you will probably experience the need to shape your work environment accordingly.

[0]: https://obua.com/publications/philosophy-of-abstraction-logi...

That section stood out to me too. I ended up doing this a few months back while working on the playback system in my video editor Recut. I ended up rewriting that system at least 5 times. I was also learning Rust at the same time, and I had little knowledge of video going in. So it was a loop like: build something, get it working, realize I designed myself into a corner and couldn’t handle some important scenario, go back to the drawing board.

Stuff like dealing with the threads and queues, playing streams from multiple files in sync when they have different frame rates, and managing playback of multiple tracks that each have lots of cuts were some of the things that tripped me up and led to redesigns.

It ended up being a good learning experience and I’m glad I spent the time to rewrite instead of trying to forge ahead with broken abstractions. It’s still not perfect but it’s miles ahead of those first few iterations.

I’ve always found that starting a new project works best when I build the baseline alone, after some design discussion. If it’s too complex a problem to build that way, the fewer and more focused the team, better the baseline is. Once you start adding more and more people to a system, things start going down hill in proportion to the number of parallel work streams. Of course, this depends on how “big” a problem you’re working on and how the problem can be broken down. (i.e divided areas of responsibility in the code base with clear contracts between them). It’s way too easy to lose focus on design philosophy and structure as more people are involved in the actual development/coding.

This is one of the foundational tenets of Extreme Programming

https://asana.com/resources/extreme-programming-xp

When following this process you should strictly adhere to TDD and constantly be refactoring/rewriting code

Funny. I wrote a similar article, with almost the same title, seventeen years into my programming career, after writing my first novel.

https://adiamond.me/2015/01/writing-and-programming/

The huge help that programming gives to a novelist is the practice of breaking down huge, sprawling problems into smaller, manageable, interconnected pieces. As a programmer/writer, you also learn to keep the big picture in mind, so the pieces naturally assemble back into a whole.

Note, that post is over a year old and it looks like the book is available here

http://antirez.com/news/136

I also just realised the name was familiar, it's the redis guy that moved on.

he's next fu cking level as a developer

Programming may be related to one half of fiction writing - the structural and logical facets. There is a whole other half of emotional authenticity and character building that make it far broader and more difficult than programming.

That is, if you want an effective product.

The thing is in programming there is no such “Mom” whose approval will validate the program. It will either run and do it’s job or not. Whereas in writing, you will at least always have your mother in the audience that will say “Sure sweety That’s a novel”

I don't fully agree with this.

If you're writing a video game for example, the emotional authenticity and character building would be equivalent to cohesive mechanics which work well together, graphical quality / aesthetics, even story and level design all require programming to one degree or another. The same can be said for other types of programs like meeting business needs, but I think the video game analogy illustrates the point best.

In other words, the authenticity and character building is how well you're fulfilling the purpose or goal that you set out to accomplish.

The mom is not too different from one's wife who does not code, but always will look at the husband's poorly written code in spare time with awe and love.

Programming is just writing... No difference whatsoever...

Is there any word when programmers engage in some other activity and then realize and rationalize that the said activity has a lot common with programming.

There is a saying: how you do one thing is how you do everything. The commonalities may say more about you than the work you are doing.

Sometimes I wish books and movies were a bit more like software. We have all read or watched something as version 1.0 and thought "that chapter or scene needs to be rewritten". Some things need big changes and not just minor edits.

It would be cool if version 1.0 would be released and get user feedback on what works and what doesn't and then the author or director would make big changes and release a version 2.0.

In some way, that kind of happened with the "Snyder cut", although the story is more complex, in that the original version of the movie never happened, a different movie was made, and the original one ended up being done, but it was also influenced by what was done for the first release and the subsequent reviews.

Nah, then nothing would ever be “finished”. Nothing is perfect.

I’d rather have things released under someone’s vision and then just left alone, than getting random updates, especially from feedback.

I believe Titanic has version 1.1 with better visual effects and correct star positions (lets call it a "change request" from Tyson)

Counterpoint: Star Wars Special Editions.

  you know that writer block also happens in programming

never thought about calling it simply "writer block". spot on

OP, I always thought the 2 processes, writing code and writing an dissertation, where the same activity. Both must be written clearly enough for a HUMAN audience, even though coding is supposed to be read by the compiler / interpreter.

A good text flows in the mind when read, and the reader builds a story in their minds. Of course coding is more complex, because sometimes there is a story inside a story, but... it is always a story.

When asked (usually by students and junior engineers) which class helped me most with my career, I always cite Senior Year High school English (American 12th grade). Mrs. Scott taught me more about organizing my thoughts and structuring a paper (and program) than any CS class I took ever did.

News flash, nearly everything is related to everything, and that’s interesting!