Ok Isn’t OK

I have over 50 years’ experience typing. I took a typing class in high school. I took another block on typing in my tech school in the Air Force. I know where the Home Row is. I don’t know why, but I know where it is.

Typing is an integral aspect of my job.My hands are on the keyboard 6-10 hours a day.

In our culture, we value experience. We equate years of experience with skill and knowledge level. By that reasoning, I should be typing 600 words a minute with zero errors. The truth is, my typing isn’t any better than when I completed my first typing course.

Why is that?

The reason is simple: I don’t care. I’ve reached a level of performance in my typing that is “good enough.”

I’ve reached the Ok Plateau.

One year of experience 20 times

This begs the question, do years of experience actually correlate with superior performance?

Not necessarily.

In his landmark paper, The Making of an Expert (Harvard Business Review, July-August 2007), psychologist K. Anders Ericsson tells us that research into expert performance indicates that the number of years an expert has been on the job doesn’t translate into superior results.

In fact, Ericsson notes, current research has revealed many fields where there is no scientific evidence that more experience leads to better performance:

One study showed that psychotherapists with advanced degrees and decades of experience aren’t reliably more successful in their treatment of randomly assigned patients than novice therapists with just three months of training are. There are even examples of expertise seeming to decline with experience. The longer physicians have been out of training, for example, the less able they are to identify unusual diseases of the lungs or heart. Because they encounter these illnesses so rarely, doctors quickly forget their characteristic features and have difficulty diagnosing them. Performance picks up only after the doctors undergo a refresher course.

This isn’t news to the software development community. In recent times it has become more and more common to speak of mediocre senior developers with twenty years of experience as having “one year of experience, twenty times.”

Yet, we all know excellent developers who have been around quite a while.

What’s the difference? What distinguishes an experienced programmer that doesn’t seem to have gotten any better with the passing of time, and one who displays continuous growth?

The Ok Plateau

The good ones are, in their own eyes, never good enough.

In the 1990s, Nelson Rockefeller, the richest person in the world at the time, was asked, “How much money is enough?”

Rockefeller famously responded, “Just a little bit more.”

If you were to ask good programmers the same sort of questions–how much knowledge is enough, how much skill is enough, how much better do you want to be–they would most likely respond: “Just a little bit more.”

Whenever you say, “I’m good enough”, you stop improving. It’s as if a switch flips and your desire to improve just powers down, along with any effort to actually become better..

That’s when you reach the Ok plateau.

In his book Moonwalking with Einstein, Josh Foer defines the Ok plateau as “the point at which you decide you’re OK with how good you are at something, turn on autopilot, and stop improving.”

The Ok plateau is not always a bad thing.. No one wants to get better at tying their shoes or washing their hair. If you obsessed over the most efficient way to floss your teeth, well, that would be just weird. We love autopilot in those cases. Most of our habits and mannerisms are performed on autopilot, which frees up cognitive resources to ponder other things.

Moving Off the Plateau

One area that the Ok plateau does not serve us well is in our careers.

If our careers are on autopilot, then we are losing altitude.

And maybe you’re ok with that. Perhaps you are at a point where things are good and you are quite satisfied to coast along, hoping you have enough momentum to carry your through to the end of your career.

However, if you are not satisfied with your current state, and the thought of floating along for the next 20 years terrifies you (and it should!), then the ok plateau is not acceptable.

The important question then becomes, “How do I move off the ok plateau?”

Cultivate Dissatisfaction

The biggest thing you can do to get off of the Ok plateau is to cultivate dissatisfaction. You land on the plateau when you’re satisfied with your knowledge, your skills, and your performance. If you find yourself in that condition, then it’s little wonder you see no need to improve. You’re Ok just the way you are.

But, whether you know it or not, you’re not Ok.

You can do better. When you realize this, you begin the journey of improvement.

And What Else?

Here are a few other ideas that might help jump start your improvement engine:

Disable autopilot

We are on autopilot when we do the same things over and over out of habit, without thinking about them.

The key word in that sentence is thinking. We need to think about what we’re doing. That means deliberately thinking about our thinking, what psychologists call metacognition.

One way we can exercise metacognition is by brute force (“Think! Think about your thinking! This is me, thinking about my thinking!). I’m not sure that would work very well.

A sneakier way is to change up your routine. Turbulence can knock a plane off autopilot (I don’t know if that’s true or not.), and a disturbance to your normal routine will cause you to think about what you’re doing.

An example is when we drive to and from work. The route is so automatic that we often arrive at work with no recollection of the journey.

However, if there is road work that causes us to take a different route, we become keenly aware of the trip, particularly if we are not familiar with the new route.

The same thing happens when we change up our routine. It forces us to focus on what we are doing and can knock us off autopilot.

Practice deliberately

The nuts and bolts of improvement are to be found in deliberate practice. Oceans of ink have been spilled on this topic, so I’ll just give a few thoughts here.

You must be motivated to improve. That’s sorta the point of this post.

You must practice the difficult bits most. Most of our real practice time is taken up going over things we already know or skills that we find easy. This does little to help us. We have to practice the hard stuff.

You must get good, hard, honest, rapid feedback. Without feedback we are learning nothing. Find a coach, a mentor, a like-minded peer to give you feedback.

You must repeat, repeat, repeat. Practicing something once or twice will not help. This is a lifetime commitment.

For more information, check out books like Talent is Overrated by Geoff Colvin or Peak by K. Anders Ericsson.

Assess the competition

We are setting ourselves up for failure when we neglect the competition. And the biggest mistake most people make is to compete against the wrong foe. Our competition is not our co-workers or subordinates, even if they are gunning for our jobs. Our competition is not the bosses, no matter if they’re trying to help us or hinder us in our careers.

After all, the folks we work with are outside of our control. There is only one opponent that we know intimately, whose thoughts and attitudes are open to us.

Us. We. Me.

I am competing with myself. I am trying to improve, not compared to others, but to my former self. I want to be better than I was last week, last month, twenty years ago.

A Cautionary Tale

I was once firmly planted on the Ok plateau. I spent four years treading water at a development job where I didn’t do much to improve my skills or knowledge. I did my job, but not much more. The frightening part was that I thought I was good. Whether I was or not is almost immaterial. I didn’t see any need to learn new things or innovate at all in my daily job.

Then one day I was summoned to the owner’s office. I had not had two conversations with him since I’d started and now he was wanting to see me. Of course, I knew what was going to happen. This was a coach-wants-to-see-you-bring-your-playbook moment that I had joked about many times.

The company was in the midst of a rough patch and had to lay off a number of people, but they only laid off one developer: me. Looking back, it was a no-brainer for the company. I was getting paid a lot (for this company, anyway), I was not delivering value, and I didn’t even realize it. Buh bye.

That was my wake-up call.

What will it take for you to move off the Ok plateau?


Agree to Disagree

Do you know someone that disagrees with everything you or anyone else says? Some people are pathologically wired to push back. It makes no difference if it’s on a subject they know nothing about, they’re operating assumption is that everyone, and I mean everyone, is lying to them or has an ax to grind or is flat out stupid.

What do you do with such folk?

Promote them.

Invite them to every meeting. Keep them at all costs; these are the folks—and this is the type of thinking—that will make you better.

We’re not Leaving

I once worked for a Lieutenant Colonel in the Air Force who was our unit’s Director of Operations (DO). The DO in a unit is the chief operating officer, the one who ensures the unit accomplishes its mission. It is his hind end that’s on the line when things go south.

In his daily staff meeting, this particular DO would not make a decision until someone disagreed with him. He would say something like this: “If this is a dumb idea, I am going to look bad and will be very upset with the people in this room. So we’re not leaving until someone disagrees with me.” An awkward silence would ensue until someone timidly offered up some criticism. Then someone else. Soon there would be a full-blown, pros and cons discussion on the issue. Then the DO would decide. Many times he would stick with the original plan, but now he knew a couple of things. He knew how his staff really felt about the issue. And he also knew more ways that things could go wrong and how to mitigate the damage if it did.

This worked because the boss encouraged critical thinking and was not threatened by criticism.

The Science is So Sound

We want people to like us. We avoid conflict and disagreement. And sometimes we’re threatened by contrary opinions. It’s not intuitive, but we need people in our lives who disagree with us. What we need in many cases is that dissenting voice.

There are a couple of reasons this is a good thing

First of all, and maybe most obviously, is that if you and I agree on everything, one of us isn’t necessary. I mean, seriously. What’s the point?

Criticism helps us to improve our understanding. It forces us to confront ideas and concerns that never occur to us. It exposes our hidden assumptions and presuppositions.

Criticism also improves our creativity, especially if we are the critic in the scenario. Accordingly, Psychiatry Professor Robert Bilder says, “Be willing to be disagreeable. There is a negative correlation between the level of creativity and ‘agreeableness,’ so those who are the most disagreeable tend to be the most creative.” (Quoted by Barbara Oakley on page 50 of A Mind For Numbers.)

Finally, criticism can help the group be more productive. Barbara Oakley, creator of the massively popular Learning How To Learn Coursera course says this: “Those you study with should have, at least on occasion, an aggressively critical edge to them. Research on creativity in teams has shown that nonjudgmental, agreeable interactions are less productive than sessions where criticism is accepted and even solicited as part of the game.” A Mind for Numbers, pp. 236-7.

You Cannot Be Serious

Are you seriously suggesting, Ken, that we are better when we have naysaying, captious, negative people on board that oppose everything we want to do and have nary a good word to say about anyone?

As appealing as that sounds, no, that’s not what I’m saying. There’s a difference between being predisposed to push back because you are by nature skeptical and questioning, and being disagreeable because you have an ax to grind, you have serious personal or emotional issues, or you’re just a terrible person. Toxic people are normally intentionally toxic and are much to be avoided.

Beware of Toxic Agreement

What we don’t often think about is that “yes persons,” sycophantic yeasayers, can be toxic as well. If you are standing there naked while everyone around you fawns over your beautiful clothing (as in The Emperor’s New Clothes), you are a little, um, exposed. As a leader in this situation, you aren’t able to distinguish fantasy from reality. This is the very definition of a Fool’s Paradise. And it is precisely the situation my DO sought to avoid. And we would do well to avoid it too.

Ergo, don’t be afraid of pushback.

And don’t be afraid to push back. If you are an agreeable sort, then try a little disagreement on for size. A little skepticism can be a healthy thing!

Who knows? It might get your promoted!

Calendar with Deadline Circled

I Work Best Under Pressure

I work best under pressure.

Have you ever heard someone say that? I have. In fact, I’ve even said it.

What does it mean that someone works best under pressure?

A Dialog

Many times you hear those words when someone is trying to justify their lack of progress on a task. The deadline is looming and, from the supervisor’s standpoint, there has been precious little done.

For example, here’s a hypothetical conversation between a supervisor and a worker.

Super: How’s that TPS report coming along?

Worker: It’s going well.

Super: How far along are you?

Worker: Actually, I haven’t started it yet. But I know what it needs to say.

Super: You do realize it’s due on my desk by the end of the day.

Worker: Yep.

Super: I’m curious. You’ve had this assignment for two weeks. Why haven’t you started work on it?

Worker: That’s how I work. I do my best work under pressure.

(This is what the worker wants the super to say)

Super: Wow, that’s a relief. I’m so glad you have it under control. You really are amazing. I see that all those long lunches and all the times you came in late and left early have not affected the quality of your work. Carry on!

(This is what the super wants to say)

Super: How about I call security and have them escort you from the building? Would that be enough pressure for you?

(This is what the super says)

Super: Uh huh. Right. Just make sure the report is on my desk by five o’clock. For your sake, I hope it’s right.

No doubt the report will miraculously appear.

Will it be right?

Will it even be adequate?


It may be that the worker was being truthful in saying that he or she works best under pressure. Or maybe the worker had given it some thought and knew exactly what needed to be in the report and that it would not take very long.

Then again, maybe not. For a hundred different reasons, the report may be inadequate or incomplete. Data might not be available that the worker thought would be there. A personal or family emergency could have arisen just as they sat down to work on the report. Or the worker could have just underestimated the amount of work required to finish the job.

The most likely case is that the report will be adequate but will also be missing important data or observations the worker could have included but did not.

Why not?

To understand one reason why not, we need to take a side excursion into the fascinating world of human thought.

Diffuse Thinking

Psychologists have identified two modes of thinking in which the human brain engages, the focused mode and the diffuse mode.

Focused mode is just as the name implies—we are focused on a single task or concept. When we are concentrating on something we are in focused mode.

Diffuse mode is what happen when our attention wanders. Focused attention is tiring and we tend to allow other thoughts to intrude or our eyes to wander around the room.

You would think that focused thinking would be good and should be engaged in as much as possible, and that diffuse mode is bad and should be discouraged.

You would be wrong.

Experiments in cognitive science have revealed a most interesting thing—when we remove our attention from a difficult or complex task, our minds continue to grind away, subconsciously.  It is during this diffuse mode thinking that many of our most creative ideas occur.

This is actually not such a new concept. I have heard many people say “I get my best ideas in the shower” or “I like to take a walk and take my mind off the problem…then the answer comes to me.” This is just the diffuse mode in action.

The Danger of Procrastination

I am a world-class procrastinator, so this is not a diatribe against procrastination, and certainly not against procrastinators. There are many, well-known disadvantages to putting off the tasks we should be working on. It creates stress (pressure!). We are unable to enjoy free time because the task is always niggling at our consciences. The constant feeling that we have undone tasks is exhausting to us, mentally.

But I would say that the greatest danger in procrastination is that it denies us the opportunity to engage the diffuse mode. This robs us of our best ideas, our most creative observations, and the solutions to our most pressing problems.

Of course, we are not always given enough time to complete our tasks. We don’t have much choice If we’re given a short deadline, jump right on it, and finish it just in time without much time to set it aside and let diffuse mode crunch on it. (Supervisors would do well to take this into consideration when setting deadlines!)

More often than not, however, we are given enough time. We, if we are of the procrastinating sort, squander it.

Fast First Draft

What do we do, then? How do we work so that we bring our focused and diffuse modes both to bear on the problems we’re solving?

If we’re just being lazy or distracted, then the obvious answer is to get off our collective butt and get to work. Unfortunately, I’ve known too many good folks who are neither lazy nor distracted, and yet they experience the same issues with procrastination.

There’s a lot to be said about procrastination, but right now I have one suggestion that might be helpful. This is based on the observation that many people, including me, have trouble just getting off the starting line.

My suggestion is to create a fast first draft. This sounds like writing advice, and it is, but it applies to any project. Create a fast first design. Create a rapid prototype. Do something quickly. You may end up discarding this work, but it will do several things for you.

1.     It gets you moving.

2.     You feel a sense of relief and confidence that you’re actually doing something.

3.     It’s a concrete point of departure to lead you to what you really want to say/design/build.

4.     It gives you sufficient time to receive constructive feedback from stakeholders and allows you the time to engage in diffuse mode thinking.

Whenever I’ve executed a fast first draft, I’ve experienced much more success in my tasks than when I am tentative, not making a move until I’m absolutely sure it won’t be wasted effort. No one likes to waste effort, but if you knock something out quickly and then get feedback, the rework may actually be reduced. You will find out if your headed in the wrong direction before you get too far down the road.

Perhaps more importantly, you’ll give yourself some time to take a break from the project, allowing your mind to ruminate in diffuse mode.

It may also help you avoid awkward conversations with your supervisor.


Do You Ever Feel Like A Hack?

My son, who is a developer with a few years of experience, posed this question to me recently at breakfast. I could tell he was a little distraught.

My answer was, “All the time.” I don’t think this was much of an encouragement to him. I later relayed this story to a colleague of mine, a person I regard as one of the finest programmers I’ve ever known. His response was immediate: “All day every day.”

This seems odd to me. I don’t see such thinking in other professions. I’ve never had a plumber confess to me, “You know, I suppose my work is ok, but I just can’t shake this feeling that it’s crap, no pun intended.” Can you imagine a doctor saying that? Can you imagine a doctor even entertaining that notion?

Why do we feel this way?

What is a Hack?


I suppose the first question we should answer is, What is a hack?

I first heard the word used long ago, long before I knew what programming was, long before programming was available to the masses. A hack writer, for instance, is one who pumps out low-quality, short-deadline pieces just to make a buck. Although some famous writers (Anton Checkov, Arthur Koestler) were hacks early in their careers just to pay the bills, hacks are usually portrayed as mercenary, more devoted to income than art. In fact, according to Wikipedia, the term comes from hackney, which describes a horse that is easy to ride and available for hire.

I believe some of this carries over to the software development world, but not totally. In our case, the emphasis is not on making money as much as it is short-deadline work of questionable quality. We work quickly, sometimes at gunpoint, and aren’t happy at all with our work.

Where’s the Fire?


I believe part of the issue is that we are so used to rushing our work. There are a number of reasons for this—we are working to a completely unreasonable deadline (this happens in agile projects more than we are willing to admit), we are trying to keep up with the other devs on our team, and we sometimes feel like imposters so we push our work through.

Whatever the reason, we rush. We pull a story, give it a cursory read, create a feature branch, and start coding. We tack on a unit test at the end and submit a pull request. Then it’s on to the next story.

When we do this, several things happen. The code review elicits numerous comments, further cementing in our mind that we’re just not very good. Testing reveals a plethora of defects, with the same effect. We actually slow the process down because of all the rework.

Probably the most devastating of the results of hurrying through our work is that we accumulate a mountain of tech debt. Just as a credit card is a short-cut to accumulating things without going through the hard discipline of saving for them, rushing to finish our story causes us to pursue low-quality solutions in the name of expediency. We don’t refactor our code, so we have methods that are hundreds of lines long with an unfathomable number of dependencies, making them almost impossible to test. The result is brittle code with inadequate testing. Our confidence is almost zero that we can make changes without breaking something.

All this adds up to a tech debt invoice that will eventually come due and we will not have the funds to pay it back. Eventually, we must declare bankruptcy and start over with a very low credit score. Low as in zero.

What Do We Do?

That depends on how serious we think the problem is. Is it really this bad?

Sometimes. I’ve painted a pretty dark picture that isn’t entirely true or fair. Whether the landscape is as bleak as what I’ve described or not, I think we feel that we could and should be better. And I know from experience on some projects that I’m actually understating the case.

On the other hand, we’ve all worked on projects that were not disasters.

Regardless, there are some things I’ve noticed in the way I work and in the way that many of the teams I’ve been part of work that contribute to our angst. Here’s a list that is neither comprehensive nor exhaustive, but it’s a good place to start. I’ll be elaborating on them in subsequent articles.

  1. We don’t design. We start coding immediately. We need to step back and try to understand what we’re doing and consider how best to accomplish it. This takes some time.
  2. We don’t collaborate. We talk a lot about teams and say we value collaboration, but we still don’t like to pair. Designs should be a team activity and even if we refuse to pair when we’re coding, we’d better collaborate with one or two team members when we’re designing. We avoid insurmountable problems and massive rework when we talk things through and explore options with our teammates.
  3. We hurry. This may be the root cause. We feel time pressure even when there’s no deadline. This is good—we shouldn’t dawdle. But if we rush just to get something out the door and pull our story across the board, the story will just get blocked because of the defects and rework. In the words of UCLA basketball coach John Wooden, “Work quickly, but don’t hurry.”
    We don’t write tests. This may be the most efficient remedy. Unit tests make us reason about our code and figure out way things could go wrong. Well-written tests expose design flaws and suggest solutions.

    Tired of Writing Crap

    The biggest thing we can do to improve our code is to realize it ain’t so great. A healthy discontent with the situation will lead you to make changes. In an excellent rant on the Clean Coder Blog, Robert Martin put’s it very succinctly:
We are tired of writing crap.

That, according to Uncle Bob, is the motivation behind the Software Craftsmanship movement.

That will be the motivation behind your metamorphosis as a developer.


So Happy Together

Bobby Knight. You either love him or hate him. I’m from Indiana, so I love him. But that doesn’t mean I don’t recognize his significant shortcomings. To call him a flawed hero is an understatement.

There’s one thing that is beyond dispute, however. Bobby Knight valued team play above individual achievement. He naturally recruited highly talented players, but what he looked for more than anything else were players who would put the team above their own ambitions. More than once he led an undertalented team that was high in discipline and teamwork deep into the NCAA tournament.

We need to learn a lesson from The General.

We’re better together than we are by ourselves. Period.

Software development is a team sport. Period.

Beware A Guy In A Room

I once heard a talk at a conference by a Microsoft manager who admonished us as development team members, “Beware of a guy in a room!” What he was talking about is the lone wolf programmer who sequesters himself or herself to work on a key part of the project and either emerges six months later with a solution incompatible with the rest of the system, or never emerges at all. Sometimes he leaves the company and the team doesn’t find out until weeks later. Ok, I made that last part up, but I always wondered if that ever happened.

This sounds ridiculous, but anyone who has read The Phoenix Project knows what a ‘Brent’ is. In the story, a high-profile software project dragged on for years partially because one of the key developers, Brent, was at the beck and call of every manager in the company and spent 100% of his time fighting fires. He had become indispensable. This wreaked havoc across the entire enterprise. One of the major turning points in the book was when Brent was freed up to work on the Phoenix Project.

We’re All Brents

The truth is that we’re all Brents. We may or may not want to be indispensable—seems like too much work to me. But even if we don’t, our attitude is frequently like the surly partner in every buddy movie you’ve ever seen: “I work alone.”

Of course, we say the right things in an interview. We love working in teams. We’re equally comfortable on a team or as an individual contributor. We’re real team players.

What we really want is to be given some work and to be left alone to do it. We think pairing is a waste of time, collaboration is overrated, and we’d be better off with the minimum amount of interaction with others so we can “get stuff done.”

We can’t admit this, of course, because we’re agile and if people knew what we really thought, we’d have to put up with a constant stream of chatter aimed at persuading us of the error of our ways.

It’s Complicated

Of course, I’ve overstated the case and erected bit of a straw person here. Many of us do like working on teams and aren’t being deceitful in interview. We are team players.

But we’re also techies. We weren’t drawn to extroverted jobs like recruiting or sales. We like wrestling with technical issues and solving hard problems. We enjoy heads down, focused work that produces a satisfying solution.

What complicates this further is that we feel like we’re not evaluated on our team skills, but on our individual technical skills. When stories move across the board and eventually into the “Done” column, my name is on the story, not the folks I collaborated with.

You Might Be A Brent If…

There’s no easy answer to this tension we feel between individual and team contribution. You may be in a situation where you are the only developer on the team, or even in the entire organization, so you better be able to work alone.

In today’s climate, however, it’s more likely you’re part of a team. In that case, how do I know if I’m being a Brent?

Here are some indicators:

  1. You refuse or prefer not to pair.
  2. When you do pair and you’re the one on the keyboard, you just start typing away without communicating with your partner at all.
  3. When you pair and your partner is on the keyboard, you are impatient with your partner and eventually just take the keyboard away from them.
  4. You think story refinement is an interruption to your workflow rather than an integral part of it.
  5. You don’t participate in retros, or you give such little thought to what went well, what went poorly, and what the team could improve upon that you can’t give meaningful input.
  6. When you’re assigned a story, you create a feature branch, pull up your IDE, and start typing. Little or no thought is given to design, and you don’t ask another developer to walk through what you should do with you. Sometimes you don’t even read the acceptance criteria.

Lest you think I’m being unfair or overly harsh, these are just a sampling of the sins I have committed over time and that I struggle with.

What Now?

What do we do now? How do I become a better team player?

The easy answer is to look at the list of indicators above and don’t do those things. The problem is, this list is neither comprehensive nor can I claim it is representative of what all developers face. It’s just a list of my major neuroses.

What I can say is to give it some reflection and see where you might be falling short as a team member. And talk to your team. If you can’t talk to your team, that’s probably an indicator in itself.

Finally, here’s an aphorism I’ve heard in several different contexts, but it applies here very well:

If you want to go fast, travel alone.

If you want to go far, travel together.

harder, not smarter

Work Harder, Not Smarter

I know, I know. You’re thinking, “Don’t you have that backwards, Ken?” Shouldn’t you be telling me to “work smarter, not harder”?

I get it. One of the most cherished business clichés on our Cherished Business Cliché List is, “Work smarter, not harder.” Hardly a week goes by in which we do not encounter this aphorism in one form or another.

I would have to say that in most situations, this is sage advice. Cliché’s may be tiresome, but they normally contain a kernel of truth in them. If we can do something more efficiently with the same or better return for our effort, then that is indeed working smarter. Of course, whether we follow this advice in any given situation is another question altogether. But it’s still something worth striving for.

The problem occurs when we try to work smarter on things that require more effort and time to realize a return.

Like learning, for instance.


Here’s a news flash. Thinking is hard. This explains why people avoid it. I’m as guilty as anyone, if not even more so. I remember my dad admonishing me on more than one occasion with a single-word command: “Think!”

Like most people, I want things to be easy. I suppose there’s no virtue in making things more difficult than they need to be, but even when simplified and “easified”, most of the things we encounter in life just don’t go very smoothly.

Learning is no exception. We marvel at people that are adept at picking things up, that seem to acquire knowledge in the same way most of us acquire extra pounds over the holidays: effortlessly. We look at those folks and think, “Why not me?”

It’s especially frustrating because many of us (guilty!) remember things that are of no importance whatsoever. I can quote movies that I saw when I was a child, I can recall stupid comments I and my brothers made 50 years ago, but I can’t remember basic syntax in languages I’ve used for years. It is most frustrating.

We try to alleviate our frustration by searching for a magic formula, a process that will enable us to learn in our sleep, or at least make things easier than they are. We read blog posts, we watch videos, we listen to recordings. We try to figure out “how we learn.” If we decide we’re visual learners we abandon reading to exclusively watch videos. Maybe we hate reading anyway, so this works out perfectly. Or we’re auditory learners, so we focus on listening to audio books.

Play Fetch

This is where I deliver bad news.

There is no way to make learning easy. There is no 5-step process I can give you that will suddenly make you able to effortlessly remember what you study.

If you want to recall what you’ve learned, then you’ll need to…um…recall it.

You’ll need to play fetch.

What experiments by cognitive psychologists have shown, in hundreds of studies across a diverse spectrum of subjects, is that the most effective thing you can do to remember information is to practice recalling it from memory.

This is more effective than reading the same text over and over again. It’s more effective than underlining and highlighting as you read. It’s more effective than going over and over your notes.

It’s more effective than anything else you can do.

I know. Not what you wanted to hear. We want it to be easy. We want to avoid the mental exertion of thinking. It’s just too hard.


What Now

Once we’re done whining, we might wonder to ourselves, “How do I apply this?”

Here are a couple of things you might try the next time you attempt to learn something new (or relearn something you once knew):

  • When you are in a class or at a conference, take notes during class. Then, after the class or presentation, sit in a quiet spot, pull out a blank sheet of paper, and jot down, from memory (no peeking at your notes!), the important points that the speaker made. See if you can reconstruct the argument or list all the main points. Try to remember minor points that the speaker thought were particularly important. Don’t give up when your mind goes blank. Push yourself to remember. When the well finally does go dry, compare what you’ve written with your notes and fill in any blanks.Revisit your notes after a day or two and perform the same exercise. Do not just read your notes. This has been shown to be virtually useless. Recall first, then check your notes to see what you’re leaving out.
  • When you’re reading an article or a text, stop after every section, cover the paper up, and try to remember what you just read. As in number 1, put some real effort into it. After you run out of thoughts, return the section and highlight (or underline) the points that you remembered. Also note important points that you failed to remember.This is going to slow your reading down considerably. Who cares? Is it more important to learn the material or plough through some number of words? If it’s just pleasure reading, by all means, let ‘er rip. But if you are learning as part of deliberate practice, i.e., as part of a program to become better at your profession or some craft, then the time invested is more than worth it.

If you do this once or twice, you probably won’t notice much difference. It’s only as you purposefully apply recall to your learning for a period of time that you notice your retention improving.

No Royal Road

The ancient Greek mathematician, Euclid, is famous for developing the system of geometry we refer to as plane geometry or, in his honor, Euclidean. Working in the third century BCE, he wrote his Elements, one of the most influential books in all of history, a monumental work that has endured to the present day. He lived in Alexandria, and so drew the attention of the ruler, Ptolemy I, who was fascinated by this new area of knowledge, but was daunted by the sheer volume of learning it entailed. He famously wrote to Euclid, asking if there was some short-cut he could take to acquire knowledge of geometry. Euclid’s reply is equally famous:

There is no royal road to geometry.

What Euclid told the king about geometry applies equally to learning in general:

There is no royal road to learning.

It takes effort, and the worst kind of mental effort: recalling from memory without notes or prompts. And this effort is not just an unfortunate byproduct of the process. It’s what makes learning stick.

You’ll be working harder, but you’ll be getting smarter!

books and pencil

Always Be Learning

In a wonderfully uncomfortable scene in the 1992 movie Glengarry Glen Ross, a hotshot salesman from company headquarters played by Alec Baldwin delivers the news to the salesmen at a New York City real estate office that two of their number will still have a job by the end of the week. The remaining three or four will be sacked. Who will keep their jobs? The top two in sales, of course. Dollars through the door. Closed deals. Those are the metrics.

In the climax of the scene, Baldwin writes three letters on a chalkboard: ABC. He then delivers the key to the real estate business and, one suspects, the key to all of life. Always Be Closing. If you aren’t closing, you aren’t selling. If you aren’t selling, you’re not going to have a job at the end of the week.

In this post I’m Alec Baldwin. Hopefully not as mean or arrogant. I could be, I suppose, but I hope not.

No, my message to you, while not as catchy as ABC is ABL: Always Be Learning.

What are you learning?

I am currently helping to run a local developer meetup and at the beginning of each meeting, I ask the question: What are you learning?

It’s an important question, one we need to ask ourselves and each other with some regularity. It’s important in general because as human beings, learning is almost synonymous with growth. If our learning stops, then we stagnate as people. We are never exposed to new ideas, our own entrenched beliefs are never challenged, and we become one-dimensional and boring. And in our culture, boring is the unpardonable sin.

More importantly for our purposes here, it’s vital for our careers as technologists and software developers. In fact, I would argue that continual learning is the single most important thing you can do to advance in your career.

But What About Actually Doing Something?

But Ken, always learning implies you’re never actually doing the work. You don’t get paid to learn. You get paid to code.

Good point. Let’s ponder that.

What does it mean to do the work? If you can answer that question, that means you know something. If you know it, that means, without fail, you learned it at some point. None of us is born with the knowledge to create a REST api or write a left outer join in SQL. I realize there are those that walk among you, whose keyboard you are not worthy to touch, that seem to just know everything. They pick up new skills or make logical connections so quickly that it seems there was never a time when they didn’t know what they know.

But that’s just silly. Of course, even the best and the brightest had to learn exactly what you need to learn.

Moreover, what we are able to do is limited by what we know. If you want to do more, then you must learn more.

Does This Mean I Must Know Everything Before I Can Do Anything?

Not at all. Fortunately, we learn best when we learn a little and then apply it. Then learn a little more, then apply that bit. It can actually be an impediment to learn too much up front about any particular skill.

This is one of my greatest weaknesses. I tend to think I need to know how a watch works before I can use one. I’m always better off learning enough to get going, trying it out, then going back and filling in the gaps in my knowledge. In this scenario, practice and theory advance together, not in lock-step by any means, but in general.

There Is No Substitute For Understanding

The goal, of course, is understanding. There is absolutely no substitute for understanding. Without understanding we do things without knowing why, and when something goes wrong…and something always goes wrong…we cannot figure it out. Stack Overflow, here we come.

And we’ve all had the experience of making a change in our code that ‘fixed’ a problem, but we don’t know why. Is it really fixed? Maybe. But then again…

To be fair, much of what we need to know and understand is arcane and beyond our understanding. Whenever we use a new third-party library, for example, we always come in with preconceived notions of how it should work, based on our past experience and on our understanding of its functionality. And we are invariably not just wrong, but not even close.

The insidious thing is that we can become quite proficient using technologies we don’t understand, and this creates an illusion in our minds that we actually get it. Psychologists have discovered a tendency among us humanoid bipeds called the fluency trap. When we first read a passage on something new or complex, we don’t understand much. If we reread the passage, we feel like we get a little more, until after a third or fourth reading we feel as if we understand it pretty well.

Many times, it’s a lie. We don’t really understand the concepts, we are just more familiar with the words and vocabulary used. Want proof? How many times have your read something over and over again, convinced yourself that you understood the material, and then babbled like an idiot when you tried to explain it to someone? Guilty, many times over.

By the way, this is why when studying for a test, reading and re-reading the text is not a good practice. We feel we know material that we don’t really understand. This applies to college classes and in studying for a certification exam or an entrance exam. There are better ways, but that’s for a later article.

Learn Together

One of the most effective things you can do to enhance your learning and gain better understanding of what you study is to do it with another person, or a group of other persons. We are better together when it comes to developing software, and we are also better together when it comes to learning something.

This is not a new concept. Many of us joined study groups in school to prepare for tests. We often form groups around certification exams. Even when we gather around the proverbial water cooler and discuss esoteric technical topics of great import, there is something magical about the confluence of ideas that can develop. We learn from one another. We know that.

What I’m suggesting here is that group learning should be a part of your regular cadence of career development.

The ideal is to find such a group and meet together regularly, say, once a week. For most, if not all, folks, this is impractical. A monthly meetup, though, would be a great second choice You get to meet new folks, you get to hear about some topic or perform some exercise, and there is usually pizza! Win, win, win!

Apply yourself

We’ve wandered a bit, but I hope you see that it’s important to Always Be Learning. Learning itself is not the goal. Understanding is what we strive for and what will drive our careers forward. Armed with understanding, we can not only do the work, but we can solve problems, create innovative solutions, and mentor others to do the same.

You will be the coveted unicorn.


What’s In It For Me?

Want to move forward in your career?

Want to be upwardly mobile in the software development ecosystem?

What to know one of the most effective ways to climb the career ladder?

Help someone else out with their career.

This is not intuitive. Since, on most days, I’m the only one inside my head, it’s natural for me to focus on myself and do what’s best for me.

The paradox is that often, many times–ok, almost always, what’s best for me is to take the spotlight off of my own funky bad self and train it on those around me, especially people that I can help in some way. Particularly in the software biz, where teams are highly valued and culture-fit is of primary importance, it’s imperative that we build into one another.

There is an infinite number of ways we can help other developers learn and grow. Speak at meetups, user groups, and conferences. Conduct hackathons and katas. Start a book club and read technical books together. Tutor college and high-school students. Write a blog. Create videos. You can probably think of other ways.

The truth is, finding ways to help people is not the issue. The issue is truly understanding that as you build into others, your career benefits as well. In fact, it’s one of the most effective things you can do as part of your career trajectory. As motivational maven Zig Ziglar put it, “You can have everything in life you want, if you will just help enough other people get what they want.”

So if you care about your career, start caring about others as well.

What’s In It For Me?

I’m not quite there, Ken. Sounds like a mess of self-help mumbo-jumbo to me.

Fair enough. I said earlier it’s not intuitive. So here are some thoughts on how we help our own careers as we build into others.

  • Helping others broadens your perspective. When we work with others for the express purpose of helping them learn and improve, we quickly realize that their education, background, and experience are radically different from ours. We are exposed to different ways of thinking. This broadens our perspective and many times challenges us in ways we don’t, and in fact can’t, anticipate. This often exposes areas of weakness that had hitherto escaped our notice.
  • Helping others deepens your understanding. Helping other learn helps us learn. It is proverbial that if you really want to learn something, teach it to someone else. When we explain something to another person, our knowledge and skill gaps are painfully exposed, driving us to learn more and develop our understanding.
  • Helping others increases your value. Building into others increases your value to your employer and to potential employers. As you build into others, you will naturally become more knowledgeable and technically competent. You will also develop the soft skills that employers covet in their teams.
  • Helping others strengthens your network.We strengthen our network, in both breadth and depth, when we help others. The more developers we know and help, the greater the chance we will be mentoring a future colleague. Or maybe the next Bill Gates. And if the next Bill Gates ever thinks back on me, I want them to be kind, generous thoughts.
  • Helping others is its own reward. It just feels good. Even if there were no other benefits to serving the community, we would still be obligated to help one another. It’s the right thing to do. And we feel an inexplicable joy when we help someone, and that is reward enough. In fact, if it’s not enough, we’re not really helping them; we’re using them.

Guarding the Guild

We are members of a profession. We are also members of a guild. Guilds are associations of trades people organized to establish standards of excellent work and help their members deliver work that meets these standards. While not a formal organization, good developers recognize that it benefits everyone—stakeholders, manager, techies, society in general—when developers follow good practice and deliver great systems.

This is another powerful reason to build into one another. We need to guard the guild. Just as an army drill instructor looks on recruits as those with whom he or she may have to depend on in a firefight, so we need to prepare our fellow developers for the battle. We don’t know with whom we will someday share a foxhole.

So do yourself a favor. Forget about your career once in a while and help someone else with theirs.


Getting Your Career In Shape

There are few things more important to your health and welfare than keeping yourself in good physical shape. It’s a struggle for many of us (me), but in my experience, the times that I have been most disciplined in diet and exercise have been the most healthful.

Similarly, you need to get in shape and stay in shape, career-wise. You’ll find that your confidence and performance will skyrocket as you exercise yourself to build your career.

This post is about getting your career in shape.


What in the wide, wide, world of sports does that mean?

Before we talk about T-shaped skills, let’s back up for a moment.

We’ve talked before about taking control of your career. If you’re going to advance in your career, you must own it. It’s your career. Not your boss’s. Not your employer’s. Yours.

How, exactly, can I take ownership of my career? What should I be doing?

In other words, what should I be doing to build my career?

The obvious place to start is my own skills and knowledge.

Learn something new

In fact, learn lots of new things. Never stop learning. And there are more resources available to us now than any one person could possibly use. We experience an embarrassment of riches in the tech world and if you’re not taking advantage of it, shame on you!

There’s Udemy, Pluralsight,, Coursera, YouTube channels, TEDx, and probably a dozen more that I’ve never heard of that offer affordable training in every conceivable programming language, framework, and technology.

There are meetups and user groups that many times offer presentations on current technologies.

There are professional organizations like the Association of Computing Machinery (ACM) and the IEEE Computer Society that offer webinars, books, and access to complete archives of journal articles. The ACM Digital Library is a treasure trove of classic papers in computer science. Membership can be a little pricey, but many employers reimburse membership fees for professional organizations.

If you’re old-school, like me (actually, I’m just old), you like physical books. There are plenty of them available, from good to great. Tech books are expensive, so choose wisely, and buy used.

The T-Shaped Skillset

In a 2010 interview, IDEO CEO Tim Brown put forth the idea of a ‘T-shaped’ person, contrasting it with an ‘I-shaped’ person.

“T-shaped people have two kinds of characteristics, hence the use of the letter “T” to describe them. The vertical stroke of the “T” is a depth of skill that allows them to contribute to the creative process. That can be from any number of different fields: an industrial designer, an architect, a social scientist, a business specialist or a mechanical engineer. The horizontal stroke of the “T” is the disposition for collaboration across disciplines. It is composed of two things. First, empathy. It’s important because it allows people to imagine the problem from another perspective—to stand in somebody else’s shoes. Second, they tend to get very enthusiastic about other people’s disciplines, to the point that they may actually start to practice them. T-shaped people have both depth and breadth in their skills.”

An I-shaped person, on the other hand, is one with an expert-level depth of knowledge and skill but lacks breadth in collaborative skills and curiosity about other disciplines.

Why is this important? Why can’t I just learn my job, hone my skills, and get better at what the company pays me to do? Isn’t there something to be said for heads down, hands on keyboard, “just do the work” thinking?

Of course there is. The work has to get done.

However, just depth of knowledge and expertise is not enough.

The reason for this is that in recent years, we’ve come to understand that it is not expert individuals that deliver the most value. It is highly collaborative teams that are doing the greatest work and delivering the value the company requires.

The horizontal stroke on the T represents a breadth of knowledge, not only of technical areas not directly related to your particular skill set, but areas of human understanding. The quality Tim Brown focused on was empathy. If you are on team and the members have no empathy for others, your collaboration will be limited. The members will not see other people’s points of view, will not be willing to adjust their own beliefs and opinions based on evidence, and the team will devolve into power struggles and politics. Not that I’ve ever been there.

Empathy is just one important example. Others include listening skills, knowing how to speak to folks without making them feel stupid, basic cognitive psychology, emotional intelligence, and a host of others. These are sometimes pejoratively referred to as “soft” skills, but they have become increasingly important in recent years. In fact, many places value your ability to fit into the culture and your prospective team at the same level, if not higher than your technical ability.

How does one become T-shaped?

The answer is easy, the execution is hard—by definition.

It takes effort, just like everything worth having does. We get better at the things into which we put effort. And not just effort, but purposeful effort. We try to get better.

This is not news.

The important thing to realize, though, is that it’s not enough to be a technical wizard. In today’s team-oriented environment, the folks who thrive are the ones that can do the job and don’t make their co-workers want to jump off a bridge. Or push them off.

I realize this does not answer the original question, “What should I be learning?” But you shouldn’t answer that question before answering the question, “What shape is your skill set?” If you fall short on the ‘breadth’ of knowledge area, then maybe you should shore that up.

Your T-shaped co-workers will thank you, and your company will reward you!