Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Log driven programming (2013)

antirez.com

Post reply on HN
Print view View original

31–40 of 69 posts

Re: Log driven programming (2013)

#31

Post by rick22 »

mosselman wrote: post #7

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"

Re: Log driven programming (2013)

#32

Post by raytracer »

A couple of years ago I started using TODO:HIGH, TODO:MED and TODO:LOW.

TODO:HIGH is for things that need to be completed for the current feature or bug fix.

TODO:MED is for things that should be completed before the next public build.

TODO:LOW is for stuff that would be good to get done eventually. (A function is complete but doesn't read well so I'll add a note to refactor it at later date.)

When writing new code I try to get something up and running ASAP by filling in functionality with broad strokes. I'll go back and fill in the details once the larger picture is in place. With less code written, it's easier to refactor (or restart), if the design is not quite right.

Writing lots of TODOs helps ensure nothing gets forgotten about.

Picking an easy TODO from the backlog can be good way to warm up when starting the day too.

I'm used to working solo however. Not sure how this approach would go down on a team.

Re: Log driven programming (2013)

#33

Post by chatmasta »

onion2k wrote: post #12
mosselman wrote: post #7

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…

The best habit that any developer can have is reading code. It’s shocking how few devs spend time reading code; whether the code is from library dependencies or entirely unrelated third party projects, I always learn something new just by reading it.

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.

Re: Log driven programming (2013)

#34

Post by thecatspaw »

Fellshard wrote: post #3

Ostensibly, this is what TODO comments have always been for. Realistically, I guess it's probably better that these types of comments remain out of the code itself unless you and your team can practice proper rigor around them, e.g. using prehooks to enforce that no TODOs are left around before committing or merging.

personally I just write the function call, wait for my IDE to complain that the function doesnt exist, press command enter to have it generated with a throw new NotImplementedException().

works well for me, gives me the illusion of a working api, and I get autocompletion.

This requires you to give your functions well thought out names though

Re: Log driven programming (2013)

#35

Post by Dowwie »

mosselman wrote: post #7

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…

Have you considered publishing a manifesto about this.. "thought driven programming"? :)

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.

Re: Log driven programming (2013)

#36

Post by mbrock »

mosselman wrote: post #26
thachmai wrote: post #20

Earlier quoted context omitted.

In my experience, not a lot of developers manage to organize their thoughts well enough to write them down. 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.

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

Re: Log driven programming (2013)

#37

Post by mosselman »

detaro wrote: post #29
mosselman wrote: post #26

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…

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

Re: Log driven programming (2013)

#38

Post by mosselman »

Dowwie wrote: post #35
mosselman wrote: post #7

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…

Have you considered publishing a manifesto about this.. "thought driven programming"? :) 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.

Sure, but names matter, don't they?

Re: Log driven programming (2013)

#39

Post by suprfnk »

raytracer wrote: post #32

A couple of years ago I started using TODO:HIGH, TODO:MED and TODO:LOW. TODO:HIGH is for things that need to be completed for the current feature or bug fix. TODO:MED is for things that should be completed before the next public build. TODO:LOW is for stuff that would be good to get done eventually. (A function is complete but doesn't read well so I'll add a note to refactor it at later date.) When writing new code I…

Exactly. I don't see why you would do this in another application. Doing it in another application means you also have to take note of _where_ the piece of your TODO is. That means filename and line number?

While I don't use priorities, I do liberally use "// TODO: " if it's something I need to do that takes me out of the current problem. Then when I'm finishing up a feature or bug fix, I just walk past the list of TODO's.

A recent example would be: On this new project I was on, while implementing a feature, I didn't know how resource files were handled yet -- so I hardcoded some strings with a "// TODO: Put these strings in resource files". Researching the way resource files are handled will pull you out of the current problem, while it's something that can easily be solved later.

Post reply on HN