The open offices I’ve worked in—and some were otherwise great places to work—usually lead to distraction, decreased productivity, and low morale in myself and the people I’ve worked with. For the record, I think offices when used as places to meet, to share ideas, or to bust out code in a 2-week sprint are great. But as an everyday environment, open offices come at a price.
—I think coders tend to shift between modes. Sometimes we need co-worker input to bounce ideas off of/troubleshoot something, and sometimes we need quiet to crank out code. In my ideal office environment, you partition out the devs and those that need to be on the phone for their job (sales, biz-dev, CEOs). From there, groups of 2-4 devs in a single space is probably ideal (large partitioned cube or office). Also, they should have enough personal space in between, and plenty of chairs so they can pair if needed. Ideally, you want to bug your cube/office mates when you’re stuck on sometime that you can’t get past, but not for small things that you could easily look up yourself. Sometimes, having a group of experts can lead to a death by 1000s cuts (What was the command in vim to jump a word? What’s the syntax for text-gradients in css?) That said, I’m a HUGE fan of code reviews, pair programming, group debugging, etc. I think it’s all about striking a balance.
At TeachStreet we have partitioned spaces (bigger than a cube, smaller than an office), which we call pods (long story). Additionally, we have lot of common space (couches, big table, space to move around an posture in front of a whiteboard). We’ve changed up our space a bit a number of times since we’ve been there - I think an important lesson as well is to adapt your space to your needs as much as possible. Each team is going to be different.
(via superamit)
office space
work
This upcoming July, I’ll have worked for ten years as a professional software engineer. I’ve worked for both big and small companies and have learned a few things that other nerds may find helpful when turning from “hacking around at stuff" to “career code monkey".
It’s better to agree than be right
In reality, wether you are disagreeing about a feature or architecture, you’re probably both completely off the mark. Users do things with products and software you’d never imagine. So rather then waste time arguing until you’re blue in the face, quickly come to a common ground, and move on. You’ll realize soon enough that you were both wrong, and a third solution was actually the correct one, and you can quickly fix what you did wrong. (Unless you’re making pacemakers, then ignore everything I just said. You have to be right).
Listen to the customer patiently, then figure out what they really want
Rarely do customers know what they want. And when they do, if you do everything they ask, you’ll end up with a “Homer". So, listen to what they say, then figure what problems they are actually having, then solve those problems for them. They’ll rarely be upset that you didn’t solve the problem form them their way. (And if they are, they’re jerks).
They’re only your customer if they’re making you money
Everything else is a distraction. Some of the most vocal “customers" you’ll end up with will never pay you a dime, so don’t waste you’re time trying to make them happy. Remember, at the end of the day, businesses are here to make money. You can do other stuff too, but if you don’t make money, you don’t have a business anymore.
There’s no point in religious wars
VI vs. Emacs. Spaces vs. tabs. SOAP vs. REST. Ruby vs. Python. Either find a group of people that commonly agree, or allow people to pick their own tools. Anything else is wasting everyone’s time since people rarely convert when forced. FYI, if you’re a non-technical found and you’re looking for good talent, the fastest way to attract people is with the magic words “You can use whatever tools you want". It’s like catnip for alpha-geeks stuck doing something they hate.
Educate rather than shut-out
Commonly when engineers don’t want to do something one way, they’ll just say “It’s too complicated". Yes, sometimes business owners just asked you to solve an NP-hard problem, but most of the time, we think the idea is dumb and we’re stone-walling you. Or you asked us to solve the really hard version of the problem, when you can simplify it by changing one tiny thing. It’s our responsibility as engineers to explain the cost of different decisions, and provide different options. If your business owners are smart, they’ll learn from your advice and make better suggestions in the future.
This isn’t rocket science (unless it is)
Let’s face it, most of what we do is putting buttons on pages, so let’s stop grandstanding on how skilled we are, and how difficult and challenging our jobs are. 10% of the time you get to do something really cool and blow the dust off old math books, but the rest of the time, you’re making license plates. When you can, show non-devs what you’re doing and let them help. Copy writers? Graphic Designers? Let them in on writing some HTML. It’s not that hard, and if they learn on how this stuff works, they can even help you out in the future. If we put a man on the moon with Newtonian physics, we can teach some ordinary Joes some HTML.
Here’s to 30+ more years…
Realistically, unless I run into magical spontaneous wealth, I’ll be at this for 30 or so more years (at least). And even if I did win the lottery, I’ll probably still come into work (because I really enjoy what I do). Since I know I’m in for the long haul, I’m always trying to make sure that I’m going to make this a marathon instead of a sprint. That means keeping an eye on burnout, and learning from mistakes. So here’s to year 11, and counting…
software
nerd
career
