Team Sports and Developers
Not usually two words you here go hand-in-hand but here I was thinking about this over the weekend and it brought up some past thoughts I had on the subject. It's always an interesting experience the first time you play a team sport with a co-worker, we've all been there and at the end of it the reactions usually range from it having been a great experience to you preferring to have a root canal done... twice... in the same day. Having thought about this a little over the weekend I got to thinking about every interview I've ever conducted where I asked a question related to teamwork, leadership, conflict, etc (you know the soft-skills, the skills that separate the transformers from the toaster ovens);
Do you enjoy working in teams or on your own? Oh both, yessir, I am definitely a team player but I am also happy to work on my own and get the job done. (They should post that answer on StockAnswers.com and rent it out).
Or
How would you resolve a conflict with a fellow co-worker or manager? Oh, well, let's be honest we wouldn't have any disagreements (wink, wink) BUT in the odd case that we would, I'd get everyone together and talk through it calmly and rationally so we can come to a win-win conclusion for everyone involved (again see StockAnswers.com).
Now let's re-phrase the two questions into some sports venacular;
If you are on my team, are you going to pass the ball or try and take it to the net on your own, every time, even when someone is open?
Or
When someone from the other team commits a penalty against you are the type to go nuts on that player argue to the nth degree with the referee, maybe seek some retribution? Or do you move on and keep playing?
Both sets of questions are pretty much the same, the only thing that changed was the context. You might think the adreline only comes into play in sports, but you'd be wrong - I've seen developers become possessive and highly argumentative about theirs and others code - true story.
It's very probable that the answers you would get to the above questions would be from StockAnswers.com, but maybe some die-hard players would start to open up a little bit (which is what we want);
- "Well if the opposing team is running my goalie, I'm going to get in their way and block them" - alright, willing to take one for the team and protect his group - leadership potential.
- "Well the ball went out on me and the ref called it the other way so I told him it was on me" - solid, honesty and respect for other teams in the organization.
- "I scored on our team once, but went out and kept trying" - READ: when I broke last night's build, it was my fault, so I stayed later to get it up and running so QA wouldn't be too far behind.
I wish it were that easy, I love both individual and team sports - I love seeing the transitions in personality in people I work with and when you step back to watch them you can totally see the similarities in how they approach their work, their style and ethics.
I am seriously looking forward to my next Interview because I'm thinking I'm going to hold it in a gym - play a little one-on-one, floor hockey, dodgeball, anything - if they get past that phase, I'll inject some technical questions near the end. At the very least, if the interview goes sideways I would have gotten some exercise and had a fun night at the gym.
BTW - We need more examples of sportsmanship like this - http://www.youtube.com/watch?v=NOMN__ozGSI
The 10 minute fix for the 3 month problem
For almost 3 months now I have had this ongoing drip in my new shower. It was fine for 5 months when it was nothing but drywall and and sub-floor, but shortly after installing the shower pan, the mebrane, all that tile and then the door itself the shower heads started to leak...
And I didn't know why.
This was killing me. I talked to the guy at the local Home Depot to try and get some insight into what might be wrong, could it be something really, really small that I forgot to do? No luck.
I then emailed the manufacturer who offered a Life Time Warranty on the product (and they do), I explained the situation, they emailed me the new parts - free of charge. So far so good. I received them about 6 weeks ago, and they sat there on my dresser, mocking me each time I got up to get my socks in the morning and in the evening when I had to move them to put down my Ipad.
Mocking me to dare and try to install them on my own.
Everynight for the past 3 months when I have gone to bed I could hear a faint... Drip, Drip, Drip... reminding me of how I was too chicken to fix the problem. Good Night Greg - You "drip, drip, drip".
You are not a plumber, you don't have the experience, you don't know what you are doing - your pathetic attempts will only end in you to putting a hole through the pipes, flooding your subfloor and causing you to rip that beautiful tile and membrane that took you 4 solid weekends to install and cost so much.
I had to bite the bullet this weekend, my permit is about to expire and I need to get this fixed so I can get my final inspection done. So Saturday night, I manned up, turned off the water supply, got out the replacement parts, and replaced them. Turned the water back on, tested the shower heads, no leaks inside the walls, turned them off and...
No Drip, Drip, Drip.
I checked about 5 more times last night before I went to bed and again this morning and throughout the day, it was dry - there was no more drips, no more leaks, no more uncertainty, no more problem.
And all it took was 10 minutes, for both taps, in total. Yes that's right, I internalized the fear of screwing up for the past 6 weeks for a job that took me 10 minutes and over half of that time was spent trying to line up the screws when putting it back together (totally separate from the problem).
It's amazing how, despite all of our advances, we still have the ability to internalize so much fear for the unknown and deconstruct "what we don't know" so analytically versus constructing "what we do know", how we will learn from this experience and take action immediately to solve the problem.
Is this what happens when projects slow down when new features and problems are introduced into the mix? I've seen projects and features pushed because of the unknown, we don't know, it sounds big, lots of unknowns, we're not sure where to start. Watch for it the next time you see this happening in a meeting, feature review or in your own code... the fix could turn out to be 10 minutes of your time.
The Architecture can't do that
This my friends is the Kiss of Death in software development. Want a surefire way to suck the air out of the room in seconds? Utter this line at your next feature review meeting. I love watching the room - scanning from developers to product managers to dev managers to sales to anyone else in the room - they are all looking at each other waiting for someone to jump in and offer some kind of an olive branch to let them breathe again. In the worst case, Sales starts to blame PM who starts to blame the Dev Manager who, if they are having one of those horrible days and is completely ignorant of the software suite, might look to the developer for answers.
The problem here is that it's the not the architecture of the product that can't implement the new feature(s). Of course it can, its software, you have IDEs, you built it, you can change it. Maybe you built it against some crazy convuluted design pattern that only Sara and her sister have full working knowledge of and they just bailed on the company and you really don't have a grasp on how it works or maybe its that the feature is so new that what you currently have in your software suite is completely irrelevant to solving the problem at hand?
These are not the faults of software architecture.
I've seen the look a developer has when he mumbles this statement for the first time, I've BEEN that developer who mumbles that statement for the first time. It's not a deer in the headlights look, it's a look of resignment where the developer starts to calculate all the different possibilities of what is being asked in the feature and they are evaluating it against what the system has and then factoring in how much time they have (there is a calculation here somewhere) and then it hits them - I can't give you what you want, when you want it without creating some steaming pile of dung that will do this and only this and become the bane of our existence for now and ever more. And the architecture takes the rap because it cannot quickly absorb the new features as fast as we thought it could, Widget A does not plug gracefully into the framework, instead it kludges in and requires a little finesse. Is this all bad, no not entirely, if this was the complete focus of your application/framework then yes this would be a bad thing, but in this case it is not you (as the developer) are trying to build a feature for a product for your company.
In the end, the problem is the delivery model.
No matter the role you play in feature delivery of a software product, when you hear someone mumble this answer your first thought needs to be to stop what you are doing and get to the bottom of the real issue (DANGER WILL ROBINSON! DANGER WILL ROBINSON). What really is the problem? Did we cut corners on the last release and now we are paying for it? We can fix that. Have we pushed out critical bugs that need to get fixed before we think about this? Are the expectations too heavy in too tight a timeframe? These are all questions that have nothing to do with the architecture and everything to do the management of the software.
When you dig into the reasons behind "The Architecture can't do that", it rarely ends up being the actual architecture but rather something else altogether that you never would have thought to be the issue in the first place.
The Essential Teamwork
Teamwork - it is at all times the most important concept you will ever have to deal with, you are either on the team or you are leading the team. This topic is discussed all over in forums and denizens of books in leadership, management and methodology circles. Everyone has a spin, everyone has a secret recipe that makes a team work.
In the end what does it come down to? It comes down to each person believing that everyone else on their team is going to try as hard as they will. That Jeff is going to give it 120% and Jane's going to do the same, they might have incredibly different skills sets and proficiencies, but in the end knowing that they are both willing to give their all. When you're in that meeting room discussing the battle plan to accomplish a task, everyone should be looking at everyone and know immediately - "I'm not going to let you down and I sure as hell know that you're not going to let me down, so let's go do this."
If you embed this mindset into every member of your team, you are setting the bar for entry of all others into your team. Once you set that bar you cannot lower it, lowering the bar means it is ok for someone "kinda, wanting to" be there but not really being fully committed. When you get that inevitable senior management question when times are tough - "Who is your bottom 10%?" your answer should ALWAYS, ALWAYS be 0 because everyone is a 120% player. Being a 120% player does not mean they put in 8 hours of overtime a day, no it means that you can count on them at all times to step up to the plate and hit a homerun.
The Measure of a Developer
So here's the deal, I don't enjoy interviewing people... especially developers. The process on a whole does not do anything for me, sometimes I leave excited, like - "that was great, we need to get this gal" and sometimes I don't - "well I'm glad the WCF guru was able to explain how he used his Neutron binding for us". But at the end of the day, the biggest problem I have is that developer resumes are a horrid mess of acronyms that they may or may not have used further complicated by delineations between Junior, Intermediate and Senior. I can't tell you how many "Gurus" I have interviewed to only have them tell me - "yeah I was more the maintenance guy on it" or "yeah I didn't use that part of the framework". I would NEVER declare myself a guru in anything because there is an infinite amount of information out there that you can't know it all. But my biggest peeve with interviews is the guys who come in with 15 years experience thinking they are Senior-Level but then when you talk to them, their knowledge is a Junior, but somehow these years of toiling away on code has given them the right to be a Senior? So with that in mind, here is how I measure a developer's worth when I am looking to hire someone.
Experience is Not Years
I don't care how many years you have been working with programming language X, I care about what you have done with programming language X. Do you want they guy who has built and maintained 4 projects with ASP.NET for the last 5 years (putting him at a typical Intermediate level) or do you want the guy that in the span of 2 years has built 12 ASP.NET sites, each more complicated then the last? It's not a trick question, the latter is the guy you want - he's pushed his train of thought further and built on his skillset at a much more accelerated rate. Assuming, all things being equal, that the 12 projects increased in scope and easily surpassed our previous candidate's 4 projects, the choice is obvious, you want the guy who has a wider breadth of the framework and a better understanding of what can and will go wrong with these projects. Years do not equal knowledge, I would easily consider the second candidate an Intermediate (again assuming he really knew his stuff) over the guy with 5 years experience.
Passion is Mandatory
I run an interview like a conversation, and I always throw in a question about what you do in your spare time, how do you keep up-to-date with changes in the industry, etc, etc. I am always, always blown away by the number of people that rely soley on MSDN, don't get me wrong, I use MSDN (and the magazine) a lot, but there is so much more out there, guys are writing blogs on how they have solved problems in innovative ways that go beyond the documentation on MSDN. The guys that tinker in the evening for the sake of figuring out a problem to understand it are the guys I hire. Partly because you know they are genuinely interested in what they are doing, but mostly because I know that passion will shine through in their work in the form of pride, dedication and quality to getting the job done.
Velocity
Alright so we've got a candidate that has some solid experience based on what they have done and they have the passion for the job - so let's peg this candidate as a strong Intermediate. My final criteria for determining the measure of a developer cannot be discovered during an Interview. Nope, you're going to have to go with your gut and bring buddy in. Maybe you can do this as a test exercise, but really you will not witness it until they are hired working through problems with you and your team. The final measure of any good developer is how much quality code they can pump out in X amount of time. Anyone can paint a Mona Lisa if given enough time to learn the finer points of painting, but for many this would take years. When we're working on the next release, I need passionate, experienced people who can hit the ground running and pound out code like its going out of style. Do I want them going a reckless pace? No, but I want them going at a velocity that shows progress is being made and we are getting things done. Remember velocity is about quality OF code, not quantity OF code - this is often the hardest trait to find - some guys can think of a problem and get right to it, others can sit their for days before starting to go and then they go at a slow rate.
So there you have it - the Measure of a Developer is achieved by their Experience (not in Years), passion and velocity to get the job done. It's not a complicated set of characteristics but it can be a hard set to come by. The key is that when you find these people, you make sure you do what you can to keep them, because they are not an easy find and like Aladdin said, they are a Diamond in the Rough.