How do you survive in a corporate coding environment?

Question

I work for a smallish software shop with a mix of internal products, and external consulting. For the last few years I've been working on in house apps at the office with a bunch of other geeks. Fairly laid back and productive. Pretty much perfect coding conditions:

• good equipment
• quiet, focused team rooms with a few developers who are all on the same project
• freedom to use whatever tools we wanted
• agile processes
• everyone is a developer (even the bosses)
• clear requirements with real scope
• enthusiastic, passionate people who are really onto it

However recently I've changed projects and moved into an external consulting team embedded at a big corporate site with all the resulting bureaucratic BS and overhead that goes with it:

• Constant interruptions
• loud open-plan cubicle environment
• slow equipment
• heavy, burdensome process (even though they call it "agile")
• restrictive IT environment
• slow, overly complicated, limited tools
• vague requirements. No one seems to know what is going on
• cynical teams. Mix of average and mediocre client contacts to rely on

And it's driving me nuts.

So what does everyone else who is in this boat do to keep their sanity?

Answer 1

Just quit. Life is too short to be miserable. You clearly know what environment works for you and what environment doesn't. Find another job like the first one. I know it's easier said than done... but you really owe it to yourself.

Answer 2

For the noise, I bring a good headphone and use music.

Slow equipment and constant interruption are concern that you should talk to your project manager. I am just he wants you to work the fast that you can. He might help you.

Answer 3

I changed jobs to be in a good/productive/friendly/encouraging/inquisitive environment.

I can sympathize with you, though. I've worked at several awful places that were exactly the same as you describe. The problem was, there was no way for me to change the environment, or their process.

Answer 4

Things that have helped me:

• Focus only on what's your responsibility, and do that as perfectly as the situation allows
• Find a person who has both power and understanding, and politely suggest improvements to them
• Ask questions to clarify the requirements; it's annoying, but you might annoy them into doing better
• Get headphones
• Look for a different job, so you can feel like you're not locked into this forever

I've also learned that the grass is not necessarily as green on the other side as it looks - so be grateful for what you have.

Answer 5

Mostly it's not bad. I've worked for companies of all sizes pretty much, and the differences are more per company than anything actually size based.

Some of the structure imposed by a large company would probably do a lot of the younger, more independent talent in our industry some good.

Occasionally when I've been told to do something amazingly stupid or to do it in an amazingly stupid way, I have a mantra: "I'm being paid well and could be being paid a lot less to do a lot more work, so shut up and do it". Then I go home at 5:00 and concentrate on my own life.

Answer 6

As has been stated in other posts, listening to music is great for cutting out the noise.

Most of the points you raise are common in large departments\projects, the best way to approach them is to attempt to educate and convince those around you of alternatives.

You could provide a business case for faster machines (joelonsoftware provides a lot of information about developer productivity).

Unclear requirements are unavoidable in a business environment where the stakeholders often don't know what they want upfront and change is frequent, this often overrides many technical issues and so obscures them as well. The best way of addressing this is to adopt an process which acknowledges this and manages it, e.g. Agile.

If you have concerns over the tools and processes, I would initially discuss this with the other developers and then take it to the development\project manager.

There are often benefits, which may not be clear initially, of the constrictive nature of roles and environments (often not as tight as initially thought). These can include access to deeper knowledge due to specialisation and the ability to delegate some activities to other people in the organisation, however it usually mean things happen more in parallel but slower. You may also get exposure\experience of a wider range of role and activities and meet lots of people.

It will take time and lots of effort to educate and convince people regarding these issues, though once this starts to happen the cynicism will likely start to relax and disappear, enacting change on a large team/department is not easy and generally requires momentum by getting more people enthused and involved. Personally I thrive off this, despite it often being frustrating, as it allows me to engage people in debate and mentor people. However I am very focused on the people\process aspects of software development over technologies. If this is not for you then I would consider moving jobs or requesting reassignment back to an in house team.

This relies on the people you are working, as this is the most important thing in development, with being approachable and committed to the project\department\organisation, if this is not the case you may want to look for an alternative job.

Answer 7

• Ambient music / talk radio
• Keep a blog or a side project at home to do it "the right way"

Answer 8

Recognize that navigating the corporate waters is just one more engineering challenge for you, and you will start coming up with novel solutions for your problems. As an example, I worked as a consultant at one company where I needed to be physically let into the server room in order to do my work. I had to do a ridiculous amount of paperwork each day just to get in, and it was wearing me down. So one day I brought a big bag of homemade chocolate chip cookies to the woman who oversaw the server room, and that was the end of the paperwork for me.

Or you could just take advantage of your total insignificance in your new environment, and get some serious web surfing in.

Answer 9

I have some experience with this where I work. In general, tell your boss your concerns, and if they're not addressed, keep bringing them up as they will affect your productivity, and sell your manager on helping you address them.

Here's what I've done:

• For the loud workspace, listen to music, loud enough to drown the music out.
• For the constant interruptions, listen to music, but with big headphones! I've found people find them more intimidating than just earbuds. People will be less likely to bug you if it's clear you're in the zone. Also, if the music is loud enough, they have to catch your eye by waving their hand or something. It makes it a lot more work for them to bug you.
• For the slow, rigid processes, try and convince your coworkers and bosses that changing to a more agile approach would be beneficial. I was working on a product with a one-year release cycle and managed to convince everyone through lots of meetings, emails, etc, that agile is a better approach. Just be relentless, but always kind.
• For vague requirements, just keep clarifying. Show them what you've done, and ask if it's okay. Explain that you're having a hard time guessing what they want and that you can only clarify if there's some communication between you. By creating some samples or prototypes, you give them an way to clarify the requirements without having to do much work. (sad I know, but it works)