This is essentially the process that Things 3 (I’m not affiliated in any way) for MacOS/iOS uses. It separates adding new tasks (for your inbox) from the step of organizing and scheduling them. So if you think of something you need to do, you can use a keyboard shortcut to pull up a prompt quick add it (from whatever app you’re using) and carry on with whatever else you’re working on.
Log driven programming (2013)
51–60 of 69 posts
Re: Log driven programming (2013)
#52Earlier quoted context omitted.
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 ta…
You are, in turn, oversimplifying what I am saying. 'Language matters' might be closer to what I should have said and in that sense I oversimplified my own words.
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.
Re: Log driven programming (2013)
#53How 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…
[deleted]
Re: Log driven programming (2013)
#54Earlier quoted context omitted.
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...
(I swear I'm not trying to plug anything)
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.
Re: Log driven programming (2013)
#55Earlier quoted context omitted.
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 r…
There are two interesting parts to reading code.
- Working out what it actually does, and why
- Working out why somebody *wrote it in that way*
Maybe it's just me vOv
Re: Log driven programming (2013)
#56How 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…
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.
Consider what programming is, then consider the implications of the suggestion that few developers manage to organize their thoughts well enough to write them down.
Re: Log driven programming (2013)
#57A 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…
That's what I do as well. Also, in OO languages like Java or C#, you can throw "NotImplemented" style exceptions. So that if you mistakenly wrote "TO DO" instead of "TODO" and can't find it statically, the runtime will let you know.
Re: Log driven programming (2013)
#58Earlier quoted context omitted.
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 ta…
You are, in turn, oversimplifying what I am saying. 'Language matters' might be closer to what I should have said and in that sense I oversimplified my own words. 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…
Language matters indeed. I guess that if you'd said "I find coming up with a name with the word 'driven' in it for such a common thing somewhat grandiose." you'd not have provoked such a strong reaction, but you didn't. You said note-taking is "frivolous" (which to me suggested you think it's a bad idea!). You don't acknowledge the difference to "just taking notes", which might make it a not-so-common thing.
Re: Log driven programming (2013)
#59Earlier quoted context omitted.
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?
Naming is really hard work. English isn't even Salvatore's primary language. He's done better than I could in Italian.
Re: Log driven programming (2013)
#60How 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…
Don't give them ideas. Thought driven programming is now a thing.