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.

Apr
3

By

How We Get Coding Standards Wrong

Category: Reasoning About Code Tags: , | 22 Comments

The other day, I sat in on a meeting where a large-ish group was discussing “standards” for their particular area of software development. I have the word standards in quotes because, by design, there wasn’t a clear definition as to what sorts of standards they would be; it was an open-ended exercise. The standard could cover anything from variable casing to development practices and principles to holistic approaches. When asked for my input, I was sort of bemused by the process, and I said that I didn’t really have much in the way of an answer. I declined to elaborate much more on that since I wasn’t interested in derailing the meeting in any way, but it did get me to thinking about why the exercise seemed sort of futile to me.

I generally have a natural leeriness when it comes to coding and development standards and especially activities designed to flesh those out, and in this post I’d like to explore why. It isn’t that I don’t believe standards should exist or that I believe they aren’t important. It’s just that I think we frequently miss the point and create standards out of some sense that it’s The Right Thing, and thus create standards that are pointless or even detrimental.

Standards by Committee Anti-Pattern

One problem with defining standards in a group setting is that any group containing some socially savvy people is going to gravitate toward diplomacy. Contentious and arbitrary subjects (so-called “religious wars”) like camel case versus Pascal case or where the bracket after a function goes will be avoided in favor or things upon which a consensus may be reached. But think about what’s actually happening–everyone’s agreeing that the things that everyone already does should be standardized. This is a fairly vacuous exercise in bureaucracy, useful only in the hypothetical realm where a new person comes on board and happens to disagree with something upon which twenty others agree.

People doing this are solving a problem that doesn’t exist: “how do we make sure everyone does this the same way when everyone’s currently doing it the same way?” It also tends to favor documenting current process rather than thinking critically about ideal process.

Let’s capture all of the stuff that we all do and write it down. Okay, so, coding standards. When working on a .NET project, first drive to the office. Then, have your keycard ready to get in the building. Next, enter the building…

Obviously this is silly, but hopefully the point hits home. The simple fact that you do something or that everyone in the group does something doesn’t mean that it’s worth capturing as trainable knowledge and enforcing on the group. And yet this is a direction I frequently see groups take as they get into a groove of “yes, and” when discussing standards. It can just turn into “let’s make a list of everything we do.”

Pointless Homogeneity

The concept of capturing the intersection of everyone’s approach and coding style dovetails into another problem with groups hashing out standards: a group-think bias. Slightly different from the notion that everything common should be documented, this is the notion that everything should be common. For instance, I once worked in a shop where developers were all mandated to use the same diff tool. I’m not kidding. If anyone bothered with a justification for this, I don’t recall what it was, other than some nod to pointless standards.

CookieCutter

You can take this pretty far. Imagine demands that you use the same syntax highlighting colors as your peers or that you keep your file system organized in the same way as everyone else. What does this have to do with the code you’re producing? Who knows…

It might seem like the kind of thing where you should just indulge the the harmless control freak driving it or the group that dreams it up as a unit, but this runs the risk of birthing a toxic culture. With everything, however inconsequential, homogenized, there is no room for creative thinkers to innovate with new approaches.

Make-Work Tasks

Another risk you run when coming up with standards is to create so-called standards that amount to codifying and mandating busy-work. I’ve made my evolving opinion of comments in code quite clear on a few occasions, and I consider them to be an excellent example. When you make “comment every method” a standard, you’re standardizing the procedure (mindlessly adding comments) and not the goal (clarity and communication).

There are plenty of other examples one might dream up. The silly mandate of “sort and organize usings” that I blogged about some time back comes to mind. This is another example of standardizing pointless make-work tasks that provide no substantive benefit. In all cases, the problem is that you’re not only asking developers to engage in brainless busy-work–you’re codifying it as an official mandate.

Getting Too Specific

Another source of issues that I’ve seen in the establishment of standards is a tendency to get too specific. “What sort of convention should we use when we declare a generic interface below an enumeration inside of a nested class?” Really? Does that come up often enough that it’s important for everyone to get on the same page about how to approach it?

I recognize the human desire for set closure; we don’t like it when a dresser is missing a drawer or when we haven’t collected the whole set, but sometimes you’ve just got to let it go. We’re not the IRS–it’s going to be alright if there are contingencies that we haven’t covered and oddball loopholes that we haven’t addressed.

Missing the Point

For me, this is the biggest one. Usually standards discussions are about superficial programming concerns rather than substantive ones, and that’s unfortunate. It is the aforementioned camel vs Pascal case wars or whether to put brackets and which kinds to use. To var or not to var? Should constants be all caps? If an interface is in a forest and doesn’t have an “I” in front of its name, is it still an interface?

I understand the benefit of consistency in naming, casing, and other syntactic considerations. I really do, in spite of my tendency to be dismissive and iconoclast on this front when discussing them. But, first off, let’s not pretend that there really is a right way with these things–there’s just the way that you’re used to doing them. And, more importantly, let’s not pretend that this is really all that important in the grand scheme of things.

We use consistent casing and naming so that a reader of the code can tell at a glance whether something is a field or a local variable or whether something is a method or a property or a constant. It’s really about promoting readability, which, in turn, is about maximizing maintainability. But you know what’s much harder on maintainability than Jones’s great constant casing blunder of 2010 where he forgot to use ALL CAPS? Writing bad code.

If you’re banging out behemoth methods with control statements eight deep, all of the camel case in the world isn’t going to make your code readable. A standard mandating that all such methods be prepended with “yuck” might help, but the real thing that you need is some standards about writing clean code. Keeping methods and classes small and focused, principles like DRY and SOLID, and other good design principles are much more important standards to which to aspire, but they’re often less concrete and harder to enforce. It’s much easier and more rote for a code reviewer to look for casing issues or missing comments than to analyze code for good software practice and object-oriented design. The latter is often less cut-and-dry and more a matter of degrees, so it’s frequently glossed over in favor of more tangible, simple things. Problem is, those tangible, simple things really aren’t all that important to the health of your applications and projects over the long haul.

It’s All Just Premature Optimization

The common thread here is that all of these standards anti-patterns result from solving non-existent problems. If you have some collection of half-baked standards at your company that go on for some pages and then say, “after that, follow the Microsoft standards,” imagine how they came about. I bet a few of the group’s original engineers or most senior people had a conversation that went something like, “We should probably have some standards.” “Yeah, I guess… but why now?” “I dunno… I think it’s, like, what you’re supposed to do.”

I suspect that if you did a survey, a lot more standards documents have started with conversations like that than with conversations about hours lost to maintenance and difficulty reading code. They are born out of cargo-cult practice rather than a necessity to solve some problem. Philosophically, they start as solutions in search of a problem rather than solutions to actual problems.

The situation is complicated by the fact that adoption of certain standards may have solved real problems in the past for developers on the team, and they’re simply doing the smart thing and carrying their knowledge forward. The trouble is that not all projects face the same problems. When discussing approaches, start with abstract and general abiding principles like SOLID and DRY and take it from there. If half of your team uses camel case and the other half Pascal and it’s causing communication and maintenance difficulties, flip a coin and set a standard. Repeat as necessary with other standards to keep the project moving and humming. But don’t make them up just for the sake of doing so. You wouldn’t start writing random code that may never solve any actual problem, so why create a standard that way?

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.

« Older Posts
Newer Posts »