I do this:
While programming it pays off to stop and think about the code. I call this, thought driven programming.
If this helps a few new devs who don't have access to a good mentor (because, say, their mentor makes assumptions about what's obvious..) to tell them about this idea then it's automatically a useful post.
Not every developer is blogging their best practices. If you want to see them and learn from them, the best place to look is in the code.
Honestly I think we should be reading at least 10x the amount of code we write. For every novel an author writes, how many novels do you think they read? Certainly more than ten. Why shouldn’t we do the same? In a world awash with open source code, there is really no excuse not to be reading as much of it as possible.
- Working out what it actually does, and why
- Working out why somebody *wrote it in that way*
Maybe it's just me vOv
I've found this to be a really good way to learn from bugs. There is something in the act of writing it down that makes the lessons of it stick better in my mind.
More details here: https://henrikwarne.com/2016/06/16/18-lessons-from-13-years-...
“Thought-driven programming” is a good idea, of course, but are you thinking in an effective and productive way? Are there approaches you can use to be more effective? I hope you agree that there might be some value in identifying and teaching such approaches.
It is the equivalent of articles and videos on bullet journaling that you find everywhere, portraying it as the silver bullet to becoming organised. "12 ways to organise your life". It might work for some, it might not for others.
Maybe you manage to work with only people who can write down their thoughts coherently. But that's the rare exception and not the norm.
This is exactly what I mean with something becoming a dogma when you call it 'xyz driven' programming. You are painting a picture where taking notes while programming is a requirement of being a good programming. I am saying that it doesn't have to be.
Peter Buwalda is a Dutch writer who takes multiple showers a day. He says it helps him overcome his writers block. There is also some science behind this; it turns out your senses will be so busy with the steady flow of sound, the feeling of the water and the fact that there is no visual distraction that you can focus on your thoughts better. He isn't the first to realise this, hence the term 'shower-thoughts'.
So, one could argue, 'shower driven programming' is something we should all do. Installing showers in offices for this purpose or expecting people who work at home to take multiple showers a day in order to focus would be nonsense, but then I could also counter by saying "Well maybe you manage to work with people who can focus without taking constant showers, but that is not the norm."
Ridiculous right? So why isn't it ridiculous to demand that people take notes when programming?
Some of the replies on my comment have been along the lines of 'will someone please think of the children!' with reference to junior programmers. What junior programmers don't need is yet another dogma by which they should 'drive' their development.
It would have been completely different if the 'post' would have been 'Taking notes while programming can be helpful'. That strikes a completely different chord, namely, a helpful one. The word 'driven' does what you demonstrate: it makes people feel inferior when they don't do whatever the given driver is.
Who, exactly, is demanding anything? You're way overblowing what is just a useful suggestion from someone who probably realized that would have been useful earlier in their career, and hence is trying to help others.
It's "log driven" because the logs, when read back, direct what you work on. Making that title to be some sort of mandate is inferring something that, frankly, simply isn't there.
"It's surprising how much objectionable you find in..."
It isn't much, it is just the one word that I find wrong. The comment you are responding to is an analysis of the effect of the chosen wording as demonstrated by @thachmai.
The semantics of the word 'driven' here ARE turning the given workflow into something that should be adhered to. If this weren't the case the word 'driven' would have no meaning and could thus be left out. Which would have been the better choice.
Furthermore, if you look at the article itself you can see that the whole tone is in line with my feeling about the title:
"The worst thing you can do is to interrupt what you are currently doing in order to fix the new problem. Instead just write freeMyObject() and don't care, but at the same time, open a different editor, and write:"
This doesn't come across as "Do you ever get distracted while programming by small pieces of irrelevant code? Try keeping a todo list to keep track of little cleanup so that you can come back to them later."
The author seems to think that you are a bad programmer if you don't take notes while programming and cleanup things you find along the way. @thachmai picked up on this and repeated this frame in his reply to my first comment. I got excited by this as it is exactly what I meant.
Words matter.
“-driven” doesn't imply demand, it implies the center of a given workflow. antirez is stating that this approach (which is more than just taking notes, since taking notes just means “writing stuff down” and says nothing about interruption) boosts productivity, and that it is centered around the process of stashing thoughts and observations without interrupting the present task. He also outlines why he thinks this is the case.
You are mischaracterizing the blog post by underspecifying what it says, then attacking the mischaracterization… I'm not sure that approach tracks with your claim to care about semantics. It's not just words that matter, it's also how they're collected into titles, sentences, paragraphs, documents, and how they exist in their broader context (software industry parlance, in this case).
This 'article' explains the trivial task of keeping track of todos and separating main and sub tasks. Something that I most people know how to do. 'Centralising' what we do around the written word is what separates us from animals and you find it everywhere.
I find coming up with a name with the word 'driven' in it for such a common thing somewhat grandiose. That is my critique.
It sounds similar to Rich Hickey's famous concept of hammock-driven development.
One of the (painful) things I learned and continue to learn once I got into tech coaching is how much stuff we do without thinking about it. It gets into muscle memory and it's gone, as it should be. This is one of the reasons mobbing is so successful -- and why it doesn't make a lick of sense to anybody who codes for a living.
So no, there's no level of detail here that I think would be too much. (It may or may not belong on HN, and there's a question around how to organize this detail so that it's useful for folks, but those are different questions from whether or not it has value)
1-star commenters will say they learned nothing new, while 5-star commenters will be happy they found knowledge from experience enginners in (kinda compact) book form...
It's weird. I did a blog series "Program F# like a stupid person". My point was 1) everybody makes mistakes, and 2) with the right attitude, you can plow through and make really cool complex solutions for folks. You just have to stick with it.
I don't think it was very popular. For the internet crowd, who only only have ten seconds to skim the material, "Program F# like a stupid person" became "Stupid person programming F#". It was just far, far too easy not to grok it. There are those 1-star folks.
A few did. Maybe 10%? Out of maybe 300 readers I got 6 or 7 people who absolutely loved it. 50 or 60 got it but didn't need it, and the vast majority didn't like it. They thought it was a Bad. Thing. They wanted tech porn. "New cloud-based logging app processes 14 Trillion records per nanosecond! Now with graphs!". That's their kind of story, whether or not they're processing one record per hour or not. It just feels cool. I get it.
I would love to find a way to cut through that noise and help people. I've thought about twitch, but that almost seems too unstructured. There's a way of organizing and presenting this material that I haven't mastered yet. It'll be fun to figure out.
antirez shared a successful methodology for programming. He gave that methodology a name. It is helpful to name something when communicating the idea to others.
Examples include Cory Doctorow and Ted Nelson.