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.

Comments

Post a Comment

Popular posts from this blog

Please use ANSI-92 SQL Join Syntax

-
Image
Way back in 1992, a standard was published for SQL. In it, the syntax for specifying joins in SQL Database was finally standardized. This was a good thing because (for folks who've been doing this a while), trying to decode the vagaries of how various Databases handled outer joins could drive you bonkers yielding different results depending on the parse order of things in the from and where clauses. Unfortunately, some DBMS vendors took a while to adopt this standard (Oracle didn't support it until 2001), but at this point if you're using a major RDBMS and NOT using it, you're probably mired in a tradition or habit that bears changing. As an example of what I'm describing, here are some examples of what I mean. Old School (no standard syntax + implementation and evaluation of predicates varied by vendor [and query]): select * from customer, order where customer.customer = order.customerid ANSI way (agreed to standard, predicate evaluation has some rules
Read more

the myth of asynchronous JDBC

-
Image
I keep seeing people (especially in the scala/typesafe world) posting about async jdbc libraries. STOP IT! Under the current APIs, async JDBC belongs in a realm with Unicorns, Tiger Squirrels, and 8' spiders. While you might be able to move the blocking operations and queue requests and keep your "main" worker threads from blocking, jdbc is synchronous. At some point, somewhere, there's going to be a thread blocking waiting for a response. It's frustrating to see so many folks hyping this and muddying the waters. Unless you write your own client for a dbms and have a dbms that can multiplex calls over a single connection (or using some other strategy to enable this capability) db access is going to block. It's not impossible to make the calls completely async, but nobody's built it yet. Yes, I know ajdbc is taking a stab at this capability, but even IT uses a thread pool for the blocking calls (be default). Someday we'll have async databa
Read more

The difference between Scalability, Performance, Efficiency, and Concurrency explained

-
I thought I'd give some explanation of the difference between scalability, performance, Efficiency, and concurrency. To make things more accessible (and because I'm watching a cooking show on TV) I'm going to use a baking metaphor to help explain the differences. In our case, the system in question is baking cookies for consumers. Scalability, is how well something responds to adding more resources. If we can double our capacity by doubling the number of resources, we've got linear scalability. In our baking example, if we add more ingredients, we can scale to a larger number of cookies. To contrast with our other metrics, this doesn't actually increase the performance of creating a single cookie (they still take 10 minutes to bake), and the efficiency is the same (we just have more capacity). We also cannot bake more cookies in a fixed time period, but over a larger time period we can produce more cookies. Performance is how fast something can get done, u
Read more