Programming Environment (work environment)

Question

As programmers we require a much more structured work environment than (for example) laborers, dentists, mechanics, etc. We need an atmosphere where we can concentrate on what we are doing, and not spend all day trying to figure out which one of the 100+ release procedures is the right one for a specific customer, or trying to fix a 10 year old release document template which doesn't work correctly.

Through the media we are (well, I am) lead to believe that there are two types of work environment for us programmer folk:

A. The type where ...

• lack of source control
• lack of documentation
• no formal release procedure
• constantly being interrupted
• unrealistic schedules
• uncertain of deliverables

B. The type where ...

• the programmers have a say in the schedule
• nice working environment free of distractions
• bug tracking / releases / documentation follow a distinct cycle free of much deviation
• there is time to make mind maps and other supporting documentation

Although my current position doesn't show ALL the signs of type A, it certainly does show most, and its driving me nuts.

Do these idealistic environments that we read about exist, or is it a bit like the pot at the end of the rainbow?

Answer 1

You might be interested in reading about the Capability Maturity Model. It attempts to quantify factors you're talking about.

Answer 2

Every place I have ever worked is somewhere between A and B. Yes it does drive you nuts, but if you are patient you can effect change. The secret comes from Dave Thomas.

1. Shut up and Ship
2. He who ships gets to speak

i.e. The first thing you need to do is grit your teeth and get on with your job. Once you get some runs on the board, then you will have some cred to go back to management and suggest improvements. Pick your battles one at a time starting with the highest priority (rather than ranting about everything being bad), and phrase stuff positively (e.g. I think we could get things done a lot faster if we did X). Over time you can convince people that making these changes is worthwhile and as you see the benefits of change people are more likely to warm to your ideas.

Having said that if your workplace doesn't have source code control then everyone is probably wearing floppy shoes and red noses and driving around in comically small cars throwing buckets of confetti at each other. Suggest you quit and go and find a real job.

Answer 3

From my limited experience, they do exist, at least in part. A company that exhibits features from your B-list would almost certainly require a good, skilled, visionary CTO that has a clear idea of where the projects of the company are and where they are going. A good COO is a major plus as well.

Also, although I haven't gotten the chance to try it out yet, namely for lack of an employer interested in such things, I think that the Agile Process and Scrum are promising starts to implementing characteristics from your B-list. I'm not yet convinced that either of them are end-all solutions, but I think that things like that are headed in the right direction.

Answer 4

Every job you ever have will be somewhere on the spectrum between A and B. Jobs that are closer to A are managed by managers who were never developers, or haven't been developers in quite a while.

Answer 5

Source control is 100% in your control to fix. No-one has to know that you have git running on your local machine. Or Subversion.

Documentation is another that is within your control, albeit how much time you can spend on it is another matter. MoinMoin is easy to setup (and has it's own version control). Nothing is stopping you from hosting the documentation in your version control system either.

The last 4 are for...

• job-sites
• that section at the end of the interview where they ask you for questions
• why it's prudent to research the company you are applying for, as opposed to spamming out resume's to recruitment agencies

Although Dean Povey's comment hit a lot of home runs.

Answer 6

There is unlikely a organisation that is 100% perfect (not even Microsoft) in their practices. What you probably want is an organisation that recognises its own flaws, and has a desired ideal/vision for working conditions, and works towards achieving that. Such places do exist. Companies like Fog Creek and SSW are always working at improvement toward a better environment B.

The problem with most organisations is management don't even know what is a good ideal to work towards. All there usually exist are the notion developers need to work harder, longer, better, "smarter" at their jobs to improve software quality and turnaround, without a solid plan on how to achieve such. That is why Joel Spolsky recommended his 12-step Joel test for counter-interviewing. There is also a discussion about this topic in this site.

Answer 7

Try taking responsibility and simply introduce your desired best practices step by step as you go along. Who else is going to change the work environment for the better if not the developers themselves?

Answer 8

I have never seen type B in practice...I believe it is mostly imaginary. Even when some software company starts off following your B model, it soon falls back to A. Maybe all these nice things (like not being interrupted !) are just ...luxury.