Good article, I agree with the concepts completely. However, I don’t know how well they gibe with reality. For example I work for a large auto insurance company, my division alone has 300 developers working more or less on a common platform (and tools to support it, maintain it, etc) and though it pains me to say it, barely capable of maintenance coding, god forbid innovating new concepts. And these folks run the gambit from entry level to retired in place, to about to retire. They’re not looking for a leader, they’re looking for a paycheck and doing as little as possible to get it. I agree this is really a company culture problem, but if my company is like any of your’s this isn’t sounding our of the ordinary.
One is called “Standing naked in the snow” - about the transformation necessary for moving from engineering to management. Management is fundamentally different from engineering.
Another is “Pasta e Fagioli” about building team spirit by cooking together.
Sadly though the reality is one of messy even amateurish software kludged together by clueless undereducated losers who can’t even work version control, wouldn’t know an interface if it bit them and for whom a normal form is something you use to apply for expense with. The new guy is trying to gently point out that your guys a bunch of lamers who need the axe… and your afraid he’s right - because he is.
A very good post.
In the software industry, higher managers tend to create more problems rather than solving the existing ones.
I would love to read the book and share the knowledge with my team
Jeff Atwood (quoted): “I think the lesson here is that you need to convince developers that they should follow the standards because they want to, because they believe in them.”
Ideally, it would be possible to convince them. In practice, one might not be able to.
Steve (quoted): It’s a “secret” because many developers aren’t aware of this concept and think the project is their “canvas” to express themselves. Which isn’t bad, but perhaps do that mostly on your own stuff.
I know it’s a secret. It’s still strange that it is a secret. The “express themselves” issue is what I have a problem with. It’s bad because it typically leaves messes that the “artist” doesn’t have to clean up. Also this attitude indicates that the “artist” thinks he knows everything and he won’t be open minded to learn new (or different) things. It’s a bit weird that the default assumption of a developer is that he’s an “artist” and not a member of a team.
It’s painful when other devs don’t realize the value of some practices, but you can’t really force them much. All you can do is, as you said, lead by example.
In other engineering disciplines, it doesn’t matter whether someone’s feelings might be hurt by criticism. If you are doing it wrong, the building will fall down, the power plant will blow up, the pipeline will burst, or the car will not start, no matter what you feel about your design.
In a structural engineering firm, you’d never hear people leading their coworkers by saying “While your idea of using tapioca pudding instead of concrete as a structural material is interesting, might I respectfully suggest some reasons why we might want to…”; instead, they would unleash a stream of profanities that would shock Sergeant Hartman before summarily firing the individual.
However, it seems like in the software industry, we’re constantly cajoled to ‘be humble’, ‘be discreet with constructive criticism’, and ‘herd cats’ when people are doing the software equivalent of using pudding instead of concrete.