5 ms·
I require all of my programmers to be on site, not because of any need to monitor what they're doing (Pivotal Tracker, source control, IM, and email take care o
by kschrader 16y ago
I require all of my programmers to be on site, not because of any need to monitor what they're doing (Pivotal Tracker, source control, IM, and email take care of most of that for us, even while we're in the office) but to have the kind of conversations that can only happen when you have a bunch of engineers around a white board trying to solve a hard problem (no, IRC is not the same thing).
I still haven't come across a tool that allows telecommuters to replicate this process.
- tswicegood 16y agoCouple of questions for you then: * Do you do this every day? * If so, do you get anything done? I only being slightly facetious. I agree that there's a lot to be said for brainstorming in person. I'd also argue that there's a lot to be said for brainstorming out of your normal environment (i.e., office). But you don't do this every day. You code every day. Why not rent out some office/conference space for an afternoon every few weeks as you ramp up on your next iteration and save the money on the office space all the while allowing your programmers to be more productive?
- kschrader 16y agoYes, discussions between programmers about how to best implement things happen every day. We work in an open work space, and I can't even count the number of times that someone has jumped into a discussion with a better idea of how to implement something. If that saves the original people a couple of hours (or days, etc) then we've immediately increased productivity. I don't buy into the idea that being "more productive" means sitting by yourself in your home office cranking out code.
- mattm 16y agoIt takes at least 15 minutes for people to get back into a productive working state after being interrupted. If you interrupt an office of 8 and one person has an idea that saves 2 hours, you are only breaking even. I worked in an open space before and it drove me nuts until I finally left. It was fine when there was just a few of us but as they started adding more people, the number of interruptions started to go up exponentially until some days it seemed like I was being interrupted all the time.
- rdl 16y agoI hate open plan offices especially when they're shared across multiple work groups, functional areas (e.g. devs sharing with phone ad sales!), or even worse, companies. I think the happy medium is some flexibility among telecommuting, private offices, group work areas (taking over a conference room, or something less formal), and informal mixing areas. There is no single office environment which is best for all tasks. I'm at my most productive by telecommuting from home one day a week, and daily from 0600 to 1000 (not always on the main company project); then working in the office, meeting with clients outside, etc. from 1000 to 1800, and then whatever team building, client events, etc. from 1800 to 0000.
- akeefer 16y agoLike most things in life, it depends. Just because it didn't work in your case doesn't mean it never works, that it's never a good idea, and that it's always a waste of time. For us, it's turned out to work really well, and we feel like the benefits outweigh the costs. Your mileage will vary. For some reason, though, this is a subject on which many people feel qualified to make pronouncements about the wisdom of what other people are doing. I have, for example, had a candidate come in for an interview, look at the office layout, lecture me for 15 minutes about how we must be idiots because we're killing our productivity with our open layout, and then leave because he'd refuse to work in a place like that. At least it saved me the other 45 minutes I would have had to spend interviewing the guy.
- strlen 16y agoThere's a cynical side in me which makes me wonder if companies that embrace all of open floor plan, fixed working hours (implicit requirement due to practices such as daily 9:30 stand-up meetings), required physical presence are specifically trying to make sure that engineers aren't solving any difficult problems: to make sure the engineers are interchangeable components, as well as that the company adds as little value as possible to their customers (while still wringing profit out of them). Incidentally, no sane software company that I know off is rigorous about enforcing all three in all circumstances. The places I've seen hailed as successes of upper-case-A Agile, on the other hand, are typically gluing together software other people have written (without modifying the software itself, unlike legitimate open source companies) with very little value being added. Disclaimer: I have nothing against lower-case-a agile, that is developing software iteratively and ensuring a large suite of tests to allow for rapid refactoring; it's the right tool for many (but not all) problems. Upper-case-A Agile (Scrum, XP, etc...) and "TDD", on the other hand, just smell wrong.
- kschrader 16y agoPerhaps instead of down-voting this you can simply reply to it. Unless of course you don't think that discussions happen everyday or that it's not ultimately saving us time.
- tswicegood 16y agoDiscussions like that can happen on IRC. @mattm is correct, you're taking the whole team for a few hours (or maybe days) saved, you're on the raw end of the deal. There's nothing saying that type of conversation requires high-bandwidth communication. It's often more efficient to have one programmer waiting on a response in IRC rather than interrupting the entire group. You're optimizing for the 5% instead of the 95%. I think this is a case of a survivor bias---you remember all of the times having people in the same space saved time and forget all the ideas that went nowhere and interruptions that pulled someone out of the groove.
- mattm 16y agoI solve hard problems better when I have quiet time where I can think through the problem. Some people do think by talking but I imagine most engineers do not fall into this category.
- kschrader 16y agoMany companies, software (Facebook) and otherwise (Toyota) have open layouts to encourage problem solving in groups. Most of the good engineers I know are just as adept at hashing out a solution on a whiteboard as they are doing it quietly by themselves, and, given the sample set that I've seen over the years, I've found that the collaborative solutions tends to be better.
- andrewbadera 16y agoEffectiveness of group brainstorming was disproven years ago.
- lonestar 16y agoDo you have a reference for this? I'd be interested in reading it.
- regularfry 16y agoIf you can find a copy of 59 Seconds, by Richard Wiseman, it's mentioned in there (with references, if I remember correctly). I don't have my copy handy.
- deleted 16y ago[deleted]
- kscaldef 16y agoProblem solving is not the same thing as brainstorming. Brainstorming is deliberately loosely structured and undirected. A group of engineers huddled around a whiteboard or a monitor are exactly the opposite: highly focused on the details of a single problem.
- sofuture 16y agoI 100% agree with you. I've both telecommuted and worked in-person, and there is nothing that beats face to face interaction. Period. The 'oh I need alone time to solve problems' excuse is as awful and trite a cliché as 'programmers drink Mt. Dew and live in the basement'. Being an in-person employee does not mean you're working in an mega-corporate shackled environment damaging to your fragile hacker self -- it means you are simply able to directly and immediately converse with your coworkers. Excited hackers stammering out 'HOLY CRAP GUYS I FIGURED OUT THE CACHING PROBLEM What do you think about XYZ?' and the ensuing flurry of discussion is not something duplicated via IRC/email.
- extension 16y agoOverwhelmingly, I have found that the thought process I use to solve technical problems is utterly crippled by any sort of interaction with other people. When I've tried collaborative sessions of this sort, they have become prolonged debates over some mediocre solution. Often, a superior solution starts to take shape in my mind, but I'm too distracted by the conversation to develop it. If I bring my unformed idea into the conversation, I'm bombarded with questions that I can't answer yet, and I'm still too distracted to do the actual thinking I would need to answer them. Whatever solution comes out of this, I will inevitably end up improving it dramatically when I have a chance to reflect on it in solitude. My realtime creative thought process just does not scale to multiple brains. However, I can certainly collaborate in non-realtime. That is, through email, or some other asynchronous medium that gives me unlimited time for solitary thought. I don't want to seem like a megalomaniac, but this really is how it works for me, based on a decade of experience. And I don't think I'm an anomaly among programmers, at least not good ones.