Stories about Software


Are Your Meetings Worth Attending?

“Remember, kids, your projects are due a week from Monday, so you’d better get started if you haven’t already.”

This imminently relatable phrase, or one like it, is probably the first exposure to nagging that most of us had outside of the home. Oh sure, Mom and Dad had nagged us for years to clean our rooms, say please and thank you, and wear jackets. But our teachers introduced us to business nagging. I’m using the term “business nagging” to characterize the general practice of nudging people to do things for common professional effort.


If you fast forward to your adult life, business nagging morphs into things like, “don’t forget to sign off on your hours in payroll,” and, “everyone must update their email signatures to use the company’s official font by next week.” The subject matter becomes more adult in nature, but the tone and implications do not. When you hear these phrases, you’re transported back in time to junior high, when you needed to rely on a teacher to help prevent your general incompetence at life from creating unfavorable situations for yourself.

There’s a subtle problem with business nagging growing up alongside of us. As children, we actually are pretty incompetent at looking out for own interests. Left to our own devices, we’ll procrastinate on the school project and then pull an all-nighter ahead of turning in something that earns us a C minus. But as we grow to adulthood, we learn these lessons firsthand and wind up being generally decent at looking out for ourselves. We tend not to need nagging nearly as often to do things that will benefit us, so being nagged to do things that will benefit us winds up becoming largely superfluous.

And that leaves the most common form of business nagging: being nagged to do things that offer no obvious benefit to the recipient of the nagging. Signing off on your hours in payroll doesn’t benefit you directly (except, perhaps, by removing the artificial threat not to compensate you for the work you’ve done). Changing your email signature doesn’t benefit you directly. According to someone with some degree of power somewhere in the organization, you doing these things will benefit the company. Presumably, if the company benefits, so do you, somehow. But there is as much vagueness in that equation as there are “somes” in the previous sentence. From where you’re sitting, it’s just bureaucratic procedure having only one tangible benefit—getting the administrator of the business nagging to go away and leave you alone.

This was a post I originally wrote for Infragistics. Click here to read the rest.


Appeasers, Crusaders, and Why Meetings Usually Suck

I think this is about to get weird, but bear with me, if you’re so inclined.  This is going to be another one of those posts in which I try to explain myself by way of a vague apology for my abnormality.  But maybe if enough of you are similarly abnormal, it’ll gain a little steam.  I’d like to talk today about my odd, intuitive approach to disagreements over the rightness of opinions or beliefs. (For epistemological purposes, consider anything that you’d think of as a “fact” to fall into the belief category.)

So, let’s say that Alice and Bob are sitting on a bench, and Alice proclaims that blue is the best color.  Bob might agree that Alice is right.  He might disagree with her on the basis that red is actually the best color, or he might disagree with her on the basis that this is a purely subjective consideration, so the idea of a “best” color is absurd.  In short, Bob thinks that Alice is wrong.

Perception of rightness affects different people differently, it appears to me.  There are a lot of people out there for whom rightness is extremely important, and the idea that someone might be wrong and not corrected offends them deeply (as shown here, ably, by xkcd).  I am not one of those people.  I might be baited into the occasional back and forth online (or in any asynchronous form) when someone directly accuses me of wrongness, but that’s pretty much it.  I almost never seek out people to correct general wrongness, and I certainly don’t do it in person — with the exception of very close friends and family, and only then in casual conversation.  By and large, other people being wrong about things doesn’t matter to me.  If I’m sitting in the bar, having a beer, and some drunk is yammering political opinions that get increasingly moronic with each boilermaker, I have an innate gift for quietly enjoying the free spectacle.

But there are situations that require cooperation, often professional ones.  Working with another person, there may be some debate or disagreement over the course of action that ought to be taken, and, in such cases, the moment happens when I’m convinced that someone is wrong, and they’re equally convinced that I’m wrong.  The first thing that I do is evaluate whether or not the wrongness negatively impacts me.  If not…meh, whatever. Read More


8 Career Tips That Don’t Require Competence

A few weeks ago, I posted my spin on the MacLeod Hierarchy and promised to follow up with a post addressing the kind of vacuous, non-strategic career advice that is often given in Buzzfeed sorts of formats.  I started, then, to type this post, but realized that a bridge of sorts was needed.  So I indulged a digression wherein I described the corporate idealist that typically solicits and follows this sort of advice.  (That post also became pretty popular, with a number of requests to pre-order my upcoming book, which you can now check out here on leanpub).  Now, having described the corporate idealist and his willingness to overwork in exchange for useless status tokens, I can go on to be clearer about why so much of the career advice that you tend to hear is so, well, frankly, dumb.

I started to write this just from anecdotal experience, including various comical, ham-fisted self promotion attempts that I’ve watched over the years.  But then I thought it’d make more sense to go out, do some research, and synthesize my experience with actual advice offered in these “Linkbait for Idealist” articles.  This is a list of the ones that I read as reference material.  (As an aside, I also stumbled across a few that offered fairly sensible, decent advice for how to advance meaningfully, so it is actually possible to find advice that isn’t silly)


Read More


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.”

Acknowledgements | Contact | About | Social Media