6 ms·

I can't upvote this article enough times -- it's concise yet rich with astute observations. Just one example: "Thirty Years Ago...Insulating developers from in

I can't upvote this article enough times -- it's concise yet rich with astute observations. Just one example: "Thirty Years Ago...Insulating developers from interruptions was management’s Prime Directive." From my own experience, when I started at IBM in the mid 1980s, we had private offices just for this very reason. Me and my colleagues also recognized, though, that we were on the tail-end of those good ol' days. By the early 1990s "bullpens" were becoming the rage, and the rest is history. Another, "QA was other people": it was other people, and not the can't-make-it, under-performers, either. Testing was a discipline in and of itself, with very experienced testers. They were often older programmers in their last 5-10 years which knew what kinds of corners and edges to think of. That, too, was a just a fond memory by the early '90s.

jonstewart 5y ago
I’m 43 and I’m a dev manager. I try as hard as possible to insulate my developers from interruptions and pointless meetings. We have a dev team meeting every two weeks, and each dev maybe has 1-2 other meetings in those two weeks to discuss software with end-users; very much focused on the software. That’s it. But we also pair-program — when it makes sense — and we practice TDD. Perhaps the author has not observed good TDD. I find TDD enormously helpful; TDD helps me get into flow, and maintain it. I think there’s as much wrong with this article as there is right, and can’t really recommend it.
- zzbzq 5y ago
  I like the take that people who dislike TDD just haven't seen good TDD. I also like the take that people who exalt TDD are bad programmers. Both are hypothetically possible.
  - philwelch 5y ago
    What about people with nuanced takes on TDD? A lot of what turns me off about TDD is the dogmatism. If I'm coding a bug fix, I will often start by writing a unit test that reproduces the root cause of the bug because I don't want a regression, and I want to be sure that my unit test actually catches the bug before I fix it. If I'm writing a pure function and I want unit test coverage on it, I might as well write the unit tests first. But it's not necessarily useful to write all of your unit tests first.
    - postalrat 5y ago
      What do you do when you write the test, "fix" the bug, only to find out the bug you saw is just a small example of a larger bug.
      - philwelch 5y ago
        Depends. Maybe I throw everything away, write a new unit test for the true root cause, and start over from there. I’m comfortable taking very long journeys to reach very small code changes if that’s the best solution.
        theK 5y ago
        Correct, often a root cause fix turns out to introduce much less complexity than a symptom fix.
    - taylodl 5y ago
      What you're doing is similar to what I call Maintenance-Driven Development (https://taylodl.wordpress.com/2012/07/21/maintenance-driven-development/ https://taylodl.wordpress.com/2012/07/21/maintenance-driven-...). Put your testing effort in things that are likely to fail and don't insist on 100% code coverage, not even close. For example, I hear people complain all the time about how stupid it is to test getters/setters. So don't write tests for them (even better, don't implement them - but that's another story!) They're not likely to fail. Maybe if a code's cycolomatic complexity score exceeds a certain value then test it (consider refactoring to reduce the complexity too!) In my decades of software development experience I can tell you most developers have a good "feel" for what needs to be tested and what doesn't. Listen to them - they're usually right. If they're not then you'll catch it on the break-fix.
- Jetrel 5y ago
  Yeah, speaking as an increasingly older developer, "resistance to interruption" is probably one of the cardinal skills you can learn as a developer. The ironic thing about it is the actual skill you're developing when you do this is extremely valuable even when doing "solo, uninterrupted work", because, ironically, one of the greatest sources of distractions is your own mind's brainstorming. In doing "solo, meditative work", the hardest skill you have to develop is keeping your mind trained on the direct thing you're trying to accomplish, and not letting other parts of the problem intrude on your though process. If you've got any drop of ADD/ADHD (which by the "any drop" definition basically includes everyone), your mind will constantly get pulled away from the "task at hand" and start thinking about other parts of the problem. You'll be working on subsystem A (i.e. the task at hand), and you'll start thinking about how it interacts with subsystem B, and start thinking "oh gosh, I didn't realize this will also impose some constraints on subsystem C". One of the key reasons this is a mind trap is because these side-things are genuinely useful; you'll run into caveats as your mind starts exploring "the interaction of subsystem A and B", and start to realize B's actually going to impose some hard constraints on A. The naive thing to do is to assume "well, there's no point in designing A because of what I just discovered - I better figure out all those constraints first". What happens then is a sort of writer's block - no matter what you end up thinking of, you constantly get distracted with caveats and gotchas, and rarely manage to have a session where you can fully "think through" subsystem A and draft a complete design. If this tendency isn't policed, you'll have a tendency in all of your "deep flow" sessions to have your mind start the session by thinking about the real thing you're trying to build, but then aimlessly wander off onto the paths of all the ways your thing interacts with other stuff. Don't get me wrong - it's a useful thing to be able to do, but it needs to be deployed "at will" rather than being a gravity well your mind gets pulled into by compulsion. Ideally, even though you know some of it will violate some constraints, it's a hugely useful skill to be able to keep your mind on target and fully think through "subsystem A", any constraint-violations-be-damned. Sure, it won't work, but at least you'll have a mental sketch of the whole thing which can then be amended. Usually you'll find that the sketch is still mostly right, and more importantly, you'll now be able to conceptualize "the whole thing" instead of always getting stuck on the first third. --- The skills to maintain - and reestablish this "mental target lock" seem IME to be identical with the ones you need to stay in a flow state even with people around you constantly distracting you. Even if no "other people" are distracting you, and you're in a private office, you'll still be distracting yourself, so — I've found that a bulk of the improvement has to come from you, yourself, developing mental discipline on this, rather than from you having a favorable environment. Otherwise you'll have a private office to just daydream about development, rather than constructively thinking through things. A favorable environment can be great to have, but the ability to rapidly recover from distractions is something that makes a developer extremely effective even if they've got a favorable, external-distraction-free environment, rather than being a skill that becomes worthless if the external distractions are removed.
- jdlshore 5y ago
  > Perhaps the author has not observed good TDD. It’s quite possible; Microsoft perpetrated a brain-dead interpretation of TDD around the time the author is describing (2008) and there are still people there who believe that’s what TDD is. (Their definition: write all the tests, then write all the code. Moronic.)
  - _tom_ 5y ago
    Sounds like waterfall, but with tests, instead of documentation.

jonstewart 5y ago

I’m 43 and I’m a dev manager. I try as hard as possible to insulate my developers from interruptions and pointless meetings. We have a dev team meeting every two weeks, and each dev maybe has 1-2 other meetings in those two weeks to discuss software with end-users; very much focused on the software. That’s it. But we also pair-program — when it makes sense — and we practice TDD. Perhaps the author has not observed good TDD. I find TDD enormously helpful; TDD helps me get into flow, and maintain it. I think there’s as much wrong with this article as there is right, and can’t really recommend it.

zzbzq 5y ago
I like the take that people who dislike TDD just haven't seen good TDD. I also like the take that people who exalt TDD are bad programmers. Both are hypothetically possible.
- philwelch 5y ago
  What about people with nuanced takes on TDD? A lot of what turns me off about TDD is the dogmatism. If I'm coding a bug fix, I will often start by writing a unit test that reproduces the root cause of the bug because I don't want a regression, and I want to be sure that my unit test actually catches the bug before I fix it. If I'm writing a pure function and I want unit test coverage on it, I might as well write the unit tests first. But it's not necessarily useful to write all of your unit tests first.
  - postalrat 5y ago
    What do you do when you write the test, "fix" the bug, only to find out the bug you saw is just a small example of a larger bug.
    - philwelch 5y ago
      Depends. Maybe I throw everything away, write a new unit test for the true root cause, and start over from there. I’m comfortable taking very long journeys to reach very small code changes if that’s the best solution.
      - theK 5y ago
        Correct, often a root cause fix turns out to introduce much less complexity than a symptom fix.
  - taylodl 5y ago
    What you're doing is similar to what I call Maintenance-Driven Development (https://taylodl.wordpress.com/2012/07/21/maintenance-driven-development/ https://taylodl.wordpress.com/2012/07/21/maintenance-driven-...). Put your testing effort in things that are likely to fail and don't insist on 100% code coverage, not even close. For example, I hear people complain all the time about how stupid it is to test getters/setters. So don't write tests for them (even better, don't implement them - but that's another story!) They're not likely to fail. Maybe if a code's cycolomatic complexity score exceeds a certain value then test it (consider refactoring to reduce the complexity too!) In my decades of software development experience I can tell you most developers have a good "feel" for what needs to be tested and what doesn't. Listen to them - they're usually right. If they're not then you'll catch it on the break-fix.
Jetrel 5y ago
Yeah, speaking as an increasingly older developer, "resistance to interruption" is probably one of the cardinal skills you can learn as a developer. The ironic thing about it is the actual skill you're developing when you do this is extremely valuable even when doing "solo, uninterrupted work", because, ironically, one of the greatest sources of distractions is your own mind's brainstorming. In doing "solo, meditative work", the hardest skill you have to develop is keeping your mind trained on the direct thing you're trying to accomplish, and not letting other parts of the problem intrude on your though process. If you've got any drop of ADD/ADHD (which by the "any drop" definition basically includes everyone), your mind will constantly get pulled away from the "task at hand" and start thinking about other parts of the problem. You'll be working on subsystem A (i.e. the task at hand), and you'll start thinking about how it interacts with subsystem B, and start thinking "oh gosh, I didn't realize this will also impose some constraints on subsystem C". One of the key reasons this is a mind trap is because these side-things are genuinely useful; you'll run into caveats as your mind starts exploring "the interaction of subsystem A and B", and start to realize B's actually going to impose some hard constraints on A. The naive thing to do is to assume "well, there's no point in designing A because of what I just discovered - I better figure out all those constraints first". What happens then is a sort of writer's block - no matter what you end up thinking of, you constantly get distracted with caveats and gotchas, and rarely manage to have a session where you can fully "think through" subsystem A and draft a complete design. If this tendency isn't policed, you'll have a tendency in all of your "deep flow" sessions to have your mind start the session by thinking about the real thing you're trying to build, but then aimlessly wander off onto the paths of all the ways your thing interacts with other stuff. Don't get me wrong - it's a useful thing to be able to do, but it needs to be deployed "at will" rather than being a gravity well your mind gets pulled into by compulsion. Ideally, even though you know some of it will violate some constraints, it's a hugely useful skill to be able to keep your mind on target and fully think through "subsystem A", any constraint-violations-be-damned. Sure, it won't work, but at least you'll have a mental sketch of the whole thing which can then be amended. Usually you'll find that the sketch is still mostly right, and more importantly, you'll now be able to conceptualize "the whole thing" instead of always getting stuck on the first third. --- The skills to maintain - and reestablish this "mental target lock" seem IME to be identical with the ones you need to stay in a flow state even with people around you constantly distracting you. Even if no "other people" are distracting you, and you're in a private office, you'll still be distracting yourself, so — I've found that a bulk of the improvement has to come from you, yourself, developing mental discipline on this, rather than from you having a favorable environment. Otherwise you'll have a private office to just daydream about development, rather than constructively thinking through things. A favorable environment can be great to have, but the ability to rapidly recover from distractions is something that makes a developer extremely effective even if they've got a favorable, external-distraction-free environment, rather than being a skill that becomes worthless if the external distractions are removed.
jdlshore 5y ago
> Perhaps the author has not observed good TDD. It’s quite possible; Microsoft perpetrated a brain-dead interpretation of TDD around the time the author is describing (2008) and there are still people there who believe that’s what TDD is. (Their definition: write all the tests, then write all the code. Moronic.)
- _tom_ 5y ago
  Sounds like waterfall, but with tests, instead of documentation.