I'm in the job market and I have a set of priorities for my next job including salary, line of business, etc. One thing that is nowhere on my list of requirements however, is the development process methodology. I feel my job is to create software and I view the process structure as something I can adapt to whether it's scrum or waterfall or whatever. Is the development process methodology a priority for you?
As a programmer, do you care what method the development process uses?
development process
It is important to me only as far as not getting in the way of the common sense that we hope most professionals would have.When we talk about version control, there is the argument that any version control beats not having anything at all, this isn't the case with development methods. Methods mean rules, and rules are sometimes broken. I've worked for companies that have been doing really goofy things for as long as anyone can remember, whatever problem the goofy procedure happened to cure went away a long time ago.I want the following out of a company:Clearly documented procedures that fit on a few pages. If I have to read a dissertation or (worse) a novel in order to get up to speed, I'll be lost for a long time.Evidence that the company is open to changing procedures for the better. I need to be able to go to someone and say I realize why you're doing [xyz], but there's a tool out that does most of that for you now. Can we use it?A little competition can be good and is often unavoidable. But, I'll avoid any shop where competition is used as a primary means to motivate people. If you have codified something that sends the # of lines committed per day by developer to the laser printer at 5 PM, I don't want to work for you.If you have not prevented builds in blessed repositories from receiving changes that break said build, I run like heck. The last thing I want to do at 5:00 is pull in changes from the master repo to test my local build, only to find myself fixing someone else's semicolon.I prefer jumping into methods that resemble an established method that fell from the agile tree. It's not mandatory, but a sense of familiarity helps to overcome the initial hump of trying to be productive while not making a procedural mistake. If I see that I'll spend more time resenting procedures than being thankful that they exist, I'll probably pass on the job. The other resounding oh no, never again! is We're hoping you'll also set up best practices for us. We have six million lines of code and 21 telecommuters, should we be using an SVN or something?.Someone could have some fun sorting that out. I'm not that guy :)