5 ms·

Our dev culture discourages anyone working in "the zone" because more often than not, it produces crappy code -- crappy mainly in that it's hard for others to u

by mildavw 15y ago

Our dev culture discourages anyone working in "the zone" because more often than not, it produces crappy code -- crappy mainly in that it's hard for others to understand/maintain. If you're off by yourself thinking about something really hard, you're doing it wrong. You should be hashing out new ideas in conversations with other devs. Grab a conference room if you're conversation gets animated or regards something with a very narrow scope that others won't care about, otherwise do it in the open so anyone can jump in. "Disruptions" are conversations where ideas and implementations are fleshed out. That's the hard work. Coding quietly means you're doing something so trivial that pairing would be silly. I really believe this dev culture produces fewer defects and makes the team more responsive since so much knowledge is shared.

samd 15y ago
The Agile mantra these days is write code instead of talking, but there's no faster way to iterate than to have a conversation. Sure you've got to write code at some point, but save yourself wasted hours and days doing the wrong thing and talk about it for 30 minutes. People seem to forget that code is a means, not an end. P.S. Down-voting the OP for having a different opinion, for shame Hacker News.
- mildavw 15y ago
  On re-read, I'm guessing the down votes are for tone. It reads a little rigid and preachy to me now. What I was attempting to describe is the mindset our team currently has, not what yours should have. Our particular team of 8 devs is happy and productive with it. I do understand that this approach could be less than ideal for a different team, or the same team working on projects of a different nature.
deleted 15y ago
[deleted]
mattvanhorn 15y ago
You obviously have little idea of what it means to be "in the zone." It is just as easy to get there with a pair as without, provided you have a decent environment to work in. Pairing is like tennis, another activity which can get you in the zone. Your environment sounds to me like a typical too-many-chefs situation, and those environments usually tend to turn out mediocre crap fairly quickly, when the tasks are trivial, and to take forever to get something working when the task is complex and everybody needs to get their two cents in on how to do things.
- mildavw 15y ago
  Our team has very good chemistry, lots of respect for opinions all the way around. So I don't think people feel the need to get their two cents in on every issue. If a subset takes off on something, the rest know that they'll be brought up to speed at some later point, and the code quality will be decent. If there are parts of it that aren't decent, we'll either agree to fix them, or agree that we don't have resources and we'll have to live with them. Regarding definitions of "in the zone", mine wouldn't include a pair in a good rhythm. Being in the zone, to me, evokes a lone programmer writing lots of code while holding complex mental models in his/her head for hours at a time. It's a pleasurable feeling for most of us with a bent for logic and problem solving, but my experience is that it doesn't always produce the best code. * spelling edit
  - jebblue 15y ago
    >> So I don't think people feel the need to get their two cents in on every issue. Do you feel that a poll of you team would result in a 80/20 rule matching your perspective?
    - mildavw 15y ago
      I'm not sure what you mean. Would 80% agree with me? Do 20% of the people give 1.6 cents? What is the 80/20 rule in this case?
  - philwelch 15y ago
    I'm curious, what exactly kind of software do you work on? I suspect your approach might work okay for fairly simple apps where the main question is getting the requirements right, but not so much with anything that requires serious thinking. Or maybe you're just all a bunch of extraverts.
    - mildavw 15y ago
      Yes, fleshing out requirements is a big part of it. Our apps are web apps but in financing, so they're not totally trivial. We do both the public facing web-apps and the tool used by loan processors for administration. Our team has a high number of extraverts, but the introverts seem just as happy. We have no surly curmudgeons. When I hired on, I was surprised that so many people rode bikes to work. And when I proposed climbing a local mountain to one similarly outdoorsy co-worker, I was surprised that the whole team was interested. 10 out of the 12 in the office either did the warm-up climb or actually camped out overnight and completed the larger climb (Mt St. Helens). I found this amount of shared lifestyle/outside-interests to be unique among places I've worked. I'm certain we weren't hired because of these interests, but it seems to have worked out that we share a lot of them.
pnathan 15y ago
Where do you work? I'd like to not apply.
- mildavw 15y ago
  Your snark actually raises a good point: The optimal office arrangement probably depends on who works there. Last Friday our team presented some of our dev proceses to the local agile group. We had 5 devs and a product person there. Someone observed that our team seems to have really good personal chemistry and we all agreed. We chalked it up to careful hiring. If you wouldn't function well with our set-up, we probably wouldn't offer you a job.
mildavw 15y ago
Incidentally, our work space was designed by the team. We moved last summer. The management chose the office and we were given $50k to do whatever we wanted with it. We built one conference room, a server room, and two small meeting rooms. The rest was open with clusters of stand-up desks.
brown9-2 15y ago
This seems like such an odd outlook to me, one in which you are effectively saying that no single indivisible task should or could ever be completed by a single person in a few hours of focused work.
- mildavw 15y ago
  Yes, we pretty much try to pair on everything. It doesn't work out when there is an odd number or someone gets pulled elsewhere, so it's not all of the time. When we don't pair, we do code reviews (also by a pair).

by mildavw 15y ago

samd 15y ago

The Agile mantra these days is write code instead of talking, but there's no faster way to iterate than to have a conversation. Sure you've got to write code at some point, but save yourself wasted hours and days doing the wrong thing and talk about it for 30 minutes. People seem to forget that code is a means, not an end. P.S. Down-voting the OP for having a different opinion, for shame Hacker News.

mildavw 15y ago
On re-read, I'm guessing the down votes are for tone. It reads a little rigid and preachy to me now. What I was attempting to describe is the mindset our team currently has, not what yours should have. Our particular team of 8 devs is happy and productive with it. I do understand that this approach could be less than ideal for a different team, or the same team working on projects of a different nature.

deleted 15y ago

[deleted]

mattvanhorn 15y ago

You obviously have little idea of what it means to be "in the zone." It is just as easy to get there with a pair as without, provided you have a decent environment to work in. Pairing is like tennis, another activity which can get you in the zone. Your environment sounds to me like a typical too-many-chefs situation, and those environments usually tend to turn out mediocre crap fairly quickly, when the tasks are trivial, and to take forever to get something working when the task is complex and everybody needs to get their two cents in on how to do things.

mildavw 15y ago
Our team has very good chemistry, lots of respect for opinions all the way around. So I don't think people feel the need to get their two cents in on every issue. If a subset takes off on something, the rest know that they'll be brought up to speed at some later point, and the code quality will be decent. If there are parts of it that aren't decent, we'll either agree to fix them, or agree that we don't have resources and we'll have to live with them. Regarding definitions of "in the zone", mine wouldn't include a pair in a good rhythm. Being in the zone, to me, evokes a lone programmer writing lots of code while holding complex mental models in his/her head for hours at a time. It's a pleasurable feeling for most of us with a bent for logic and problem solving, but my experience is that it doesn't always produce the best code. * spelling edit
- jebblue 15y ago
  >> So I don't think people feel the need to get their two cents in on every issue. Do you feel that a poll of you team would result in a 80/20 rule matching your perspective?
  - mildavw 15y ago
    I'm not sure what you mean. Would 80% agree with me? Do 20% of the people give 1.6 cents? What is the 80/20 rule in this case?
- philwelch 15y ago
  I'm curious, what exactly kind of software do you work on? I suspect your approach might work okay for fairly simple apps where the main question is getting the requirements right, but not so much with anything that requires serious thinking. Or maybe you're just all a bunch of extraverts.
  - mildavw 15y ago
    Yes, fleshing out requirements is a big part of it. Our apps are web apps but in financing, so they're not totally trivial. We do both the public facing web-apps and the tool used by loan processors for administration. Our team has a high number of extraverts, but the introverts seem just as happy. We have no surly curmudgeons. When I hired on, I was surprised that so many people rode bikes to work. And when I proposed climbing a local mountain to one similarly outdoorsy co-worker, I was surprised that the whole team was interested. 10 out of the 12 in the office either did the warm-up climb or actually camped out overnight and completed the larger climb (Mt St. Helens). I found this amount of shared lifestyle/outside-interests to be unique among places I've worked. I'm certain we weren't hired because of these interests, but it seems to have worked out that we share a lot of them.

pnathan 15y ago

Where do you work? I'd like to not apply.

mildavw 15y ago
Your snark actually raises a good point: The optimal office arrangement probably depends on who works there. Last Friday our team presented some of our dev proceses to the local agile group. We had 5 devs and a product person there. Someone observed that our team seems to have really good personal chemistry and we all agreed. We chalked it up to careful hiring. If you wouldn't function well with our set-up, we probably wouldn't offer you a job.

mildavw 15y ago

Incidentally, our work space was designed by the team. We moved last summer. The management chose the office and we were given $50k to do whatever we wanted with it. We built one conference room, a server room, and two small meeting rooms. The rest was open with clusters of stand-up desks.

brown9-2 15y ago

This seems like such an odd outlook to me, one in which you are effectively saying that no single indivisible task should or could ever be completed by a single person in a few hours of focused work.

mildavw 15y ago
Yes, we pretty much try to pair on everything. It doesn't work out when there is an odd number or someone gets pulled elsewhere, so it's not all of the time. When we don't pair, we do code reviews (also by a pair).