Live data from Hacker News

Log driven programming (2013)

antirez.com

41–50 of 69 posts

Re: Log driven programming (2013)

#41
For those unaware, the author of this article (Salvatore Sanfilippo) is a prolific programmer and leader in open source. He's been very productive in this role, authoring systems that many use today, such as Redis.

Obviously, Salvatore didn't invent a new creative workflow that he's branded "log driven programming". His intent with this article more likely was to share with others how he works productively. I can imagine that people asked him how he gets so much work done, considering how complex programming is, especially low level systems programming in C.

While the article was written in 2013, it shares timeless advice.

Re: Log driven programming (2013)

#42
post #31

How is something as frivolous as taking notes while programming, which many people do, worth a blog post and a mention here on HN? Let alone turning it into some dogmatic principle to work by, by calling it 'log driven' programming. What is next? Keyboard driven programming? 3-monitor-driven programming? I do this: While programming it pays off to stop and think about the code. I call this, thought driven programming…

Its not just taking notes. Its a common pattern while fixing bug, you encounter a code path that with a 3 minute time you can make it so much better, but should you continue on your original plan or take 3 minutes to make the code better is the question. The blog says don't spend time on diverging the original plan instead mark it for later. Another good name would be "breath first traversal development"

Sure, or, the name can be left out and the title could have been 'How I use notes while programming'. It doesn't need to be turned into a named concept, because it isn't a concept, it is just some advice that is so shallow that I question its relevance to HN.

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.

Re: Log driven programming (2013)

#43
post #5

https://orgmode.org/manual/Capture-_002d-Refile-_002d-Archiv... > An important part of any organization system is the ability to quickly capture new ideas and tasks, and to associate reference material with them. Org does this using a process called capture .

This, and it's something baked into Spacemacs (easy to replicate with a vanilla Emacs, thought): working within a projectile-initialized folder, hitting po will open a TODO.org at the root folder of your project, where you can write anything you want (including inserting an Org-mode link to the file/line you were editing), and save/switch back to your file in a handful of keystrokes.

Downside: you end up with too much notes.

Re: Log driven programming (2013)

#44

How is something as frivolous as taking notes while programming, which many people do, worth a blog post and a mention here on HN? Let alone turning it into some dogmatic principle to work by, by calling it 'log driven' programming. What is next? Keyboard driven programming? 3-monitor-driven programming? I do this: While programming it pays off to stop and think about the code. I call this, thought driven programming…

I've personally found great benefit reading this and I am sure a lot of people will. As obvious as it may sound, it's always nice to be reminded every once in a while.

Re: Log driven programming (2013)

#45

How is something as frivolous as taking notes while programming, which many people do, worth a blog post and a mention here on HN? Let alone turning it into some dogmatic principle to work by, by calling it 'log driven' programming. What is next? Keyboard driven programming? 3-monitor-driven programming? I do this: While programming it pays off to stop and think about the code. I call this, thought driven programming…

You’re oversimplifying. The key point isn’t the note-taking, it’s about putting newly discovered sub-tasks on a backlog rather than tackling them immediately. It’s good advice, and not something that comes naturally to everyone. “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 t…

He's also overreacting.

Re: Log driven programming (2013)

#46
post #12

How is something as frivolous as taking notes while programming, which many people do, worth a blog post and a mention here on HN? Let alone turning it into some dogmatic principle to work by, by calling it 'log driven' programming. What is next? Keyboard driven programming? 3-monitor-driven programming? I do this: While programming it pays off to stop and think about the code. I call this, thought driven programming…

Over the past 20something years of being a developer I've found there are a lot of things that seem obvious to me now that junior developers don't do by default. Looking back I wonder when I started doing all these obvious things. Presumably, if I didn't discover them myself, it was when I was told about them or I read about them. If no one is writing these "frivolous" things down then how will juniors learn? If this…

Not sure if this is "obvious" or not, but a very simple thing I've been doing for the past 15 years is to write a short log entry every time I encounter an especially tricky bug.

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-...

Re: Log driven programming (2013)

#47
post #29

Earlier quoted context omitted.

It's surprising how much objectionable you find in what to me is simply an experienced programmer sharing a detail of his personal workflow. Naming doesn't turn something into a "dogmatic principle".

Before I begin again, I grant you that the length of my replies seem to imply that I care a lot. I don't, I just like to talk about semantics and when people raise new arguments, I like to explore the subject some more with a reply. For all I care you will write an article on 'boxer short driven programming' on how you sit around in your underwear programming and think everyone should do it. "It's surprising how much…

Workflows being a dime a dozen in both the software industry and all industries more generally, saying that any word makes a workflow “something that should be adhered to” seems like an overstatement. It's absolutely clear that the author thinks it is worth adhering to, however.

“-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).

Re: Log driven programming (2013)

#49
post #8

Earlier quoted context omitted.

"Common sense is not so common." - Voltaire

Yep. 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…

Yep. I like books like this https://www.amazon.com/Effective-Engineer-Engineering-Dispro... for this reason.

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...

Re: Log driven programming (2013)

#50
post #36

Earlier quoted context omitted.

"Maybe you manage to work with only people who can write down their thoughts coherently." 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…

I for one find myself very curious about this shower-driven programming. It sounds similar to Rich Hickey's famous concept of hammock-driven development.

Hammock-driven development requires less water, which is good.
Post reply on HN