DaedTech

Stories about Software

Apr
5

By

How Stagnation is Justified: Language of the Expert Beginner

Category: The Life of a Programmer Tags: , | 9 Comments

So far in the “Expert Beginner” series of posts, I’ve chronicled how Expert Beginners emerge and how they wind up infecting an entire software development group. Today I’d like to turn my attention to the rhetoric of this archetype in a software group already suffering from Expert Beginner-induced rot. In other words, I’m going to discuss how Expert Beginners deeply entrenched in their lairs interact with newbies to the department.

It’s no accident that this post specifically mentions the language, rather than interpersonal interactions, of the Expert Beginner. The reason here is that the actions aren’t particularly remarkable. They resemble the actions of any tenured employee, line manager or person in a position of company trust. They delegate, call the shots, set policy, and probably engage in status posturing where they play chicken with meeting lateness or sit with their feet on the table when talking to those of lesser organizational status. Experts and Expert Beginners are pretty hard to tell apart based exclusively on how they behave. It’s the language that provides a fascinating tell.

Most people, when arguing a position, will cite some combination of facts and deductive or inductive reasoning, perhaps with the occasional logical fallacy sprinkled in by mistake. For instance, “I left the windows open because I wanted to air out the house and I didn’t realize it was supposed to rain,” describes a choice and the rationale for it with an implied mea culpa. The Expert Beginner takes a fundamentally different approach, and that’s what I’ll be exploring here.

False Tradeoffs and Empty Valuations

If you’re cynical or intelligent with a touch of arrogance, there’s an expression you’re likely to find funny. It’s a little too ubiquitous for me to be sure who originally coined the phrase, but if anyone knows, I’m happy to amend and offer an original source attribution. The phrase is, “Whenever someone says ‘I’m not book smart, but I’m street smart,’ all I hear is, ‘I’m not real smart, but I’m imaginary smart.'” I had a bit of a chuckle the first time I read that, but it’s not actually what I, personally, think when I hear someone describe himself as “street smart” rather than “book smart.” What I think is being communicated is “I’m not book smart, and I’m sort of sensitive about that, so I’d like that particular valuation of people not to be emphasized by society.” Or, more succinctly, “I’m not book smart, and I want that not to be held against me.”

“Street smart” is, at its core, a counterfeit status currency proffered in lieu of a legitimate one. It has meaning only in the context of it being accepted as a stand-in for the real McCoy. If I get the sense that you’re considering accepting me into your club based on the quantity of “smarts” that I have, and I’m not particularly confident that I can come up with the ante, I offer you some worthless thing called “street smarts” and claim that it’s of equal replacement value. If you decide to accept this currency, then I win. And, interestingly, if enough other people decide to accept it, then it becomes a real form of currency (which I think it’d be pretty easy to argue that “street smart” has).

Whatever you may think of the “book smart vs street smart” dichotomy notwithstanding, you’d be hard pressed to argue that the transaction doesn’t follow the pattern of “I want X,” “I don’t have that, but I have Y (and I’m claiming Y is just as good).” And understanding this attempted substitution is key to understanding one of the core planks of the language of Expert Beginners. They are extremely adept at creating empty valuations as stand-ins for meaningful ones. To see this in action, consider the following:

  1. Version control isn’t really that important if you have a good architecture where two people never have to touch the same file.
  2. We don’t write unit tests because our developers spend extra time inspecting the code after they’ve written it.
  3. Yeah, we don’t do a lot of Java here, but you can do anything with Perl that you can with Java.
  4. Our build may not be automated, but it’s very scientific and there’s a lot of complicated stuff that requires an expert to do manually.
  5. We don’t need to be agile or iterative because we write requirements really well.
  6. We save a lot of money by not splurging on productivity add-ins and fancy development environments, and it makes our programmers more independent.

In all cases here, the pattern is the same. The Expert Beginner takes something that’s considered an industry standard or best practice, admits to not practicing it, and offers instead something completely unacceptable (or even nonsensical/made up) as a stand-in, implying that you should accept the switch because they say so.

Condescension and Devaluations

This language tactic is worth only a brief mention because it’s pretty obvious as a ploy, and it squanders a lot of realpolitik capital in the office if anyone is paying attention. It’s basically the domain-specific equivalent of some idiot being interviewed on the local news, just before dying of hurricane, saying something like “I’m not gonna let a buncha fancy Harvard science-guys tell me about storms–I’ve lived here for forty years and I can feel ’em comin’ in my bones. If I need to evacuate, I’ll know it!”

In his fiefdom, an Expert Beginner is obligated to have some explanation for ignoring best practices that at least rises to the level of sophistry and offers some sort of explanation, however improbable. This is where last section’s false valuations shine. Simply scoffing at best practices and new ideas has to be done sparingly or upper management will start to notice and create uncomfortable situations. And besides, this reaction is frankly beneath the average Expert Beginner–it’s how a frustrated and petulant Novice would react. Still, it will occasionally be trotted out in a pinch and can be effective in that usage scenario since it requires no brain cells and will just be interpreted as passion rather than intellectual laziness.

The Angry Driver Effect

If you ever watch a truly surly driver on the highway, you’ll notice an interesting bit of irritable cognitive bias against literally everyone else on the road. The driver will shake her fist at motorists passing her, calling them “maniacs,” while shaking the same fist at those going more slowly, calling them “putzes.” There’s simply no pleasing her.

An Expert Beginner employs this tactic with all members of the group as well, although without the anger. For example, if she has a Master’s degree, she will characterize solutions put forth by those with Bachelor’s degrees as lacking formal polish, while simultaneously characterizing those put forth by people with PhDs as overly academic or out of touch. If the solution different from hers is presented by someone that also has a Master’s, she will pivot to another subject.

Is your solution one that she understands immediately? Too simplistic. Does she not understand it? Over-engineered and convoluted. Are you younger than her? It’s full of rookie mistakes. Older? Out of touch and hackneyed. Did you take longer than it would have taken her? You’re inefficient. Did it take you less time? You’re careless. She will keep pivoting, as needed, ad infinitum.

Taken individually, any one of these characterizations makes sense and impresses. In a way, it’s like the cold-reading game that psychics play. Here the trick is to identify a personal difference and characterize it; anything produced by its owner as negative. The Expert Beginner controls the location of the goalposts via framing in the same way that the psychic rattles off a series of ‘predictions’ until one is right, as evidenced by micro-expressions. The actual subtext is, “I’m in charge and I get to define good and bad, so good is me, and some amount less good is you.”

Interestingly, the Expert Beginner’s definition of good versus bad is completely orthogonal to any external characterizations of the same. For instance, if the Expert Beginner had been a C student, then, in her group, D students would be superior to A students because of their relative proximity to the ideal C student. The D students might be “humble, but a little slow,” while A students would be “blinded by their own arrogance,” or some such thing. It’s completely irrelevant that society at large considers A students to be of the most value.

Experts are Wrong

Given that Expert Beginners are of mediocre ability by definition, the subject of expertise is a touchy one. Within the small group, this isn’t really a problem since the Expert Beginner is the designated Expert there by definition. But within a larger scope, actual Experts exist, and they do present a problem–particularly when group members are exposed to them and realize that discrepancies exist.

For instance, let’s say that an Expert Beginner in a small group has never bothered with source control for code, due to laziness and a simple lack of exposure. This decision is likely settled case-law within the group, having been justified with something like the “good architecture” canard from the Empty Valuations section. But if any group member watches a Pluralsight video or attends a conference which exposes them to industry experts and best practices, the conflict becomes immediately apparent and will be brought to the attention of the reigning Expert Beginner. In the last post, I made a brief example of an Expert Beginner reaction to such a situation: “you can’t believe everything you see on TV.”

This is the simplest and most straightforward reaction to such a situation. The Expert Beginner believes that he and his ‘fellow’ Expert have a simple difference of opinion among ‘peers.’ While it may be true that one Expert speaks at conferences about source control best practices and the other one runs the IT for Bill’s Bait Shop and has never used source control, either opinion is just as valid. But on a long enough timeline, this false relativism falls apart due to mounting disagreement between the Expert Beginner and real Experts.

When this happens, the natural bit of nuance that Expert Beginners introduce is exceptionalism. Rather than saying, “well, source control or not, either one is fine,” and risk looking like the oddball, the Expert Beginner invents a mitigating circumstance that would not apply to other Experts, effectively creating an argument that he can win by forfeit. (None of his opponents are aware of his existence and thus offer no counter-argument.) For instance, the Bait Shop’s Expert Beginner might say, “sure, those Experts are right that source control is a good idea in most cases, but they don’t understand the bait industry.”

This is a pretty effective master-stroke. The actual Experts have been dressed down for their lack of knowledge of the bait industry while the Expert Beginner is sitting pretty as the most informed one of the bunch. And, best of all, none of the actual Experts are aware of this argument, so none of them will bother to poke holes in it. Crisis averted.

All Qualitative Comparisons Lead Back to Seniority

A final arrow in the Expert Beginner debate quiver is the simple tactic of non sequitur about seniority, tenure, or company experience. On the surface this would seem like the most contrived and least credible ploy possible, but it’s surprisingly effective in corporate culture, where seniority is the default currency in the economy of developmental promotions. Most denizens of the corporate world automatically assign value and respect to “years with the company.”

Since there is no bigger beneficiary of this phenomenon than an Expert Beginner, he plows investment into it in an attempt to drive the market price as high as possible. If you ask the Expert Beginner why there is no automated build process, he might respond with something like, “you’ll understand after you’ve worked here for a while.” If you ask him this potentially embarrassing question in front of others, he’ll up the ante to “I asked that once too when I was new and naive–you have a lot to learn,” at which time anyone present is required by corporate etiquette to laugh at the newbie and nervously reaffirm that value is directly proportional to months employed by Acme Inc.

The form and delivery of this particular tactic will vary a good bit, but the pattern is the same at a meta-level. State your conclusion, invent a segue, and subtly remind everyone present that you’ve been there the longest. “We tried the whole TDD thing way back in 2005, and I think all of the senior developers and project managers know how poorly that went.” “Migrating from VB6 to something more modern definitely sounds like a good idea at first, but there are some VPs you haven’t met that aren’t going to buy that one.”

It goes beyond simple non sequitur. This tactic serves as a thinly veiled reminder as to who calls the shots. It’s a message that says, “here’s a gentle reminder that I’ve been here a long time and I don’t need to justify things to the likes of you.” Most people receive this Expert Beginner message loudly and clearly and start to join in, hopeful for the time they can point the business end at someone else as part of the “Greater Newbie Theory.”

Ab Hominem

In the beginning of this post, I talked about the standard means for making and/or defending arguments (deductive or inductive reasoning) and how Expert Beginners do something else altogether. I’ve provided a lot of examples of it, but I haven’t actually defined it. The central feature of the Expert Beginner’s influence-consolidation language is an inextricable fusing of arguer and argument, which is the polar opposite of standard argument form. For instance, it doesn’t matter who says, “if all humans have hearts, and Jim is a human, then Jim has a heart.” The argument stands on its own. But it does matter who says, “Those of us who’ve been around for a while would know why not bothering to define requirements is actually better than SCRUM.” That argument is preposterous from an outsider or a newbie but acceptable from an Expert Beginner.

A well-formed argument says, “if you think about this, you’ll find it persuasive.” The language of the Expert Beginner says, “it’s better if you don’t think about this–just remember who I am, and that’s all you need to know.” This can be overt, such as with the seniority dropping, or it can be more subtle, such as with empty valuations. It can also be stacked so that a gentle non sequitur can be followed with a nastier “get off of my lawn” type of dressing down if the first message is not received.

In the end, it all makes perfect sense. Expert Beginners arrive at their stations through default, rather than merit. As such, they have basically no practice at persuading anyone to see the value of their ideas or at demonstrating the superiority of their approach. Instead, the only thing they can offer is the evidence that they have of their qualifications–their relative position of authority. And so, during any arguments or explanations, all roads lead back to them, their position titles, their time with the company, and the fact that their opinions are inviolate.

If you find yourself frequently making arguments along the lines of the ones that I’ve described here, I’d suggest putting a little more thought and effort into them from now on. No matter who you are or how advanced you may be, having to defend your opinions and approaches is an invaluable skill that should be kept as sharp as possible. You’ll often learn just as much from justifying your approach as formulating it in the first place. If you’re reading this article, it’s pretty unlikely that you’re an Expert Beginner. And, assuming that you’re not, you probably want to make sure people don’t confuse you with one.

Next: “Up or Not: Ambition of the Expert Beginner”

Edit: The E-Book is now available. Here is the publisher website which contains links to the different media for which the book is available.

Mar
31

By

Optimizing Proto-Geeks for Business

Category: The Life of a Programmer Tags: , | 1 Comment

In a recent post, I talked about the importance of having Proto-Geeks in your software group rather than Loafers and the toxic impact of too many Loafers in the group. If you’ll recall, Proto-Geeks are automaters (in other words, developers) that are enthusiastic about new technologies, and Loafers are ones that don’t much care for it and have a purely utilitarian desire to automate. Loafers are interested in automating only to maximize their efficiency so that their benefit-to-effort ratio is maximized.

One thing that I mentioned only briefly in the last post was the idea that Loafers, in spite of having no love for new technologies or ideas, would have the best business sense. Where Proto-Geeks might go bounding off on unprofitable digressions simply for the sake of solving technological puzzles, Loafers will keep their eyes on the prize. I dismissed this as an issue by saying that Loafers were locally maximizing and self-interested rather than being concerned with the best interests of the group as a whole. In retrospect, I think that this is a bit of an oversimplification of both the motivations of the Loafer and the best way to navigate the balance between interest in new technology and conservative business sense.

Let me be clear: the best approach is to have as few Loafers as possible. So the real question is how to reign in Proto-Geeks and get them to have business sense. And I think the answer is a two-pronged one: use gamification strategies and do away with the tired notion that programmers don’t “know business” and that you stick them in a room, slide pizza under the door, and get software in return at some point.

PizzaUnderTheDoor

No More Project Managers

Typically, organizations create the role of “Project Manager” and “Software Developer” and, along with these roles, create the false dichotomy that the former “does business” and the latter “does technology.” Or, in the parlance from these posts, the former is a Fanboy and the latter is a Proto-Geek or a Loafer. There’s an interesting relationship between the project manager Fanboys and the Loafers, as compared with the PMs and the Proto-Geeks.

Specifically, PMs tend to like and identify with Loafers and be annoyed by Proto-Geeks. Why would Fanyboy identify with Loafer? That doesn’t seem to make a lot of sense, given that they’re in opposite quadrants. Fanboys root for technology while not being particularly adept or inclined toward automation on their own, while Loafers are leery of technology but reasonably good at automating things. So, what common ground do these archetypes find? Well, they meet in two ways:

  1. Because of the division of labor, PMs have to root for automation without doing it themselves, which means rooting for and depending on automaters.
  2. PMs that got their start in programming used to be or would have been Loafers.

If you consider the canonical question posed to Padiwan developers fresh out of school at an annual review, “do you want to be on the technical track to architect or the project management track,” you’re basically asking “are you a Proto-Geek or a Loafer?” If that seems like a harsh parallel to draw, think about what each response means: “I love technology and want to rise to the top of my craft,” versus, “programming is really just a means to a different end for me.” These are cut-and-dry responses for their respective quadrants.

So while you have one breed of Loafer that loosely corresponds to Lifer and just wants to bang out code and collect a paycheck, you have another breed that wants to bang out code just long enough to get a promotion and trade in Visual Studio and Eclipse for MS Project and a 120% booked Outlook calendar. Once that happens, it’s easy to trade in the reluctant automater card for enthusiastic tech Fanboy.

But a tension emerges from this dynamic. On the one hand, you have the people developing along the technical track, getting ahead because of their expertise in the craft for which everyone in the group is hired. On the other hand, you have a group that tends to underperform relatively in the same role, looking opportunistically for a less technical field of expertise and authority. The (incredibly cynical) logical conclusion of this dynamic is the “Dilbert Principle,” which holds that the least competent programmers will be promoted to project management where they can’t do as much damage to the software, consumed as they are with Gantt Charts and Six Sigma certifications and whatnot.

However cynical the Dilbert Principle might be and however harsh the “PM as disinterested programmer” characterization might be, there’s no altering the fact that a very real tension is born between the “tech track” and the “project management” track. This is exacerbated by the fact that “project manager” has “manager” in the title whereas “senior software engineer” or “architect” does not. Seem silly? Ask yourself what life might be like if Project Manager was renamed to the (more accurate) title “Status Reporter/Project Planner,” as observed on the Half Sigma blog:

It is often suggested that the most natural next move “up” is into project management. But the first problem with this situation is that project management sucks too. It doesn’t even deserve to have the word “management” in the title, because project management is akin to management as Naugahyde leather is to leather. Project planner and status reporter is the more correct title for this job. Once you take the word “manager” out of title, it loses a lot of its luster, doesn’t it? Everyone wants to be a manager, but few would want to be a project planner and I daresay no one would want to be a status reporter. Status reporting is generally the most hated activity of anyone who endeavors to do real work.

There’s little doubt that project managers are often de facto developer managers–generally not in the org chart, but certainly in terms of who is allowed by the organization to boss whom around. And so there tends to be a very real tension between the top technical talent and the top business-savvy talent. Ace Proto-Geeks resent being ordered around by their perceived inferiors who couldn’t hack it doing “real work” and ace Project Managers hate having to deal with prima donna programmers too stupid in the ways of office politics and business sense to put themselves on track toward real organizational power.

I submit that this is an entirely unnecessary wall to build. You can eliminate it by eliminating the “project manager” role from software groups. To take care of the “project planner” role responsible for perpetually inaccurate Gantt charts and other quixotic artifacts, just go agile. Involve the customer stakeholders directly with the development group in planning and prioritizing features. Really. Your devs are knowledge workers and bright people–you don’t need an entire role to run interference between them and customers. As for the “status reporter” role, come on. It’s 2013. If you don’t have an ALM tool that allows a C-level executive to pull up a snazzy, progress reporting chart automatically, you’re doin’ it wrong.

So the first step is to stop hiring Loafers with the specific intent that they’ll conflict with and reign in the Proto-Geeks. Running a business like US Congress isn’t a good idea. Split the meta-project/housekeeping tasks among the developers, rather than creating a clashing, non-technical position on the team for this purpose and pumping up its title in terms of office politics.

Gamify

So you’ve eliminated the Loafers, but now you need to get your Proto-Geeks to think about the bottom line once in a while. You can round them up and lecture them all you like, and if you take a hardline kind of approach, it might work after a fashion. But I really don’t recommend this because (1) Proto-Geeks are knowledge workers that are very good at gaming metrics, and (2) real talent is likely to leave. You need their buy-in and this requires you to partner with them instead of treating them like assembly line workers.

But the thing that runs a Proto-Geek’s motor is automating things using cool tools and technologies. At their core, they are puzzle solvers and tinkerers and they enjoy collecting a paycheck for figuring out how to get their geeky toys and playthings to solve problems in your organization’s problem domain. You need some way to collect and analyze the performance of machines and workers on your manufacturing floor? Dude, they can totally do that with the latest version of ASP MVC, and they can even use this new open-source site profiler to analyze the performance in realtime, and… what’s that? You only need the site and you don’t want them to get carried away with the profiler and whatever else they were about to say?

Well, just present this need to them as another problem within your domain and give them another puzzle to solve. Challenge them to build a site with as few dependencies as possible or tell them that they get to pick two and only two new toys for the next project or tell them that they can have as many toys as they want, but if they don’t make their deadlines, they don’t get any for the next project.

Another great trend from a business geek perspective is the way that cloud solutions like Azure and Salesforce work, where extra CPU cycles, memory usage, and disk space actually cost small amounts of money in real time. Nothing drives a Proto-Geek to do great things like this level of gamification where he knows–just knows–that after an all-nighter and some Mountain Dew, he can shave $40 per day here and $120 per day there.

These examples are really just off the cuff, so take them with a grain of salt, but the underlying message is important. You don’t need to hire people that are skeptical of any release of VBA after MS Access 2000 or who want to coast through programming at the entry level until they have enough seniority to be project managers in order to have team members focused on making the business profitable. You just need to have innovative and appropriate incentives in place. It’s the Proto-Geek’s job to get excited about technologies and problems and using technologies to solve problems. It’s management’s job to give them incentives that make them want to solve the right problems to ensure profitability.

Mar
28

By

I Screwed Up… You’re Welcome!

Category: The Life of a Programmer Tags: | 4 Comments

I’ve had trouble with the hosting of this site lately. As you may have noticed if you visit via the site instead of a feed reader, page load times had slowed to a crawl and sometimes the site was actually down. The hosting company, hostmonster, has provided me with good service over the last couple of years, both in terms of quality of hosting and responsiveness. I expected this to be no different a few days ago.

I called the first time I noticed substantial slowness, and I was told that it was some kind of aberration and everything was fine. A few days later, there was a problem again, and this time the source, I was told, was that there was a node down somewhere between me as a client and my site. Between these two incidents, my site had been slow. I shrugged it off and then noticed the next day that, yet again, my site was pretty much non-functional. Hoping for quicker turn-around and to see if anyone else was having issues, I mentioned this on Twitter and was quickly replied to by the Hostmonster help account with this message: “We see our admins quickly fixed an issue that came up on your server. It is already running now again.”

The only problem was that, in their hurry to congratulate themselves, they’d forgotten to see whether the problem had been fixed. It hadn’t. I called again and was told that everything looked fine to them, at which point I took to Twitter to solicit suggestions for alternative hosting options. A couple of days and a number of phone calls later, Hostmonster did work with me and the issue appears to be resolved. Apparently, a user sharing a physical machine with my site had been infested with some kind of SPAM or something and was causing resource thrashing and throttling of my site. They eventually migrated me to another machine. I haven’t yet decided what to do about hosting. I’m weighing the annoyance of my site being unresponsive for a few days against the hassle of migrating and the fact that there were some very helpful people there that I eventually got to deal with after the first few had told me what a great job they’d done at fixing my imaginary problem.

But pulling back from my experience and looking a little more critically, I think the point at which my reaction as a user went from “annoyed but understanding” to “pissed” holds some lessons for consultants or anyone who deals with end users in a support capacity. I base this on examining the situation and discovering what I found galling.

  1. Don’t publicly declare a user’s problem fixed without confirming the user’s agreement.
  2. Avoid minimizing the user’s problems with words like “little” to describe the scope of the problem or, as in my case, “[quick]” to describe the downtime.
  3. Make every reasonable attempt to reproduce a user’s problem and prove to them that you’re doing so.

I know that there’s a balance to be struck between avoiding unfair blame (i.e. marketing and spinning your product/service in the best light) and between providing your users with solutions. I also know that there is no shortage of user error to go around. But I think it’s really important to understand and empathize with users when they’re frustrated. Go on Twitter or some other public forum and read the really negative comments about software or technology services, and, at the core, you’ll see extremely frustrated users.

You’ll see users whose websites have been down for two days and who don’t know when they’ll be back up. You’ll see users who have been struggling for hours to figure out how to get “hello world” out of the stupid thing. You’ll see users who just needed to get some work done for a deadline when your horrible update rendered their software non-functional and caused them to catch flak at a meeting. And the list goes on. These are the people you’re dealing with. They’re not malicious or looking to drag your name through the mud; rather, they’re looking to vent. And that’s your opportunity to be a sympathetic ear and to turn an incensed customer into a loyal one.

How’s that, you ask? Well, as much as people hate it when they’re frustrated, they can be mollified by the sense that you see that they’re having a problem, you understand it, you can fix it, and that you’re sorry that it happened to them. “Geez, I’m really sorry that update made you miss your meeting–I’d be mad too.” I bet that’d take the edge off of most people’s anger. Probably more so than “that update ran fine for me here, and check out that awesome new font it gave you–you’re welcome!”

I’m going to make it a point to try to harness the memory of these experiences as a user to make me better and more conscientious as a software provider. I’d rather be remembered for the kind things that users say about me than the flattering things I say about myself when others are within earshot.

(I’m still weighing my options for the hosting situation and running tests to confirm the response times continue to be better than they were, but my thanks to Daniel and Bradyn at Hostmonster who were actually quite helpful following my initial period of frustration.)

Mar
25

By

In with the Proto-Geeks, Out with the Loafers

Category: The Life of a Programmer Tags: , | 1 Comment

Technology Progressives vs Conservatives Reconsidered

When it comes to our relationship with technology, most people think in terms of the classic struggle between inventors that capture the imagination and laborers that don’t want to be imagination-captured right out of a steady paycheck. I think this is a rather obvious way to consider technology in our lives, but that there’s another dimension that sort of kicks in as an “aha” moment in much the same way that a line between “left” and “right” politically is trumped by the political compass quadrant system that also addresses libertarianism vs authoritarianism.

Towards that end, I propose quadrants related to technology. On one axis, there is the line from Luddite to Technologist. This is the line along which enjoyment of technology ranges when it comes to aesthetics and emotions. Luddites have a visceral dislike for technology, often because it makes them feel insecure or afraid (e.g. laborers in a factory who are about to be replaced by robots). Technologists have an emotional connection with technological advancement, generally because they find change and new possibilities exciting and intriguing (e.g. people that read about scientific advances, hobbyists that build robots, etc.).

On the other axis, there is a range from Laborer to Automater. Along this line, applied and practical interaction with technology varies. The Laborer will have little opportunity and/or motivation to use technology to automate day-to-day tasks (e.g. an artisan or a member of a think tank). Automaters embrace optimizations brought about through the use of technology and will typically seek to be as efficient as possible. People at this end of the spectrum value technology in a pragmatic sort of way, using it as well as process to optimize for time, cost, etc. People who use mobile devices to track appointments and tasks to the point of hyper-organization are good examples.

These two axes yield the following graph, with labeled quadrants.
TechGraph

The most obvious quadrants are the Luddite-Laborer and Technologist-Automater, as those are the roles that we think of as the Curmudgeon and the Proto-Geek, respectively. Curmudgeons hate and regard with suspicion anything that is newfangled and unfamiliar, while their polar opposite, Proto-Geeks, embrace things specifically because they’re new and flashy. All of the elements of the ethos of hard work and humble living (Protestant Work Ethic to the point of absurdity) versus endless, powerful novelty (decadence, convenience, playing God) come into play here, and this represents the linear spectrum that most envision about technology. The less frequently discussed quadrants are the ones that I’m calling, “Fanboy” and, “Loafer.”

“Fanboy” is the set of people that enjoy technology for its aesthetics and have a concept of tech-chic. These are people who will buy something like a cell phone for an accessory more so than for the various practical purposes of automating parts of their lives such as the aforementioned task tracking and organization. Non-technical gamers may also fall in this quadrant. The other less commonly considered quadrant is the Loafer, who prefers to automate things in life but has no love for new technologies and techniques. Contradictory as this may seem, it’s actually relatively common. And worse, it’s toxic to your software development group.

Inside the Mind of the Loafer

To understand the problem, it’s essential to understand what makes the Loafer tick. First of all, the Loafer isn’t a malingerer in the sense that he’ll shirk his responsibilities or do work that is of inferior quality. Rather, the Loafer seeks to optimize efficiency so that the value proposition of doing work is improved. In other words, if you task a Loafer with alphabetizing a list of 50,000 names, he’ll write a program to do it because that gets the job done more quickly. He’ll charge you the same rate regardless of methodology, though, so he’s automating specifically to allow himself more free time (or profit, as it were).

By way of contrast, consider the Proto-Geek’s response to this same task. She’d most likely blurt out, “That’s easy! I could do that in any programming language–you know what? I’ll do it in Ruby because that will give me a chance to play with Ruby. Cost? Oh, geez, I dunno. Maybe ten bucks…? It’s really no big deal.” The Proto-Geek is interested in solving the problem and leveraging cool new techs to do it. Profit/time optimizing is a secondary concern. (It is also interesting to consider the reaction of the other quadrants to this scenario. Curmudgeon would probably extol the virtues of doing it by hand on your mental acuity, and Fanboy would probably do it by hand while tweeting about how there should be something that did this automatically.)

Proto-Geeks view automation as having a high cool factor. This is in contrast to Loafer, who views it as having a high profit factor. But why is this a detriment to your group? After all, it stands to reason that Loafer has the best business sense. It seems as though it’d be important to have people on the team that chose the best tool for the job rather than because they were simply excited to use it. And that is true. The problem is that Automaters further down the chart toward Luddite are operating in a way to maximize their own personal efficiency and profit, rather than the group’s.

Most Loafers in a software group don’t particularly like what they do, but they know that if they do more of it faster, they get more money–or more time to, well, Loaf. So once they find a set of tools, languages, frameworks, etc. and become facile with them, they’re not only disinterested in new technologies–they’re actively resistant. Loafers want nothing more than to continue to solve all problems that come their way as quickly and with as little effort as possible, but with a locally-maximizing, greedy approach; investing a lot of extra effort in the shorter term to learn new ways of doing things more efficiently down the road is not appealing.

If you have one or two Loafers in your group, they can serve the useful purpose as natural conservatives that prevent Proto-Geeks from running buck-wild with new techs and frameworks. But this dynamic must be carefully monitored, like an inoculation, since the proportions can quickly become toxic. Tip the group’s dynamic a little too far into the Loafer quadrant and suddenly you have a bad case of “not invented here” and complete resistance to new ideas. There’s also frequently a strong correlation between Loafers and Expert Beginnerism; established Loafers often have a track record of some success with their approach and thus a powerful, built-in argument for inertia and the status quo. And finally, Loafers tend to kill enthusiasm for learning pretty quickly since presentation of new technologies is met with sarcasm, skepticism, and derision, making it essentially uncool to learn and embrace new things lest one be accused naivete or being some kind of shill.

If you’re in a position of authority within a group and recognize a Loafer dynamic, I’d suggest shaking things up to see if you can re-awaken or inspire a Technologist in some of them. Or perhaps you can infuse the group with some fresh-faced Proto-Geeks. If, on the other hand, you’re a powerless Proto-Geek in a Loafer group, you have a range of options from persuasion to proof-of-concept pitches to management to dusting off your resume. In either case, I think it’s important to recognize your surroundings and to try to seek out the quadrant in which you’re most comfortable.

Mar
20

By

Leading Software Teams of Humans

Category: The Life of a Programmer Tags: , | 3 Comments

I’ve been working lately on a project where I handle the build and deployment processes, as well as supply code reviews and sort of serve as the steward of the code base and the person most responsible for it. Not too long ago, a junior developer delivered some changes to the code right before I had to roll out a deployment. I didn’t have time to review the changes or manually regression test with them in place (code behind and GUI, so the unit tests were of no use), so I rolled them back and did the deployment.

That night, I logged back on and reviewed the code that I had deleted prior to the build. I read through it carefully and made notes, and then I went back to the version currently checked in and implemented a simpler version of the fix checked in by the junior developer. That done, I drafted an email explaining why I had reverted the changes. I also included in it some praise for getting the defect fix right, my own solution requiring less code, and a few pointers as to what made my solution, in my opinion, preferable.

By the time I finished this and saved a draft to send out the next day, it was pretty late at night and I was tired. As I got ready for bed, I contemplated what had motivated me along this course of action when none the extra work I did was really required. Clearly I thought this course of action was important, but my motivations were mainly subconscious. I wanted to understand what guiding principles of leadership I might be abiding by here and hammer them out a bit. And I think I got it figured out.

  1. Justify and explain your decisions.
  2. Prove the merits of your approach–show, don’t tell.
  3. Let members of your team take risks, using you as a safety net.

Explain Yourself

As I discussed in a previous post, a leader/manager issuing orders “because I say so” is incrementally losing the respect of subordinates/team members. And that’s exactly what’s going on if you simply make decisions without getting input or explaining the reasoning after the fact–as would have been the case in my situation had I not sent the email. What you’re saying to people when you unilaterally take action isn’t really clear because it’s cryptic and terse. So they’re left to interpret for themselves. And interpret they will.

They’ll wonder if maybe you’re just a jerk or paranoid. They’ll assume that you think they’re not important enough to bother with an explanation. Perhaps they’ll surmise that you think they’re too stupid to understand the explanation. They’ll wonder if they did something wrong or if they could improve somehow.

And really, that last one is the biggest bummer of all. If you’re a team lead and you need to overturn a decision or go in a different direction for a valid reason, that’s a very teachable moment. If you sit with them and help them understand the rationale for your decision, you’re empowering them to mimic your decision-making next time around and improve. If you just undo all their work with no fanfare, they learn nothing except that fate (and the team lead) is cruel. Seriously–that’s the message. And there are few things more demoralizing to an engineer than feeling as though the feedback mechanism is capricious, unpredictable, and arbitrary.

Show, Don’t Tell

“Because I said so” costs you respect in another important way on a technical team, as well. Specifically, it threatens to undermine your techie cred. You may think you’re Guru and you may even be Guru, but if you don’t occasionally offer demonstrations, the team members will start to think that you’re just a loud-mouthed armchair quarterback suited only for criticism, yelling, and second-guessing.

ArmchairQuarterback

If you lead a team and you don’t know what you’re doing technically, you’ll obviously lose them. But if you’re leading a team and you have a cloud architecture “do as I say” approach at all times, the outcome will differ only in that you’ll lose them more slowly. You should do something to demonstrate your technical chops to them. This will go a long way. Rands does an excellent job of explaining this (and I pay a subtle homage to his ideas with my post’s title). You have to build something. You have to show them that you’re the leader for a reason other than because you’ve hung around the company for a while or you have friends in high places. Developers usually crave meritocracy, and flashing some chops is very likely to make them feel better about following your lead. And you get bonus points if the flashing of said chops saves them work/teaches them something/shows them something cool.

You Are the Safety Net

I worked in a group once that was permeated by fear. It was a cultural thing born out of the fact that the loudest group members were the most paranoid and their skepticism flirted dangerously with cynicism. Nobody could be trusted with changing the code base, so code reviews were mandatory, often angry affairs that treated would-be committers as dastardly saboteurs out to commit acts of digital terrorism. The result of this Orwellian vibe was that progress and change happened inordinately slowly. Group members were much more terrified of doing the wrong thing than of missing deadlines or failing to implement features, so progress crawled.

I could also tell that there were intense feelings of stress for some people working this way. The feeling that you have to constantly avoid making mistakes is crippling. It is the province of a culture of learned helplessness–get yelled at enough for making code changes that aren’t good enough and you’ll just resort to asking the yellers to sit with you and show you exactly what to do every time. You’ll take no risks, run no experiments, and come to grips with no failures. You won’t improve–you’ll operate as a grunt and collect a paycheck.

As a team leader, this is a toxic environment if performance is important to you (and it might not be–some people just like being boss and having the luxury of not being judged on lack of performance). A stagnant, timid team isn’t going to have the autonomy necessary to handle the unexpected and to dream up new and innovative ways of doing things. In order for those things to happen, your team has to be comfortable and confident that mistakes and failed experiments will be viewed as valuable lessons learned rather than staging points for demerits, blame, and loss of political capital.

SafetyNet

So if someone on your team checks in code that breaks the build or slips into QA with problems or what-have-you, resist at all costs the impulse to get worked up, fire off angry emails, publicly shame them, or anything else like that. If you’re angry or annoyed, take some deep breaths and settle down. Now, go fix what they did. Shield them from consequences of their good-faith actions that might make them gun-shy in the future. Oh, don’t get me wrong–you should certainly sit them down later and explain to them what they did, what the problem was, and what fixing it involved. But whatever you do, don’t do it in such a way that makes them scared of coding, changing things, and tinkering.

Will this approach mean some late nights for you? Yep. Does it suck to have to stay late cleaning up someone else’s mess? Sure it does. But you’re the lead. Good leaders work hard and make the people around them better. They offer enthusiasm and encouragement and a pleasant environment in which people can learn and grow. They don’t punch out at five like clockwork and throw anyone that threatens their departure time under the bus. Leadership isn’t a matter of entitlement–it’s a position of responsibility.

« Older Posts
Newer Posts »