3 ms·

All of this is a huge part of the reason I love TDD. It's a checklist, and I've always got my next item, and my working state is by and large in the code. I can

All of this is a huge part of the reason I love TDD. It's a checklist, and I've always got my next item, and my working state is by and large in the code. I can even code while VERY distracted (meetings, cough cough) and succeed (albeit slowly). It can help with the tangential issues; maybe I whip out a (failing) test, or maybe I just mantra "only fix this one test".

taneq 6y ago
These are all great points in favour of TDD. They're a ratchet on your code that lets you crank it out in small increments without losing much progress. I feel like this only helps with distractions and interruptions, though, if you're doing routine work that you already fully understand and can code 'off the top of your head'. Admittedly this is the entirety of many software jobs and the bulk of even the most challenging, but there's still sometimes a need for time to think unimpeded.
- RangerScience 6y ago
  More or less the case here; wrote this project, now refactoring and adding tests. Not every part of it could be done while 'distracted'. Good testing still helps with distractions because good testing enforces a code style that's very bite-sized; so if your 'tasks' are 20-40m, you can fit a lot of distractions. Also, each task (generally) by virtue of being so small takes up less mental RAM, so you don't have to page out as much when a distraction happens. Also makes it easy to work "around" the hard part, and come back to it when you know you'll have that uninterrupted time. Or late that night when inspiration strikes and now it's easy :)
  - thesz 6y ago
    I wonder, what kind of problem domain would allow such small and local programming?
    - RangerScience 6y ago
      Chat bot. brian.bot The hard / complex part is (first) parsing parts of a Slack conversation to the do the AI part, and (second) the Slack interactive messages, which get weird when you try to use them as a form. a lot of just "if these messages happen in this order, this correct thing still happens", where the difference between different message types is, well, not minimal, but simple and straightforward. This has definitely led to waaay to much copy pasta, but it's well encapsulated within the test fixtures.
eru 6y ago
I quite like the ideas behind the original 'extreme programming'. See eg http://www.extremeprogramming.org/ http://www.extremeprogramming.org/ Reading that website these days feels like going back in time before 'agile' became a buzzword only, and dominated by enterprise scum masters.
partyboat1586 6y ago
TDD is great but if you are coding in a meeting... you should walk out. Let them know you are not needed for that meeting, it makes the whole company more efficient.
- sanitycheck 6y ago
  Sometimes it's more efficient to be in that meeting, and half-listening, rather than dealing with the fallout from bad decisions made without your ("wait, WHAT did you say?!") input. Easier if it's a conference call, of course.
  - capableweb 6y ago
    On the other hand, it sucks being a person who is saying something in a meeting and then get interrupted because someone misheard something or didn't understand the context. Or when you ask a question to a person who is attending the meeting but they need you to repeat what you were saying because they weren't paying attention.
sideshowb 6y ago
Agree, but furthermore, it's not only tests that allow you to keep context outside your head, but also compiler errors. On complex tasks for example, calling a method that hasn't been defined yet I can offload a subtask from my head because I know for sure the compiler will remind me to implement it later if I forget. Even more explicitly, mid task my c++ can be full of #error directives each with a little note for something to be fixed at that location before I even think about running anything.
- sideshowb 6y ago
  Or, for that matter, if an entire stack of methods needs modifying to accept some new data type. All you have to do is modify one of them and the compiler won't let you run until you've done the rest. Or modify the type definition and everything using it has to change. If you want to force check every usage, rename the type. Not that I have anything against tests either, these are all just strategies for keeping a record of context.
  - RangerScience 6y ago
    I can see that. I definitely prefer my code to run even while broken, since I find it makes it easier (overall) to write - particularly when I don't have great docs for the data I'm getting from web hooks (I'm looking at you, Slack Actions), where it's useful to just pop into an in-situ REPL and poke around. Although - waaay back in the day, I was very gung-ho about using C++ template shenanigans to enforce code correctness at compile time.
    - sideshowb 6y ago
      It depends what you're working I guess. I can see where you're coming from with web hooks; in the examples above it was more of a 'pure' algorithm module and much more self contained. Haha, yes I overdid templates for this once too :)

taneq 6y ago

These are all great points in favour of TDD. They're a ratchet on your code that lets you crank it out in small increments without losing much progress. I feel like this only helps with distractions and interruptions, though, if you're doing routine work that you already fully understand and can code 'off the top of your head'. Admittedly this is the entirety of many software jobs and the bulk of even the most challenging, but there's still sometimes a need for time to think unimpeded.

RangerScience 6y ago
More or less the case here; wrote this project, now refactoring and adding tests. Not every part of it could be done while 'distracted'. Good testing still helps with distractions because good testing enforces a code style that's very bite-sized; so if your 'tasks' are 20-40m, you can fit a lot of distractions. Also, each task (generally) by virtue of being so small takes up less mental RAM, so you don't have to page out as much when a distraction happens. Also makes it easy to work "around" the hard part, and come back to it when you know you'll have that uninterrupted time. Or late that night when inspiration strikes and now it's easy :)
- thesz 6y ago
  I wonder, what kind of problem domain would allow such small and local programming?
  - RangerScience 6y ago
    Chat bot. brian.bot The hard / complex part is (first) parsing parts of a Slack conversation to the do the AI part, and (second) the Slack interactive messages, which get weird when you try to use them as a form. a lot of just "if these messages happen in this order, this correct thing still happens", where the difference between different message types is, well, not minimal, but simple and straightforward. This has definitely led to waaay to much copy pasta, but it's well encapsulated within the test fixtures.

eru 6y ago

I quite like the ideas behind the original 'extreme programming'. See eg http://www.extremeprogramming.org/ http://www.extremeprogramming.org/ Reading that website these days feels like going back in time before 'agile' became a buzzword only, and dominated by enterprise scum masters.

partyboat1586 6y ago

TDD is great but if you are coding in a meeting... you should walk out. Let them know you are not needed for that meeting, it makes the whole company more efficient.

sanitycheck 6y ago
Sometimes it's more efficient to be in that meeting, and half-listening, rather than dealing with the fallout from bad decisions made without your ("wait, WHAT did you say?!") input. Easier if it's a conference call, of course.
- capableweb 6y ago
  On the other hand, it sucks being a person who is saying something in a meeting and then get interrupted because someone misheard something or didn't understand the context. Or when you ask a question to a person who is attending the meeting but they need you to repeat what you were saying because they weren't paying attention.

sideshowb 6y ago

Agree, but furthermore, it's not only tests that allow you to keep context outside your head, but also compiler errors. On complex tasks for example, calling a method that hasn't been defined yet I can offload a subtask from my head because I know for sure the compiler will remind me to implement it later if I forget. Even more explicitly, mid task my c++ can be full of #error directives each with a little note for something to be fixed at that location before I even think about running anything.

sideshowb 6y ago
Or, for that matter, if an entire stack of methods needs modifying to accept some new data type. All you have to do is modify one of them and the compiler won't let you run until you've done the rest. Or modify the type definition and everything using it has to change. If you want to force check every usage, rename the type. Not that I have anything against tests either, these are all just strategies for keeping a record of context.
- RangerScience 6y ago
  I can see that. I definitely prefer my code to run even while broken, since I find it makes it easier (overall) to write - particularly when I don't have great docs for the data I'm getting from web hooks (I'm looking at you, Slack Actions), where it's useful to just pop into an in-situ REPL and poke around. Although - waaay back in the day, I was very gung-ho about using C++ template shenanigans to enforce code correctness at compile time.
  - sideshowb 6y ago
    It depends what you're working I guess. I can see where you're coming from with web hooks; in the examples above it was more of a 'pure' algorithm module and much more self contained. Haha, yes I overdid templates for this once too :)