Why I'm pushing your buttons

Interesting Story (to me)

I found myself in another interesting "ex post facto" software design review session and both sides of the table were getting increasingly frustrated. My frustration centered around my engineer's inability to explain "why" he did it that way or "how" it worked, and his frustration was a mystery to me. I suspect this has to do with the perception that perhaps I was telling him his baby was ugly.

I think what leads to this situation is the realization that I'm an almost negligent delegator. Yes, most who interact with me or know me professionally might not think it's true (as I DO like to get my hands dirty). I tend to give my tech leads and developers lots of rope which unfortunately means it will fit quite easily around all of our necks. This is, however, deliberate because I feel this historically has yielded the most innovative results and "generally" produces really good or really bad software. It averages out (IMHO) to "Better than average" software, and when taken with the notion that I then end up with a pool of REALLY good engineers that I can throw at fixing the "really difficult" stuff...I feel I usually end up with "above average" solutions (for long term engagements).

That having been said, there is a particular problem that this approach produces. That is, when someone takes an innovative or creative approach that isn't well thought through, we get to a situation where design guidance wasn't given early enough. Moreover, things that I could help forestall early on are then "too late to fix". In general I'm OK with this, yes it's frustrating to everyone involved, but frankly I have to be honest and say that it's deliberate. It's my approach to developing software engineers by allowing them to make and realize mistakes that has proven to work from a professional development as well as overall software quality perspective.

If you're ever in some sort of design review and I'm asking stupid or (better/worse yet) super challenging questions and questioning your every tiny detail... trust that I'm doing it not because I don't believe in your solution or don't believe your solution is "good enough" or don't believe you did a "good job", but that I want us all to do even better next time. I'm not being a dick or trying to be "Mr. Smarty Pants", I'm simply trying to help us both get better. When I say "I don't understand how this works" or "I don't think that's a good idea" I'm not saying you did a bad job, but truly just want a better understanding. I WILL say that if you've been doing this less than 20 or 30 years I may have some experience with problems you might not yet have run across and hope you will give me the benefit of having some reasonable doubt in your own capacity and experience. But I will also reserve judgement on your approach or it's quality until I have as complete an understanding as I can in the time available to me to review it.

In short, never assume I'm challenging your software because I think you (or your code) are inferior or not well thought out, but think of my challenges as an opportunity to challenge your own preconceptions and as an opportunity to grow yourself. At the end of the day, I hope to become smarter...but can only do that by accepting the notion that I might be wrong...you should do the same.