In my ChessTDD series, I was confronted with the need to create some actual acceptance tests. Historically, I’d generally done this by writing something like a console application that would exercise the system under test. But I figured this series was about readers/viewers and me learning alongside one another on a TDD journey through a complicated domain, so why not add just another piece of learning to the mix. I started watching a Pluralsight course about SpecFlow and flubbing my way through it in episodes of my series.
But as it turns out, I picked up SpecFlow quickly. Like, really quickly. As much as I’d like to think that this is because I’m some kind of genius, that’s not the explanation by a long shot. What’s really going on is a lot more in line with the “Talent is Overrated” philosophy that the deck was stacked in my favor via tons and tons of deliberate practice.
SpecFlow is somewhat intuitive, but not remarkably so. You create these text files, following a certain kind of format, and they’re easy to read. And then somehow, through behind the scenes magic, they get tied to these actual code files, and not the “code behind” for the feature file that gets generated and is hard to read. You tie them to the code files yourself in one of a few different ways. SpecFlow in general relies a good bit on this magic, and anytime there’s magic involved, relatively inexperienced developers can be thrown easily for loops. To remind myself of this fact, all I need to do is go back in time 8 years or so to when I was struggling to wrap my head around how Spring and an XML file in the Java world made it so that I never invoked constructors anywhere. IoC containers were utter black magic to me; how does this thing get instantiated, anyway?!
I just got back from a long weekend vacation and am still getting settled and back into the swing of things, so this is going to be another relatively short post. I’ll soon return to your regularly scheduled extended rants and code-cast posts, but I need a little slack in the meantime.
For the last six months or so, I’ve been making a 5 hour drive twice a week. This has provided me with a lot of opportunities to listen to books through Audible and Overdrive, and I’ve been listening to a lot of non-fiction stuff that runs the gamut from tech to sociology to science. Recently, I took a suggestion from a comment in a previous post and read/listened to “Getting Things Done.”
I have two degrees (Bachelor’s and Master’s) in computer science, so it’s probably no surprise that I place a fairly high degree of value on the background that all of this course work provided. That being said, my experience was that you learn some pretty unfortunate ‘lessons’ in CS degree programs. To name some that I learned (and later had to unlearn):
Writing readable code is for weaklings. Writing your entire loop logic inside the loop guard condition FTW!
You get partial credit for non-running (or even non-compiling) code if you add a lot of vacuous comments.
All programming projects can be wrapped up in a month or, in extreme cases, a semester.
Source control is an important thing, theoretically, but it doesn’t solve any actual problem you have.
There are no consequences to making an enormous mess of your code in the hour before your deadline as long as it hits the predefined benchmarks because you’ll never look at it again in your life.
Performance and accuracy of results are all that matter.
Staying up for 36 hours straight to wheeze across the finish line is how heroes get it done.
All you need to deliver is a bunch of source code files that compile.
First of all, I’d like to point out that these aren’t things that a professor sat me down and said at any point and, in fact, if shown this list, they’d probably say, “those things aren’t good lessons.” But these were the lessons I learned by virtue of the incentives to which I was exposed and how I was rewarded or penalized for my actions. There’s a lot of room for improvement, but I’ll come back to that later.
The common theme that drives this list of less-than-awesome lessons learned is that the academic environment and the theory that it tends to teach lend themselves to non-representative situations, contrived for the purpose of teaching a specific lesson, such as how to implement Alpha-Beta pruning or how state machines work. The best ways to drive these points of instruction home don’t correspond with workaday dev concerns like “write me a web service that triggers a database update and keep it relevant when I change my mind every month or so.”
But one lesson that I did take away that has served me very well is, “do what’s necessary to get a D instead of an F, save that off for reference, and once that’s secured, go for the C, save, etc.” In a lot of classes, we’d submit coding assignments that would run against some kind of benchmark, and it was something like, “if you satisfy 60 of the 100 conditions you get a D, 70 of 100 and you get a C, etc.” And I learned that you mitigated a lot of risk by making it your top priority not to fail or get a 0, and then improving from there. This way, if the time ran out, you’d be less like an action hero trying to defuse a bomb before the timer goes off and more like a fussy dog show entrant trying to put a few last minute touches on your dog that would improve its chances of being judged better than the other dogs, whatever that entails.
This early lesson to which I was first exposed as an undergrad, around the time the Agile Manifesto was being written, was really the precursor to concepts like iterative development and thin-sliced, end-to-end goals for software. It taught me, through real, meaningful incentives, to make sure that I secured at least some value before chasing unicorns like an A+ off into the sunset. If there were 2 minutes left to submit the assignment, I wanted the backup plan to be an A- rather than a zero.
So what does any of this matter to you grizzled software veterans a decade or however long into your careers? Well, bear in mind that there’s always an A- (or B or C or whatever) out there when a bunch of work gets thrown your way. That web service you’re tasked with writing isn’t all or nothing. Not even a phone app that shows you the time is all or nothing (if push comes to shove, and app that tells you whether it’s AM or PM is better than nothing). Things can always be pared down and scope can always be adjusted, assuming you design towards modularity.
The overriding message of this post is that you should always, always, always look at the beginning for ways that you can secure yourself intermediate grades between 0 and A+ on the way to calling your software done; it’s the only reasonable way that you can manage expectations and adjust on the fly with a software project, apart from getting your customer to agree to indefinite delays. But, for a bit of fun, I’ll leave you with a series of ideas for how college CS curricula might better prepare students for actual development gigs. These might make you laugh to think about, but they’re actually things that could add some value:
One assignment in every programming class starts you off not from scratch or from professor-written template code, but from whatever pile of mess some students turned in last semester (teaches you what an unkindness it is to make a mess in code)
Every assignment requires students to update a single, shared text file whenever they’re testing against the benchmark and they get dinged if it gets out of sync (teaching about file contention and merge conflicts)
There are one or more assignments during the course of the curriculum that simply cannot be totally completed (teaches students to prioritize while working against unrealistic parameters)
There is some code that you carry over semester to semester and thus have to live with for years and/or there is a class where each assignment builds on the code of the last one but requires refactoring (teaches writing code with the idea of maintaining it)
Lock kids out of the computer lab between 1 and 6 AM. (Teaches you that you’re going to work at places where juvenile heroics simply aren’t feasible for reasons ranging from the fact that this is a bad idea to the fact that the facility may be locked down at night)
All homework/project submissions are real-world deliverables along the lines of an actual phone app, web app or MSI installer (teaches that there’s more to delivering software than writing code)
I’m going to perform a slight experiment on myself in this post. As I type this second sentence, I have only a general idea for a post in mind, and I’m going to go out on a limb and say that this will be a relatively short post. I won’t come back and edit this paragraph if it turns out not to be, however. I’ll just look stupid. I’m going meta here because my posting cadence has slipped and I’m going to aim to combat that by mixing in some relatively short posts that are quicker to write and read. I’ve tried this before, and it’s sort of like a yo-yo diet where I cut back for a bit and then just kind of bloat back out to where I was. Anywho…
Over the course of my career a fairly common thing that I’ve done at a new company is to set up a wiki for collaboration. Almost invariably, this wiki replaces or, at least, aims to replace a series of Word documents. It’s as though there’s some kind of knowledge collection progression that goes, “nothing, README, Word, Wiki (or, perhaps, Sharepoint),” and I make my home at an organization just long enough to say, “hey, there’s a better option than shared drive/source controlled Word documents.” Why is the next step better? Searchability, not needing that “version history” table at the top, sane linking, changing the emphasis to content over styling, etc.
But, I had a thought today that I’d been sort of missing the point all these years. It’s not that wiki isn’t good, by any means, as a collaboration tool, but it’s that I’m often using it to mitigate the symptoms rather than treat the illness. If, as a developer, you find yourself opening Word to document a process, you’ve failed. If you optimize by documenting in a wiki, you’re just failing in a more searchable, sophisticated, and open-source way (unless you use Sharepoint, and then not open-source and maybe not sophisticated… hiyo, just kidding, but kind of not kidding.)
Is this a harsh thing to say? Certainly. Could you argue that I’m link baiting once you hear what comes next? Probably. But I think there’s an element of truth if you allow yourself to de-stigmatize the word “failure” and interpret it without a value judgment. For instance, today, I failed at being someone with 10,000 RSS subscribers to my blog. It’s true, but not damning. Developers documenting things with Word fall into this same category. You’re failing when you do this, and what you’re failing to do is automate.
I’ve blogged about a similar line of thought with code comments in the past. Comments in method bodies are basically developers saying, “I’m going to punt on making this code expressive and just kinda cheat by explaining this mess in English.” So it goes on a broader level with Word documents. Why do you write Word documents, after all? It’s to explain how to setup your development environment or how to perform a deploy. Maybe it’s to document what needs to happen whenever you add a new feature to the code base or in the event that you need to rollback to a previous version of the application. Whatever it is, you’re faced with some kind of procedure and you declare, “there’s a precise sequence of instructions that needs to be executed, and, as a programmer, I’m going to write them in English and use the next poor sap that happens on them as the runtime interpreter.”
I mean, think about it. If your process is defined well enough to merit a series of numbered steps in a Word document, it’s probably defined well enough to automate. Now, it might be that it’d take you three months to automate and 30 minutes to make the Word document. It might be that there are steps you lack the authority or permission to automate (or even do). It might be that you’re making a user manual or API document. There are any number of practical reasons that you’re not some kind of failure as a person for cracking open Word and explaining how to do something with a computer. You’re not a failure, but you have failed. For whatever reason, you’ve failed to automate. So next time you find yourself reflexively starting Word to make some sort of “writeup” about a technical thing, pause and ask yourself, “would automation of this process be possible and worthwhile?” It might not be, but then again, you might be surprised to find that the answer is “yes.”
Someone sent me a link to the video shown after this paragraph the other day, and I watched it. I then tweeted the link and sent it to a few of my coworkers because I figured it would make people laugh. It’s really funny, so give it a watch. But weirdly, I didn’t laugh. I watched it over and over again, mesmerized. I recognize that it’s funny and I find it funny, but I didn’t laugh.
This video is really a work of genius because it captures some incredible subtleties. There are two common archetypes captured nicely here in the form of the protagonist’s supposed allies: his boss and the project manager. I’ll give them names in their own sections below, along with the client characters. And then there are conversational tactics that bear mentioning.
This all revolves around a protagonist with whom any introverted person can identify. There’s nothing to indicate, per se, whether he’s introverted or extroverted, but the precision, the mannerisms, the posture — all of these scream “programmer” (or at least “engineer”) and so goes the association with introversion. The protagonist is the sole bulwark of sanity against a flood of idiocy, misunderstanding and general incompetence. You probably relate to him, having attended a meeting where all of the gathered C-levels and analysts thought you were being an obstructionist malingerer because you wouldn’t install Angry Birds on the meeting room’s television.
So who are the players?
In a way, I liken the smarmy project manager, Walter, to former British prime minister, Neville Chamberlain, most remembered for his foreign policy of appeasement leading up to World War II in which he sought to dampen the aggression coming from the Axis powers by essentially “befriending” them. In this particular video, Chamberlain, the project manager, is presumably along to bridge the gap between the non-subject-matter-expert customers and the total-subject-matter-expert protagonist (and whose expertise makes the video eponymous). That’s not really why he’s there (though he doesn’t realize this), and I’ll get into that later as I’m describing tactics.
Chamberlain perceives that his best interests are served by simply agreeing to whatever is happening on the other side of the aisle, improvident though this may be. On some level, he’s probably aware that this strategy is stupid, but, hey, that’s a problem for later. He thinks his boss will skewer him if they don’t get the contract, so the fact that it’s going to be hard or impossible to deliver (what Expert is trying to tell him) just means he’ll later throw someone (i.e., Expert) under the bus.
The “design specialist,” Justine, is a mildly interesting character. She generally looks at Expert with some degree of respect and looks slightly uncomfortable when the rest of the characters make fun of Expert. At one point, to Expert’s delight, she even understands his point, and she visits him after the meeting out of genuine interest in the project and what is probably a “one pro to another” kind of overture. She’s the only character in the room that sees any value in Expert, and she probably recognizes that his subject matter knowledge exceeds hers and has value. If it were just her and Expert, she would probably listen attentively. I call her Dilettante because she seems to be the type of person you encounter with a bit of knowledge in a variety of fields and a genuine interest in improving.
The client’s boss is a classic MacLeod Clueless, and a simple idiot that isn’t very interesting. She’s the classic archetype of an over-promoted middle manager whose value is clearly wrapped up in company tenure. She spouts nonsensical jargon, torpedoes her firm’s own interests throughout the meeting, and serves up her position and her firm’s money for easy pickings by any MacLeod sociopath that happens along. She’s demanding something that she doesn’t understand in a way that makes no sense, and she’s willing to pay any huckster that comes along and sells her the magic beans she’s seeking.
Big Boss Man, to whom Chamberlain reports, is a classic MacLeod Sociopath. He likely has a fairly good handle on the situation and is of the opinion that the clients are idiots, but he has an intuitive understanding of the politics of the situation. Expert is flummoxed by the stupidity of the client proposal, and Chamberlain is simpering in an effort to show his boss his value as a diplomat, believing that the customer is always right and believing that Sociopath also believes that. Sociopath doesn’t. He knows the clients are idiots, and that Chamberlain is also kind of an idiot (for evidence of this, look at his expression at 6:14 where he clearly thinks the discussion of cats and birds as lines is dumb and simply ignores the client).
This doesn’t result in him rushing into defend Expert, however. That’s counter to his best interests, which I’ll address as a tactic, but he also finds Expert somewhat distasteful. Sociopath has navigated his way ably to money and power and a position atop the corporate hierarchy, but it is probably a slight annoyance to him that he may not be the smartest guy in the room. He knows that in Expert’s area of expertise, he’s nowhere near Expert, and while that’s fine, his inability to compare their relative intellectual worth across subject areas is a source of irritation.
So, the ostensible point of this meeting and no doubt many in which you’ve sat is to define the parameters for a project and then successfully launch that project. But, if you were to read the subconscious goals of the players, they would go something like this:
Chamberlain: I want to get the client to sign off no matter what, and I want Sociopath to think it was my heroics that made this happen.
Buffoon: I want to order people around and show off.
Sociopath: I want this to be over quickly so I don’t have to listen to Buffoon and Chamberlain.
Dilettante: I want to learn on the job without it being apparent that I’m doing so.
Expert: I want to define parameters for this project and successfully launch it.
Sociopath knows that getting Buffoon to agree to the project is a veritable certainty going into the meeting, and he knows that Chamberlain’s presence is valuable, but not for the reasons that Chamberlain thinks. Chamberlain thinks he’s there because he’s a “straight shooter/smooth talker” that “speaks Expert” but Sociopath just wants him there because he understands how to butter Buffoon’s bread — by causing Buffoon to think she’s won an exchange and humbled an Expert. He’s there because Sociopath knows he’ll team up with Buffoon to laugh at Expert. Dilettante is just window dressing.
So what are the tactics by which this happens? What makes this so cathartic for engineers and programmers to watch? Well, there are a number of things occurring here.
Seizing on the only part of an explanation you understand
There’s nothing to level the playing field quite like ignoring most of what someone talking to you says and seizing on some minor point. This has two advantageous for purveyors of rhetorical fallacy. First and foremost, it lets you pivot the discussion in a way that you find favorable, but secondly, it implies that your opponent has babbled on and on and over-complicated the matter (ala Reagan countering Carter — folksy and relatable countering egg-head). Near the beginning, Expert gives a detailed explanation, avoiding saying that it would be impossible to draw red line with green ink by talking about color blindness. It’s a long-winded, but technically accurate way of saying “that’s pretty much impossible,” and all Buffoon takes away from it is “so, in principle this is possible.”
Talking down to the expert because you don’t understand
When Expert asks Buffoon to clarify what she’s talking about with “transparent ink,” she patronizingly says she thought that he’d know what “transparent” means and that he’d better know what “red” means if he’s an Expert. A little later, she doesn’t understand what perpendicular means and when Expert accidentally exposes that, she blames him for not understanding her nonsense. It’s a relatively standard approach to strike first in blaming the other for a miscommunication between two parties, but it’s especially vitriolic in a case where the party in the driver’s seat is covering inadequacy.
Begging the question (and perverting the role of experts)
I’ve encountered this myself, in my travels, and it’s certainly on display here. People assume (from ignorance) that a certain outcome is possible/feasible, and then seek out an expert to make it happen. When the expert explains that they’re misguided or trying to do something ill-advised or impossible, they adopt the stance, “I thought you were an expert, and you’re telling me you can’t do this?” Chamberlain does this throughout the clip.
This mostly comes from Sociopath and somewhat for show, but this is the tendency of those unskilled in a subject to assume that the subject is pretty simple and to generally devalue the knowledge of experts in that field. As more knowledge is acquired, so is respect for experts and humility. Sociopath dresses Expert down, particularly at the point where he says, “look, we’re not asking you to draw 20 lines — just 7.” Buffoon also does this once when she draws a triangle as an example of three perpendicular lines (“move — let me do it!”) Being the only Expert here and thoroughly outgunned and unaware of the real agenda, Expert is absolutely buried in an amplified echo chamber of Dunning Kruger.
These players and these tactics are painfully relatable. People in our line of work look at this ruefully and laugh because someone finally gets it and understands how silly the players seem to them. But introversion, lack of interest in office politics, and professional integrity are what hamstring us in such situations. I mean think of it this way — you cringe because you’re right there along with Expert, wanting these idiots to understand that red pens don’t draw green lines. You want to speak rationally to them and use analogies, diagrams and metaphors to make them see your point.
What you don’t do is turn the Dunning Kruger around on them and start telling them that they’re really going to need pure red lines if they want to maximize their verticals and strategize their synergies. You don’t tell them that kitten lines were so 2011. You don’t interrupt Chamberlain when he says “any fool can criticize” to say that you’re okay with the clients’ criticism and how he dare he call them fools. You don’t ask Chamberlain, if his title is “project manager,” why can’t he “manage” to define a clear spec.
You don’t do any of these things. Neither do I. Neither did Expert. Instead, we all do what he did in the end, which is to say, “sure, whatever buddy, I give up.” Extroverts extemporize and thrive in situations like this fueled with BS and beyond their control (though, Sociopath, who is controlling it, may be an introvert). We find ourselves at a loss for words, and utterly demoralized. Our credentials, our competence, and the validity of our very profession called into question, we bleakly resign ourselves to the madness and go home for a beer. We do that for a while, at least, and then, eventually, we Quit with a capital Q.
Perhaps that’s why I didn’t find myself laughing while watching this. Poor Anderson, the Expert, isn’t having an experience that he’ll submit to the Daily WTF and move on — he’s figuring out that his professional life is miserable. And the reason it’s miserable is because he’s realizing that expertise, ideas and results aren’t really the backbone of good business; in the land of the extroverts, egos and social capital are king.
I’ll admit as I type the first sentence of this post that I don’t know whether this will conclude a two-part “mini-series” or whether I’ll feel compelled to write further posts. But I wanted to write the follow up that I hinted at to the post I wrote about introversion for programmers (well, specifically me). Tl;dr refresher of that post is that social situations are exhausting for me because of their inherent unpredictability as compared to something like the feedback loop of a program that I’m writing (or even the easily curated, asynchronous interaction of a social media vehicle like Twitter). The subjects I left for this post were “Erik as a problem solver and pattern matcher,” consensus meetings, and two exceptional social situations that I don’t find tiring. The challenge will be spinning these things into a coherent narrative, but I’ll take a crack at it.
Whenever I look in my Outlook calendar and see something like “Meeting to Discuss Issue Escalation Strategy,” I am struck with a surprisingly profound feeling that life is filled with senseless waste, the way one might look in dismay at his sunglasses floating down a river he accidentally dropped them into. I see an hour or two of my life drifting away with no immediately obvious reclamation strategy. My hypothesis is that this is the sort of standard introvert take on what I’ll call “consensus meetings” rather than what many programmers seem to think of as a programmer take on them. As Paul Graham points out in one of my all time favorite posts, “when you’re operating on [a programmer’s] schedule, meetings are a disaster.” But I’m not really a maker these days anymore; for the time being, I’m a manager. And I still find these meetings to be a disaster.
Extroverts draw energy from social situations and become invigorated, while introverts spend energy and become exhausted. And, when I’m talking about social situations, I mean drinks and bowling with a group of friends. Introverts like me enjoy these nights but find them tiring. Now, apply this same sort of thinking to adversarial situations that are veritable clinics in bike-shedding. A bunch of introverts and extroverts gather together and set about deciding what the organizational flow chart of issue escalation should look like. Should it start at Tier 1 support and be escalated to the manager of that group, then over to internal operations and on up to Bill in DevOps? Or should it go through Susan in Accounting because she used to work in DevOps and and really has her finger on the pulse? Maybe we do that for 2 months and then go to Bill because that’s not really sustainable in the long term, but it’s good for now. And, we should probably have everyone send out a quick email any time it affects the Initrode account. And… ugh, I can’t type anymore.
So here sit a bunch of extroverts and me. The extroverts love this. People in general love having opinions and telling people their opinions. (I’m not above this — you’ve been reading my rants here for years, so there’s clearly no high ground for me to claim.) But it’s the extroverts that draw energy from this exchange and work themselves into a lather to leave their marks on the eventual end-product via this back and forth. The more this conversation draws on, the more they want to interject with their opinions, wisdom and knowledge. The more trivial and detailed the discussion becomes, the more they get their adrenaline up and enjoy the thrill of the hunt.
I on the other hand, check out almost immediately. From an organizational realpolitik perspective, these meetings are typically full of sound and fury, signifying nothing. The initial meeting organizer turns on the firehose and then quickly loses control of it as the entire affair devolves into a cartoonish torrent of ideas being sprayed around the room as the hose snakes, thrashes, and contorts with no guiding hand. Nobody is really capturing all of this, so the extroverts leave the meeting flush with the satisfaction of shouting their opinions at each other, but most likely having neglected to agree on anything. But, my inclination to check out goes deeper than the fact that nothing is particularly likely to be accomplished; it’s that neither the forum, nor the ideas and the opinions are interesting or important to me.
I earnestly apologize if this sounds arrogant or stand-offish, but it’s the honest truth. And this is where the part about me being an introverted problem solver and pattern-matcher comes in. The meeting I want to have is one where I come prepared with statistical analysis and data about the most efficient flows of information in triage scenarios. I want performance records and response times for Bill and Susan, including in her former role in the case of the latter. I want to have synthesized that data looking for patterns that coincide with issue types and resolution rates, and I want to make a recommendation on the basis of all of that. To me, those are table stakes to the meeting. Whoever has the best such analysis should clearly have his or her plan implemented.
But that’s not what happens in extrovert meetings. As soon as the meeting organizer loses control of the firehose, we’ve entered the realm of utter unpredictability. I start to present my case study and the patterns I’ve noticed, and then someone interrupts to ask if I captured that data using the new or old ticketing system. And, by the way, what power point template am I using because it’s really snazzy. And, anyway, the thing about Susan is that she’s really not as much of a people person, but Doug kind of is. Now the extroverts are firmly in command. All prior analysis goes out the window, and, as people start jabbering over one another reasoned analysis and facts are quite irrevocably replaced with opinions, speculation, gossip, and non sequitur in general. The conversation floats gently down stream and washes up on a distant shore when everyone decides that it’s time for lunch. All of the analysis… unconsidered and largely ignored.
And that, the extroverts taking over and leaving me to space out, is the best case scenario. In the worst case scenario, they start peppering me with a series of off-topic, gotcha questions to which I have to reply, “I don’t know off the top of my head, but I can look into it later.” This puts me at a huge disadvantage because extroverts, buoyed by the rush of the occasion, have no qualms about guessing, fudging, hand-waving, or otherwise manufacturing ‘analysis’ out of thin air. When things take this kind of turn, and someone else “wins the meeting,” it’s even more exhausting.
Regardless of which kind of meeting it is though, the result is usually the same. After lunch and everyone has a chance to forget the particulars of the discussion, it becomes time to email the real decision maker or chat one on one with that person, and re-present the analysis for consideration. Usually at that time, the analysis wins the day or at least heavily informs the decision. The meeting robbed me of an hour of my life to accomplish nothing, as I knew it would, when I looked sadly at my Outlook calendar that morning.
There are two kinds of meeting that have no chance to fit this pattern, however (I’m omitting from consideration meetings that are actually policed reasonably by a moderator to keep things on-agenda, since these are far more rare than they should be). These are meetings where I’m passively listening to a single presenter, or actively presenting to the group. It’s not especially interesting that I’d find the former kind of meeting not to be exhausting since it’s somewhat akin to watching a movie, but the latter is, apparently, somewhat interesting. Presenting is not exhausting to me the way that a night out at a party is exhausting. There are sometimes pre-speech/talk jitters depending on the venue, but the talk is entirely predictable to me. I control exactly what’s going to be said and shown, and the speed at which I’ll progress. There is a mild element of unpredictability during the Q&A, but as the MC for the talk, you’re usually pretty well in control of that, too. So, that is the reason I find typical corporate meetings more exhausting than presenting in front of groups.
A strange thing, that. But I think in this light it’s somewhat understandable. Having reasoned analysis, cogent arguments, and a plan is the way to bring as much predictability (and, in my opinion, potential for being productive) to the table as possible. For me, it’s also the way most likely to keep the day’s meetings from sucking the life and productivity right out of you.
In SQL Server management studio, all of objects in the database are listed in the object explorer in the format [schema].[object]. In large databases of the legacy variety, it’s not uncommon to find that the only schema for application tables/views/sprocs is dbo. In this case, navigating to the object you want requires the infuriating step of typing “dbo.” before the table name. This may not seem like a big deal, but you have to type fast for that style of navigation, and typing that period, far from home row, creates a problem. This has annoyed me for years, but today, I’d had enough.
With a few minutes of googling, I found this Q&A exchange. Clearly others feel the same way and while I don’t consider that to be ideal, it’s certainly an improvement over what I was doing. I can hit “F7″ on a folder and bring up an “object explorer” window that lets me search by object name alone because it separates schema as a different column. Win. Sort of.
I have been using SQL Server Management Studio for nearly a decade and I never knew this. But, after a few minutes with google, now I know. Sometimes it’s google, sometimes it’s a tweet, sometimes it’s asking a coworker. But, the common thread is that one day I just say “enough” and decide to do something about it. It might not be a total solution, but I decide right then and there that the situation and my life need to be improved somehow, immediately.
I think this is a pretty valuable activity. Obviously, you pick up new tips and tricks this way, but more subtly, you’re embracing a philosophy that your routines and habits can always be improved and you’re mentally setting an expiration date on mindless, sub-optimal, or obtuse activities. In a way, this is fairly agile (using lower case a in a nod to the recent blogosphere brouhaha over “taking back agile” — I just mean it’s predicated upon the idea of iterative, steady progress). You’re not paralyzing yourself by analysis to figure out the best way to do things up front all of the time, but rather leaving yourself open to the possibility (certainty) that you can improve the way you do things.
So pick something. Today. Pick something that’s a minor irritant that you’ve simply put up with for a long time and say to yourself, “This. Ends. Now.” in a dramatic, action hero voice. Spend a few minutes doing research and I’d imagine you’re going to be happy. I’ve personally never regretted anything about this time investment except for the regret that I didn’t allow myself to get fed up sooner. So, go ahead. You don’t have to take it anymore.
Negative feedback is something with which we all have to contend, and probably on a fairly regular basis. It comes in a whole lot of forms with varying degrees of merit or importance: official performance reviews, talks with coworkers, miscellaneous gossip, heated discussion with loved ones, and even things like comments on a blog post or publication (I love The Oatmeal’s treatment of this last one — see the section about comments). You may or may not be expecting it, but nevertheless, it tends to hit you like a slap in the face.
I usually respond to negative feedback by trying to understand what flaw of the feedback provider is causing them to be wrong about me. Perhaps they’re simply some kind of crank or idiot, or maybe it’s more elaborate than that. They might have serious psychological problems or else a diabolical motivation for hatching a conspiracy against me. Maybe they’re jealous. Yeah, totally.
But after a while, I stop thinking completely like a child and allow just the teeniest, tiniest bit of introspection. I mean, obviously, the person is still a jealous moron, but it is possible that maybe showing up late to work and snapping at everyone I talked to all morning could have been just the slightest bit off-putting to someone. I’ll generously allow for that possibility.
I am, of course, exaggerating for effect, but the point remains — I immediately respond to negative feedback by feeling defensive or even hostile. It’s easy to do and it’s easy to take feedback badly. And to make matters worse, there is definitely feedback that deserves to be taken badly such as someone simply being rude for no reason. Not all negative feedback is even reasonable. The end result is that it becomes very hard to make feedback lemonade out of the negative lemons your critics are lobbing at you.
But I urge you to try. Here’s an exercise I’m contemplating. Whenever I get negative feedback, legitimate or spurious, I’ll make a note about it. I’ll jot it down in some kind of notebook or perhaps make a spreadsheet or Trello board out of it, and I’ll let it digest for a while. Once somewhat removed from the initial feedback, I can probably filter more objectively for validity. If I can make some actionable improvement, I’ll do so. Every now and then I’ll check back to see if the things I used to get the feedback about have changed and if I seem to be making strides. Maybe such a scheme will be worthwhile for me and perhaps it might be for you too, if you’re so inclined.
It’s not easy to take a frank look at yourself and admit that you have shortcomings. But doing so is the best way to improve on and eliminate those shortcomings. It’s hard to recognize that negative feedback may have a grain of truth or even be dead on. I know because it’s hard for me. But it’s important to do so if you’re serious about achieving your goals in life.
If you’ve been following this blog for a while, you might have seen me engage in talk about the MacLeod Hierarchy from time to time in the comments with various posters. We’re referring to a concept where the denizens of a corporate organization fall into one of three categories: Losers, Clueless, and Sociopaths. It’s explained in delightful detail in one my favorite blog series of all time, but I’ll give you the tl;dr version here of what defines these groups, so that I can use the terms more easily in this post. I’m quoting this synopsis from Michael O. Church’s follow up analysis of the subject, which I also highly recommend. The names are inherently pejorative, which was probably a stylistic choice when picking them; none of these is inherently bad to be, from a moral or human standpoint (though one might argue that Clueless is the most embarrassing).
Losers, who recognize that low-level employment is a losing deal, and therefore commit the minimum effort not to get fired. Clueless, who work as hard as they can but fail to understand the organization’s true nature and needs, and are destined for middle management. Sociopaths, who capture the surplus value generated by the Losers and Clueless. Destined for upper management.
At this point, I’ll forgive you if you’re just now returning to my blog after a lot of reading. If you’re a fan of corporate realpolitik, those are extremely engrossing series. I bring up these terms here to use as labels when it comes to people who are self styled “idea guys” (or gals, but I’m just going to use the male version for brevity for the rest of the post). I’m going to posit that there are generally two flavors of idea guy: the Loser version and the Clueless version. There is no Sociopath “idea guy” at all, but I’ll talk about that last.
What do I mean, exactly, when I say “idea guys?” Well, I’m not being as literal as saying “people who have ideas,” which would, frankly, be pretty obtuse. Everyone has ideas all day, every day. I’m referring to people who think that their essential value is wrapped up in their ideas, and specifically in ideas that they imagine to be unique. They see themselves as original, innovative and, ironically, people who “think outside the box” (ironic in the sense that someone would describe their originality using what has to be one of the top 10 most overused cliches of all time in the corporate world). Indeed, given their talent for creativity, they see an ideal division of labor in which they kick their feet up and drop pearls of their brilliance for lesser beings to gather and turn into mundane things such as execution, operations, construction, selling, and other ‘boring details’.
I Coulda Made Facebook
The Loser “idea guy” is the “coulda been a contender” archetype. If he’s a techie, he probably talks about what a bad programmer Mark Zuckerburg is and how he got lucky by being in the right place at the right time. The Loser could have just as easily written Facebook, and he has all kinds of other ideas like that too, if he could just catch a break. He might alternate between these types of lamentations and hitting up people for partnerships on ventures where he trades the killer idea for the execution part: “hey, I’ve got this idea for a phone app, and I just need someone to do the programming and all of those details.” MacLeod Losers generally strike a deal where they exchange autonomy for bare minimum effort, so execution isn’t their forte — they’d like to hit the “I’ve got an idea” lottery where they dream something up and everyone else takes care of the details of making sure their bank accounts grow by several zeroes.
We Need to Have a Facebook!
The Clueless “idea guy” is, frankly, a lot more comical (unless you’re reporting to him, in which case he’s borderline insufferable). In contrast to his Loser brethren with illusions of Facebook clones or cures for cancer, this fellow has rather small ideas that take the form of middling corporate strategy. He is a master of bikeshedding over what color the new logo for the Alpha project should be or whether the new promo materials should go out to 25 pilot customers or 30. Actually changing the color of the logo or mailing out the materials? Pff. That’s below his paygrade, newbie — he’s an idea guy who shows up 10 minutes late to meetings, makes the ‘important’ decisions, orders everyone around for a while, and promptly forgets about the whole thing.
Whereas the Loser “idea guy” views his schemes as a way to escape gentle wage slavery, the Clueless version is delighting in playing a part afforded to him by his status with the company, which is basically itself a function of waiting one’s turn. Future Clueless comes to the company, puts up with mid level managers ordering him to do menial tasks and showing up late to his meetings, and, like someone participating in any hazing ritual, relishes the day he’ll get to do it to someone else. “Idea guy” is perfect because it involves being “too important” to follow through on anything, personally, or even extend common courtesy and respect. It’s a vehicle for enjoying a position that allows for ordering people around and reminding everyone that people in overhead positions say jump, and they have to ask “how high?”
While it’s certainly possible to encounter a Clueless with ambitious ideas (perhaps a pet project of redoing the company website to look like Apple’s or something), they’re pretty uncommon, which makes sense when you think about it. After all, part of the fundamental condition of a Clueless is enough cognitive dissonance to believe that his position was obtained through merit rather than running out the clock, and trying to push a big idea to the players in the office above him is to be threatened with rejection and possibly even ridicule, so why bother? Micromanaging and demanding the removal of ducks is a much safer strategy for pleasant reinforcement of his position of power.
I’ll Create a Bubble and Sell This Company to Facebook
So what about the Sociopath “idea guy?” As I said, I don’t think this exists. It’s not that sociopaths don’t have ideas. I might argue that they’re the only ones that have ideas of significance in the corporation (losers may have excellent ideas, but they go nowhere without a sociopath sponsor and spin). But they certainly aren’t “idea guys.” Reason being that sociopaths know what matters. To re-appropriate a famous line Vince Lombardi would say to his Packers teams, Socipaths know that “execution isn’t everything; it’s the only thing.”
A Sociopath doesn’t really assign any pride to ideas, opting instead to evaluate them on merit and implement them when doing so is advantageous. If his ends are better served by letting you take the credit for his ideas, the Sociopath will do that. Alternatively, if his ends are better served by ripping off someone’s idea and doing that, he’ll do that too. No matter what the source of the idea, it’s simply a means to an end. It’s not his baby, and it’s not to be jealously guarded, since ideas are a dime a dozen, and there will be others.
Ideas, like paper or computers or projectors, are simply tools that aid in execution or even, perhaps, inspiration for improved execution. A Sociopath is a doer in every sense — a consummate pragmatist.
Winning the Race of Achievement
If idea guys come from the ranks of Losers and Clueless but it’s only the Sociopaths that capture and capitalize on excess value created, doesn’t this mean, cynically, that people who have great ideas are never the ones that profit? Well, no, I’d argue. Sociopaths have plenty of ideas — they just aren’t “idea guys.” Ideas are commonplace across all organizational strata and across all of life. Sociopaths are simply too pragmatic and busy to create some kind of trumped up persona centered around the remarkably ordinary phenomenon of having ideas; they’re not interested in dressing up as Edison or Einstein and turning their life into some kind of extended Halloween.
Pulling back from the MacLeod categorization, it’s sufficient to say that what turns the motor of the world is commitment, work, dedication, execution, and frankly a bit of luck (though I’d argue for the adage that luck is largely a measure of time and being prepared). Sure, ideas are a part of that, but so are oxygen and conversations. They’re such ubiquitous parts of all that we do that they’re not worth focusing on or even mentioning.
In Macbeth, the title character issues a fatalistic soliloquy that describes life as “a tale, told by an idiot, full of sound and fury, signifying nothing.” This sentiment captures the impact in a group or meeting by a self-styled “idea guy,” particularly of the Clueless variety. He charges in, makes a lot of bold claims, proclamations, and predictions, and then toddles on out, altering the landscape not at all.
If you want to make your impact felt, I’d say there’s another quote that’s appropriate, popularized in American culture by Teddy Roosevelt: “walk softly and carry a big stick.” Don’t declare yourself victorious at the starting line because you dreamed up some kind of idea. Assume that ideas, even great ones, are nothing but your entry fee to the race, expected of every runner. Let them be your grit and inspiration as you labor your way through the course. But realize that the actual, boring mechanics of running — the execution — is what wins you the race rather than whatever inspirational poster saying occurs to you as you plod along.
I’m going to apologize in advance if this winds up being a long post, but it’s a topic that requires a great deal of introspection and I find that attempting to explain myself is one of the hardest things to abbreviate. Over the years, I’ve read a bit about the topic of introversion versus extroversion and, being in an industry in which introversion is often assumed, I’ve also seen a number of memes about it. This one is probably my favorite, if for no other reason than seeing the poor introvert hissing like a cat at some invasive extrovert. This comic provides a memorable graphical explanation of what other sources such as wikipedia explain more dryly: that extroverts draw energy from social interactions and that introverts spend or use up energy during those same interactions.
On the whole, I find this explanation pretty satisfying as it more or less explains my life and experience. I’m the classic example of “not all introverts are shy or socially awkward.” I am competent in social situations and even fine with things like public speaking — it’s just that, after a long evening of spending time with people, I tend to get home and think, “wow, finally…” I’m not a huge fan of the vague and sort of hand-wavy idea of “mental energy” and it seems likely to me that there’s a more concrete physiological explanation involving adrenaline and dopamine or something, but the effect on me, personally, is undeniable.
The thing I’d like to explore is how and why these interactions are taxing to me. Maybe you’ll find that my explanation resonates with you. Maybe I’m just a lone weirdo.
Control and the Unknown
I have a memory that’s simultaneously very specific and very vague. The vague parts are that I was some age or another, probably in junior high, and that I had a crush on a girl, but honestly don’t remember which one. Assuming I’m right about the age, it probably varied weekly. But what I remember with incredible clarity was sitting alone in my bedroom, staring at the phone, and contemplating calling this girl to ask her to go to a movie with me or something. I really wanted to do this. If it had gone well, I would have been in junior high hog-heaven, and if it had gone poorly, I’m sure I would have recovered from the embarrassment in relatively short order, but I just sat there, analyzing, brain churning furiously. I’d pick up the phone and start to dial and then hang up. I’d think. Go through the conversation in my head. Rehearse what I’d say. Anticipate her response. Rehearse my response to what I imagined her response to be. Etc, ad nauseum.
Man, I’m tired just thinking about it, and that’s probably why I remember it. I never called the girl, which is probably why I don’t remember who she was (and I think I might have gone through this exercise with more than one), but young, introverted Erik was exhausted by a social situation that never even actually happened. Imagine how exhausting the phone call would been had I summoned up the intestinal fortitude to go through with it.
I’ll come back to that in a moment, but first I’d like to talk about how much I dislike conversations about the weather on a variety of levels. When talking about the weather, there are three possible categories of conversation: trite, tactical, and pseudo-religious. The first category is barely worth mentioning in that it is the “hot enough for you?” nervous drivel that serves as an awkward social lubricant in situations where people feel the need to make small talk and no alcohol is present. The second kind of conversation is planning that revolves around the weather such as “we should maybe reschedule our picnic for tomorrow because it seems like it’s going to rain.” The third category is the kind of long-ranging predictions about the weather that people tend to engage in knowing tones for the sake of having opinions: “well, after this brutal winter, we’re probably going to be in for a mild summer.”
When it comes to why I dislike weather conversations, it depends on the flavor. Not surprisingly, I find the trite weather observations to be, well trite — restatements of plainly observable facts aren’t the stuff of scintillating dialog. I find tactical weather discussions annoying because far more often than not they come up in the form of impediments like altered plans, grounded planes, traffic, etc. The pseudo-religious conversations I find bemusing and wholly unrelatable since weather is simply a chaotic system like a financial market or the movement of all of the fish in the ocean. Trying to predict it without unimaginable leaps in processing power or a wholly new form of mathematics is a waste of time and claiming to understand what’s coming is most likely the manifestation of a very human desire to make sense of the senseless and to see purpose in all things. This is why I call them “pseudo-religious” — they all assign moral meaning to the whims of chaotic systems, such as suggesting that storms are Divine punishment for our moral degradation or, alternatively, suggesting that the Earth is going to be uninhabitable because of our present eco-sins. But the fact that an ordered universe (or weather system) is more appealing doesn’t magically create purpose to make it somehow predictable and just.
So weather is either obvious and mundane, obvious and important, or unknowable. And, for this reason, as a serial problem solver, obsessive pattern-matcher (more or this in a subsequent post), and introvert, I find the weather completely uninteresting. It’s either a non-problem, a relatively easily solved problem (have your picnic inside if it’s raining), or an unsolvable problem about which speculation is pointless. If I tried to solve the problem of what the weather would be like in a month, I’d become exhausted by my own failure — in much the same way I became exhausted by the problem of trying to figure out how the girl that would have been on the other end of the phone line would react to my interest and invitation to a date. But, unlike the weather, the date situation had a relatively limited set of parameters and outcomes and much more potential benefit, so I at least labored to the point of exhaustion instead of saying, “why bother in the first place?” I had more control over that situation by far than the weather, but my control was still limited.
Programming, Safe Feedback, and Blissful Introversion
I’m at my happiest when I’m in my office succeeding quickly at small tasks. I made a post some time back about how I create a list of small tasks in an Excel sheet and change their background color from yellow to green as I work. I’m at my happiest when doing some TDD and checking things off the list. I write a test, see red, change the code, see green, refactor. I do this a few times, and I turn a spreadsheet cell from yellow to green. I’m moving efficiently through a mountain of work with small, steady, repeatable victories.
I’m in my own world. If I try something that doesn’t work, the test doesn’t go green and I learn from the experience and try other things until it does. If I’m stumped, I hop on google or stack overflow and see if I can find a solution. I experiment. I change the task list. I do a lot of different things where the pattern is “change something, see the results, and proceed accordingly.” My most productive days are large, beautiful crystals made from lattice structures of tiny examples of the scientific method: hypothesis (red test), experiment (change the code), analysis (green/move on or still red/try again).
In my own world, life is extremely predictable and within my control. Things change only when I change them and I know the results quickly and in a safe, consequence-free way. If I was wrong about something, I just hit control-Z and lesson learned with no harm done. There are endless mulligans as I go about my cycle of learning and building. I need not venture forth into the world with my products or conclusions until I know that things are bullet-proof. I can prove that the code works with automated scripts. I can back up my arguments with well-researched support. I find this not to be tiring but to be therapeutic and invigorating. After a day of uninterrupted, productive coding, I’m usually pretty energized and will head to the gym to burn it off.
Social Situations and Exhaustion
I’m less happy during the day when progress isn’t measured easily and the feedback loop is longer or non-existent. If, for instance, I leave my office and sit in several meetings where people offer opinions and try to reach consensus (more on this as well in a subsequent post), I grow tired fairly quickly. Such things are almost never people taking turns presenting evidence and well-crafted arguments, but far more often rapid fire opinions ‘substantiated’ with hearsay and conjecture. I can’t prepare for these conversations because I have no idea what people will dream up to talk about and when volume and charisma count for as much as reasoning and evidence, there’s no predicting what kind of outcome will follow.
And even if it isn’t meetings, people throw weird curveballs at me all day. Someone will come and claim that something is a crisis when it really isn’t, and I have to stop and spend time calming this person down or trying to persuade them to look at the bigger picture. I’ll speak with coworkers that are having a personal issue with one another. I’ll get invited to lunch when I have a lot of work to do, but I don’t want to be rude by saying no. These situations are quasi-chaotic. They aren’t chaotic like the weather or a market, but they’re extremely hard to predict and there’s no good way to back out of a bad choice and try the other branch. If I turn the guys down for lunch and see their faces drop, there’s no taking back that my initial reaction was to reject them, even if I reverse course quickly.
None of this is to day that I don’t like dealing with other people or that I’m some kind of hermit. I like going out to lunch with friends and coworkers. I like shooting the breeze sometimes. I understand that things come up that require my attention. And I’ll even grudgingly admit that every now and then a meeting is mildly productive. But all of these things are tiring. (There are two exceptions that I’ll cover in a subsequent post as well — times where I’m speaking/presenting to an audience and times when I’m mostly just listening to someone offer opinions for long stretches without feedback) I just want to get back to my office, sit at my desk, and be in a world of controlled experiments, careful reasoning, and strictly knowable and measurable outcomes. After a day without these, I’m usually too tired for the gym.
Maybe others have different reasons for their introversion than I do. But I’m willing to bet that I’m not alone in thinking that it’s a matter of preferring controlled environments and predictable outcomes. And what’s more, I bet that the correlation between introversion and certain personality types or vocations (i.e. programmers, among others) can be partially explained by this “introverts as highly analytical” notion. Food for thought on this Friday, anyway. I have more to say on this subject, but I’ll probably space these posts out a bit, since they’re about as far from the standard technical/workplace fare as I get on this blog.