Stories about Software


Clean Communication

Do you remember your early days of software development in a team setting? If you do, and you’re anything like me, you’ll have awkward memories of trying too hard. Eager to show that you were ready for a seat at the big kids’ table, you’d dive into new assignments with the sort of over-eager attitude that made the grizzled veterans around you roll their eyes knowingly and, perhaps, smile faintly indulgent smiles.

It was time for you to shine. Adding a new radio button option to an existing series of options was the perfect chance for you to show that you knew what the Composite Pattern was. And, why use any of the collection types in the standard library when you could roll your own and use a method header comment to prove, mathematically, that it sorted itself in O(n log n)? Any unimaginative clod could write code that did what the users needed it to do, but it took a visionary, like you or me from days past, to write code that mostly did what users needed it to do while showcasing lessons from all 4 years of your undergraduate programs. Each feature that you delivered was a chance to add to your own personal portfolio at the company.


Read More


The Tech Lead Role: Lessons from Ancient Rome


Julius Caesar, Mark Antony, and Cassius walk into a bar, and the bartender asks them what they’ll have. “3 beers!” Caesar proclaims. “2 beers,” whispers Cassius.


Because I’m not a historian, I have the luxury of making spurious historical arguments that suit my purpose. I can even bring in Star Wars if I want to. For those of you only passingly familiar with the story of Caesar, he was the pivotal, popular, and controversial figure around which the Roman Republic became the Roman Empire. He was also the obvious inspiration for the scene in which Chancellor Palpatine becomes Emperor Palpatine, causing Padme to remark, “so this is how liberty dies… with thunderous applause.” Caesar was a popular and extraordinary general that imposed his will on the increasingly ineffectual Roman Republic, essentially replacing it with a more unified and centralized imperial government. That is, until his friends in the bar assassinated him in the name of “liberty.”

Caligula Read More


Lifting the Curse of Knowledge

As most of you know, one of the biggest anti-patterns when you’re instantiating program slots is to forget to set CanRemoveOverride to true. But what you probably didn’t know was that the SlotConfig is — Just kidding. I lifted this from a post I wrote almost 3 years ago about legacy code I was working with then. I have little more idea than you do what any of that means.

Read More


Is This Problem Worth Solving?

I’ve done a little bit of work lately on a utility that reads from log files that are generated over the course of a month. Probably about 98% of the time, users would only be interested in this month’s file and last month’s file. How should I handle this?

At different points in my career, I’d have answered this question differently. Early on, my answer would have been to ignore the sentence about “98% of the time” and just implement a solution wherein the user had to pick which file or files he wanted. For a lot of my career, I would have written the utility to read this month and last month’s files by default and to take an optional command line parameter to specify a different file to read (“sensible defaults”). These days, my inclination is more toward just writing it to read this month’s and last month’s file, shipping it, and seeing if anyone complains — seeing if that 2% is really 2% or if, maybe, it’s actually 0%.

Part of this evolution in me was the evolution of the software industry itself. When I started out doing a lot of C and C++ in the Linux/Unix worlds, gigantic documents and users’ manuals were the norm. If you were a programmer, it was your responsibility to write massive, sprawling APIs and if you used someone’s code, it was your responsibility to use those massive APIs and read those gigantic manuals. So, who cares what percentage of time a user might do what? You just write everything that could ever possibly happen into your code and then tell everyone to go read the manual.

Then things started to get a little more “agile” and YAGNI started to prevail. On top of that, the user became more of a first class citizen, so “let’s default to the most common path” became the attractive thing to do and “RTFM” went the way of the dodo. The iconic example would be a mid 2000’s Windows or web application that would give you a sensible experience and then offer a dizzying array of features in some “Advanced Settings” window.

The next step was born with the release of the iPhone when it started to become acceptable and then normal to write dead simple things that didn’t purport to do everything. Apple’s lead here was, “this is the app, this is what it does, take it or leave it.” The “advanced settings” window was replaced by “we’ll tell you what settings you want,” which requires no window.

This shifting environment over the last 15 years informed my perspective but wasn’t entirely responsible for it. I’d say what was responsible for the shift were two realizations. First, I realized, “a ‘business spec’ isn’t nearly as important as understanding your users, their goals, and how they will use what you give them.” It became important to understand that one particular use case was so dominant that making it a pleasant experience at the cost of making another experience less pleasant was clearly worthwhile. The second realization came years later, when I learned that your users do, frequently, want you to tell them how to use your stuff.

Some of this opinion arose from spending good bits of time in a consulting capacity, where pointing out problems and offering a handful of solutions typically results in, “well, you’re the expert — which one should I do?” You hear that enough and you start saying instead, “here’s a problem I’ve noticed and here’s how I’ve had success in the past fixing this problem.” It makes sense when you think about it. Imagine having someone out to fix your HVAC system and he offers you 4 possible solutions. You might ask a bit about cost/benefit and pros/cons, but what you’ll probably wind up saying is, “so…. what would you do and/or what should I do?”


There’s an elegance to coding up what a user will do 98% of the time and just shipping that, crude as it sounds. As I mentioned, it will confirm whether your “98%” estimate was actually accurate. But, more importantly, you’ll get a solution for 98% of the problem to market pretty quickly, letting the customer realize the overwhelming majority of ROI right away. On top of that, you’ll also not spend a bunch of money chasing the 2% case up front before knowing for sure what the impact of not having it will be. And finally, you add the possibility for a money-saving work-around. If the utility always reads this month’s and last month’s files, and we need to read one from a year ago… rather than writing a bunch of code for that… why not just rename the file from a year ago and run it? That’ll cost your client 10 seconds per occurrence (and these occurrences are rare, remember) rather than hundreds or thousands of dollars in billable work as you handle all sorts of edge cases around date/time validation, command line args, etc.

I always wince a little when I offer anecdotes of the form, “when I was younger, I had position X but I’ve come to have position Y” because it introduces a subtle fallacy of “when you get wiser like me, you’ll see that you’re wrong and I’m right.” But in this case, the point wasn’t to discredit my old ways of thinking, per se, but rather to explain how past experiences have guided the change in my approach. I’ve actually stumbled a fair bit into this, rather than arrived here with a lot of careful deliberation. You see, there were a lot of times that I completely whiffed on considering the 2% case at all and just shipped, realizing to my horror only after the fact that I’d forgotten something. Bracing for getting reamed as soon as someone figured out that I’d overlooked the 2% case, I battened down the hatches and prepared to face the fire only to face… absolutely nothing. No one noticed or cared, and the time spent on the 2% would have been a total waste.

So next time you find yourself thinking about how to handle some bizarre edge case or unlikely scenario, pull back and ask yourself whether handling that is worth delaying the normal cases or not. Ask yourself if your user can live with a gap in the edge case or work-around it. And really, ask yourself what the ROI for implementation looks like. This last exercise, more so than learning any particular framework, language or library, is what distinguishes a problem solver from a code slinger.


Be the We

There’s a moment at a job that you’ve probably never thought about specifically, but it’s a knee point of sorts. Think of arriving at a new gig that you take somewhere, fresh out of the interview process, pumped about the new opportunity and the 10% pay bump you’ve negotiated for yourself, and generally rarin’ to go. You’ve come out of an interview process in which you’ve presented a pretty rosy picture of yourself and so have they, so everything’s awesome.

Then you arrive for your first day with your passport to prove citizenship and your lofty expectations and, after a period of getting settled, you get down to work and see what’s going on. Maybe it’s a walk through the code base or your first standup meeting where it happens. Maybe it’s a department meeting. I don’t know. But somewhere, it happens. You see something pretty crazy that calls into question all of the awesome things you thought about your new Shangri La. Maybe the company is using Visual Source Safe for source control. Maybe “daily standup” is a manager sitting while 30 direct reports spend 2 hours furnishing status updates. If you think hard, I’m sure you can remember the first “these people are insane” moment that you had at any given company. But that’s not the moment that I’m posting about; that’s just a baseline moment to which we’ll return shortly.

That first WTF moment probably isn’t the last and, to some degree, this is inevitable since not everyone will do things in quite the same way. You respond to these early moments by asking questions of the people there: “so, what’s the backstory behind that 12,000 line singleton class” or maybe “why do you guys put up with code commits taking 3 hours?” And, what’s more, you probably make the case to remedy some of these things and, perhaps even have some success. You fight strategic battles but you don’t (and can’t) win them all, and at some point you and the company adapt to each other like an ice cube in a warm glass of water becoming coolish water. You change some things and get used to others.

And then the moment in question comes. It sneaks up on you when a new hire comes on board, looks at the code commit process you’ve trimmed from 3 hours to 2 hours and says, “what’s wrong with you guys that commits take 2 hours?” The moment happens when you say, “that’s not me, man — you should have seen what these goofballs were doing before I got here. Don’t lump me in with them.” Tell me this has never happened to you, I dare you. You wince and say, “it was like that when I got here!”

As one of my favorite movie characters (I make the distinction because I have no idea if the actual man said things like this) Doc Holliday said in Tombstone, “apparently, my hypocrisy knows no bounds.” I mention this because I’m about to advise against this in a “do as I say and not as I’ve done” sense. Over the course of my career, I’ve tended to disengage (and eventually leave) from situations that I found to be degenerate, rather than battling endlessly to correct them. This led to a tendency to keep myself at arm’s length from a group if I didn’t like things that were happening.


What I’ve come to understand is that there is no “me and them” except in the realm of your (and my) hollow excuses. As soon as you sign on with that company, there’s only “we.” I’ve learned the hard way that accepting this immediately results in better outcomes in the same way as the “fail fast” mantra. The best outcome is that you get there, ask questions about “why does our build take so long and how can we fix it,” and you start chipping away, making real progress that you can take pride in. Your investment of your own reputation in the endeavor provides strong motivation. Another decent outcome is that you can’t make progress and are forced more quickly to ask yourself, “do I want to be part of a ‘we’ that operates this way — do I want my name on this?” If the answer to that is “no” and there’s no sign of improvement, it’s better to exit stage left as soon as you can than to sit around, making sure everyone knows that you don’t actually think much of your group.

Really, that’s a terrible outcome for as long as it continues. You’re unhappy and you look like an excuse-offering malcontent. Your peers resent you because they perceive (probably correctly) that you’re bashing their previous work or throwing them under the bus. It’s a bad situation all the way around, and it can be avoided, I’ve learned over time, by getting to “we” as quickly as possible.

So when transitioning to a new job, assignment, team, or whatever, start talking immediately about what “we” do. It will align you with your group, generate earlier feedback for you on whether it’s a good fit or not, and probably bias you over the long haul to evaluating mutual compatibility more carefully up front.


The Dominant Leader Fallacy

There’s nothing quite like the pressure of assuming organizational leadership for the first time in a professional capacity. And, seriously, I mean in a professional capacity — I’m not talking about being voted captain of the freshman basketball team or student government something. Non-professional leadership scenarios are akin to poker games played at the kids’ table for chips only in that they’re artificial scenarios designed to build character by simulating the real thing. In these scenarios, a wrong decision can cost you a soda machine in the cafeteria whereas in a professional capacity wrong decisions can alter careers and livelihoods (and, in higher pressure gigs than I’ve ever had, sometimes even human lives).

I can’t speak across the board, but I can speak to organizational leadership against the backdrop of knowledge work (and in this case, I mean official leadership, as opposed to ad-hoc or thought leadership). In this field, you often have a good bit of “paying your dues” before you’re deemed ready for leadership. Sadly, the gatekeeper factors here are often duration of tenure or having been a leader before (the entry level Catch-22 all over again, wherein you need leadership experience to be given a leadership role and a leadership role to gain leadership experience). Thus, the waiting period might be years or even decades, in some cases, so if you’re ambitious, you’re probably chomping at your bit for a long time before it comes. And then it comes…

…and you’d better not screw it up! The very people that gave you the nod have you on quite the short leash, and they’re ready to yank you off the stage with a cane should you show the slightest hint of weakness. Whatever you do, never admit to ignorance of any sort. If it’s an acronym you’ve never heard or a technology you haven’t used, grit your teeth, fake your way through it and study up until 4 in the morning so that you can stay perfect in everyone’s eyes. And don’t think that this only applies to your superiors. Those you’re leading are also waiting for any excuse to dethrone you and lay their own claim, so don’t sleep on them, either.


Heh. I don’t know that I ever thought these things, consciously, but I certainly did to some degree on a subconscious level. And, while I’ve never been the sort to try to bluff at having knowledge I don’t, the part about staying up ’til 4 AM studying was (and still kind of is) definitely my style. I didn’t want to blow the whole leadership thing, so I broke my back trying to be perfect. But these days… not so much. I now break my back trying to do other things.

At some point, I figured out that trying to know more than 5 or 10 or however many people doesn’t scale very well and, even if it did, would winning knowledge trivia duels be the best use of your time as a leader? Maybe if you’re running a gang or a pack of wolves this makes sense — your cred is tied up in your ability to dominate any challengers. But I like to think that we have a bit more organizational sophistication in our approach. In knowledge worker professions, the best use of a leader’s time is removing obstacles that are stopping the team from excelling and figuring out how to create an environment that gives rise to good ideas.

If you’re a leader and you don’t know some finer point of the language that your team is using or you’re less familiar with a deployment tool than someone on your team, don’t hide that fact — embrace it! You’ve found a skill and there’s probably a need. Good leaders play match-maker in these situations. “Hey, you seem like you really know your Python and I know there’s some nasty code over in that particular module, so maybe you could get it sorted where the rest of us failed.” If you think back to the best leaders/bosses/managers/whatevers that you had in your career, did you appreciate them because they were better at everything than you were? Or did you maybe appreciate them because they got out of your way, trusted you, and guided the team toward playing to your strengths?

So if you’re new to leadership, relax and take a deep breath. You’re not playing a game of “king of the hill” and the team members aren’t adversaries looking for a crack in your armor. You’re playing a team sport and you’re more like the coach — they expect you to put them in a position to succeed rather than to push them out of the way and single-handedly win the game for them. So go in, cop to what you don’t know, and solicit volunteers for people to get the job done and maybe even teach you a thing or two along the way. Leadership is a matter of trust — not dominance.


People Deserve The “What”

I don’t read blogs nearly as often these days as I used to and as I wish I currently did. A lot of this is the result of generating increasing amounts of my own content in various forms, and the rest is probably that I spend most of my time these days in coaching/administrative sorts of roles, rather than with large stretches of uninterrupted desk time. Nevertheless, I do try to sneak in a few posts or articles per day, albeit sometimes behind the bleeding edge.

The other day I noticed this post from Uncle Bob, which referenced (and thus led me to watch) this video:

One Hacker Way – Erik Meijer from Reaktor on Vimeo.

Here’s a wikipedia entry on Erik Meijer, the speaker, who, among other things, is responsible for Linq. He has a suitably impressive resume that I bore in mind my absolute love of Linq and listened through the duration of the talk, which seemed mainly to have the loose thesis, “everyone sucks at everything and I hate you, yes, specifically, you.” Removing tongue from cheek, it seemed to be garden variety contrarian talk: “{Whatever} is popular, but I’m hear to tell you that everyone is wrong and {whatever} actually {sucks/is dead/ruined Christmas} and {very new, vague concept} is what you need to do instead.” You can usually schedule a follow-up talk in a couple years of the form “{Very new, vague concept} was a great idea when I had it, but you all screwed it up, so it’s time to dust off and retry {whatever}.”

Sometimes I find this sort of thing thought provoking. I try very hard to be able to justify any practice that I use beyond just “well, that’s the way the winds are blowing” or some such. My preference is to be able to defeat serious frontal assaults out of nowhere on any given thing that I may be doing (not that I prefer to spend my days doing this, but I’d like to think I could, if necessary). So, watching critiques of practices that I employ, such as TDD, puts me into a position where I consider whether there might be better ways to solve problems that I have than the ways I’m currently solving them.

This talk didn’t have that affect on me — it didn’t really have much of any effect on me, and it actually reminded me of meetings that drone on and start to try my attention span. But that makes no sense; it’s a guy using colorful language, obviously possessed of a sense of humor, and saying things that are provocative and in direct disagreement with the way I do things. I’d expect some mix of amusement, indignation, annoyance, etc — not inattentiveness. I had to think on it a bit before I realized why this was: at the end of the day, it’s someone telling me what to do without explaining how those marching orders help me solve any kind of problem.

(Paraphrased) “Agile sucks. Commit code or you’re worthless. Quit your job if they want you to practice TDD.” My response is, more or less, “that’s… dramatic… but how does this information solve any problem at all that I have?” It’s like some kind of mandatory ISO meeting where someone explains to me that everything I’ve ever done is terrible and hell, fire and brimstone await and there are all of these important compliances and audits and such. It’s all very impressive in the presentation, but abstract and hypothetical enough that it’s hard for me not to zone out after a bit (though I have a specific personality trait/defect that I struggle mightily to pay attention to information that I don’t perceive a use for at the moment).

To pull back and get a little more abstract, let’s consider modes of information exchange where one person is delegating, in some fashion, to another person. There is the “what,” which is goal-oriented, and the “how,” which is process oriented. One or both may be present in a form of delegation (if neither is present, then what you have isn’t actually any kind of delegation). Let’s consider the three cases this allows.

How, but not What

This is really the least helpful case when it comes to knowledge workers, and it’s the least effective form of delegation. It’s the category into which Erik’s talk and the hypothetical ISO meeting fall. You’ve got someone telling you what to do, but not really tell you why you should do it or what they think will be accomplished. It’s usually from a position of authority, most typically a micro-manager. Erik’s apparent likening of software developers to military and a hierarchical organization like the Catholic Church is sort of telling here, as these are the types of institutions that espouse an operational philosophy of “it’s not your job to think, grunt, just do as I tell you.” Or, “don’t worry about what or why, just concern yourself with the how.”

Erik’s authority comes from his status/accomplishments in the industry. ISO guy’s authority comes from bureaucratic rules and civil laws. General’s authority comes from the command and control structure. All of this is effective for easily-automated process or purely tactical thinking, but it’s tended to fail pretty repeatably throughout history for knowledge workers. See, for instance, development shops that believe it’s effective to bring on a couple of architects to be the brains of writing software and then hiring legions of unskilled grunts to do the mindless work of programming.

And, apart from this being pretty ineffective when it comes to delegating to knowledge workers, it’s also a bummer. Being micromanaged sucks all of the fun out of our jobs. Imagine sitting there programming and someone comes up to you and starts telling you to adopt different coding standards and change your indentations and such. When you ask, “why,” he just calls you and idiot and tells you that “what are we trying to accomplish here” is above your pay-grade, peon.


How and What

This is probably the most common scenario these days in a lot of shops for most interactions. You get a mixture of the goal and the process — the what and the how. An iconic example of this is the former-hero developer that’s been promoted to architect/team lead/dev manager and who no longer has time to work on all of the features she otherwise might have. She fights the urge to just roll up her sleeves and do it, knowing that doesn’t scale, but that doesn’t stop her from saying, “you need to get this information stored for later… and, you should do this by using the repository pattern to encapsulate this particular…” and so on.

It’s better than how without what. You’re being told the goal and you’re part of the discussion, and I consider that table stakes for effective knowledge work. But in this case, it’s like getting a math textbook with all of the answers scribbled underneath each problem. It’s helpful for getting right answers quickly (assuming they are right), but it’s not helpful for your own learning or morale.

The trouble is, this is natural for the former hero-dev and anyone in her position. She knows what the problem is and she knows a workable solution. So wouldn’t it be beneficial for her to just share that knowledge? Well, maybe, but it’s nuanced. And I’d argue that the longer term cost of this quasi-dysfunctional arrangement tends to outweigh the short term gains.

What but not How

This is the best situation for knowledge workers. It allows for the ‘ideal’ distribution of work, if you will, since it’s like two systems being a generalized service interface. Former-hero tells you what she needs and leaves it up to you how to do that. She worries about her stuff and you worry about yours. If one of you needs input from the other, you approach that on an as needed basis and the relationship is one of mutual trust. Knowledge workers thrive in this sort of environment. Knowledge work requires creativity and creativity flourishes in low pressure, non-contentious, free environments.

Interestingly, to bring things back full circle, this is an excellent working arrangement, but it would make for a poor talk/book/blog post. Telling you what but not how would mean I’d make a post like, “I think the Java language could really be improved, but I’ll leave it to you to decide how in the comments.” Effective presentations need “How and What” — “here’s a problem that you have, and here’s how I propose that it might be fixed.”

So What?

Why do I draw these distinctions? To encourage you to be mindful of the how and the what in your interactions with others. In code, good encapsulation and separation of concerns are achieved by having public method signatures define “what” and private implementations define “how.” I think this is a good model for dividing work with others. When dealing with them, encourage them to define what they want from you rather than how they want you to do it. And when delegating, try to avoid telling people how to do things, telling them what it is you want instead.

This scales much, much better than anything else. Life is simply too complex and short for you to spend your time knowing how to solve everyone’s problems better than they do. Like it or not, you’re going to have to rely on the expertise of others, so rather than micromanaging them, trust them and spend your time getting your stuff right and figuring out how to surround yourself by as many trustworthy people as possible. And, if you do find yourself in a position to be explaining the how of something — maybe you’ve been asked or are casually conversing or whatever — make sure that you supply the “what” to go along with the “how.” If you can’t put a “what” to it and make it convincing, people will be hard pressed to care about your “how.”


Annihilating Complexity

I think that I’ve been blogging long enough to earn a bit of latitude when it comes to making up pseudo-scientific ‘theories’ to describe the universe.  So, indulge me, if you will, as I abuse concepts of physics by using them as staging points for a narrative of human behavior.  I think it’ll be fun for all involved and it’s my hope that, on the other side of this, I’ve advanced the course of human knowledge rather than lowering everyone’s IQ.  But, hey, caveat emptor.

If you ever had the good fortune to take a high school chemistry class, you might have studied endothermic and exothermic reactions.  I say good fortune because these reactions involve the flow of heat into and out of systems, so appropriate demonstrations almost certainly involved melting things or blowing things up.  To (over) simplify the situation and avoid you needing to precisely define “system” or to ask the question, “what on Earth is enthalpy,” let’s just say that exothermic things spew heat into the world and endothermic ones remove it from the world.  Like I said, indulge me.

In a talk called, “Simple Made Easy,” Rich Hickey describes “finding” a term for the introduction of needless complexity to a system: “to complect”  (literally meaning to join together by weaving).  I’ve come to think of and use this word to describe times where a solution to a problem is actually more complicated than the problem itself, meaning there has been a pointless introduction of additional complexity.  Now that I spend my days in the world of Java again, I’m reminded of the witticism: “I had a problem and I used Java to solve it — now I have a ProblemFactory.”

Now, to bring this apparent non sequitur to heel, here’s what these two concepts have in common in my mind.  I’d like to define two camps of people: “endocomplectic” people and “exocomplectic” people or, “endocomplectics and exocomplectics.”  Endocomplectics are people who remove complexity from their surroundings — something about their nature allows them to simplify things, essentially absorbing, or at least deflecting complexity and making the area around them simpler for others.  Exocomplectics, on the other hand, add complexity to their surroundings, and make life harder for those nearby.

To get a bit more specific, let’s define three conceptual scopes: the world, the group, and the individual. The world is, well, the world. The group is the setting in which you can observe this in action — typically your team room or something similar in a work capacity (though it can also certainly apply to non-work considerations like families or groups of friends). And the individual is, not surprisingly, the person in question. Let’s also further divide the exocomplectics and endocomplectics into sub-categories. Exocomplectics include complexity creators and complexity adders and endocompletics include complexity removers and complexity annihilators. I’m operating on a hypothesis that this is the essence of what you need to seek or skip in interviewing and that any behavior from being a good teammate and human being to solving problems effectively can be expressed on this spectrum.  Crappy people create complexity and awesome people annihilate it.

Complexity Creators

I’ve actually posted about this, albeit many moons ago. A complexity creator, in the world/group/individual scoping sense, is someone who has some kind of internal reservoir of “potential complexity” and, like an octopus with its ink, spews it out into the world around them, seeking to obfuscate and confuse.


Think of someone you can recall that’s perhaps out of their depth in their role or else extremely lazy or something like that. You can probably picture someone that meets this definition and the weird things that they say when you ask simple questions like, “so, what did you do last week,” or “hey, can you work on feature X a bit?” Explanations as to how incredibly hard the task is start to rain down in an onslaught of excuse-hail, bludgeoning you into taking cover. “Oh, well, there’s a lot of angles, and I had to read up on it a bit and then consult Bill and Steve over in accounting, and then I fired off 12 emails to Microsoft, and…” You stand there, jaw hanging slack, because all they would have needed to do would have been to add a few lines of markup and call it a day.

This is a complexity creator. Complexity creators are exocomplectics that actually birth complexity into existence, adding opacity and disorientation to what otherwise would have been a clear cut situation. These tend to be net-negative producers whose removal from their group would be a classic case of “addition by subtraction.”

Complexity Adders

Complexity adders don’t manufacture any complexity themselves, but they do find a way to add it to the group. If you think of complexity as a sort of commodity, complexity adders move it from the world scope into the group scope. Generally, this is done without any ill-intent whatsoever and is primarily an accident. Perhaps the easiest example to understand would be a new Director of Software Development coming into a shop, sizing up the team, and introducing some kind of development process with all sorts of gates, phase exits, orchestration components and other elaborate things designed to solve problems that the team may face someday. New director is bringing a complicated ‘solution’ with him from the outside world and introducing it to the team. Usually this sort of thing doesn’t go particularly well.

Zooming out a bit, complexity adders are those who attempt good faith solutions but inadvertently muddy the waters. In their wake, they tend to leave a fair bit of confusion. There’s also an unfortunate insidious element to this type of team member in that their effort is often unimpeachable. That is, they really believe in what they’re doing and will often put in 70 hour weeks to try to see it through. Complexity creators generate and inject complexity to hide shortcomings whereas complexity adders suffer simply from bungled execution.

Complexity Removers

These folks are probably people you think of as classic good teammates. They have a tendency to cut to the core of issues and eliminate a lot of nonsense. Pragmatic solutions that make people’s lives easier are their bread and butter. If you’ve got too much on your plate and you’re stressed out, they’ll suggest that you punt some of it over to another group. If a BA or external stakeholder comes over with garbled requirements, a complexity remover will put the brakes on and insist on better input.

Complexity removers move complexity from within the group to somewhere else. As far as the group is concerned, they’re eliminating complexity and, since the world consists of lots of nested groups, they’re often improving things on the whole by shuffling it to where it belongs. Complexity removers are people that you’ll tend to remember fondly in some capacity or another as you go on about your career.

Complexity Annihilators

These people are game changers. Complexity removers do what they do via tweaks and incremental improvements, whereas complexity annihilators do something different. The former look for simpler ways to execute the existing solutions they have to the problem whereas the latter simply define different solutions. To put a little bit more concreteness to this, consider a scenario where a team was struggling to implement a web app that kept track of todo items and let you mark them as “in progress” or “finished.” A complexity remover might suggest first putting out a version that was just a single list and then implementing states later. Or, perhaps she would advocate using a client side javascript framework instead of struggling with the home-rolled version the team was using.

But a complexity annihilator would say something like, “dude, why don’t you just use Trello? Here, I’ll show you.” And, as the look of disbelief settles over the other team members, all present can sense the complexity just winking out of existence. Poof — gone! Now that we’ve solved that, what’s next?!

This is a pretty contrived example, but it illustrates the point — the game change. Complexity annihilators find ways to radically simplify the lives of those around them and without moving complexity anywhere. They just, well, annihilate it. And they’re good at it. I mention this last bit because someone who fails at this and oversimplifies into the realm of wrong or absurd (e.g. suggesting Trello as a solution for automated grammar corrections) is actually a complexity adder, by virtue of bringing some new, irrelevant idea into the mix.

So What?

As I mentioned earlier, I have an operating hypothesis that you can classify people along this spectrum pretty widely. I’ve talked exclusively about technical problems, by way of example, but think even of interpersonal relationships. Humans and their interactions are complicated, and it’s pretty easy to do something wrong and inadvertently annoy others or create destructive tension, which is a complexity-add (since tension represents a source of impediments). Complexity creators and adders in this context will tend to foment strife, deliberately or inadvertently. Complexity removers will diffuse situations and annihilators will invent ways to make said tension impossible (e.g. preventing arguments over coding standards by implementing an auto-format on the build machine).

This idea hasn’t percolated enough in my head for me to suggest interviewing tactics to elicit complexity adders, so I’d be open to suggestions. But, if we could come up with some, I think that it could shift the focus to something more productive than trying to figure out if people had X years of C# or whatever. And, as individuals, I think we could all do well to evaluate ourselves along this spectrum. I don’t think any of us are born into one of these buckets, per se, so improvement is certainly possible. It seems a worthy goal to me that we should all strive to be complexity annihilators.


Help, My Boss Sucks!

I might be accused of link bait for a title like this, but I actually get a decent amount of questions that, when you distill them down to their bare essence, amount to this title. The questions are often packaged in narrative (possibly rant) form and almost invariably summed up with an apology for all of the detail. Please don’t apologize for that level of detail. It’s not that I enjoy hearing about your miseries, but I think that there’s definitely a shared catharsis that occurs when recounting or listening to tales of corporate stupidity with a narrator that’s powerless to stop it.

My Expert Beginner series and eventual E-Book resonated with a lot of people largely, I think, because of this dynamic. The experience of dealing with an entrenched incompetent is so common in our industry that thousands and thousands of people read these posts and, thought, “hey, yeah, I had to deal with a guy just like that!” And I’m small potatoes — the DailyWTF is an entire, vibrant site with tens of thousands of subscribers and a number of authors and editors dedicated to this kind of thing. If you want to go even bigger, think of Dilbert and his pointy haired boss or the Peter Principle.

Assuming, however, that commiseration with others isn’t enough to bring the joy back into your life (or at least to remove the angst from it), the question then follows, “what should I do?” It’s at this point that one might expect to stumble across some kind of insipid faux-answer on LinkedIn or something. It’d probably go something like this:

Top Ten Tips to Tame a Terrible Tyrant

  1. Take up meditation or yoga and learn to take deep breaths when your stress level is getting high so that you can react calmly even in the face of irrational behavior.
  2. Ask yourself if you’re not part of the problem too and do some serious introspection.
  3. You don’t have to like someone to respect them.
  4. Talk to human resources and ask for discretion.
  5. Have a heart to heart and explain your concerns, being courteous but firm.
  6. Enlist the help of a mentor or respected person in the group to make things more livable.
  7. Empathize with their motivations and learn why they do what they do so that you can avoid their triggers.
  8. Heap praise on the boss when he or she avoids behaviors you don’t like in favor of ones that you do.
  9. Seek out a project that puts you on loan to another group or, perhaps, minimizes the direct interaction with your boss.
  10. If all else fails and you’re at wits’ end, perhaps, maybe, possibly, you might want to consider some kind of change in, you know, jobs — but do a ton of research before you do anything and make lots of idea webs and charts and make really, really sure that this is what you want to do because it’s a huge decision.

Honestly, go out and google something like, “what to do about a bad boss” and this is the sort of platitudinous, enumerated non-answer to which you’ll be treated.  It’s manicured, politically correct, carefully considered, diplomatic, and a load of crap.

Let’s get real.

What To Do When Your Boss Sucks

  1. Form an exit strategy.  That’s it.  There is no 2.


Wait, Wat?

Yes, you read that correctly.  I don’t advocate that you take up yoga or work it out on the heavy bag or recite “calm blue ocean” or empathize or anything else.  If you find yourself miserable at work day after day because of a boss with whom you are fundamentally incompatible or if you find yourself googling “what to do about a bad boss” or if you find yourself writing to someone like me to ask for advice on what to do about your bad boss, you’re in a fundamentally awful position that’s probably shaving hours and days off of your life.  Whatever appeasement strategy upon which you may choose to embark is only going to mitigate that — it won’t alter it.  You need to take control of your destiny and that requires an executable, measurable, and tangible plan of action.

I’m not advising you to rage quit or do anything rash — that’s an awful plan (or perhaps a non-plan).  What I’m suggesting that you do is start laying out a sequence of events that removes this person from your life.  There are a lot of ways that this could happen.  Obviously, you could quit and work elsewhere, but you could also plan to stick it out until the boss retires in 18 months.  Perhaps you start taking classes at night so that you can transfer into a different group or maybe you find some team-lead type that acts as a buffer between you and Mr Spacely.  It could be that you do something as unusual as becoming a huge advocate for your boss to upper management so that he’ll get that promotion that will take him to another division or, at least, away from dealing with you directly.  Maybe you initiate controlled explosions inside of your own ears so that you never have to hear his terrible voice again and he can’t deal with you unless he learns sign language.  Go make yourself a brainstorming list — no idea short of criminal malfeasance too farfetched — and capture every imaginable path to your emancipation.  Once you’ve got that list in hand, start narrowing it down and firming it up until you have several strategies that you can work simultaneously, all timeboxed and with contingency plans.

You need to have measurable goals against which you can measure progress and you need to understand when to pivot.  A good plan would be something like, “I’m going to get that certification that will make me a bit more cross functional and then I’ll start volunteering for work over in Bill’s group in my spare time.  Within 3 months of that, I’ll casually broach the subject of spending some time in that group and within 4 months, I’ll make it official.  While that’s going on, I’ll talk to HR within the next month about the idea of a potential transfer.  If after 4 months, none of that is going well, I’ll start interviewing for other positions.”

Now when you’re looking at your life, you’re not seeing an unending string of misery to be mitigated only with non-actionable platitudes like, “be more understanding” and “ask yourself if you aren’t partially responsible.”  Instead, you have a plan of action that you believe, if followed, will lead you to being happier.  Because here’s the thing — if you’re fundamentally incompatible with a boss then “who is responsible” is a non-starter and being more understanding isn’t really going to help.  There’s a Protestant Work Ethic, “Pain is Gain” underpinning to all of this that’s really not appropriate.  Is it an inappropriate sense of entitlement that must drive you to say, “I shouldn’t have to work somewhere that my boss makes me miserable?”  Many would argue yes, but I’m not one of them, and I think that’s silly.

If you’re overly picky or sensitive, you’ll wind up job hopping, getting stuck somewhere or, perhaps, have trouble finding work.  That’s how you pay the piper for being too picky or sensitive and, if those things start happening, maybe you should embark on a course of introspection.  But if you’re miserable under a boss, that’s real and there’s no way it’s entirely your fault.  It’s not your sole responsibility to figure out a way to prevent someone from making you miserable and you ought to view this as a no-fault problem to set about solving.  That’s where the plan comes in.

A boss is someone who should be removing impediments from your path to allow you to be as productive and awesome as possible.  That’s not feel-good BS — it’s the way to get the most value and productivity out of knowledge workers.  No boss that truly embraces this mandate should be making your life miserable, even if you are an over-sensitive, uber-picky prima donna.  If the boss is making you miserable on a daily basis then he’s an impediment and not an impediment remover.  Since you’re then responsible for removing your own impediments, there’s only one thing to be done with this boss: remove him from your life.

That’s All Well and Good…

I realize that this all probably sounds rash and maybe you think, “easy for you to say,” but it didn’t just happen to become easy for me to say.  I planned for it.  I’ve spent a lifetime optimizing for my own happiness and satisfaction with what I do and, when that temporarily wanes, due to a boss or anything else, I form a plan, follow it, and fix the problem.  And I do this by thinking in terms of diversification and dependency.

If you take a job at Acme Inc, settle in for a 10+ year stay, and let your resume gather dust, then you’re largely dependent on Acme Inc for your well being via income — you’re putting all of your eggs in that basket.  If Acme then burps out a bad manager and puts him above you in the org chart, you find yourself in the same position as a cable company customer: “yeah, we’re awful, but good luck doing anything else.”  If it seems daunting or hard to plan at this point, it’s because you’re pretty coupled to Acme.  You still can and should make a plan, by all means, but that’s why my advice might seem cavalier.

I have contingency plans all the time, and they range from W2 opportunities to 1099/B2B work to royalty streams to oddball, go-for-broke schemes like moving to the country to be a hermit and try my hand at writing novels.  Some of them are clearly more realistic or feasible than others, but they all exist and I’m in a constant state of assessing my happiness and weighing my options.  Don’t confuse this with fickleness or disloyalty in me and I’m not advocating those things in you.  If I could find something that made me consistently happy, work-wise, for the next 2 decades, I’d happily take the consistency and stability, and I cheerfully advise you to do the same.  But when life or companies throw crap situations at you don’t hesitate to start executing contingency plans to bring your happiness level back to where you want it.  Your happiness is something that you can’t count on anyone but you to monitor and it’s not just important to your quality of life — it’s important to your quality of output as a knowledge worker.  You and your reputation can’t afford for you not to be happy.


Keeping Your Eyes on the Prize

I’ve heard people say things like, “we need to use the strategy pattern here” or “we need a repository layer between the services and domain objects.” Let’s take that at face value and assume that these are things that they “need” to do, in the sense that they’re solid solutions to some problem. The point of confusion then comes from a lack of understanding of the goal. I mean, I doubt that the goal is “to use the strategy pattern” or “add a repository layer,” so someone is explaining a means of achieving a goal.

If the context of the discussion is two people well aware of and in agreement upon the actual goal, then this is entirely unremarkable. It’s just a couple of people collaborating to solve a problem. Somewhat more interesting is the case of the two people not sharing a common goal. For instance, if the first person’s goal is “make it easy to add a new implementation to the code base” while the second person’s goal is, “practice using the strategy pattern,” agreement becomes a matter of coincidence rather than collaboration, and the possibility of tragi-comic feuding emerges. The most noteworthy case, however, is where one or more people are unaware of the goal or don’t actually have a broader goal. “We need to use the strategy pattern because my Software Engineering textbook says Gang of Four is good.” Or, in the Expert Beginner world, “we need to use Strategy Pattern because that’s just what we do.”

Lack of a Goal

I’m not going to spend a whole lot of time on this because it’s pretty straightforward. Assuming that the person in question isn’t a nihilist or troublemaker, this is the epitome of cargo cult. I think that perhaps the most iconic example of this is the pervasive mid-2000’s use of Systems Hungarian Notation. This gives rise to the following type of terminally stupid conversation:

Interloper: Why did you do this: “const char* lpcstr_str”
Cult Member: I wanted to declare a string.
Interloper: Okay, but why did you name it that?
Cult Member: Because it’s a string.
Interloper: That name seems inscrutable and redundant — what’s the upside?
Cult Member: I don’t understand the question. It’s a string. That’s what you name strings.

Cult member has no goal whatsoever because his routine has become a goal unto itself. And really, that’s sort of a sad state of affairs not worth elaboration.


Lack of Consideration of a Goal

Not all participation in routine is the celebration of routine. Routine does, in fact, have a purpose. It’s sort of the human-natural way of prioritizing cognition. What I mean is, imagine a world where you approached everything as if it were a riddle requiring critical thinking. Every morning you’d stop to ask yourself if there wasn’t, in fact, a better way to brew your coffee than using your Keurig. And, the drive to work? Should you find a new route? Should you drive at all?

Nobody has time for this, so a great many activities are conducted on auto-pilot with rationale revisited only strategically. Every now and then you may wonder if you should make your coffee differently or drive to work via a different route, most likely as a result of ongoing frustration with something. And that’s fine. In fact, it’s probably efficient.

This applies in a limited way to programming. I say limited because programming is knowledge work and it’s also rarely repetitive if you’re doing it well. Programming isn’t like driving to work or making coffee; you’re generally blazing a new trail even if you’re doing something comparably formulaic like some kind of forms-over-data/CRUD app. The domain changes, the languages/frameworks/tools in use change, and the business context changes. There may be aspects of the craft that you don’t revisit as often, such as, say, which source control tool or programming language you use, but by and large programming demands fewer brain reps on auto-pilot than most other things in life. In this context, lack of consideration of a goal puts you in danger of settling in to a rut and not being at your sharpest.

Keeping your Eye on the Goal

As you go through your life as a programmer, I have a definite suggestion for how you can avoid a rut. Always be able to rattle off your goal when asked about what you’re doing. That’s it, really. The goal doesn’t necessarily have to be great, and your means of achieving it doesn’t need to be either (I mean, do your best, but I’m making a point here). Just knowing what it is you’re trying to accomplish well enough to articulate it will help you a lot.

So if you’re overhead saying, “we need to implement the strategy pattern here” and someone asks you why you think that, be ready with “the goal is to allow future implementations with a minimum of violence to the code base ala the Open/Closed Principle.” Now, it could be that the strategy pattern is a poor choice or that you’re gold plating or whatever else, but at least you’re not caught flat-footed when challenged on your motivation and, more importantly, thinking in terms of goals creates a concrete link between your solution and added value.

And if the next question you want to ask is, “what if someone asks you for the goal behind your goal,” this absolutely iterates. A logical follow up would be “why are you worried about future implementations,” and your logical answer may be, “we’ve been asked to add 3 already, so it seems like a 4th and perhaps beyond are likely.” Now, your connection of solution to broader goal is “business has created a lot of churn around X, so I think we can use the strategy pattern to minimize the risk associated with any more similar churn.” Want to go another round? How about the fact that each time this has churned it’s cost your company $15,000, and you think that, with the strategy pattern, you can cut that to $5,000.

So, where does the iteration end? Perhaps at “we’ll have more money if we do this.” Perhaps further (“we need more money so that…”). Perhaps not that far. But, really, the further back along the path of your reasoning, the better. The more you can tie your specifics to broader, strategic goals, the more persuasive you’re going to be and the more likely you are to have solutions that, even imperfectly executed, will be a help. So the next time you find yourself talking about patterns or repositories or frameworks or whatever, do an exercise and see how far back you can iterate if you were confronted with a child asking, “but, why?” ad nauseum. Worst case scenario? You waste a few minutes practicing justifications of your decisions.

Acknowledgements | Contact | About | Social Media