The World of Jay Little
logo
The Death of the Meritocracy
5/7/2016 12:38 AM
Before you read this post, I urge you to read through my resume. When you do take particular note of how long it takes me to move from employer to employer. You'll notice that I don't spend too much time in any one place. Why is that? I've been thinking a lot about that as of late, and I have some thoughts that I'd like to share with the world at large.

To put it arrogantly: I'm very good at what I do. I have knack for consistently driving to the heart of problems and providing working solutions to those problems in relatively short order. Software development just so happens to be my preferred tool when it comes to providing solutions. I'm not above providing solutions that don't utilize software, but generally software solutions are the kinds of solutions I provide. I attribute most of my talent to the fact that I was lucky enough to be born into a family where I was exposed to technology at a very early age, though not too early. I won't bore you with the details as they have been covered in previous posts, but I got my first computer, an Apple IIe, at the age of six. I began to learn how to program at the same time thanks to a BASIC book my father, who is also a software developer, bought for me.

I thrive in an environment that provides technical challenges. At my most trying professional moments, it is the lure of the unconquered challenge that gives me my second wind. I hate to dismiss, avoid and hide from problems. I enjoy tackling them head on. I also enjoy dealing them quickly and efficiently. I believe that software developers exist for a single purpose: To increase the efficiency of their would-be users. Anything else is fluff to be ignored. This approach has led to a weird combination of beliefs ultimately resulting in a professional ethos that is hard for many to understand. Rather than delve further into those details though, I'd prefer to return to the original discussion.

Did my previous employers fail to provide me with technical challenges? They did not. In fact I have never had an employer or a client who has failed to challenge me in some notable way from a technical standpoint. Unfortunately what all have ultimately failed to provide, with the exception of one, is a true meritocracy. According to dictionary.com the primary definition of meritocracy is "an elite group of people whose progress is based on ability and talent rather than on class privilege or wealth." Talented people really want to be recognized and appreciated. They also want to make a positive difference. But what few if any of us are willing to tolerate is being lorded over by those we consider to mediocre.

Therein lies the crux of my problem. I have worked at a number of places over the years and other than working for myself, no place could be considered a meritocracy. Whether the employer/client was big or small the end result was the same: People were more likely to recognized and rewarded on the basis of politics rather than the basis of merit. Sometimes people are not rewarded at all.

I've lost count of the number of times a manager has told me during a performance review: "I know you deserved a higher rating than this. But the company restricts how many people we can give the top rating out to and unfortunately you didn't make the cut." Whereas at the same time, my mediocre co-workers tend to receive similar performance reviews without the same caveat, despite the overwhelming obvious gulf of difference in performance. Each and every time I experience this at an employer, it effectively marks the beginning of the end for me. To be told that I deserved better but received something less repeatedly has worn me down over the years. As soon as I hear it, I almost always start looking for another job out of instinct.

Keep in mind, I don't just provide more results, I generally provide better results. Are there developers out there that can produce better quality solutions than me? Sure, but they are far and few between. Thnakfully I have been blessed enough to work with more than a few of them over the years as you can learn a lot from these people. Are there faster developers? Yes, but that answer depends entirely on how you measure speed. If you measure what developers can produce in an hour, there are faster developers than me. But if you measure what developers can produce in day, a week, a sprint or even a year you'll find nobody faster than I. My speed is consistent and something I bring to bear every single day. It's not the top speed out there, but it's faster than most and can be maintained indefinitely. A privileged upbringing and a relentless desire for practical self-improvement are at the heart of these results.

Yet here I am, detailing the fact that in my career (and I suspect the careers of many many others) there is no such thing as a meritocracy. Perhaps this environment exists in Silicon Valley somewhere, but back here in good old South Carolina I have yet to experience it. There are no words to describe the disappointment a talented person experiences when they realize that they have become a victim of corporate homogenization. What is that? I am more than happy to explain.

Nowadays its trendy for software shops to tell their employees, "We have the best developers in the country!" Though it is decidedly not true given the wide range of actual capabilities, it seems to sell with the masses. People have an inherent desire to believe that they are part of something great. If an employer keeps enough talented people around, they can even manage to make the illusion persist for awhile. But that's the heart of the problem. At some point instead of just serving the kool-aid, companies inevitably end up drinking the kool-aid.

I refer to this trend as "Getting high on your own supply". I have worked at so many places over the years which suffered from this syndrome that's it's just kind of sad at this point. Nevertheless once a shop drinks the kool-aid here, the death of the meritocracy is all but assured. Talented people stop being recognized and rewarded because the assumption is that everybody is talented therefore talent is no longer a unique asset but an assumed prerequisite that everybody brings to the table. When that becomes the case, talented people are marginalized and when that happens: They depart.

This trend is more prevalent in medium and large employers than it is with small ones. In a small startup situation, it's virtually impossible to homogenize employees because transparency is naturally at its highest possible point. But once an organization grows, the people at the top of organization inevitably become more disconnected from the people in the trenches. They lose whatever insight they used to have and are left only with their preconceptions and whatever their direct reports are willing to share with them.

In any event once the talented people are driven out of an organization, the organization will begin to flounder. Depending on the size of the organization and the state of things in general, it might take years for the effects to become apparent. But make no mistake: Once an employer has been marked in this sense, it is hard to roll back that perception.

Talented software developers are a rare commodity nowadays in terms of quality, speed and consistency. Can those exceptional traits be taught? I remain skeptical, though admittedly I am unqualified to argue the point. Nevertheless, drawing and retaining talent is often the difference between success and failure for a software development shop. The sooner the MBAs of the world get acquainted with this reality, the better off the rest of the world will be.

In my preferred system what would happen to the less talented software developers out there? They will either improve or go away. A meritocracy appeals to talented people because it promotes the concept of natural selection and it does not tolerate a trend of failure. One of the side effects of these kool-aid shops is that the less talented developers will inevitably begin to overestimate their own skills, though frankly they were more than likely doing that already. The basic take away here is that if you refuse to provide your employees with detailed and accurate feedback they will respond in kind by refusing to provide you with good work whether they are talented or not.

When I worked for myself, I did not have any of these problems. My merit was proven each and every billable cycle when my clients chose to pay me and I continued to provide them with the benefits of my labor. In retrospect I really miss working for myself. Sadly my skills in business development are stunningly lacking compared to my skills in software development so once my big client ran into serious issues, it was all over but the crying. Despite those sobering facts, I miss it. I really do. That doesn't seem like it will change anytime soon either.
Art or Science: Measuring Dev Productivity
4/10/2016 12:30 PM
I've recently spent some time mulling over the question of how one can adequately and consistently measure the productivity of software developers. The answer to this question interests me both as a software developer who is ranked against his teammates and as a member of a software development team that is ranked against other teams in the same company. How do you determine which dev is the most productive and which one is the least productive? How do you do that on a team level?

The real question begging to be asked here is: "What kind of data could be gathered in an effort to track productivity?" Well we could try something simple like tracking the lines of code a dev outputs on a daily/weekly/monthly basis, but such simple measurements have long since been rejected and rightfully so. Lines of code have nothing to do with how productive a dev can be especially when we are presented with situations in which more efficient solutions tend to require less lines of code than inefficient ones. The same reasoning can be used to debunk tracking the number of commits a dev makes to a source code repository as well.

Okay then so why not the number of stories completed or a sum of story points associated with those completed stories? Agile development is all the rage nowadays and most teams likely have access to these kinds of data streams as a result, so in theory this makes some sense. Nevertheless at the end of the day the number of stories and story points means very little in my mind. This mostly revolves around the fact that story points after largely fictional units that have no basis in reality whatsoever. While a well disciplined team could perhaps use a tally of story points to compare its current performance with its performance in the past (assuming that story points are applied consistently and thoughtfully) it seems ludicrous to use that as a metric for comparing performance between teams as the value of a story point is determined on a team by team basis. Moreover the number of stories is even less appealing for use in comparing one team to another as the number of stories on the board or in the backlog is more a responsibility of the Product Owner and the users he/she represents rather than the team itself. Within the team comparing a number of stories between developers is not a very useful metric as stories will vary wildly in terms of complexity so a raw count of completed stories should do little to bolster or dampen perceptions of any particular devs productivity.

What about asking other team members? For instance why not ask the team members tasked with QA to rank developers based on the amount of testing surface area their stories encompass? While I think this idea is better than the previous ideas, it doesn't lend itself as well to empirical measurement. However if you can circumvent any obvious personal bias, it seems to me that QA Engineers are probably in the best position to judge relative dev productivity within a team. Though to be frank, such a mechanism doesn't lend itself well at all to comparing one team to another. It also runs the risk of measuring the wrong thing as the amount of time a QA Engineer spends in the recursive process of identifying bugs and testing the fixes provided by devs should detract from the perception of a devs productivity rather than enhancing it.

What about asking the users? Now to be fair, outside of extreme situations, users are unlikely to know which specific dev worked on the new features that are being delivered to them, but I think this is actually a good thing. At the end of the day a craftsman can be best judged by the fruit of their labors rather than the chaos leading up to it. What's most important here is that users are also in the best position to judge the relative merit of one feature over another. A user is in the unique position of providing the best feedback at the most pure level precisely because they generally aren't well acquainted with the people doing the work behind the scenes but only familiar with whether or not the work provided a direct benefit to them. At the end of the day, software devs exist for one and one reason only: To solve problems and make users more efficient. Anything we produce that lacks those benefits may as well not even exist to begin with.

Now I'm sure some will read this article and take issue with that conclusion (especially the architects of the world), however they won't get much sympathy from me. The reality of the situation with software devs is this: If your work doesn't benefit the user in some way, your work isn't valuable. We can muddle about with class design and service layers for months on end and still provide absolutely no benefit for current and prospective end users. Adopting such an approach to software development, especially in a world focused on agile development (which itself is focused on delivering features to the end user in a timely manner) is stunningly dangerous, ass-backwards and likely career limiting.

In a perfect world, a dev who focuses on end user delivery and satisfaction will likely score well both in terms of QA feedback and on the less than useful story and point metrics as well. Lines of code and number of commits are metrics that really don't apply well in any situation sadly and can be easily gamed by less than capable devs looking to mask their poor performance.
Search:   [Rss]   [Email]