Everyday Problem Solvers
Well I must say that I always enjoyed interviewing candidates, and there’s quite some time that i don’t do it. I like it so much because everytime I open that interview door I see the chance to meet someone that will impress me (and it’s sad to say that some don’t even try) even though they rarely do. Read more of this post
It takes discipline for development teams to benefit from modern software engineering conventions. If your team doesn’t have the right kind of engineering discipline, the tools and processes you use are almost irrelevant. I advocated as much in Discipline Makes Strong Developers.
But some commenters were understandably apprehensive about the idea of having a Senior Drill Instructor Gunnery Sergeant Hartman on their team, enforcing engineering discipline.
Cajoling and berating your coworkers into compliance isn’t an effective motivational technique for software developers, at least not in my experience.If you want to pull your team up to a higher level of engineering, you need a leader, not an enforcer. The goal isn’t to brainwash everyone you work with, but to negotiate commonly acceptable standards with your peers.
I thought Dennis Forbes did an outstanding job of summarizing effective leadership strategies in his post effectively integrating into software development teams. He opens with a hypothetical (and if I know Dennis, probably autobiographical) email that describes the pitfalls of being perceived as an enforcer:
I was recently brought in to help a software team get a product out the door, with a mandate of helping with some web app code. I’ve been trying my best to integrate with the team, trying to earn some credibility and respect by making myself useful. I’ve been forwarding various Joel On Software essays to all, recommending that the office stock up on Code Complete, Peopleware, andThe Mythical Man Month, and I make an effort to point out everything I believe could be done better. I regularly browse through the source repository to find ways that other members could be working better.
When other developers ask for my help, I try to maximize my input by broadening my assistance to cover the way they’re developing, how they could improve their typing form, what naming standard they use, to advocate a better code editing tool, and to give my educated final word regarding the whole stored procedure/dynamic SQL debate.
Despite all of this, I keep facing resistance, and I don’t think the team likes me very much. Many of my suggestions aren’t adopted, and several people have replied with what I suspect is thinly veiled sarcasm.
What’s going wrong?
I’m sure we’ve all worked with someone like this. Maybe we were even that person ourselves. Even with the best of intentions, and armed with the top books on the reading list, you’ll end up like Gunnery Sergeant Hartman ultimately did: gunned down by your own team.
At the end of his post, Dennis provides a thoughtful summary of how to avoid being shot by your own team:
Be humble. Always first presume that you’re wrong. While developers do make mistakes, and as a new hire you should certainly assist others in catching and correcting mistakes, you should try to ensure that you’re certain of your observation before proudly declaring your find. It is enormously damaging to your credibility when you cry wolf.Be discreet with constructive criticism. A developer is much more likely to be accept casual suggestions and quiet leading questions than they are if the same is emailed to the entire group. Widening the audience is more likely to yield defensiveness and retribution. The team is always considering what your motives are, and you will be called on it and exiled if you degrade the work of others for self-promotion.
The best way to earn credibility and respect is through hard work and real results. Cheap, superficial substitutes — like best practice emails sent to all, or passing comments about how great it would be to implement some silver bullet — won’t yield the same effect, and are more easily neutralized.
Actions speak louder than words. Simply talking about implementing a team blog, or a wiki, or a new source control mechanism, or a new technology, is cheap. Everyone knows that you’re just trying to claim ownership of the idea when someone eventually actually does the hard work of doing it, and they’ll detest you for it. If you want to propose something, put some elbow grease behind it. For instance, demonstrate the foundations of a team blog, including preliminary usage guidelines, and a demonstration of all of the supporting technologies. This doesn’t guarantee that the initiative will fly, and the effort might be for naught, but the team will identify that it’s actual motiviation and effort behind it, rather than an attempt at some easy points.
There is no one-size-fits-all advice. Not every application is a high-volume e-commerce site. Just because that’s the most common best-practices subject doesn’t mean that it’s even remotely the best design philosophies for the group you’re joining.
What I like about Dennis’ advice is that it focuses squarely on action and results. It correlates very highly with what I’ve personally observed to work:the most effective kind of technical leadership is leading by example. All too often there are no development leads with the time and authority to enforce, even if they wanted to, so actions become the only currency.
But actions alone may not be enough. You can spend a lifetime learning how to lead and still not get it right. Gerald Weinberg’s book Becoming a Technical Leader: an Organic Problem-Solving Approach provides a much deeper analysis of leadership that’s specific to the profession of software engineering.
Within the first few chapters, Weinberg cuts to the very heart of the problem with both Gunnery Sergeant Hartman’s and Dennis Forbes’ hypothetical motivational techniques:
How do we want to be helped? I don’t want to be helped out of pity. I don’t want to be helped out of selfishness. These are situations in which the helper really cares nothing about me as a human being. What I would have others do unto me is to love me– not romantic love, of course, but true human caring.So, if you want to motivate people, either directly or by creating a helping environment, you must first convince them that you care about them, and the only sure way to convince them is by actually caring. People may be fooled about caring, but not for long. That’s why the second version of the Golden Rule says, “Love thy neighbor”, not “Pretend you love thy neighbor.” Don’t fool yourself. If you don’t really care about the people whom you lead, you’ll never succeed as their leader.
Weinberg’s Becoming a Technical Leader is truly a classic. It is, quite simply, the thinking geek’s How to Win Friends and Influence People. So much of leadership is learning to give a damn about other people, something that us programmers are notoriously bad at. We may love our machines and our code, but our teammates prove much more complicated.
Yesterday i read a quote by Bill Gates that goes something like this: “Success is a lousy teacher. It seduces smart people into thinking they can’t lose“. Some time ago i saw a movie named A Good Year (Russel Crowe) and the movie said something like “You’ll come to see that a man learns nothing from winning. The act of losing, however, can elicit great wisdom. Not least of which is, uh… how much more enjoyable it is to win. It’s inevitable to lose now and again. The trick is not to make a habit of it.” and quite a few more on the same idea… and it got me thinking how it sucks to lose, how important power and success (or the image of) is to us and manly why can’t we all just be.
As a man of science, specifically computer science i find it quite hard to comprehend some behaviors, like faith for example, but nevertheless I try. Thinking real hard about why loosing sucks i came by the thought that it only sucks because when you lose you don’t get the bug, cof! cof! cof!, i mean, the big prize, and i came to understand that it’s a moment thing! I wonder how one stops “accepting the defeat” and become a “looser”… by that logic, winners are sour losers, but losers nevertheless… which leave us to the question: Are there winners?
Some argue that winners indeed are losers that didn’t accepted the defeat, worked hard on to something and become a winner… to that i always say “the dispute was not over when someone was declared a looser, and should be declared as under-advantage (os something like that) instead”, because once someone is declared winner of the race, he’s the winner and everyone else is a looser, therefore there is no general concept of winner, therefore everyone can be a winner, but not at the same time. Being cruel, the second place is the first user, cof! cof! cof! i mean, the first looser.
By now you must be thinking that there’s nothing motivational about this post. I don’t care about what you think. Motivation is not “Go for it! You can make it!”, that’s cheering! Motivation is something that drives you to do something. Motivator is the agent of motivation, like love, passion, hunger, fear, anger, etc… Some say that Fear is the most powerful motivator, idiots say that love is (if you really think about it, fear motivates a lot more than love.. like fear of losing someone you love… you don’t move a mountain because you love someone, you move it because you are afraid that if you don’t, that person will go away…). In my opinion the most effective motivator is hunger (hunger is like a bitchy woman who will bitch until you satisfy her). Fear, Love, Anger are powerful, but very unstable, a sunny/rainy day might ruin the whole motivation. But REVENGE… oh sweet revenge… is the most powerful! Very dangerous!
Think about it… success might push you forward… loosing might stop you… but revenge sweet revenge will certainly get you to completely plan and eventually destroy someone. Quite a dark ending…