1. 5
  1.  

  2. 4

    Everything in this article is so contrary to what I’ve heard. I read a book recently (don’t recall its name), where the primary point was, beyond anything else — giving programmers offices of their own. This one simple thing seemed to be massive productive booster. It’s also the number one thing on the Field Guide to Developers by Joel Spolsky of Joel on Software fame.

    He also wrote a short piece called the Private Offices Redux, where he says:

    Not every programmer in the world wants to work in a private office. In fact quite a few would tell you unequivocally that they prefer the camaradarie and easy information sharing of an open space.

    Don’t fall for it. They also want M&Ms for breakfast and a pony. Open space is fun but not productive. Last summer, the Project Aardvark interns were all in a big open space. The net result was that there was no such thing as a conversation between two people. Every time I went out there to talk to one of them, it became a conversation with all of them; every time two people had to talk, instead of going off to a quiet space somewhere, they just spoke directly to each other, interrupting the other two’s concentration. Although this slightly helps keep everyone “in the loop,” it also knocks programmers out of flow causing them to lose their concentration and devastating productivity, so I prefer to keep people in the loop using more formal methods, like weekly email status reports, and through informal methods like eating lunch together every day, which is why we have free catered lunches and a really big table.

    The above quote really says it all. If you were unsettled about your opinion with regard with regard to private offices, the above quote should have fixed.

    If I were to start a startup (something I would like to, eventually) — private offices would be an nonnegotiable requirement. Even if that meant taking up an office in a less expensive area, I’d make sure everyone got an office of their own (even though it might be small).

    You’d be amazed at how tiny the offices that my professors at my university’s Department of Computer Science were. We’re talking about brilliant people here. They were given small offices. So I thinks it’d be okay if a bunch of startuppers had tiny offices (at least during the budding stages of the startup). But an office is something they must all have.

    1. 3

      Everything in this article is so contrary to what I’ve heard. I read a book recently (don’t recall its name), where the primary point was, beyond anything else — giving programmers offices of their own.

      I think the book you are thinking of may be PeopleWare.

      1. 1

        Yes, that was the book. Thanks for pointing out! :–)

        I also remember reading somewhere that, this book was a must-read at Microsoft, at least in its early days. Don’t know if things have changed now at MS. (The second article I linked into in the grand-parent comment: Private Offices Redux seems to suggest it might have.)

    2. 3

      So instead you should keep your developers working in a hovel with a giant bullpen, paint peeling on the walls, stained and smelly carpet, and so on…because “oh god they may think they can actually go home on the weekends now”?

      I can see the point of not patting yourself on the back or focusing on how far you have come, and instead keeping focused on what you want to do, but the way the article was couched seems a bit questionable to me.

      1. 3

        Indeed. Correlation and causation and all that.

        “Our exec staff spent time worrying about who had the corner office.” Yeah, see, the poison was already there. You don’t think they were waging turf wars before the new office?

        I would rephrase the article entirely. At the point where you have grown to need real offices, you will have inevitably hired some bad apples. They will fuck your company up. The new building is not a problem; it’s a handy reminder to review who and what your company has already become.

        1. 2

          I would upvote more if I could.

          Nearly all startupish companies I have been at that “failed”, I think could be traced to poor (or outright awful) management hires. Hiring (especially mid to senior management) is one of the most important things you do as a company, and often times it seems to be one of the most lackadaisical. It is often just pushed off on human resource.

          Another important thing that is often overlooked at a company, is firing bad hires.

          1. 1

            Another important thing that is often overlooked at a company, is firing bad hires.

            What kind of negative consequences have you seen arise out of this (a tendency to not fire bad hires / keep them too long)?

            Also, why do companies hesitate to let go of a bad hire? Has it got to do with the law? Or it something that’s got to do with just how companies operate today?

            1. 3

              Incompetence is hard to spot. In my experience, it goes something like this. Bad high manager promises the moon, fails to deliver. Finally CEO says changes need to be made. Word is passed down. Low level manager fires a bunch of otherwise competent engineers who were being led around in circles. CEO is told changes have been made.

              After the next failure, high manager fires the low managers. Reports back to CEO the real problem has been identified.

              After the third failure, CEO realizes high manager is incompetent and fires him. By the time this happens, the engineering staff, culture, and morale have been completely decimated.

              This kills startups because new CEOs are told the key to success is delegation. So they delegate their company to death and shut their ears to the screaming. Skip level meetings are vital. I’d say for any company under 100, the CEO should be personally talking to at least every team, if not every individual.

              1. 1

                Nicely stated.

                I’d say for any company under 100, the CEO should be personally talking to at least every team, if not every individual.

                I very much agree. I think, at the very least, the CEO of smaller companies would be well served having some regular ‘open office hours’.

              2. 1

                What kind of negative consequences have you seen arise out of this (a tendency to not fire bad hires / keep them too long)?

                Developers writing awful code that is hard to maintain, and/or not pulling their weight and resulting in poor team morale, buggy code, frustrating and needlessly long code review cycles, combative attitudes, and so on. Consequences are usually poor quality and poor team morale. This tends to be dealt with more readily though, as they are usually “lower rung” in the corporate hierarchy.

                Managers alienating their reports, and causing exodus of valued employees, poor morale, customer relations issues resulting in lost contracts and accounts. Depending on their level and influence, they may be hard to dislodge.

                Also, why do companies hesitate to let go of a bad hire? Has it got to do with the law? Or it something that’s got to do with just how companies operate today?

                I think some of it was just that management got along well with each other (“oh cut him a break, that is just the way he is”, and some of it was cronyism (“I have worked with him so long”, “pal of the ceo”, etc) and some perhaps fear of change in general. Some of it may be due to law as well. Depending on the jurisdiction or country, it can indeed be hard to fire someone. Some of it may be cost/benefit. Possibly a contractual thing with severance requirements for early dismissal, so they will just ignore bad behavior until some timeframe passes. I am sure some of it is just as a company gets to a certain size, people can just run under the radar to a certain extent too.