You are viewing a read-only archive of the Blogs.Harvard network. Learn more.

Offices and Opens and Saving your Work

A thread picks up on reddit every so often about developers needing quiet and the evils of open floor plans.

Many years ago I got a new job and during the interview process I was told I’d get my own office. There were several open offices, the person I was replacing had her own office. It was a sure thing. My first day I was grouped with the most junior developer of the group. I hated it. For a year or so I was the only person who had to share an office. (Yes, I see what I did there, this article is about me, not him.) After a week I was used to it.

Then the dev team moved to a new location. Half of the developers got offices and half got cubes. I had a cube right out in open, offering no privacy. I hated it. I had to learn how to work with a laptop on the lap and I had to be okay with people coming up behind me and commenting on whatever I was looking at. It took a week or so, but I got used to it.

Then the cube next to me opened up. I went in over the weekend and disassembled the wall connecting them. I reworked it so I had a double wide cube with walls toward the door. Privacy achieved. It was great. People could still come by and chat, I had room for a small table to have important 1:1s for discussing XML or Lost. But no one could lurk on me. I felt safe and open.

Then the band broke up a and different people were slung in different directions. I was moved into the same situation I was in when I was hired. I was the only one who had to share an office. I actually made a stink. We were the only people sharing and there were other options. I deserved my own office, right? Probably. But I got stuck with this guy — and this is no reflection on him, he’s great, but still, entitlement. And uh, peace and quiet?

Anyway, this was around the same time I was getting into agile. Really understanding principles of software development. How things really can work well in imperfect environments. Software development, I was discovering, was 90% collaboration/communication and 10% coding. I could go off and continue soloing my projects, or I could discuss what I’m doing more with my team and find better, and often faster ways of doing things.

I came to the realization that the time of the solo coder was gone. An office for a developer no longer makes sense. Developers are the center of work. If they’re inaccessible, they may not be getting the information they need to be doing the work correctly. Which happens constantly. Developers will often run down a rabbit hole head first if it’s an interesting problem. Having an office, with a closed door, is a great way to not be in communication with a team.

The argument most developers make is best explained in the following cartoon to the right:


The idea is that we work a lot in our heads. We are putting things together in an organic way. And when someone interrupts that organic process, work is actually LOST.

Interruptions are a part of the job. How we deal with them defines the kind of software engineer we are. To the comic, I would liken it to working on a Word document and not saving. KNOWING full well that at some point someone is going to message you on a chat client that makes Word crash. And autosave isn’t working… okay fine, it’s not a perfect metaphor.

So how do you save?

The concept of saving work can be thought of multiple ways. Rough documentation is always good. Map out your thinking in a document, a google doc or a confluence doc. I create google docs for almost everything nowadays. Some of them end up trash within in day, but it’s good to not lose my train of thought. I can stop anytime, continue it while I’m walking or commuting, pop it out in a meeting that isn’t relevant to me, whatever. You can also talk it over with a coworker. Bringing someone else into your train of thought can not only help you figure out a good solution, but also help in retaining the information. Building a collaborative relationship with your coworkers is paramount to succeeding in software development in the new world. The point is, interruptions are going to happen, so like, save often.

Posted in Uncategorized. Tags: , , , . Comments Off on Offices and Opens and Saving your Work »

Kurogo, Open Source, and Foot in Mouth

Several years ago I worked on a mobile project using modo labs’ kurogo. What we did was simple enough. It provided a mobile framework, using its own phonegap-like technology as a way to “compile” we code into native apps for android and ios. When we were a decade behind in mobility, it provided a means to do things that sounded like they should be done.

Fast forward to present. Modo labs is touting their new v2.0. That’s interesting, right? I knew their 1.x platform and was not impressed, but this is new. In the wake of the new rages in mobility (spa’s and APIs) I couldn’t wait to see what they had come up with.

But wait I did. It took several months to provide me with code to muck with. A project that really enjoys calling itself open source — but they’re not making v2.0 open source. That’s the secret sauce. Okay, fine, maybe they’re having trouble making money with an open source project. I shouldn’t judge it too harshly on that.

Well, I finally got into some training on the product. Got my hands on the code literally 20 minutes before the training. The setup docs were poorly written. In a time where vagrant and docker are on my mind a lot, not having a VM, having to set things up manually seemed like taking a step backwards in time.

Finally got into the nitty gritty, and quickly noticed not much had changed. They are still peddling the same design decisions they made a decade ago. A new enhanced administration, but the apps being created will look pretty much the same. The configuration files write the application for you. As a developer, this was disappointing.

But I realized they’re not making a product for developers. They’re creating a product for configuration managers.

I was floored when I saw PeopleSoft “development” for the first time. It’s the future though. It’s a way to create applications without having to pay for developers with specialized education / experience.

As the people who are putting together the University’s PeopleSoft campus solution I’m sure will tell you, it’s a double edged sword. A LOT can be done by people with minimal training, but getting outside of the box, creating “experiences” becomes borderline impossible.

That said, Kurogo I’m sure has its place among a certain breed of application. And I hope it will take off, and people find use for it. But it is an elegant product, for a more civilized age.

Posted in Uncategorized. Tags: , . Comments Off on Kurogo, Open Source, and Foot in Mouth »