Programming Environment (work environment)?

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.

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.

Shut up and Ship 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.

Last paragraph is just excellent. – Assaf Levy Oct 3 at 9:24.

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.

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?

Fortunate position to be hired into a position of high responsibility. Set a good example and raise the bar for everyone else (and show how your good habits have paid off with measurable metrics like a lower bug rate). – Ether Aug 24 '09 at 2:29.

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

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.

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.

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.

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.

I cant really gove you an answer,but what I can give you is a way to a solution, that is you have to find the anglde that you relate to or peaks your interest. A good paper is one that people get drawn into because it reaches them ln some way.As for me WW11 to me, I think of the holocaust and the effect it had on the survivors, their families and those who stood by and did nothing until it was too late.