Email Is the Worst Form of Internal Communication

Email is the worst form of internal communication in common usage today. The only redeeming characteristic of email is to create proof that at some point in time, you tried to inform someone of something. In this way, it is very similar to its direct ancestor: paper mail delivered by the postal service, and it is just as obsolete. Unfortunately, as remote work has become an immediate necessity for millions of people worldwide, email has become a primary form of communication.

Read More »

The Danger of ‘The Dark Sage’

JP Ventura left an intriguing comment on The Sage that I’d like to explore:

Considering each coin has two sides, what would be the dark side (i.e., opposite) of the Sage?

What I find interesting about this question is the fact that I had not given much thought to the “dark side” of the 12 highly effective developers. The Sage, in particular, can have several dark manifestations as ostensibly, they are supposed to be a benevolent master whose primary interest is helping the members of their team grow. If we look at someone who is pretending to act in a way that could be confused with The Sage but is, in fact, the opposite, we get something like this:

  • Someone who is pretending to be a master, but is not.
  • Someone who is pretending to help their team grow, but is not.

I have worked with people like this, and the thing that jumps out to me the most is that – at the time – I had no idea that they were not what they pretended to be. It would take many more years of experience before I would be able to realize their lie. 

“Mastery” is elusive and resists being pinned down to one concrete set of attributes. Furthermore, if someone is a “Master” or not is entirely subjective to who is making the assessment. A typical way a “pretend master” would come to exist is a group of novices who perceive someone highly proficient as a master. High proficiency, however, is not mastery. In my article “How to Learn Upskilling,” I give my breakdown of what I think constitutes a master (loosely based on the Dreyfus Model of Skill Acquisition), which amounts to being the person experts look to for instruction. This description cuts through the problem of “relative mastery,” as at least novices are not confused that they are experts…usually.

I do have sympathy for the master-only-because-they-are-surrounded-by-novices, however. When you have a team of a dozen developers treating you like a master, it is easy to get confused so long as you judge yourself solely in that limited context. The antidote for this is to break outside of our statistically insignificant bubble by comparing yourself to known masters. Determining who the masters are, unfortunately, becomes very difficult in the software industry, as unlike older disciplines with well-known masters, we have to guess at who our masters are. With no one to compare themselves to, the pretend master becomes understandable. 

There is, of course, a litmus test to mastery that the “Dark Sage” should know if they were indeed a master, and this is where they become unforgivable. The Dunning-Kruger effect predicts that a true master doesn’t think they are a master, as true masters are acutely aware of what they do not know, and therefore think they know nothing. Consequently, I believe someone pretended to be a master knows they are not, yet they suppress this feeling because they enjoy the privilege that comes with mastery. They are dishonest, and they know they are aware of their dishonesty. 

So far, this “fake master” phenomenon has not yet become a problem. Sadly, it often leads to arrogance and condescension triggered by having their mastery challenged. The self-defense mechanism of the fake master, when challenged, is to counter-attack the challenger. The true master instead uses the challenge as a point of self-reflection: “Perhaps I am wrong?” Indeed, true masters are never defensive when challenged because they are not conscious of their mastery, and see the challenge as reinforcing their belief that they know nothing. The Dark Sage, therefore, not only provides weak guidance due to the lack of mastery but is arrogant and condescending due to their instinctive defensive reaction of, “Who are you to question me?” 

Perhaps the Dark Sage, even at this point, is not necessarily a problem. Perhaps they internally believe themselves to be a master, but keep that belief to themselves. The danger comes when they inject themselves into an otherwise healthy debate between two competent or proficient developers and tells them what they should do. Had they not intervened, the developers might have reached an optimal conclusion, but when the Dark Sage says, “It is best to do what I tell you to do,” the process of solution discovery is terminated. Over time, the consequences are dire: the project suffers from bad advice, and the development team fails to grow due to mistraining while also not being allowed to make their own decisions. In the absence of a Sage, a development team can still be highly successful by making mistakes, learning from them, and getting better over time. The Dark Sage shuts down the process of team self-improvement, and instead of giving wisdom, they give misguidance.

Now that I have thought this through, I wonder if the three items in the Identification Checklist for “The Sage” are sufficient. However, without some way to confirm that “The Sage” is a true master, perhaps these three items are the best I can do with any hope of keeping the list concise. If there is a suggestion for other criteria, I would certainly consider adding them. The maximum criteria I have used is five, and The Sage currently has only three, so the list can grow slightly without diverging from established standards.

The relationship between determining technical feasibility and productivity

This is an answer to a question asked by Ashvini Chaudhari in the “Agile and Lean Software Development” LinkedIn group:

Dear All , I m pursuing my PhD in Agile Software Engineering. I have a question regarding spike solution ” If we add spike in project development will it have effect on team velocity? and if yes what could be the parameters ? All the responses will be consider as a general opinion in my PhD thesis.

Read More »

I pity Tim Cook

It’s clear the Job’s deathbed playbook has long since been used up. The Apple devices are getting worse and worse year over year, but Tim Cook has managed to drive shareholder value despite that. Apple is the most valuable company in the world – no one can take that away from Tim Cook; but Apple has fallen from grace, and as captain of the ship Tim Cook bears all the blame.

Read More »

Define your problem before picking a solution

Our industry revels in coming up with solutions, but is quite poor at defining problems. This has resulted in an vast constellation of technological solutions, but with the majority of investment capital being centered around a small handful of banal consumer problems (Hailing Rides, Shopping Convenience, Entertainment, etc.) If we are to solve problems that are worth solving, we’re going to need to get better at defining our problems before we pick solutions.

Read More »

“Artificial Intelligence” is deeply disappointing, and so are we

The term “Artificial Intelligence” transitioned from Science Fiction to Product Marketing with very little time in-between to consider what exactly qualifies as “AI”. While tackling this definition has been done ad nauseam for hundreds of years, I believe that the modern definition of “AI” and those from Science Fiction are worlds apart. This is my attempt to bridge that gap.

Read More »

Are we working or playing?

Recently I’ve been talking to companies that want me to improve staff productivity. The opening conversation tends to be about the same: they pitch me on their company and what a “great place to work” it is. They brag about how smart the people are, how much fun everyone has, and how it’s more like a family that a bunch of co-workers. They describe all the perks like massages, video games, beer-on-tap, coffee bars, and how much everyone loves them. “Sounds like you have it all together,” I say after hearing all of this. “Well,” they reply, “I just wish we could get a bit more out of them.”

Read More »

A Far Too Brief Rough Outline of How to Approach Single-Date Estimation

In my previous “An Attempt at a Pragmatic Framework for Defining a ‘Senior Engineer’”, in the “A Process to Estimate Work” section I said:

“It is beyond the scope of this post to describe everything that goes into making a good estimate, but suffice to say a senior engineer views estimates as a difficult challenge to be surmounted, and as a result will normally ask for dedicated time simply to come up with the estimates.”

A commenter asked that I write an article on estimation, and this is my feeble attempt to do so.

Read More »