Hacker News new | comments | ask | show | jobs | submit login
Updating classic workplace sabotage techniques (antipope.org)
378 points by cstross on May 15, 2016 | hide | past | web | favorite | 280 comments



I'm a career changer from actuary to software developer. The most shocking part of the career change was open office arrangements.

Both careers are technical and require both concentration and collaboration. Actuaries tend to have their own cubicles (offices for mid-level and higher).

Software developers require much more concentration. So I just assumed that the virtually all software developers would have their own offices because a solo cubicle seemed inadequate for most developer jobs. And of course, who would be dumb enough to use open office for developers? ... well, I got a little surprise.

Everyone tries to undo the damage of a bad floor design with expensive headphones, but it's just not adequate.


http://www.cs.virginia.edu/~robins/YouAndYourResearch.html

Another trait, it took me a while to notice. I noticed the following facts about people who work with the door open or the door closed. I notice that if you have the door to your office closed, you get more work done today and tomorrow, and you are more productive than most. But 10 years later somehow you don't know quite know what problems are worth working on; all the hard work you do is sort of tangential in importance. He who works with the door open gets all kinds of interruptions, but he also occasionally gets clues as to what the world is and what might be important. Now I cannot prove the cause and effect sequence because you might say, ``The closed door is symbolic of a closed mind.'' I don't know. But I can say there is a pretty good correlation between those who work with the doors open and those who ultimately do important things, although people who work with doors closed often work harder. Somehow they seem to work on slightly the wrong thing - not much, but enough that they miss fame. -- Richard Hamming


It's slightly amusing that everyone seem to miss the huge difference between:

    A. Individual office with open door
    B. Open plan office
I'd imagine the ideal would be individual offices with no doors:

This would create a good enough sense of intimacy and would be obvious to people that when they pass the space of you non-existing door they are entering your space so they should have a reason to do it and you acceptance. And of course, having an actual separate ceiling atop your office is important - the visual part matters, we need the feeling of "private cave" even if we agree to share it most of the time. And open space above only brings anxiety and makes you feel that you are in an open savannah and a predator can jump at you from behind the bushes anytime.

But of course, we live in a plentiful age, obsessed with efficiency (oh, the bitter irony of the contradiction...), so all that wasted space and extra paid on rent because open-office spaces are probably cheaper is a no-no...


It's slightly amusing that everyone seem to miss the huge difference between: (A) Individual office with open door (B) Open plan office

Exactly. And Hamming didn't work in an open plan office at Bell Labs. The fact that he writes about open vs. closed doors implies that they had offices with doors.

"I'd imagine the ideal would be individual offices with no doors"

Doors are very useful to have, even if they remain open most of the time:

- Closing your door allows you to have a meeting with a couple of people in your office without disturbing your neighbors.

- If you manage people, you'll need to be able to have private conversations with them (e.g., performance reviews).

- Sometimes, you really need to concentrate on a difficult problem without interruptions.

- You'll occasionally want to be able to have private, personal phone conversations, e.g., with your doctor.


> Doors are very useful to have

Then I'd use them as some kind of status token, to gamify things a bit. Mangers would have offices with doors by necessity, for private conversations with employees etc. And for the rest, if you are a lead developer, or tech lead or senior developer, than you get a door added to your office. Otherwise the hinges stay, but no door... like a hint of "when you'll get better, you'll get that door" :)


An "incentivise the workforce through privacy deprivation", eh? I'd probably take it a step further - open plan toilets. Some employees spend far too long on the John. You can't stop them from going, that would be gross and impractical. But you can use social engineering to help them remember they are there to work and to do so collaboratively.

I can't tell you how much time I've lost to the porcelain throne! (I never measured it) but I do know that I want to get ahead, and when I get to do a crap in a cubicle with a door, I'll have made it!

P.S. This is why wifi and laptops are so great. A lot of thinking time can be had on the dunny. To really get your creative juices flowing, encourage your employees to think about direction on the bog. You could get your next Gmail there. Think of it as 10% time, without need to allocate the 10%. Your employees will thank you!


Or just kill two birds with one stone and swap all of their chairs for toilets!


The CEO could be given a squatty potty instead of an executive chair. It's doable.


I find that 50% of my work I can do in an open plan or open door environment and for the other 50%, I need quiet and a distraction-free environment. Open plan definitely doesn't provide that, but I'm not convinced that open door does either -- it very much depends on the floor layout (eg how busy is the corridor outside the office?)

If its a quiet-low-traffic work environment, then open door is perfectly fine, but if not, then it won't provide the quiet that a closed door does. I don't care about privacy, I care about (lack of) noise and distractions.

My ideal setup would provide a communal quiet library-rules room with couches; sound-proofed meeting rooms with doors; breakout areas for groups to sit and talk; hot-desking space; and 1-man offices with doors. Then allow people to use them as preferred or necessary for the work they're currently doing.

Failing that, at a minimum have open-plan + plenty of silent "library rules" space.

> "when you'll get better, you'll get that door"

So, you want to sabotage my work quality until I produce better quality work?

EDIT: Forgot to say that movement (seeing people walk past out of the corner of your eye, for example) can be just as distracting as noise.


New idea: Open-office floor plans, within individualized ceilings above every workstation! ;-]


I've been thinking about that quote from time to time for a while now, and what strikes me is that his generalization does sound very plausible, but we have to remember that his experience is from a very specific context. To me it seems like having an open door at Los Alamos or Bell Labs back then, is akin to hanging around HN, certain IRC/Slack channels, and so on, today. At least for the vast majority of us, who wouldn't be exposed to such bright people otherwise.

Although I wouldn't count myself as successful by any metric, I still think I've picked up a lot of interesting and useful stuff though osmosis, stuff that a lot of people not exposed to the same things only realize a few years later when it hits the mainstream and becomes part of the zeitgeist of Western culture (and so much else that never hits a more general audience but still holds promise within their respective niches if one can connect the dots).


I think doored offices have the nice property of supporting both modes (open and closed). Closed-door mode is for getting work done, deep thought, or reflection. Open-door mode for allowing/encouraging communication with others, encouraging collaboration, yet comes with an understanding that you may be interrupted.

Open office plans force the open-door mode, and make the closed-door mode quite hard (if not impossible for some people) -- not everyone is comfortable wearing headphones all day, people will interrupt you anyway with headphones on, etc.


In addition to the ability to shut the door, the office limits noise and sights to one direction - in front of you. And it limits it to when people actually have something to say to you specifically.

Open office has you surrounded, including people behind you and in your peripheral vision. It's much less comfortable and causes a little anxiety. And your attention constantly gets ripped around in every direction.


A classic talk.

An office with an open door is still better for getting stuff done today than a cubicle, which is still better than open plan.

Ie the right tradeoff might still be to open your office door, but that doesn't say much about putting yourself into an even more exposed position.


It's a pity he never studied those who kept their door closed when they were concentrating and kept it open the rest of the time.


Yes, though it's only a talk with lots of generalizations. He probably has more nuanced views in private.


I hope you're not suggesting this as a defense of open-plan offices. Moreover, though I think Hamming said a lot of right and useful things, this isn't really one of them. DeMarco and Lister, in Peopleware, even have a whole chapter called "Bring Back the Door" -- I'd rather take productivity advice from people who actually study productivity. Such folks support the ability to close doors and gain privacy when you need it. Hamming, in this matter, is just a Monday morning quarterback. His name and awe don't mean I have to venerate everything he says. Same with Feynman, or anyone else, and especially when they are talking out of their own depth, as Hamming is here.


It's insane. Not to mention how much friction it causes for no good reason. How do you even have this conversation with your neighbor without seeming high strung: "I don't dislike you as a person but your loud typing, constant sniffling and loud chewing habits make me want to put a pillow over your face when you're asleep."


See hotdesking. An agile work environment lets you avoid this confrontation by picking up and going to sit between two of the sales team.


You nearly had me for a second there. I could almost see that coming out of the mouth of a Scrum evangelist.


Is this a joke or are you being serious? If your sales people do any work, they're incredibly noisy by being on the phone all the time.


I was wondering if the joke was a little too dry, but yes it's a joke. Our workplace recently converted to an "agile workspace" and I have sales people sitting across from me regularly on the phone. :(


You really need to be careful if you are afflicted with a very dry sense of humour. Too often you risk being taken seriously by management and your ideas being implemented.


Another great idea for sabotage. Plausible deniability for awful suggestions.


Another excellent example of why dry humour is so dangerous. Too often you risk your colleagues taking your suggestions seriously and carrying them out.

If I was in HR I'd be keeping a close eye on you.


we need full surveillance on that productivity hazard!


> If your sales people do any work

This might be the joke


...joke- hotdesking is also called out in the article.


Sounds very similar to chili dogging.


I think it was done to save money at some point, and then because so many people do it, it seems like the right thing to do now. Yet everyone who happens to get a chance at an office wants it.


Sometimes it is not done to save money. At my previous workplace we had a new CEO come in 4 years ago.

1st. She trashed talked what was done before.

2nd. she took away any coffee or tea provided for employees to use, saying it cost $10000 a year to provide them.

3rd. Then she got a plan for a complete renovation of the office space, so executive officers had offices in the middle of the building that looked out over what would be open plan offices, so that no-one had the slightest bit of privacy at all. This was not done to fit more people in.

4th. Then a move to a completely different state in the country was being talked about.

I am glad I don't work there any more.

Edit: Formatting.


So was it IBM, as someone says down thread? That's a pretty horrible sequence of behaviors. I wonder how the CEO would describe those choices? Honestly appraising the previous leader for #1? For #2, I remember when steve ballmer removed all office supplies at microsoft except for the first floor in every building, to "save money". It was kind of stupid. #3 does sound like a prison. Basically, why would anyone want to work at a place like that?


No I was working at a, I would say smaller, regulatory agency, I don't want to be any more specific than that. Probably should have mentioned that in the original post, my apologies.


Regarding #3: isn't that how modern prisons are constructed? A central "panopticon" watchtower looking out into the cells.


Well, he is talking about IBM. I guess I can see why you'd confuse the two.


Sorry, I am not talking about IBM. I was actually working at a regulatory agency. I don't want to be any more specific than that. Sorry for the confusion.


It's been well-known since at least the time when Peopleware was first published (so at least several decades) that open-plan office designs don't actually save money. Not even in dense urban areas. Not even over short time periods like 1 year.

In order to believe that they do, you essentially have to have such an unrealistically hyperbolic discount function that you believe marginal productivity of your workers is nearly worthless compared to the up-front costs of the real estate.


I don't want an office. I explicitly say no to one each year. Not to say that many people don't want one, but for me it would be detrimental. Being in an open area lets me overhear things that are useful and removes one barrier to socialising. If I was in an office I would do neither - I'm not the type to hang around the water cooler so being in an open ara combats that some.


I have met people who never had an office, so they thing that open office is great and wound't want an office...


I worked at a place with my own office and at open plan offices and much prefer the latter, but thank you for your condescension.


Okay, well I guess I am corrected, there are people who like open offices. I didn't mean it to be condescending. I have a number of friends who are devs, and they had a similar feeling to me and we made a mistake in assuming that our experience was universal (a common mistake :-)).


Working with a serial desk-napper eh?


Software is supposed to be done "with a door". Somewhere in the past 20 years (e.g. at Microsoft 20 years ago everyone had a door -- lots of studies published showing clearly doors produce a meaningful productivity benefit), we lost the battle and so we have the open office and headphones. Obviously open offices are cheaper.


It makes more sense if you think of tech companies as media companies instead of software companies. Facebook doesn't need hundreds of programmers as such, they need hundreds of people to manage their publishing platform which happens to be done using programming. This is of course true for many industries that uses software, but someone like Facebook is probably close to media than, say, manufacturing.


Open offices and headphones are the Uber model of facilities. We aren't paying for a quiet environment, you have to buy your own tiny office and wear it on your head.


FWIW, the last two companies I've worked at provided everyone with noise canceling headphones as well as a privacy shawl that you can cloak over your head and monitor.


It was at Microsoft that the change occurred: some management consultant at Microsoft issued the fatwa "beware the guy in a room". A person who isn't actively engaged with The Company at all times, who is off doing his own thing, is a huge productivity risk because he lengthens his manager's OODA loop.


If the OODA loop seriously got dragged into this nonsense, that is ridiculous. That would almost be the exact opposite of Boyd's strategy.


It wasn't described in OODA loop terms but rather in terms of "going dark". You don't want to have a developer "go dark" for too long. Of course that means that what management wants is exactly the opposite, for the developer to be continuously accountable and hence, always available.

Jim McCarthy, the originator of the "guy in a room" quote, has indicated that it's not to be taken merely metaphorically, that offices encourage isolation and "going dark", and open plan is key to productivity, collaboration, and accountability.


Jim McCarthy made that observation while he was a manager at Microsoft (not a management consultant, though after he left MS he became one). He's absolutely right - dudes alone in a room all too often are doing the wrong thing very effectively.

http://www.goodreads.com/book/show/1416996.Dynamics_of_Softw...


That feels pretty resolvable without forcing everyone to work in each other's lap wearing huge headphones.

In my experience daily standups are often enough to keep everyone on the same page and make sure no one is dashing off in the wrong direction.


As a counterpoint, I'm not sure I would want to work/program in a non-open environment anymore. Software is a collaborative act to me, these days.


Different learning styles.

I once worked with a programmer who needed to externalize thoughts before he could make sense of them. He needed a sounding board and was constantly talking to anyone who would listen and respond. That was his thought process.

I, on the other hand, need to internalize thoughts before I can make sense of them. I need silence to process and chew on a problem for at least a couple of minutes before I can talk about them to others. That is my thought process.

We worked together on exactly one feature. He would get frustrated because when he talked to me, he got nothing in return. I was too busy listening to respond and as a result he kept talking, which frustrated me to no end because he gave me no time to process what he was saying.

Neither of us got what we needed, so he finished the feature by himself and I moved on to a different one.

My co-worker loved open office plans. I hate them.


I'd say the main tradeoff of open office plans and active pair programming is that it requires a lot of empathy for the differences of others' communication and learning styles. That goes both ways for those that need to listen/digest and those that like to talk. Not everyone has the same capacity and thus would prefer to be more of a solo contributor. I am kind of in between - I love pairing but after several weeks I need a break and prefer to be an individual contributor for a while.


I'm not sure it has anything to do with empathy. You can empathize with somebody else's need to either work alone or work with other people, but that doesn't really change anything. Pair programmers still need people to talk to and no matter how quiet they are they will always hamper the efforts of those who need silence.

Something that doesn't often get mentioned is it also works the other way around: if the quiet programmers exert their influence over the open office so it's quiet, that hampers the efforts of those who need to verbalize to think. The "oppression" goes both ways.

I'm not naive. I don't think companies will ever go back to individual offices for everyone. But putting a soundproof barrier down the center of a bullpen is doable. One side is for the loud folks, the other for the quiet ones. Everyone can hop from one side to the other as needed.


Hmm, a super talkative programmer, I've never met one.


I've met quite a few. In an open office it's easier to ignore or gracefully leave the conversation. With individual offices you'll get pulled into tangential/"fun" discussions after a meeting when the team is on the way back to their offices. I could keep going, but you get the picture... After working with enough diverse programmers, you will see some varieties.


> In an open office it's easier to ignore or gracefully leave the conversation.

Not when people are having a conversation with the people sat next to / opposite you and you're trying to finish a complicated feature. An office or cubicle would help (but probably not stop these assholes) because it sends the signal that this is a workspace, not a communal chat space.


It's helpful if you don't refer to the loud folk as assholes for the crime of being themselves. I've never had a coworker tell me "no" when I've asked them if they could take their conversation to a meeting room because I need to concentrate to finish X feature. If the office is especially noisy, I'll camp out in empty meeting rooms.


We have plenty of communal areas away from desks (e.g. the kitchen area is the size of this section of office) for people to have conversations - they know this already. But open plan softens (if not erases) the distinction between "communal area" and "work area".

Also we don't have enough meeting rooms to accommodate even scheduled meetings which means "camping out in empty meeting rooms" is a non-starter of a suggestion, sadly.


I've had 2 reporting to me. I am not naturally one myself. Its a trait that has to be monitored and kept in check to certain degree but is I think a very good trait when properly focused on work (while at work).

I've had VPs ask me about how productive those programmers were with side remarks about seeing them frequently talking with front desk and hr (presumably socially). One was really productive so not really an issue for me but not good having to explain that.


> I've had VPs ask me about how productive those programmers were with side remarks about seeing them frequently talking with front desk and hr (presumably socially).

Developers like that are hugely valuable in a start-up, they talk to everyone, get to know what their jobs are, and are the people you go to when you need to know what the problems internal users are facing really are.


I feel much more comfortable having conversations with collaborators in an office where I know my conversation isn't bothering anyone else.


<thought bubble>Please don't sit next to me. Please don't sit next to me. Please don't sit next to me.</thought bubble>


From my experience it's almost cyclic. In any set of tasks there is a phase where there's a lot of direct communication to get the ball roaling, but then there will be a zone where asynchronous communication will be ok as long as a response comes within dozens of minutes. Then at the end of a cycle there will be more discussions about the produced features/goods and it sall starts again.

I wish it was easier to move from an open space model to a walled one depending on the needs. After a few years I started hating having headphones all day long, so my solution is to get away from my desk and find odd places where few people go, but it's of course not scalable nor comfortable.


Personally, I enjoy being able to talk about programming issues with the other dev without having to leave my chair, BUT we also spend more time than we should talking about Rihanna's butt, sports or whatever...


You can actually collaborate better, if you can huddle up with your mates in an enclosed space. (So you don't bother all the other people who want to get stuff done.)


Yep, that's what meeting rooms are for. They should be plentiful....


Yes, offices for say 4 people and meeting rooms for talking to people when you don't want to annoy your neighbours.


What makes you think it was not those days?


This is what the espresso machine is for :)


What type of work do you do?


The open-office movement is actually a decade-long strategy backed by Sennheiser and Sony.


I know this was a joke, but I swear by the Audiotechnica ANC33is IEMs - http://www.audio-technica.com/cms/headphones/11871cf05c62c83....

I get 15-20 hours of the noise cancelling feature out of a single AAA battery. They'll still work pretty well without the noise cancelling turned on due to their shape.


It doesn't matter if you could perfectly cancel-out noise, hand-waving and shoulder-taps will interrupt whatever flow you were having.


True, but so will a knock or banging on the door, even if it is locked.

I have an office room although most colleagues are in open office with low-wall cubicles. Still, I find I can get more done at the hours when office is empty.


I try to make the best of a bad situation - the ambient noise was a far bigger problem for me in my current location.


Lucky you, I'm the exact opposite. It's mostly quiet here, and relatively normal/plain/cheap ear phones remove the speaking around me. In that case ear phones are actually a distraction/nuisance; having to constantly take them in/out, people speaking to you having to constantly say "Sorry to interrupt", "just a quick question", because they're more aware of bothering you, etc.


Also, doctors who specialise in hearing loss (given the volume we pump into our ears to block out the noise in open plan offices), as well as pharmaceutical companies making any drugs that deal with increases in stress (another fun side-effect of open plan nonsense).

See https://tommorris.org/posts/9403


Sigh... yet another entry for the "why I don't do business with Sony" list.


I'm not sure if you missed the joke, or if I missed a joke that you just made.


No one believes me when I tell them this, but open offices are 99% of the reason why I work remotely. I honestly could never understand it.


It's easy to understand. Open plan offices have the advantage of being cheaper, and the disadvantage of harming productivity. The cost savings are immediately apparent and easily attributed. Productivity hits (or gains) come later, are harder to assign a utility to, and are harder to attribute.


My theory is that productivity hits are much smaller than we developers tend to think (as awful as it sounds). I elaborate more on that in http://www.mikhanov.com/2015/06/08/open-plan-offices-creativ...


Your theory is, to put it bluntly, wrong.

Maybe it applies to people slapping together node.js libraries, but otherwise developers need a working environment in which they can focus.

Creativity is not only about innovating at the bleeding edge, but also coming up with effective solutions, optimisation, designing software, organising code, etc. A lot of software development is creative work.

Besides, not being able to focus will also lead to increased stress levels, overlooking bugs and decreased productivity.


IMO, the fact that they're cheaper is only a justification. After all, most places are open-office rather than remote.

The big reason why management likes open office is, in my opinion, that those environments make them feel like they've got more oversight and control.


I agree it isn't the cost. It's mostly that you can see what everybody is doing. If you don't have management or processes you trust, and a lot of new employees, you worry that you will have some kind of bad behavior. Also that its easy to move people around, which you do a lot when you are growing.

I work at a startup with open offices (my second) and the absenteeism blows me away. I really believe it is because the office is an unpleasant place to work. But hey, we have ping pong tables!


I think these kinds of decisions, including recognized reduction of productivity, has to do with how desks and offices are taxed and depreciated, what has to be written into accounts, and the fact that death marches are free.


About 70% here. 30% is commuting.


Initially I did it to avoid the commute, but it's increasingly a way to get a private office where I can actually get work done. Having said that I still find the occasional visits to the office a valuable thing, but I approach with the understanding that I'm not going to be writing any code, and instead getting tuned into what the business is doing, and where I should be focusing my effort.


I believe you, because I feel exactly the same way -- I work remotely because I find open office plans very distracting.


I'm part of a development team that resides in an 'open office.' One member of my team has told me that he likes the open plan so much that he'd quit if forced into an office/cube situation. Most others at my office have expressed a mild preference for the open arrangement. I certainly don't think it has negatively impacted the productivity of anyone on my team.

It seems to me like the real questions here is "what is the percentage of people who are more productive with offices than with an open arrangement?" Based on the comments here on HN, it's skewing toward offices, but I think that might be a self-selection thing. I certainly don't think it's a forgone conclusion that offices are better for everyone.

Incidentally, I have a marginal preference for offices, and I have gone the expensive headphone route. I guess I'm in line with the "HN commenters" sub-population :)


The employees often prefer open office layouts because they get less done. There is a lot more distraction and a lot more hob-nobbing. Little things that someone would've solved on their own after a few minutes of troubleshooting become a group troubleshooting session, etc. People who are not actually interested in their work but just like to hang out with the people they work with (probably at least 85% of employees) tend to like open plan offices because they make it "more fun". Productivity does decline because any work that requires concentration is substantially more difficult to perform.


When you say categorically that "Productivity DOES decline because any work that requires concentration is substantially more difficult to perform," you're assuming that the majority of people have a harder time concentrating in an open office environment. Based on my own observations, I don't think that's true of every sub-population.

It would be interesting if a researcher tried to quantify this with volunteers from different companies with differing floor plans.


There are multiple studies which confirmed that background noise impairs concentration, increases stress levels and disrupts clear thinking.

Interestingly, even if one consciously ignores the noise, its effects are still visible in the body through blood pressure spikes, increased stress level hormones, etc.


Sources? I'd be curious to see sample sizes and if this was true for 100% of study participants.


>People who are not actually interested in their work

So, by that vein, do you prefer having lunch breaks where you eat at your desk or do you not care about your work? Which is it? Because clearly working through lunch is more productive, so if that's not your choice then you are lazy and not motivated.


That's a false dilemma. Break time is break time, and it's probably better to take it away from your desk for a variety of reasons, no matter how productive you want to be.

However, open plan offices make it so work time is always noisy and you have to work to avoid making eye contact with others. That's going to make it much harder to be productive, regardless of how much productivity one desires to achieve. Employees who prefer chit-chat to productive work are going to prefer open offices because it decreases productivity on the whole, which means they'll have to compete less with others to appear useful, and because it makes it much easier to start a conversation and otherwise engage in non-work social activity.

To clarify, I'm not saying there's anything wrong with preferring chit-chat to productivity per se (again acknowledging that this is the preference of the vast majority of employed persons), especially when management is sending a clear endorsement of that perspective by literally removing all barriers in the office and throwing everyone into a giant single room. I'm just saying the people who are usually annoyed by open plan offices are usually people who come to work to concentrate on a task and get it accomplished, rather than people who come to work mainly for the external social engagement.


Going through lunch will be more productive short term, but longer term one will become sick. My guess is that it's due to not taking breaks (one needs to unwind when eating) and stress levels building up.


Not true. Your brain does need a break now and then. It actually helps (given the right timing) to leave and talk a walk now and then.


I'm clearly the outlier here - reading through the rest of the comments - but I actually hate working by myself. Given the choice between a private office and a shared table at a coffee shop I'd take the coffee shop every time. The thing is, for me it's not about social interaction. I just enjoy working amongst other people who are also amongst others working. Something about the energy I guess. Sounds silly when I write it out.


I think this may largely depend on facts like whether you are naturally introverted/extroverted, and how you grew up, or learned to program.

For me, I learned to program as a hobby, from ages 10-18, for fun at home. I mostly worked alone. Learning to work on a team took some time, but even now I often times wish I could work remote. I don't mind getting pinged about things people need, but the constant noise and movement of the office makes me far less productive than I would otherwise be.

However, sometimes it offers me the focus I need to actually work, if I'm in a procrastinating mood. And I think some people probably struggle with this more often than I do.


I'm in almost the same situation as you, of learning to program alone at home and introverted in general.

I feel much more productive working in an open-plan office than working alone. :s


I like working at coffee shops because the hum is relatively constant and comes from all around. At an open office plan, in my experience (which is mostly non-mixed: all developers, no sales people), it'll be relatively quiet until someone's phone rings (and invariably they're not at their desk and it rings for a painful 30 seconds)/someone takes a phone call/a group starts talking or joking around. Since there's only one single point of noise, I find it much more distracting than if the entire area was mildly noisy the entire time.


No one should have a phone on their desk in an open plan office.


Honestly, the cell phone ringtones are far worse than the office phones (which everyone has as well).


didn't know i got downvotes and i fat fingered one for you, so i guess i'll contribute...

I agree with your sentiment. Being nearby passionate workers is empathetically energetic, and adds motivation for me to do even mundane tasks. I develop a sort of weak rivalry around my peers and I'll rise to the "highest" level that I perceive. It's very encouraging to be around intelligent and motivated people, and being exposed to them is nice.

Conversation/talking can get out of hand, but that depends on both who's contributing and who's not intervening. I've only had open office conversations go too far when nobody wants to tell those involved to stop/quiet down/etc.

I think for a lot of the professions on HN, the solution to "open office bad" is to work remotely, and I think it's very unfortunate when employers disallow/discourage that options, as many people are genuinely more productive at home and/or working odd hours. While there's a pretty decent stigma of "working" from home, there are some people who genuinely are productive and can actually work from home, no quotes needed.


Yeah, you described it better than I did :)

I contract full time as well as working on my own projects. I'm often called in to augment other teams either IRL or remotely and I genuinely do enjoy that, at least in the short term.

The other days though - I wake up early, a full queue, clear scope, plenty of energy, coffee, work while the sun's rising. 11am hits and all of a sudden it's just...lonely. Hit's me like a brick some days. That's usually when I head to a coffee shop or into some co-working space. It's a funny thing.

Edit - Spelling


Has anyone done a study on the long term effects on hearing and bacteria growth from long term headphone wearing.

It makes me mad that people think fixing the problem is wearing headphones.


Especially since wearing headphones for long stretches of time tends to give me a raging headache.


Same, but I typically take that as a cue to stand up and go outside, sitting all day is also phenomenally unhealthy.


I wish I had the freedom to work from home, I've done it a few times and I'm not just marginally more productive, I'm exponentially more productive and more communicative because I'm aware that people can't see what I'm working on and so we don't end up fixing similar things. (although that could change if I got used to it).

I wish wish wish! I had some modicum of privacy and sanctuary at work so I could just sit down with only the problems in my screen unless intentionally interrupted.


Perhaps you need to find the appropriate employer? I work remotely as often as I'm in the office and our office has many devs who are permanent remote (does require more coming into HQ regularly for sync ups - less for frequent travelers like consultants or salespeople).


I'm a systems administrator, our roles typically are less free in movement/time than developers unfortunately. I've been looking for an employer who will let me work from home for a good 5 years.


I have a couple of work-from-home sysadmins - look for tech contracts based out of SV or other hubs where they might not care where you work.

Unfortunately these do tend to be contracts rather than employment oppties, but that can sometimes be good (higher rates, though you need to buy your own benefits).


My experience is that open office productivity depends an awful lot on who is in the office.

When it's just people coding, normally interruptions are things that make sense. How should I build this or that thing? Where can I get help with X?

However, for many years I had a guy in the office who was a pontificator. He would read some news article and start a debate about (inevitably) politics. People would get drawn into it due to his particular style (very opinionated, uninformed) and the debate could easily eat up the entire morning or afternoon. He would literally stand up and announce some funny point he'd come across, loudly.

Ate up enormous amounts of time.


The only thing an open office is for is walking potential investors through, waving your arm grandly.


"Our engineers per square foot is higher than any of our competitors, as you can see."


... and we have started work on vertical stacking to solidify our lead.


It also:

a) saves money on furniture and real estate costs (visible on the bottom line; productivity losses aren't)

b) provides for free a panopticon under which your boss knows where you are and what you are doing, or can at least ask your coworkers and expect them to point you out to him


Yup, open offices primary benefit is surveillance and control. Management is happy to sacrifice individual productivity for more control over workers.

Surveillance is a useful tool for sucking surplus value from our minds. Open offices make ordinary workers (slackers) uncomfortable because of constant surveillance by management, but work isn't about making workers content. Work is about dominating workers so they produce.

An added benefit of the panopticon pen is that it's harder for devs to slack, sabotage, and organize. A watched worker is an easily controlled worker.


Is there a list of tech employers who do open plan, low cube, high cube, shared office, private office, private big office (to have people work together temporarily), remote-only?


I think it's a status issue.

Actuary is respected profession. There is lots of responsibility and they have higher median salary than programmers.

Programmers are dime a dozen. Only top level architects have status. If programmer is highly valued, he usually has some other title than programmer/developer.


Alas, even people at Google and Facebook etc, who can (probably?) hold their own against actuaries in terms of salary don't get offices.

Of course, most companies need only a few actuaries, so giving them a handful of offices is easy. If you have a company that's mostly engineers, that's gonna look different to the beancounters.


I'd honestly prefer cubicles to an open office layout... At least the former offers some degree of privacy and protection from visual distractions.


Please don't promote cubicles. I hate sitting in a little box the whole day. It feels like prison.


I've worked in both, and the open office was far worse for me.


On a scale from 1 to 10, open office is 2 and cubicle 3, an office is 10. Maybe it's a little better but it still sucks.


Yeah, I'm not exactly a huge fan of cubicles either, but I definitely consider it the lesser of two evils if I had to choose between cubicles and open offices. Private offices would be amazing, of course, but it's not realistic to expect most startups to be able to provide one for every developer given the real estate market in SF.


If they cared they could provide smaller offices, maybe one for 4 people or so. This works pretty well too.


And an office with a nice plant (rubber, snake, spider, palm, etc) in it really turns things up to 11.


After a decade or two in open offices, many software developers probably end up conditioned against privacy enough that they no longer see how offensive spyware/tracking is to most people.


As a European there's absolutely no way I would EVER work in a cubicle. It looks horrible to me, like I'm a chicken in a battery cage. Aside from not wanting to work in a horrible environment like that, I communicate a lot (about work) and it's so much harder to do that when you're physically separated.


I'm in a cube at my current employer. I like that I don't constantly see people walk by my desk, and that the three developers I work closest with are right next to me for easy collaboration, but with enough separation between us to allow us to easily work on separate tasks without minor movements jostling a desk, etc.

I also like that we each have a whiteboard, plus whiteboards in the "hallways". Anything important tends to go to text, one way or another.

I'm apprehensive about working in an open-plan office, or some arrangement with a shared desk. One concern is constant movement in my peripheral vision. Another is degradation of communication. I like my text. Having something written means that I don't have to ask someone to repeat themselves again. Add to it: Half my team is remote, so no office layout will change how I communicate with them (IM+email).

Then again, I've never worked in an open plan office. Maybe I'd like it, and the things that I see as potential issues would dissolve away...but it seems like a panopticon-distraction fest, looking at it from the outside.


Open office plans wouldn't be so bad if companies implemented a "quiet zone". It would be cheap and efficient to have a quiet room with college library style desks like:

http://www.wiregrass.edu/images/library/benhillLibrary.jpg

The people who thrive in open office plans can thrive while the people who need some space can have their space.


It's popular to hate on open floor layouts, but I personally find myself more productive in that environment than with a private office. I think little moments where a quick chat with another developer, a manager, a project/product manager/business analyst clears things up or unblocks me are more frequent than times when I need intense deep quiet uninterrupted concentration.

And it's easier to indicate to the rest of the team that you need to be not disturbed with stuff like those expensive headphones than to go wander the hallways to other people's offices, or have to organize meetings whenever you want to have more than 2 people in a quick huddle.

If you're working from specs on a multi-month timeline, sure, lock me away into an office and I'll come back with what you asked for. But if you want to work quickly, build MVPs, iterate with customer feedback, and change direction quickly, an open floor layout is infinitely better even if it makes a couple antisocial engineers grumble about it on their blog.


As a counterpoint, I'm usually the guy that people ask questions to, so for me it is an obvious productivity drain. Working from home however isn't a solution either, because somehow I cannot make the mental switch to "work mode" as easily. I would love a separate office with a door that closes so I could control interruptions more effectively.

The irony is that at one point for a two month crunch period they did give me exactly that (repurposed a meeting room for me and a team mate who was not very talkative). Most productive two months in my entire career. So, management clearly knows the open plan is detrimental to productivity. And yet...


Any thoughts on leaving Actuarial work? I was thinking of going the other way.. a consistent education/testing seems like it fixes the eternal new wheels and pop experts problem of software as a career.


Actuary is a great cozy career (less exciting in both good and bad ways). I recommend it if you like it. The only downside is limited geographic range.

But for me, software is a calling.


Well the majority of good software jobs are going to be geographically limited as well, unless you have the skillset and experience to break into remote work.


Is there such a thing as developing software for the actuarial industry?


Yes. It's demanding, well-paid and hard to break into.


I work at a life insurance company in NYC. Feel free to ping me if you're interested


Yes. I had a talk about this in Hacker News a while back, when I was deciding on whether to go into software or become an actuary. You can do both.


We (Pivotal) have an open office layout everywhere because all coding is done in pairs, the concentration still happens this way, except you're vocalizing your inside voice with your pair. And they're providing active feedback. Two screens, two keyboards, two mice, but one computer/desktop.

It's not for everyone, but in tandem with mandatory-no-meetings beyond a 5 minute daily standup and couple of set hour-long meetings every week, this can lead to very productive working days.


I had a chance of visiting the office of Pivotal Labs in London for an interview (this may or may not be the one you're talking about). The open plan layout they have is by far the worst I've seen. Here's why:

* The office zone starts right behind a reception and only separated from a receptionist by a thin glass wall, slightly wider than receptionist's desk. When I arrived, reception wasn't manned, so after hearing me ringing the doorbell several times, some developer interrupted his pair coding session and walked down with an irritated face to open a door for me. I can only imagine how many breaks in coding do FedEx delivery people ensure.

* The open plan office itseld is slightly prolonged and has long "corridor" areas cutting through it. I can only guess why they want to maximize the number of developers whose backs and monitors are turned towards everyone who passes by.

* The desk density is super high (it may even beat Facebook's, but my perception may be wrong here).

(update) Also, during a pair coding session I took part in, two men and me were enthusiastically discussing the code we wrote. 40cm away, at another desk someone was trying to get on with their work and was visibly irritated. So it might be that open plan is not so great for pair coding after all.


> The open plan office itseld is slightly prolonged and has long "corridor" areas cutting through it. I can only guess why they want to maximize the number of developers whose backs and monitors are turned towards everyone who passes by.

I remember watching a video about Pivotal's offices and work routine. The distinct impression I got is that Pivotal is a very regimented sweatshop with rigid working hours - everyone is expected to show up at 8am for breakfast, and pair-programming and a "panopticon" style open office layout are there mostly to prevent procrastination and force people to at least try to code. The good part is that the developers there have a set 8 hour workday and leave earlier in the afternoon. It obviously works for them because they can just churn out sort-of working apps and let some other suckers deal with maintenance/rewrites later.


"very regimented sweatshop ... The good part is that the developers there have a set 8 hour workday and leave earlier in the afternoon"

You use the term sweatshop, and then say everyone goes home early. Really?

" rigid working hours"

Business hours are not for everyone, but they are for a lot of people, and they help foster collaboration.

"everyone is expected to show up at 8am for breakfast"

Not mandatory (it's an incentive to come in on time), but it is free.. As is lunch. Not dissimilar from most SV companies.

"mostly to prevent procrastination and force people to at least try to code"

So, it's a sweatshop because people are encouraged to work, and not browse Facebook behind a closed door?

There are lots of opportunities to take a break, from Xbox to ping-pong.

"It obviously works for them because they can just churn out sort-of working apps and let some other suckers deal with maintenance/rewrites later."

This is quite a conclusion to draw from a video.

You do realize that outside of R&D, most Labs teams are balanced customer/Pivotal pairs? There is no belief in handing over to a maintenance team, let alone doing the development by ourselves. You build it, you run it, is the mantra.

The whole business model is to build products while teaching companies a culture (open, Devops, collaborative but high discipline) and process (XP, CD) and tools (PaaS, open source) of how to build software productively.


> So, it's a sweatshop because people are encouraged to work, and not browse Facebook behind a closed door?

It is a sweatshop because management is trying to impose a rigid pace of work and a surveillance scheme on employees.

The word "sweatshop" is traditionally (AFAIK, don't have access to OED right now to confirm) associated with garment cut-and-sew workshops, which are organized exactly like an open plan programming office: https://duckduckgo.com/?q=sewing+factory&t=ffsb&iax=1&ia=ima...

The false dichotomy you present (you are either working exactly like we tell you to work when and how we tell you to work, or you must be slacking off) is exactly the kind of rationalizing used by sweatshop managers who are trying to break unions or deskill workers. I recommend reading David Noble's _Forces of Production: A Social History of Industrial Automation_ and Ellen Rose's _User Error: Resisting Computer Culture_ to learn more about how and why these efforts are used, why they are counterproductive, and to learn how to recognize when management is trying to apply them to your work as a computer programmer.


"It is a sweatshop because management is trying to impose a rigid pace of work and a surveillance scheme on employees."

Sorry, that's nonsense. Instead of "rigid" and "surveillance", I'd say "disciplined" and "actually managed". As opposed to "do whatever you'd like" and "unmanaged".

What's the difference of a disciplined culture and a rigid culture, or surveillance vs. actual management? I'd say it's whether the employees actually WANT and VALUE these things.

In my experience, everyone here WANTS a strong discipline of TDD, pairing, CI/CD, 8 hour work day, etc. And everyone WANTS a strong product manager and product owner that knows what's going on with the latest stories, bugs, and velocity. It makes for a better product, team, and morale.


Try sprinting at full speed for an hour.

Now try walking normally for an hour.

Which makes you the most tired?


Sprinting, obviously.

I'd posit it is a much more fulfilling experience to put a full 8 hours x 5 days sustainably, than the industry's usual "crap we need to work evenings and weekends, we're late"


I'm not saying you are a sweatshop, merely pointing out sweatshops can still have workers who operate during normal working hours.


I hear you, but I'm saying that's not the generally accepted use of the term which is: long hours, socially unacceptable working conditions, and low wages. It conjures up the image of something that warrants legal/political challenge.

I could see this being argued for the traditional game development industry, which was plagued by long hours, harassment, and shit pay.


That's a fair point. It was wrong to call Pivotal a sweatshop, I've never worked there or even visited so it would not be right to call the organisation that. Actually, I didn't mean to even imply Pivotal was, I was more focussed on a very narrow point so if I gave you the impression I agreed then I apologise because it isn't the case!

I think you've already recognised the work hours aren't for everyone in your previous comment, so it sounds like Pivotal's hiring policy is pretty solid on this point. And in fact, it's not even an unreasonable expectation for everyone to come in on time, but probably a less popular one on HN judging from the downvotes you are getting.

To be honest, it's a model I prefer. In my previous workplace I worked ridiculous hours due to understaffing and a few other issues and had to resign from burn-out. I'd much prefer to work for a Pivotal than I would a company like the last one I worked for :-)

Heck, if Pivotal can get all their work done without a final crunch time, that's actually pretty amazing! I'd go so far as to say that I've never heard of a company who got this working before, so if that is the case then Pivotal are clearly doing something right.

If only you were hiring in Australia, I'd seriously consider applying :P


"I'd go so far as to say that I've never heard of a company who got this working before, so if that is the case then Pivotal are clearly doing something right."

I hadn't really seen it before either, TBH. It is not perfect - sometimes we ship late. But that's part of the culture - Pivotal Tracker (www.pivotaltracker.com) tells you the date you're expected to ship given the work you have left, you don't tell it when to ship ;)

Management won't break people over a deadline, they'll generally slip the date. Sustainability is more important.

We do have a small/growing office in Sydney with a few openings: http://pivotal.io/locations/sydney


Good feedback (yes London is one of the offices). I haven't seen that one but it sounds more cramped than the ones I've visited in other cities and has a different layout. Most offices have a large separate lobby area (always staffed with a receptionist ;) away from desks , close to the cafeteria/presentation area.

Sorry you had a disappointing experience.


How is an open layout better for pairing than a shared office?


It's not.


Pairs switch up every day or two and people switch teams every 12-16 weeks or so. Also there's a strong belief in "open door" policy for impromptu conversations with the product managers or other devs, and in having build/test/CD pipeline status screens visible by the team at all times.


So the status quot is one of constant churn and never settling into any kind of groove, ever.

Sounds extremely stressful


If you're in a small team, you get to know everyone, and cross-pollinate the various skills some individuals may have over others. The groove and "team gel" happens within a couple of weeks.

It's not for everyone, and there are some "consulting" individual contributors here and there, but the point is to have a sustainable pace that's always "busy" and everyone is "checked in" rather than have a few weeks of "crunch time" to meet a deadline. Some need to "check out" for a while, that's also fine.

Most product cycles last 3-4 months, and it's up to you if you want to switch teams. some don't.


theoretically less friction in 'switching pairs': finding a new desk when you start a new task with a different person should be easier than giving up an office


I worked at Pivotal (as a client), pairing 100% of the time in their open office. I liked the guys I worked with but despised everything else about it. Quitting that job to freelance and work remotely was the most liberating and healthy thing I've ever experienced.


This is the only career I've ever had, but so much about it is nonsensical to me. We are smart individually, but at a team or organizational level we are real idiots.


I for one prefer open plans for developers - and everyone else. A) The headphones are just a dime in the wider context. B) Sure, if you are working on the next video compression algorithm then concentration is golden and you rightly deserve a hut in the middle of endless flowerfield by the lake high in the mountains (Howl's Moving Castle style). Otherwise the ability to constantly share information with your colleagues and management (both ways) is way more important. The proverbial 9 out of 10 startups fail not because their developers could not achieve deep concentration and if you can not write JavaScript with your headphones on (on a train, while the kids watch TV, in a buzzing open plan office) maybe you lack important work skill.


My problem in the open office plan is that I can't wear headphones for extended (or even short) periods without my tinnitus getting set off.


I am sorry to hear that and I totally agree that the open plan is not better for everyone, all I am saying that it is not inherently bad for everyone.


Code that doesn't require deep concentration is boilerplate that should be machine-generated if it's needed at all.


Sure and trucks should not need a driver but they still do. 99% of the work mankind does does not really require deep concentration, including most of what the IT departments do.


> The most shocking part of the career change was open office arrangements.

Does any company give new software developers offices?

Software developers grow up with more screen time than others. They need forced interaction in order to communicate enough in person. Otherwise it's all by text and can easily degrade to passive aggression.

Offended? Cool.

When software engineers demonstrate they will come out of the office to speak in the open when needed, then they deserve the office.

But, I imagine if you gave everyone one, many would hide in there and only exit for the bathroom and food.

An A/B test of workplace environments might be a cool experiment. Targeting the same product with equally skilled developers, which is more successful?


'hey! look at these introverted developers' meme

As an extremely vocal individual, being vocal actually is a loss in productivity. When I am trying to communicate what I am doing to my co-workers - it leads the project from slowing down - and me unable to meet my deadlines.

This is why I do not like to waste my time explaining others what I am doing. Its more productive for them to specify the Inputs and Outputs and me doing my thing.


> being vocal actually is a loss in productivity

You're talking about someone who is too noisy. This kind of person probably benefits from an open environment with instant feedback. Even though the group may suffer a bit short term, in the long term, that person will be a better team member when they learn when and how to speak.

People who are too quiet can also benefit from being among a respectful group. Safety in numbers, and you can learn from your peers.

These are not hard and fast rules. I'm just discussing times when open environments can help teams. The parent of this thread did not mention any of the benefits of open offices.


You made a pretty sweeping assertion about software developers. Is this an anecdotal observation or do you have any empirical data to back it up? Genuinely curious...


You mean this? -- "Software developers grow up with more screen time than others. They need forced interaction in order to communicate enough in person. Otherwise it's all by text and can easily degrade to passive aggression."

Yup it is a sweeping generalization. I'm comfortable making it. I am/was one. It's totally anecdotal, based on my 15 years experience in work and school environments around both engineers and sales-y type people. The engineers are, on the whole, way more comfortable with screens than people. There's absolutely nothing wrong with that.

I'm not aware of any published research but if I were going to design an office I'd try to research people's experiences by asking friends or Google [1]

All engineers are different and there are many who prefer people to screens. I think the rest of my first comment explained that people are not all the same and can change over time.

I would never create an office seating plan without getting to know each individual. I would also change it up over time. Sitting in the same place all the time for years is too boring.

[1] https://encrypted.google.com/search?safe=off&q=software+engi...


I see where you are coming from, it's just I doubt your premise. I don't think your average software developer grows up with more screen time than the average teenager playing XBox360 or PlayStation III. Heck, I know accountancy and law students who were socially well adjusted that played more Counter Strike than I did messing about with my Linux system when I was a student!


> I know accountancy and law students who were socially well adjusted that played more Counter Strike than I did messing about with my Linux system when I was a student!

Sure, there are individuals at any point on the scale. We're talking about averages though.

I have no qualms about disagreeing over where the averages lie. In fact I would widen my generalization and say that younger people are, on average, more comfortable talking through screens than directly person to person. Young engineers are just a subset of that who I think are more likely to be screen focused.

I'm okay with embracing some elements of stereotypes. Denying them entirely seems like an equally useless generalization.

This sub-thread was started by someone who felt open office environments aren't effective. Yet, open offices can be a tool for getting people used to person to person interaction. Every person, group, and organization will decide whether they think that's important or not.


Just a small difference of opinion, I honestly asked to understand where you were coming from :-) I've also got only anecdotal information, in all likelihood you could be correct!

Open communication within any organisation is very important so a developer who sits in his own office all day is a concern I'm in agreement with you. I guess I'm just not convinced of the reasons for the behaviour. But I think your observations are interesting and valid, so I appreciate you taking the time to give me a solid answer!


Sure thing! Thanks to you also for making me think =)

> I guess I'm just not convinced of the reasons for the behaviour

Reasons for behavior, even for a single individual, are super tough if not impossible to nail down. But we can make some educated guesses based on correlations. If we prevent ourselves from forming such hypotheses, life might get pretty boring. In hindsight, my original statement could be more accurately prefaced by "in my experience, ..."


I'm a developer and I like open offices. Sure, you have to be careful of your neighbors and don't interrupt them consistently. But, unless your coworkers are complete douches, this is pretty much easy to do.

I like to answer questions, technical or not, and it's really nice to be able to exchange ideas with someone (who was lurking on slack, anyway), from times to times.


An open office is essential if you're pair programming.

If not, I agree it makes no sense. I guess it can cut down on frivolous browsing.


An closed office/cubicle is fine for pair programming. You need room for just 2 people, not 20.


But I want to talk to the rest of the team fairly frequently.


I mean this in the nicest possible way ... Are you sure they want to talk to you ... frequently?


I've worked this way for several years, in a few different teams.

I guess it sounds weird if you've never done it, but it works really well.

Now and then, someone will ask "Hey, does anyone know X?" or something else, and issues will be resolved quickly. One counter intuitive thing that makes this possible is that since you're already engaged in a conversation with your pair, this turns out to not be disruptive.


i think that type of conversation is better suited for a Slack chat


To me, that suggests pairing would prevent me from ever starting to deeply concentrate on a problem.


Unless you are also switching pairs frequently, then this is not paired programming.


That is what chat is for. Bonus, it works whether you and I are breathing the same oxygen, or if we are on different continents.


This raises an interesting question, how do you become a deep worker if you're pair programming? I guess it's because the pair is both working on the same problem and can both get deep focus on that problem. Implies they should have their own office though.


You don't become a "deep worker".

Concentrating deeply means you're keeping too much state in your head. Write more tests instead. If it's still a problem, bring a co-worker over, or better yet, pair program. It's not the 1980s anymore, this industry is not for solitary special-snowflake hackers. You're a part of a team -- like a node in a cluster -- and the team's productivity is what matters.


At first I thought this was serious, but I'm not sure now. Surprising that a couple of responses to the grandparent say that programming doesn't require deep focus!


Trust me, it was surprising experiencing it too!


It would be nice if those pesky humans could somehow be re-programmed to behave more like the nodes/cogs that they truly are instead of being mere... free-spirited individuals. Then our ideal of the pair-programming, cluster-based corporation would become reality, comrade.


Why stop at pairs? Clustered collective consciousness is the clearly the future of programming. ;)


Hence all the meetings.


I used to think I needed deep focus and concentration to program. Then I started pair programming. I never got that deep focus, and I became very much more productive!!

Wound not have guessed that!

Now I think that if you need to focus very hard to program, you code and/or design is way to complicated.


1) Promote based on tenure. If they found your company first, they're a priori more dedicated and therefore better qualified to lead.

2) Promote into/within people management roles based on their skill as an individual contributor. E.g. the better the programmer, the better they will be at managing programmers.

3) Create a set of company values vague enough to be meaningless. Enforce them selectively and only when convenient.

4) In the name of inclusiveness, expand meeting invitations to anyone who could possibly be affected by anything talked about. Refer to them as stakeholders. Be sure to include anyone whose job is unrelated but may be interested or have an opinion.

5) All goals should be subjective. The subjective meaning of the goal should change based on timing, external factors, mood, or self-confidence. If you aren't happy, someone (else) is doing something wrong and you should immediately switch directions. This is especially important in hiring.

6) In all meetings (see 4), require consensus.

7) Set individual performance metrics based on effort. Strong indicators:

- Individual sends emails late at night

- You see individual in the office late at night/early in the morning

- Individual speaks frequently in meetings

- Individual always seems so busy

8) Hire based on pedigree, especially from names you know. If they did not attend the Tier 1 school (Stanford), they're probably not an A player.

Recruit from companies with entirely different problems from your own. For example, if you're a small startup, target executives at Google so they can make you into Google. If you're a large company, acquihire small startups to inject agility and hunger.


Great list.

Some general commentary: companies don't get this way because people are stupid. They get this way because people hyper-optimize for their own self-interests. Everything on this list is a way to show off, suck up, or CYA, all of which occurs because people want to stay employed and get promoted, and they implicitly optimize for more immediate, local rewards like positive social feedback from the colleagues they see on a daily basis.

Abstract and macro-level concepts are difficult to grasp and people have soft, differing opinions on them. However, people who work with you daily will come to "know" that you're a super hard worker if you're sending out emails at 4am. Including the company's Controller in a database schema design meeting not only gives you a chance to demonstrate your know-how to someone else in the organization, but also wins points for being careful, considerate, and cautious.

When promotion time comes, the less-visible heads-down coder who's been working hard and churning out bugfixes gets a lot less credit than his more boisterous, gregarious counterpart, who's been more focused on grooming personal biases in his favor than actually plugging in commits.

In theory a good corporate leader is supposed to make sure this kind of stuff doesn't happen, but they're only human, so really 99% of people operate this way.

What it translates to is that if you want to be a successful employee, remember ABC: Always Be Campaigning. Your primary job duty is popularity.


That is why focusing on the performance of the team is probably a better idea.


> For example, if you're a small startup, target executives at Google so they can make you into Google.

That is a warning in Robert Townsend's book 'Up the Organization'. He mentioned small corporations didn't become large corporations by acting like them. Beware of hiring enterprise level managers.

Sometimes I think this is even true for larger companies, See Atari post acquisition,Apple post Jobs 1.0. And Microsoft Ballmer era.


This is scarily accurate for Japanese companies.


Well done. Corollary to #4: expand email "To" field to anyone who could possibly be affected by anything talked about.


4(c). Make sure to include company@ in the BCC field of every email you send, just in case your email affects someone you don't know.


Better tick that "high-priority" flag too. Your message is more important because it is from you.


And make sure you turn on the read-notifications. Nothing makes clearer just how important your message is than that - besides, nobody can claim to not have read your email because you'll know they did :-)


I had to check and see if you work(ed) at my previous company.


Stop reading management advice mumbo jumbo, treat others with respect and be thoughtful in your actions.

Lots of people in the technology industry and corporate environments are too focused on performance metric dick measuring contests and moving up in the pecking order.

All I know about someone who went to a "Tier 1" school without talking to them is that they wasted their youth doing whatever nonsense you need to do to get into said school.


I agree that this is the natural answer to "How do I run a good company?" I used to believe there were places where this type of management was possible. I think it's still possible with really small companies, but I don't believe that it will ever be that way with a company of more than 15 employees anymore. People are political creatures and unfortunately, the selfish actions of a few require the rest to act in their own selfish interests if they're not going to get destroyed by someone playing by a less noble set of rules. The net effect is that all but the most naive understand that self-preservation is the name of the game and that the company or team's efficiency is a secondary concern (if it shows up on the radar at all).

The funniest thing about this is that the people who are hired to prevent political ambition and malfeasance from affecting the company's output are often the heaviest polluters.


My original comment got voted into oblivion, so maybe I'm hitting the pipe on this topic. :)

That said, I've worked in really large organizations with plenty of weird bureaucratic artifacts which nonetheless treated people with integrity and respect. Good leadership who embraces that idea and low tolerance for bad behavior is the "secret".

In my observation, the level of nastiness and bureaucratic battlefield bravery is inversely proportional to the stakes at hand. People will murder each other over a 2% raise, but not lift a finger while an obviously bad decision puts the entire company at risk.


A lot of these read more like workplace complaints and poor management processes. The point of the original was how an individual already on the system could perform small acts of sabotage.

My list would be: 1) overestimate small tasks 2) Corollary to #1, underestimate large tasks 3) Find reasons to take the overestimated tasks and perform them slowly 4) Encourage your colleagues to take the larger tasks 5) Encourage bike shedding. Frequently evaluate your code standards. 6) If you are in the position to do so, enforce a terrible naming standard. 7) Write slow tests 8) Write useless tests 9) If you notice a coverage gap, try to introduce a subtle bug

As a manager: 1) Discourage specialization in favor of "flexibility" 2) Assign tasks to those with the least domain knowledge, within reason 3) Avoid letting more than a single developer work on a particular system/increase the "bus factor" 4) If you are able, under promise and under deliver 5) When brought new ideas or are asked to use new tools, be very encouraging but say you need approval. Never ask for approval.


The upvote button wasn't enough for me. Thank you for extending the ideas of that work place sabotage concept for modern tech work, like Stross implied he would. I'm not sure what to really learn from this sabotage idea, but your comment pointed out many of the obvious flaws in how things are done currently.


Am I the only one here who doesn't understand posts like these? Anyone who's had a job or read a Dilbert comic once or twice can come up with lists like these.

The difficult part is doing all of it right.*

Look, I appreciate the history here, but nothing in the article ties back to actual planned sabotage. Do companies actually do this? Are top managers paid by competitors to break the companies they run? I mean, nearly all items on this list require C-level executive powers to effectively implement.

In all honesty, it feels to me like this article is more about how happy Stross is about his career change than anything else. That's a perfectly good topic, but can we turn this around? What's good, actionable, advice for (aspiring) managers, founders and employees? What's the oppposite of active sabotage? And can we encourage active, constructive anti-sabotage without becoming a creepy cult?

*) HN used to have lots of submissions about how to run companies right. Is it just me, or have those disappeared somewhat?


> What's the oppposite of active sabotage?

Isn't this exactly what an article like this is attempting to ask in the first place, albeit through irony and story-telling? I agree it's hardly ground-breaking, I guess it's just trying to make readers feel clever because (clearly) we'd never be stupid enough to do something like that. (Although it's worth far more to me, at least, when you get those articles saying "I did something stupid when I thought I was being clever," because if we're honest we all do things like that.) But I think OA is trying to discuss "how to run companies right."


> HN used to have lots of submissions about how to run companies right. Is it just me, or have those disappeared somewhat?

I interpreted this as being one of them.


How? He provides no tips or guidelines for what to do, only some snark about what not to do.


"Do Not Enter" street signs are useful.


It's the principle of "first, do no harm". Almost nobody follows it, but there are good reasons it is the first and in many circumstances the only real piece of advice that can be given. Look up 'via negativa' as well and daoist wu wei philosophy if inclined.


The point is to highlight common practices in this industry today that result in effective sabotage.


Read my comment above[1] and do the opposite. If you are not in management, manage your expectations to do what is best for the whole.

For example, if you are the first employee, do not expect to lead your team just because you were there first.

Here is the positive advice version:

1) Do not promote based on tenure. Talent is not 100% correlated with age or (especially) time at the company. Oftentimes the employees who thrive at early companies are generalists or love diverse responsibilities. These may not be the problems you're trying to solve later.

2) Do not promote into people management roles based on individual contribution. To be sure, knowing the problem domain is important, but, especially in engineering, people management skills are orthogonal to programming ability.

If your HR structure caps salaries for individual contributors to the point where ICs are forced to move into management, either change that or (if you determine there is a maximum value of an IC) stick to it.

3) Choose values that are specific to your company and can be reasonably disagreed with.[2] Stick to them, especially when it is hard. Values don't matter when it is the easy choice; they are defined by what you do when shit gets hard.

4) Narrow meetings to only those who provide knowledge which is Mutually Exclusive and Collectively Exhaustive. If someone does not add something that no one else in the meeting does, remove them. If others need to be updated, send them a summary.

Having an opinion does not qualify it as useful. This is also the first rule of being a CEO and the first rule of hiring product managers out of MBA programs.

5) Define success first, as objectively as possible. If you have to change the definition of success, it should be because what you're building will be fundamentally flawed without pivoting. If you are changing metrics to optimize results, your metrics for success are too in the weeds. Success is defined by what gets done, not how it gets done.

6) Have one clear decision maker. Do not appoint decision makers who are unwilling to make the right decision if it upsets everyone. Of course, they should be able to explain their reasoning enough that it shouldn't upset everyone, but the first objective is not that everyone feels like they got everything they wanted. Different people have different goals at cross purposes.

7) Effort can correlate with success, but certainly does not predict it. Writing code at 2am is not a priori more valuable than at 2pm (in fact, the opposite is likely true.) People who pride themselves as being busy will naturally resist automation.

As with most things, quantity is not the same as quality.

8) Know what pedigree tells you. Getting into Stanford likely means they thrived in high school. That may correlate with success, but certainly does not predict it. Similarly, thriving at a large organization does not predict the same skill set as thriving in a start-up. Because someone works at Google doesn't mean they have any idea how to build Google; because someone is at a startup does not mean they can turn your company into a startup.

Hope this helps.

[1]: https://news.ycombinator.com/item?id=11702549 [2]: I wrote a few sentences here: http://seneca.systems/values


See, conversely I can think of semi-legitimate arguments arguing the opposite - which may explain why these patterns are so entrenched in the modern workplace.

> Do not promote based on tenure

Maybe not solely on tenure ala the government, but the people most likely to understand your company's particular problems and history are those who have been around for quite awhile.

Having someone who can say "We tried A last time and it didn't work because of reasons B,C, and D so what's changed?" in a position of (relative) power is invaluable to avoid repeating mistakes.

> Do not promote into people management roles based on individual contribution

Agreed that someone who doesn't want to be a manager shouldn't be one, but experienced ICs can make pretty ideal managers: They've been on enough projects to make (more) reasonable estimates, they know some of the potential blocks and complications, and they can likely stay a couple steps ahead of their team.

Sure, just because you're hung doesn't mean you have to do porn, but it's easy to see why companies would be eager and even pressure experienced ICs to become managers.

> Choose values that are specific to your company... Stick to them

Why? Shouldn't we re-evaluate our values as time goes on and we gain new information?

It's hard to imagine a contentious set of values (i.e. if your company values are "Don't be evil," then fine) that shouldn't be constantly re-evaluated as time goes on.

> If someone does not add something that no one else in the meeting does, remove them.

Ouch, this sounds like an insidious one that you could abuse heavily to do the committee thing that the OP rails against.

If you want something to go through: Invite only people who agree. If someone calls you on it and asks why you didn't invite more opposition voices, reply "I didn't think Alice had anything to add that Marie didn't, so I didn't invite her." or even just feign ignorance in the name of small meetings.

If you want something to get stuck in committee hell: Invite lots of people with different opinions that will never reach anything close to consensus. Don't invite any two people who agree, because "the other person isn't adding anything."

> Define success first, as objectively as possible. If you have to change the definition of success, it should be because what you're building will be fundamentally flawed without pivoting

That's suuuuper hard to do with anything that's even remotely considered a moonshot.

It also sounds like a good way to waste a shitload of time not actually doing any work. If the project is "upgrade our codebase from Ruby 1.9 to Ruby 2.3.1" then I can spend months dreaming up all sorts of useless bullshit metrics that define "success".

> Have one clear decision maker

Sounds like a formula for a shitty dictatorship. Even the CEO isn't the one clear decision maker.

> Effort can correlate with success

It often does.

> but certainly does not predict it

It often does.

> Writing code at 2am is not a priori more valuable than at 2pm

This kinda sounds like you're shaming people who have different circadian rhythms. I know plenty of night owls who do their best work at 2am and take it easy after lunch.

> Getting into Stanford likely means they thrived in high school. That may correlate with success, but certainly does not predict it.

It also might mean that they:

* Know how to manage their time effectively

* Are fairly mature and forward-thinking

* Are good with delayed gratification

* Are generally intelligent and capable of picking things up quickly

because certainly people who meet those criteria often find themselves at places like Stanford (with luck thrown in, certainly).


> the people most likely to understand your company's particular problems and history are those who have been around for quite awhile.

That works, if what you need is someone with substantial institutional knowledge. This isn't often the case, or the domain knowledge is not the most difficult part.

Would I rather have an incredible engineer with no local government knowledge, an engineer that knows government inside and out but has never worked for a tech company, or someone who has worked with me for years?

Depends on the role, needs of the team, etc. My point is that, too often, tenure is used because that's what's always been used. This is especially tough in startups, when someone has dedicated significant time and energy in the early days but just hasn't grown at the rate of the startup. It's a very emotional human decision that fights against our nature.

> experienced ICs can make pretty ideal managers: They've been on enough projects to make (more) reasonable estimates, they know some of the potential blocks and complications, and they can likely stay a couple steps ahead of their team.

I agree that they would be great at the technical aspects. That's oftentimes the least difficult part of running a team. People are hard.

> Shouldn't we re-evaluate our values

Yes! But either live up to the values you have or change your values. My comment was against having a set of values and ignoring them when they are inconvenient.

> It also sounds like a good way to waste a shitload of time not actually doing any work. If the project is "upgrade our codebase from Ruby 1.9 to Ruby 2.3.1" then I can spend months dreaming up all sorts of useless bullshit metrics that define "success".

You've proven my point. Upgrading Ruby is not an end in itself, it should solve some actual goal. There are many (performance, security, library compatibility, tech debt, etc.) but you should be able to list why we are prioritizing that versus other things.

>> Have one clear decision maker > Sounds like a formula for a shitty dictatorship. Even the CEO isn't the one clear decision maker.

This does not mean one person who does whatever they want. It means one person who, at the end of the day, owns the decision. By that definition the CEO is absolutely the one clear decision maker.

As CEO, if our company fucks up it is my fault. If I didn't know about it, it is my fault for not knowing about it. If it was some hire 4 levels down, it is my fault for creating a culture where a) that person could be hired and b) there weren't adequate checks in place.

To be clear, we will absolutely make mistakes. I'm not saying, "someone shipped a bug so that is my fault."

>> Effort can correlate with success > It often does. >> but certainly does not predict it > It often does.

We may just agree to disagree. I believe that effort is necessary but not sufficient for success. I have meant plenty of nice, smart, well-meaning, and hardworking people who were vastly unqualified for their roles.

I love them as human beings, but, especially in strategy or people management/leadership, results flat out matter. You can get better, but you won't train a 2 into a 10. It's about recognizing your strengths and weaknesses, then working in a role which emphasizes your strengths.

> This kinda sounds like you're shaming people who have different circadian rhythms.

My comment came off wrong. As a night owl, I'm definitely not shaming people for when they work. I'm shaming people who purposefully try to look hardworking by making it known they are working at irregular times.


My problem with posts like this is that it's a vehicle for bashing the currently accepted practices.

Here are a few of my favourites in no particular order:

* Stand ups are bad - Let's be frank, I'm belting out code so quickly that staying on the same page as everyone else is just not worth the time anyway (at the speed I'm going it'll be done tomorrow anyway).

* Pair programming is bad - when was the last time I caused a bug, right? Or for that matter hit a problem I couldn't solve, and wasted time having to research the solution. Never, right? Right...ohhhh look at the cute picture of my niece on Facebook.

* Open plan offices are bad - I'm super important to the company, the company would break if I went away. I'm so much of a star that I should have the best office. Not to mention, I need somewhere to put all my trophies.

* Meetings - don't get me started on meetings. BAN THEM ALL. There must be a better way to communicate? Email? Ummm, yeah Email, wait, no, I'll come back to email. I know, lets just have someone decide on the direction we're going to go and write it on a stone tablet, that'll save some meetings (I'll get started on the tablet right after I finish here). I mean lets think about it, why do we need to coordinate anything? I'm the rockstar and if you just leave me to belt out the code it'll all come together...what do you mean other parts of the business need to do things to get ready?

* Emails - I get too many of them. For stupid things too. Ops alerts, customers asking questions, internal announcements, travel itineraries. Being included on email chain discussions about direction? Who needs that. What do you mean you made a decision without consulting me? Now we have to start over with the direction I want to go in.

And I'm out of time. Off I go to my lean, agile, open plan job.


I agree with you, I would guess some down vote sentiment comes from misunderstanding the sarcasm. Generally I think programmers aren't giving lip service fairly to the things that are actually good about the above. If the tables turn and things go south for developer demand many will be begging to call in to a daily standup because they won't have any job at all.


>Stand ups are bad - Let's be frank, I'm belting out code so quickly that staying on the same page as everyone else is just not worth the time anyway (at the speed I'm going it'll be done tomorrow anyway).

Could you elaborate on this? I find standups most useful when we're working on small widgets of feature work precisely because we move so fast. Standups keep the business side in sync with the code we're putting out (e.g. features x, y ready to release, expecting z next week). It gives them a tighter feedback loop in case they need to manage expectations or coordinate with other groups.

If we're working on meatier chunks that take longer then we back off to a pull model. When someone wants to know they ask, but daily standups aren't very helpful when updates sound like "Working on <huge_feature> for the forseeable future"


Yep agreed. I was finding arbitrary reasons to rag on stand ups to illustrate a point. You could absolutely write it the way you just said it and be even better.


Not sure I understand the down votes?

Sure I made up the reasons above, but people are genuinely hating on the things I've mentioned with no real alternatives offered.


Instead of engaging the actual points made, you made up a fake idiot, and made different, stupider arguments to support the same points.

Lunch breaks are good - Dude, I love to eat, and if I can't stop working when I have my cheeseburger then nothing is getting getting done here even though I'm smelly and 500 pounds.

Paychecks are necessary - I'm such a loser that I work for money instead of just loving cranking out sick code that disrupts the world. I grew up poor so I whine about people who don't need the money.

Not eating arsenic - Oooh, I'm such a picky wimp that I can't take a little arsenic in my food...

And I'm done. Off I go to my volunteer sweatshop that's slowly poisoning me to death.


OP's idiot wasn't fake, it's a real representation of spoiled devs. So many software developers act like divas with no actual tether to legitimate business value. They'd rather chase the latest JavaScript framework, or whatever. Instead of starting their own company where they implement these supposedly superior practices they complain on HN.

Don't you think it does a disservice to the actual underprivileged sweatshop workers of the world to compare cushy software coding jobs to sweatshops? Is your software development gig so bad that it's "slowly poisoning you to death" instead of putting food on your table and cash in your 401k? If so, why are you bothering?


1) Make people clock in. A local aerospace company used to make people clock in, which is bad enough, but they had to clock in at 8:42 because $BUREAUCRACY.

2) Have a small room for tea breaks. Split the workforce into two groups. Schedule one to end at the same time as the next one starts. (Teabreak for group A ends at 10:00 am; teabreak for group B starts at 10:00am;) This causes disruption and disgruntlement between people trying to wash up their cups and people trying to make their tea.

3) Allow some people to have cigarette breaks. Do not allow anyone else to have anything similar.

4) Occasionally drop in to the small room during teabreaks and have an important conversation, then allow that group an extra 5 minutes for their break but make sure the next teabreak group does not have that extra 5 minutes.

5) Observe what side of the desk people prefer to have their telephone. Tell them it's the wrong side, and that they must have it on the other side. Switch it for them. A surprising number of people don't just walk out here. The ones that stay? YOU HAVE BROKEN THEM AND VICTORY IS SURELY YOURS. CONTINUE TO CRUSH THEIR SPIRIT UNDER YOUR BOOTHEEL.

6) Tell someone that you're going to give them a payrise if they meet some vague but easily achievable criteria. Then, when they've achieved that, tell them that you hadn't promised the pay rise, and that their 360 feedback is disappointing this month. Especially because they keep moaning about the generous pay.

There's probably plenty of good material in "Processed World" https://en.wikipedia.org/wiki/Processed_World_(magazine)



I declare false advertising.

Q: "How can we sabotage stuff?"

A: "Here's a bunch of stuff I think is messed up. Leave your own complaints in the comments."

I am disappoint. No creative sabotage ideas here, only observations of stuff already going on that we think is "wrong." Now granted, when looking for tips on how to fuck shit up, you can look at actual fucked-up shit and get ideas. But I guess I was hoping for something more creative. And yeah not the supposedly hilarious hahajoke that "Golly things are so messed up we can't even tell if they're inept or saboteurs," and not more complaints about "If only the world listened to my brilliant ideas about how to do things the 'right' way (my way)." If I had a dollar for every asshole with an opinion...


It's because to admit to themselves that someone would want to sabotage a technology company would be to admit something much more troubling.

There's no reason, in their healthy minds, why someone would want to sabotage their IT company.

For me, the real interesting question is why would someone want to sabotage my workplace.


A corollary to #3:

It is also the job of Human Resources to ensure that the company scores as highly as possible in the local business journal's annual edition of the Best Places to Work. Here's a link to an "anonymous" survey with a unique ID embedded in the URL. We strongly encourage you to fill it out.


>"Programmers don't need root/admin access to their development environments. Marketing, however, need to be able to manage the CRM and should have global admin permissions across the network."

This!

Air gap developer workstations, have a formal procedure including a detailed approval form which must include a justification and must be reviewed and signed off by C-level for moving information/software between the outside network and the inside network.


Include clauses on the contract that forbid you from installing any kind of software on work machines, and at the same time provision work machines with a clean Windows 8 install. Not even Notepad++, it's notepad.exe for C# or violating the contract.


You don't need to sabotage competing tech companies. They sabotage themselves just fine.

- Byzantine hiring practices. Create engineering teams that are 95% new college grads. They're the only ones who'll suffer your BS, while having no experience to call upon in challenging decisions.


Pile on every cargo cult "quality assurance" technique until everybody keeps getting glowing performance reviews about how they helped implement the neat SWOT matrix that pointed to the need for better performance reviews whose consequence will make clear the path to even better SWOT matrices that will discover that more extensive performance reviews would result in...


I call this work about work.


Researching leaked/de-classified governmental documents can be incredibly interesting, especially if its from a 3 letter agency. Tons of practical techniques can be gleaned from studying the content or citations, which is easily translatable from warfare/diplomacy to layman personal/professional interactions.

A basic analysis of a selection of the NSA/GCQH leaks showed a significant number of citations to various marketing textbooks and public research papers.


If someone was actively subverting an office it would rapidly kill a company.

Maybe this is the point, but to me all the comments and even article itself read more like a commertary on common issues than an subversive insider attack.


Just like a virus that kills their hosts quickly is a shitty virus, killing the company outright may not be the best way of sabotage, especially today, when companies are dime a dozen.

Instead, a good sabotage will make the company extremely unproductive but still alive - which leads them to suck a lot more money in than they'd otherwise need, waste most of it, and then turn out subpar products being sold by the power of marketing itself, and otherwise a waste of energy, fuel, materials and man-hours...

... oh wait, we're talking about sabotage, and here I am describing most of the consumer electronics.


I think the key is, small acts of sabotage that could never be considered sabotage, so there isn't any chance of getting caught. Using a hammer that is to small or adding another technology to an already complex technology stack would never be considered sabotage. They likely wouldn't even be considered incompetence, especially in the latter case if the person who added another database/programming language/web toolkit/etc managed to achieve something with in in a short period of time.

Instead that person is a hero, and the costs associated with the decision are initially small and don't show up until that person is long gone.

Repeated a few times the small hits to productivity/quality/etc will result significant lost ground. This is probably even more important long term in the technology industry than it is to a war effort. The sides would have to be close to evenly matched and the war would have to go on a long time for all the little bits of sabotage to add up.


> latter case if the person who added another database/programming language/web toolkit/etc managed to achieve something with in in a short period of time.

This one bothers me. It's brought up all the time. And I completely agree that adding a new tool or feature adds risk and technical debt. But if there's no other way to do it... I work in a corporate VBA shop. 90 percent of our work in the last year was in VBA. But next year is looking like python, R and JS. How? Requirements changed. We got handed some projects in machine learning and we delivered, crudely but still. While in the technical sense we 'could' have coded it all in VBA it's not practical in the slightest to do so.


I don't think that is an argument against having a handful of technologies in any given stack. I think its more an argument against having a lot of similar technologies. For example, I wouldn't dream of trying to write a device driver in anything other than C, but I wouldn't try writing a web back-end in C either. OTOH, I promptly ripped out ~100 lines of perl one of our developers insisted on dropping into a bash script a month before he left. Turned out the bash equivalent was actually more concise and didn't require yet another dependency on top of the 4 major programming languages (not including bash) already contained in the project.


I read it and thought it was just a commentary on things that are wrong. With a slight sarcastic and reverse psychology spin.


My favorite by far:

"Teams are better than individuals and everyone has to be aware of the valuable contributions of employees in other roles. So let's team every programmer with a sales person—preferably working the phones at the same desk—and stack-rank them on the basis of each pair's combined quarterly contribution to the corporate bottom line."

That is gooood.

I would quit, yet be so traumatized that my productivity would still suffer, even at my next job. A double win for the enemy.


Heros that invoke long days to save the company from a crisis are well rewarded. The rewards are increased by a factor of two if the hero sleeps under their desk in an old, moldy sleeping bag. The rewards are tripled if the hero created the crisis him or herself.

Edit: typo


>> we can go a step further and institute hot desking—we will establish an average developer's workstation requirements and provide it for everyone at every desk.

Oh, dont' we all wish. In practice, unfortunately, what's calculated is the average office worker's workstation requirements. Then the developer gets that, too, like everyone else.


8GB of RAM ought to be enough for everybody.

Even if you need two instances of Visual Studio on a VM.


I was mostly thinking of monitor arrangements and how hotdesking messes with that.

For instance, in my old workplace at Small Company™ I had two 24-inch monitors. In my current (but only for another two days) workplace at Big Corp™ we're only allowed a single 19-inch monitor. Try running two instances of VS on that. I have to constantly Alt-tab between browser and IDE, or stack windows side-by-side, which is not optimal. Obviously, because we're not allowed to keep anything on our desks, we can't bring our own monitor from home. So.

>> 8GB of RAM ought to be enough for everybody.

And even that is not a given. Frex, in the last two years at Big Corp™ I had to run a lot of machine learning algorithms - those were for my MSc course, sponsored by my employer so it was OK to run during office hours. Now, my work laptop has 12 GBs of RAM and it's noticeably faster than my home laptop, with 8 GBs and a similar processor.

And the fact that my office laptop has 12 GBs is a happy accident. Normally you only get 4 GBs, 8 if you ask nicely. So I was going to ask for 8, but let's just say I got lucky and the person who managed my request for the new laptop didn't know much about RAM and suggested the 12-GB stick spontaneously (and obviously I didn't turn it down).

But that's just a silly way to handle this sort of thing. Big Corp™ can afford to give devs much more if it wants to. It just doesn't value them as highly as other staff, who get the goodies they value highly.

More

Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: