DaedTech

Stories about Software

By

A Blogger Grows Up: DaedTech Year in Review for 2013

Last year, I made a retrospective post, and I titled it “A Blog Grows Up: DaedTech Year in Review for 2012.” I think I did this because a lot of other bloggers seemed to do it. And one of the big themes of last year’s post was that I was becoming a real, non-faking-it blogger. This year, I’m making a retrospective post largely because of my own personal neurosis when it comes to symmetry and gamification. In other words, I’m doing it because it presents an opportunity to evaluate myself and compare metrics.

This sort of odd introspection is telling, and it’s the reason this year’s title is exactly four characters different from last year. One character change is in the year (2013 vs 2012), and the other three differences go to “blogger” instead of “blog.” Last year, the DaedTech blog grew up; this year, I grew up as both a blogger and as a person who maintains a blog. The blog itself isn’t a lot different. I’ve updated a few plugins and changed the theme of the blog to be more mobile-friendly. I won’t win any UX awards, but I’m staying reasonably current in the limited time that I have. There have been no real game changers in terms of the way the blog looks.

And yet, the results from blogging is once again dramatic. In 2011, my followers were in the tens. In 2012, I was proud because I had changed that to numbering in the hundreds. I had gone out and interacted with other people, exchanged ideas, created a social media presence, improved my posting cadence and all sorts of other things that I mentioned in the linked post. I had figured out how to bolster my readership by doing all of the right things — all of the things that an experienced blogger will tell an inexperienced one to do. In a sense, I had faked it until I made it.

This year, I’m humbled and flattered to report, my regular following went from hundreds to thousands. Last year, I was ecstatic to report that 2012 had resulted in a tripling of my traffic, but in 2013, it increased by a factor of 10 from 2012. If the trajectory of readership in 2014 realizes even half of gains of previous years, next year will see DaedTech record a million unique visitors. Whereas last year I attributed this kind of growth to all of the effort that I had put in to figuring out how to attract followers, this year I attribute it to a variety of factors, not the least of which are persistence and luck. I’m fortunate in that some of my posts have become extremely popular and also in that I have a great base readership that’s very supportive. (Thanks, everyone.)

Ebooks and Course Authorship

Last year, I talked about a number of improvements to the blog. These were things like social media interaction buttons, tagging scheme, feed provider, etc. These improvements were invaluable, and they set the stage for the blog to be taken seriously. This year, I focused instead on improving the brand behind the blog. Actually, scratch that “brand” talk. I focused on improving myself and my credentials. I established a relationship with Pluralsight and began authoring content for them. I have two courses that are aimed at a relatively advanced .NET developer, which, in spite of their narrow focus, are highly rated. I am also starting work on a third course about home automation, and I’ve booked arrangements for the Pluralsight author summit later this winter in the hopes of trading tips with other authors to improve my course quality. If you aren’t improving, you’re rotting, as I once said in one of the Expert Beginner posts (more on that later).

Speaking of expert beginners, I also have put out a couple of ebooks. One was a simple republish of the “How to Keep Your Best Programmers” post. The other came as a result of my editor’s and my effort to restructure a series of posts into an actual, polished work intended for the ebook format. Both of these ebooks (and another one coming soon from my “Intro to Unit Testing” series) have been published by my friend Zack through his Chicago, 1071-based startup, Blog Into Book.

In last year’s post, I used an unordered list to outline all of the things I’d done to make DaedTech have a more successful blog. This year, I’ll just say that starting to author courses for Pluralsight and publishing ebooks have been huge successes for me. These things, combined with my own career transition, have significantly impacted the blog. I’ve recently made the jump from a developer and architect to CIO, and I feel that this has helped me offer an interesting voice on subjects running the entire technical gamut.

Expert Beginners and Optimism

A major catalyst for the blog’s popularity has been the Expert Beginner series and subsequent ebook. A fairly large number of you, to whom I am extremely grateful, have supported my by purchasing the ebook. A jaw-dropping number of you have read the series of posts and offered encouragement and positive feedback. I’d be misrepresenting the situation if I said that this series wasn’t the lion’s share of the reason that the blog has grown so much in the last year.

I’m honestly thrilled about this. I’m thrilled that so many people recognize what I’ve described as “expert beginnerism” to be one of the most subtle yet important impediments to progress in our industry. I’m also encouraged to think that I’m not crazy in thinking about this, since it’s resonated with so many people. At the time that I wrote that first post, I seriously thought that I might roundly be dismissed as some kind of malcontent and crank. I thought the expert beginners against whom I was railing dominated our industry to such a degree that my opinion would be unpopular. And yet, it was widely popular, instilling in me a sense of intense optimism that probably seems out of place from someone that wrote such cynical posts. The fact that all of you see expert beginnerism and have disdain for it means that we’re on the right track to stomping it out.

And it isn’t just readership or purchase of the ebook that encourages me. It’s the fact that my Twitter alter-ego, the Expert Beginner, has such an enthusiastic following. It is from this account that I tweet some of the most alarming, depressing, maddening, amazing, infuriating and downright surreal things that I’ve heard in my time in the industry. The fact that hundreds of people commiserate with me, including people with industry influence, cheers me up immensely on a daily basis. The more frustration I express with stupid things I’ve heard in the industry, the more that people express implicit solidarity. It renews my faith in developer-kind.

Blogging Lessons Learned

This year, I’ve learned that nitty-gritty posts about technical details tend to bring hits to the blog, but not regular readers. Regular readers, at least of this blog, seem to be drawn in more by posts about office politics, broad ideas, interactions and other big picture items. However, to have any cred as I write the latter style of post, I think some of the former style of post is necessary, lest people ask, “is he technical?” I need to learn where the sweet spot is here, but the main thing I’ve already learned is that I’m more of an op-ed blogger than one writing instructional posts. At least, that’s what I’m doing when my posts are best received.

Fun Facts

Below are my most popular posts of 2013 in terms of readership. In this post from 2012, there was a dead heat between instructional posts and op-ed style posts. This year, not so much.

  1. How Developers Stop Learning: Rise of the Expert Beginner
  2. The 7 Habits of Highly Overrated People
  3. How to Keep Your Best Programmers
  4. How Software Groups Rot: Legacy of the Expert Beginner
  5. Getting Too Cute with C# Yield Return

Here are the countries in which DaedTech is most popular:

  1. USA
  2. United Kingdom
  3. Canada
  4. India
  5. Germany
  6. Australia
  7. Russia
  8. Sweden
  9. Netherlands
  10. France

This year, I’m omitting the referrals except to mention them anecdotally.  The stats don’t appear to be especially accurate.  For instance, Hacker News referrals don’t always register properly in my analytics for some reason.  I can tell you that the biggest sources of traffic that aren’t regular readers or RSS feeds are Reddit and Hacker News.  I get a good bit of referral traffic from social media as well, and still plenty of hits from googling.

Finally, A Word of Thanks

In the end, I’d just like to thank you all for reading. Everyone has precious few hours in the day, and I’m flattered that you choose to spend some of them reading my blog when there are plenty of other things you could be doing. I’d also like to welcome the influx of traffic resulting from my recent stint at Hacker News and thank those readers for subscribing to the feed; giving my posts a chance; and for all of the retweets, mentions, upvotes and comments. I haven’t necessarily had time to respond to everyone the way I like due to the of volume of traffic/comments, but please know that it is nevertheless very much appreciated.

So thanks again, and have a great 2014!

By

Merry Christmas

I’d just like to wish all of the DaedTech readers that celebrate Christmas a Merry Christmas. I celebrate the holiday myself, and Christmas for me typically involves some travel to see family during the time between Christmas and New Year’s Eve. This year is no exception, so I probably won’t be posting, except perhaps for a retrospective post that I have in the hopper. So, enjoy your holiday time, and look for your regularly scheduled posts to resume after the new year.

By

Bike Sheds, Ducks, and Nuclear Reactors

I learned a new term the other day, and it was great. I enjoyed this so much because it was a term for a concept I was familiar with but for I had never had a word. I haven’t been this satisfied with a new word since “taking pleasure in seeing bad things happen to your enemies” was replaced with “schadenfreude.” I was listening to an episode of the Herding Code podcast from this past summer, and Nik Molnar described something called “bikeshedding.” This colloquialism is derived from an argument made by a man named C. Northcote Parkinson and later called “Parkinson’s Law of Triviality” that more debate within organizations surrounds trivial issues than extremely important ones.

Here’s a quick recap of his argument. He discusses a fictional committee with three items on its agenda: approving an atomic reactor, approving a bike shed, and approving a year’s supply of refreshments for committee meetings. The reactor is approved with almost no discussion since it is so staggeringly complicated and expensive than no one can really wrap their heads around it. A lot more arguing will be done about the bike shed, since committee members are substantially more likely to understand the particulars of construction, the cost of materials, etc. The most arguing, however, will be reserved for the subject of which drinks to have a the next meeting, since everyone understands and has an opinion about that.

This is human nature as I’ve experienced it, almost without exception. I can’t tell you how many preposterous meeting discussions have shaved precious hours off of my life while people argue about the most ridiculous things. One of the most common that comes to mind is people who are about to drive somewhere 20 minutes away spending 5-10 minutes arguing about which streets to take en route.

In the life of a programmer, this phenomenon often has special and specific significance. On the Wikipedia page I linked, I also noticed a reference to a fun Jeff Atwood post about awesome programming terms that had been coined by respondents to an old Stack Overflow question. Take a look at number five, a “duck”:

A feature added for no other reason than to draw management attention and be removed, thus avoiding unnecessary changes in other aspects of the product.

I don’t know if I actually invented this term or not, but I am certainly not the originator of the story that spawned it.

This started as a piece of Interplay corporate lore. It was well known that producers (a game industry position, roughly equivalent to PMs) had to make a change to everything that was done. The assumption was that subconsciously they felt that if they didn’t, they weren’t adding value.

The artist working on the queen animations for Battle Chess was aware of this tendency, and came up with an innovative solution. He did the animations for the queen the way that he felt would be best, with one addition: he gave the queen a pet duck. He animated this duck through all of the queen’s animations, had it flapping around the corners. He also took great care to make sure that it never overlapped the “actual” animation.

Eventually, it came time for the producer to review the animation set for the queen. The producer sat down and watched all of the animations. When they were done, he turned to the artist and said, “that looks great. Just one thing – get rid of the duck.”

When I saw this, I actually guffawed at my desk. I didn’t do that just because I found this funny — I have actually employed this strategy in the past, and I see that I am not alone in my rank cynicism in a world of Parkinson’s Law of Triviality. It definitely seems that project management types, particularly ones that were never technical (or at least never any good at it), feel a great need to seize upon something that they can understand and offer an opinion on that thing in the form of an edict in order basically to assert some kind of dominance. So, early in my career, when proposing technical plans I developed a habit of dropping a few red herring mistakes into the mix to make sure that obligatory posturing was dispensed with and any remaining criticisms were legitimate — I’d purposely do something like throw in a “we’re not going to be doing any documentation because of a lack of time” to which I would receive the admonition, “documentation is important, so add it in.” “Okie-dokie. Moving on.”

NuclearDuck

It isn’t just pointy-haired fire-hydrant peeing that exposes us to this phenomenon, however. We, as developers, are some of the worst offenders. The Wikipedia article also offers up something called “Wadler’s Law,” which appears to be corollary to Parkinson’s in that it talks about developers being more likely to argue over language syntax than semantics. In other words, you’ll get furious arguments over whether to use underscores between words in function names, but often hear crickets when you ask if the function is part of a consistent broader abstraction. My experience aligns with this as well. I can think of so, so many depressing code reviews that were all about “that method doesn’t have a doc comment” or “why are you using var” or “alphabetize your includes.” I’d offer up things like “let’s look at how cohesive the types are in this namespace,” and, again, crickets.

The great thing about opinions is that they’re an endlessly renewable, free resource. You can have as many as you like about anything you like, and no one can tell you not to (at least in societies that aren’t barbarically oppressive). But what isn’t endless is people’s interest in your opinions. If you’re the person that’s offering one up intensely and about every subject as the conversation drifts from code to personal finances to football to craft beers, you’re devaluing your own currency. As you discuss and debate, be mindful of the stakes at play and be sparing when it comes to how many times you sit at the penny slots. After all, you don’t want to be the one remembered for furiously debating camel case and coffee flavors while rubber stamping the plans for Chernobyl.

By

Beware of The Magnetars in Your Codebase

Lately, I’ve been watching a lot of “How the Universe Works” and other similar shows about astronomy. I’ve been watching them a lot, as in, I think I have some kind of problem. I want to watch them and find them fascinating and engaging and yet I also seem suddenly to be unable to fall asleep without them on.

Last night, I was indulging this strange problem when I saw what has to be the single most intense thing in the universe: a magnetar. Occasionally when a massive star runs out of fuel in its core, it explodes into as a supernova and spews matter and radiation everywhere, sending concussive shock waves hurtling out into the universe. In the aftermath, the rest of the star that doesn’t escape out collapses in on itself into an unimaginably dense thing called a “neutron star,” which is the size of Manhattan but weighs as much as the sun (for perspective, a sugar cube of neutron star would weigh as much as all of the people on earth combined).

One particularly exotic type of neutron star is called a magnetar. It’s a neutron star with a magnetic field of absolutely mind-boggling strength and a crust made out of solid iron (but up to 10 billion times stronger than steel, thanks to the near-black-hole-like gravity of the star crushing imperfections out of the crystals that form the crust). A magnetar is so intensely magnetized that if the moon were a magnetar (and forget the gravity for a moment) it would tear the watch off of your wrist and render your credit cards useless. This thing rotates many times per second, whipping its magnetic field into a frenzy and sloshing the ultra-dense neutron goo that makes up its core into a froth until the internal pressure causes something called a “starquake,” which, if it were measured on a the Richter scale, would be a 32. When these starquakes happen, the result is that the magnetar spews a torrent of radiation so powerful that it has a profound effect on the earth’s magnetic field and atmosphere from halfway across the Milky Way.

So to recap, a magnetar is a tiny thing leftover from a huge event that’s not really visible or particularly noticeable from a distance. At least, it isn’t noticeable until the unimaginable destructive force roiling in its bowels is randomly unleashed, and then it pretty much annihilates anything in its close vicinity and has a profound effect universally.

Magnetar

Image courtesy of wikipedia

I was idly thinking about this concept today while looking at some code, and I realized something. How many projects do you work on where there’s some kind of scramble or to get some new feature in ahead of schedule, to absorb scope creep and last minute changes, or to slam some kind of customization into production for a big client with a minimum of testing? Whether this goes well or poorly, the result is generally spectacular.

And when the dust settles and everyone has taken their two or three weeks off, come down from the ledge and breathed a sigh of relief, the remnants of the effort is often some quiet, dense, unapproachable and dangerous bit of code pulsing in the middle of your code base. You don’t get too near it for fear that it will tear the watch off of your wrist or result in a starquake — okay, more accurately, that it will introduce some nasty regression bug — and you just kind of leave it there to rotate and pulse ominously.

Much later, when you’ve pretty well forgotten it, it erupts and unleashes a torrent of devastation into your team’s life. One day you suddenly recall (one day too late) that if you don’t log into that one SQL server box and restart that scheduled task on any March 1st not in a leap year, all 173,224 users of the Initrode account are suddenly unable to log into anything in their ERP system, and they’re planning a shipment of medical supplies to hurricane victims and abused puppies. You’ve had all of the atoms in your organization pulverized out of existence by the flare of a magentar in your code base.

How do you avoid this fate? I’ll give you a list of two:

  1. Do the right thing now.
  2. Push back against creating the situation in the first place.

The first one is the more politically tenable one in organizations. The business is going to do what the business is going to do, and that’s to allow sales to promise clients a cure for cancer by June 15th if they promise to pitch in personally for steak dinners for the dev team, on their honor. It can be hard to push back against it, so what you can do is ride the storm out and then make sure you carve out time to repair the damage when the dust settles. Don’t let that rogue task threaten your very existence once a year (but not in leap years). And don’t cop out by documenting it on a wiki somewhere. Do the right thing and write some code that automates whatever it is that should trigger it to happen. While you’re at it, automate some sort of reminder scheme for monitoring purposes and some fault tolerance, since this seems pretty important. You may have needed to hack something out to meet your deadline, but there’s nothing saying you have to live with that and let it spin and pulse its way to bursting anger.

The better solution, though, is to push back on the business and not let supernovae into your development process in the first place. This is hard, but it’s the right path. Instead of disarming volatile things that you’ve introduced in a pinch, avoid introducing them altogether. Believe it or not, this is a skill that actually takes practice because it involves navigating office-political terrain beyond simply explaining things to someone in rational fashion and prevailing upon their good judgment.

But really, I could boil these two points down to one single thing that logically implies both: care about the fate of the project and the codebase. If you invest yourself in it and truly care about it, you’ll find that you naturally avoid letting people introduce explosive forces in the first place. You certainly don’t allow alien, stealth deathbombs to fester in it, waiting to spew radiation at you. Metaphorical radiation, that is. Unless you code for a nuclear power company. Then, real radiation.

By

The 7 Habits of Highly Overrated People

I remember having a discussion with a more tenured coworker, with the subject being the impending departure of another coworker. I said, “man, it’s going to be rough when he leaves, considering how much he’s done for us over the last several years.” The person I was talking to replied in a way that perplexed me. He said, “when you think about it, though, he really hasn’t done anything.” Ridiculous. I immediately objected and started my defense:

Well, in the last release, he worked on… that is, I think he was part of the team that did… or maybe it was… well, whatever, bad example. I know in the release before that, he was instrumental in… uh… that thing with the speed improvement stuff, I think. Wait, no, that was Bill. He did the… maybe that was two releases ago, when he… Holy crap, you’re right. He doesn’t do anything!

How did this happen? Meaning, how did I get this so wrong? Am I just an idiot? It could be, except that fails as an explanation for this particular case because the next day` I talked to someone who said, “boy, we’re sure going to miss him.” It seemed I was not alone in just assuming that this guy had been an instrumental cog in the work of the group when he had really, well, not been.

In the time that has passed since that incident, I’ve paid attention to people in groups and collaborating on projects. I’ve had occasion to do this as a team member and a team lead, as a boss and a line employee, as a consultant and as a team member collaborating with consultants, and just about everything else you can think of. And what I’ve observed is that this phenomenon is not a function of the people who have been fooled but the person doing the fooling. When you look at people who wind up being highly overrated, they share certain common habits.

If you too want to be highly overrated, read on. Being overrated can mean that you’re mediocre but people think that you’re great, or it can mean that you’re completely incompetent but nestle in somewhere and go unnoticed, doing, as Peter Gibbons in Office Space puts it, “just enough not to get fired.” The common facet is that there’s a sizable deficit between your actual value and your perceived value — you appear useful while actually being relatively useless. Here’s how.

TomSawyer

1. “Overcommunicate”

I’m putting this term in quotes because it was common enough at one place I worked to earn a spot on a corporate BS Bingo card, but I’ve never heard it anywhere else. I don’t know exactly what people there meant by it, and for all I know, neither do they, so I’m going to reappropriate it here. If you want to seem productive without doing anything useful, then a great way to do so is to make lots of phone calls, send lots of emails, create lots of memos, etc.

A lot of people mistake activity for productivity, and you can capitalize on that. If you send one or two emails a day, summarizing what’s going on with a project in excruciating detail, people will start to think of you as that vaguely annoying person who has his fingers on the pulse all of the time. This is an even better strategy if you make the rounds, calling and talking to people to get status updates as to what they’re doing before sending an email.

Now, I know what you’re thinking — that might actually be productive. And, well, it might be, nominally so. But do you notice that you’ve got a very tangible plan of action here and there’s been no mention of what the project actually involves? A great way to appear useful without being useful is engage heavily in an activity completely orthogonal to the actual goal.

2. Be Bossy and Critical

Being an “overcommunicator” is a good start, but you can really drive your phantom value home by ordering people around and being hypercritical. If your daily (or hourly) status report is well received, just go ahead and start dropping instructions in for the team members. “We’re getting a little off schedule with our reporting, so Jim, it’d be great if you could coordinate with Barbara on some checks for report generation.” Having your finger on the pulse is one thing, but creating the pulse is a lot better. Now, you might wind up getting called out on this if you’re in no position of actual authority, but I bet you’d be surprised how infrequently this happens. Most people are conflict avoiders and reconcilers and you can use that to your advantage.

But if you do get called out (or even if you don’t), just get hypercritical. “Oh my God, Jim and Barbara, what is up with the reports! Am I going to have to take this on myself?!” Don’t worry about doing the actual work yourself — that’s not part of the plan. You’re just making it clear that you’re displeased and using a bit of shaming to get other people to do things. This shuts up people inclined to call you out on bossiness because they’re going to become sidetracked by getting defensive and demonstrating that they are, in fact, perfectly capable of doing the reports.

3. Shamelessly Self Promote

If a deluge of communication and orders and criticisms aren’t enough to convince people how instrumental you are, it never hurts just to tell them straight out. This is sort of like “fake it till you make it” but without the intention of getting to the part where you “make it.” Whenever you send out one of your frequent email digests, walk around and tell people what hard work it is putting together the digests and saying things like, “I’d rather be home with my family than staying until 10 PM putting those emails together, but you know how it is — we’ve all got to sacrifice.” Don’t worry, the 10:00 part is just a helpful ’embellishment’ — you don’t actually need to do things to take credit for them (more on that later).

Similarly, if you are ever subject to any criticisms, just launch a blitzkrieg of things that you’ve done at your opponent and suggest that everyone can agree how awesome those things are. List every digest email you’ve sent over the last month, and mention the time you sent each one. By the fifth or sixth email, your critic will just give up out of sheer exasperation and agree that your performance has been impeccable.

4. Distract with Arguments about Minutiae

If you’re having trouble making the mental leap to finding good things about your performance to mention, you can always completely derail the discussion. If someone mentions that you haven’t checked in code in the last month, just point out that in the source control system you’re using, technically, “check in” is not the preferred verbiage. Rather, you “promote code.” The distinction may not seem important, but the importance is subtle. It really goes to the deeper philosophy of programming or, as some might call it, “the art of software engineering.” Now, when you’ve been doing this as long as I have, you’ll understand that code promotions… ha! You no longer have any idea what we were talking about!

This technique is not only effective for deflecting criticism but also for putting the brakes on policy changes that you don’t like and your peers getting credit for their accomplishments. Sure, Susan might have gotten a big feature in ahead of schedule, but a lot of her code is using a set of classes that some have argued should be deprecated, which means that it might not be as future-proof as it could. Oh, and you’ve run some time trials and feel like you could definitely shave a few nanoseconds off of the code that executes between the database read and the export to a flat file.

5. Time It So You Look Good (Or Everyone Else Looks Bad)

If you ever wind up in the unfortunate position of having to write some code, you can generally get out of it fairly easily. The most tried and true way is for the project to be delayed or abandoned, and you can do your part to make that happen while making it appear to be someone else’s fault. One great way to do that is to create a huge communication gap that appears to be everyone’s fault but yours.

Here’s what I mean. Let’s say that you’re working with Bill and Bill goes home every night at 6:00 PM. At 6:01, send Bill an email saying that you’re all set to get to work, but you just need the class stub from him to get started. Sucker. Now 15 hours are going to pass where he’s the bottleneck before he gets in at 9:00 the next morning and responds. If you’re lucky and you’ve buried him in digest emails, you might even get an extra hour or two.

If Bill wises to your game and stays a few extra minutes, start sending those emails at like 10:00 PM from home. After all, what’s it to you? It takes just as little effort not to work at 6:00 as it does at 10:00. Now, you’ve given up a few hours of response time, but you’re still sitting pretty at 11 hours or so, and you can now show people that you work pretty much around the clock and that if you’re going to be saddled with an idiot like Bill that waits 12 hours to get you critical information, you pretty much have to work around the clock.

6. Plan Excuses Ahead of Time

This is best explained with an example. Many years ago, I worked as lead on a project with an offshore consultant who was the Rembrandt of pre-planned excuses. This person’s job title was some variant of “Software Engineer” but I’m not sure I ever witnessed software or engineering even attempted. One morning I came in and messaged him to see if he’d made progress overnight on a task I’d set him to work on. He responded by asking if I’d seen his email from last night. I hadn’t, so I checked. It said, “the clock is wrong, and I can’t proceed — please advise.”

After a bit of back and forth, I came to realize that he was referring to the clock in the taskbar on his desktop. I asked him how this could possibly be relevant and what he told me was that he wasn’t sure how the clock being off might affect the long-running upload that was part of the task, and that since he wasn’t familiar with Slackware Linux, he didn’t know how to adjust the clock. I kid you not. A “software engineer” couldn’t figure out how to change the time on his computer and thought that this time being wrong would adversely affect an upload that in no way depended on any kind of timestamp or notion of time. That was his story, and he was sticking with it.

And it is actually perfect. It’s exasperating but unassailable. After all, he was a “complete expert in Windows and several different distributions of Linux,” but Slackware was something he hadn’t been trained in, so how could he possibly be expected to complete this impossible task without me giving him instructions? And, going back to number five, where had I been all night, anyway? Sleeping? Pff.

7. Take Credit in Non-Disprovable Ways

The flip side of pre-creating explanations for non-productivity so that you can sit back in a metaphorical hammock and be protected from accusations of laziness is to take credit inappropriately, but in ways that aren’t technically wrong. A good example of this might be to make sure to check in a few lines of code to a project that appears as though it will be successful so that your name automatically winds up on the roster of people at the release lunch. Once you’re at that lunch, no one can take that credit away from you.

But that’s a little on the nose and not overly subtle. After all, anyone looking can see that you added three lines of white space, and objective metrics are not your friends. Do subjective things. Offer a bunch of unsolicited advice to people and then later point out that you offered “leadership and mentoring.” When asked later at a post mortem (or deposition) whether you were a leader on the project, people will remember those moments and say, grudgingly and with annoyance, “yeah, I guess you could say that.” And, that’s all you’re after. If you’re making sure to self-promote as described in section three, all you really need here is a few people that won’t outright say that you’re lying when asked about your claims.

Is This Really For You?

Let me tell you something. If you’re thinking of doing these things, don’t. If you’re currently doing them, stop. I’m not saying this because you’ll be insufferable (though you will be) and I want to defend humanity from this sort of thing. I’m offering this as advice. Seriously. These things are a whole lot more transparent than the people who do them think they are, and acting like this is a guaranteed way to have a moment in life where you wonder why you’ve bounced around so much, having so much trouble with the people you work with.

A study I read once of the nature of generosity said that appearing generous conferred an evolutionary advantage. Apparently generous people were more likely to be the recipients of help during lean times. It also turned out that the best way to appear generous was actually to be generous since false displays of generosity were usually discovered and resulted in ostracism and a substantially worse outcome than even simply being miserly. It’s the same thing in the workplace with effort and competence. If you don’t like your work or find it overwhelming, then consider doing something else or finding an environment that’s more your speed rather than being manipulative or playing games. You and everyone around you will be better off in the end.