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?

Screen Shot 2021-04-07 at 10.36.40 AM

From Coder to Professional Developer

Whether you just finished a bootcamp, graduated from college with a computer engineering degree, or maybe even have a few years under your belt it’s hard to progress from your first job as a coder to a full-fledged career as a developer. You will need to spend time on both improving soft skills as well as technical skills. Short changing either of these won’t produce the long-term career goals that you are shooting for. Here are a few traits I’ve seen that ease this transition.

Be Passionate

If you landed in tech because you saw a salary guide and thought that’s my ticket to the big time, then I wish you the best of luck. On a cautionary note, this will require either finding the right company that needs legacy skills while somehow staying afloat, or diligence on your part in staying up to date in an ever changing technology landscape

If, however, you love being challenged and get joy after cleverly solving a difficult problem, then all that is left is to put in the time and dedication to learning, growing, and accepting new challenges. Having passion makes it easier to invest the time and energy necessary to keep your skills current each and every year.

Focus on Teamwork

Development appears to be a solo activity, because it usually starts out that way for most of us.  It rarely if ever turns out that way. If you are looking to be left alone in the corner coding all day you are limiting your usefulness to the company, and despite being irreplaceable you will be replaced. 

You should want to be part of a team so that you can learn from others. Your peers will help you improve your craft, and one day you can repay the favor to other up and coming developers. Some things you should learn from your peers are coding standards, how code is organized, coding techniques, and how things are done in this company’s view of the real world*. 

Without team collaboration and mentors your growth will quickly plateau regardless of your talent.

Check Your Ego at the Door

You now have training behind you, and have developed some level of competency and confidence in your abilities using a particular tech stack. How do you go about showing what you are capable of? 

What work is beneath your talent and skills? None, full stop.

Charlie,  that’s easy for you to say now that you have years of experience. Are you just trying to get out of doing the boring work? 

No definitely not. Let me meander through a recent project, where I was in similar shoes. In my case it was a construction project. While I’m competent with hand tools and power tools this project was out of my comfort zone. Luckily, I had access to a few professionals that could not only do the work, but they could show me how to do some of the work. 

There were parts of the project I couldn’t do because I didn’t have the requisite experience, and more importantly because I couldn’t see the whole picture. Left to my own devices I may have tried to drywall before all the plumbing had been fully connected. More than likely I would have at least forgotten to test the plumbing for leaks. Sure, I may have eventually gotten there, but it would have been costly, time consuming, and infinitely more frustrating.

What was I able to bring to this project without getting in the way too much? 

  • Keep the area clean and organized
  • Ensure there was breakfast, lunch, drinks, and snacks available
  • Coordinate schedules
  • Pickup building materials and tools from the store
  • Basic drywall measuring, cutting, installing, and finishing
  • Painting, caulking, and trim work

I could have left all of that up to the professionals too, but I learned a lot along the way, got the project done quicker, and took some of the load off the professionals. I now have more confidence if I was ever stupid enough to do another similar project. 

But what’s that got to do with you being a better developer? Are you ready to build a whole application by yourself that actual users will use, and more importantly expect to work consistently? Will you remember to test the plumbing before installing and finishing the drywall? What is the definition of a rhetorical question?

Here is my take on what you should bring to a project early on in your career

Follow Team Processes

Do what the team asks of you. Try to understand what the processes are trying to accomplish. If you don’t understand, ask. It may be that it used to solve a problem, and your team no longer experiences that problem due to other mitigating processes or team maturity. File the processes that work away for later projects. For that matter, file the ones that don’t work away so you can avoid them in the future.

Code Reviews

Review existing code in the application to understand the various components and technologies in use. This could be part of a formal code review process, or after the fact. Spend a little time doing this every day. Gather questions about code you don’t fully understand, and periodically ask your teammates.


Quality is not just for testers anymore. While testing may also be the primary focus of a specific role on the team, it is a whole team sport. 

You are responsible for the quality of the application, so what can you do to improve it?  First be open to participating in all aspects of testing. This could range from writing unit tests, to testing features that were  deployed to a server for the first time, to testing a feature another developer wrote, to ensuring the UI is consistent, to ad-hoc exploratory testing. 

You need to know how your application actually works to know how best to add functionality and fix bugs without introducing new bugs. 

Second, work directly with the testers to understand their role and techniques. Have discussions early and often about how they are going to test your code, and any other expectations they have for the code you are writing.

Quality benefits from the team’s collective perspectives, so please bring your perspective to the table to build stable and useful software.

Learn the Business

Pay attention in meetings to better understand the business context. Understand the terms the business uses and create a dictionary of terms, acronyms, etc. to better engage with your business partners. You need to understand what the business is saying in order to build a solution that solves their problems. Development teams should adopt the same consistent terminology in their code so you don’t need a special decoder ring to talk to the business.

Use your understanding of the business context when creating or refining stories, reviewing code, and testing.

Small Features

Start out with small features that only take mimicking existing code. Ideally this would be across the full stack so you get understanding of the structure of code. This puts some of what you learned in Code Reviews into practice and may highlight subtle nuances of the code you need to work through to fully digest.

Be Adaptable

Be willing to try to stretch into different roles or technologies if it benefits the team. If you are only familiar with JavaScript but your back end application is written in C#, then learn about C# until you can at least read and understand it.

Find People to Learn From and With

Several times in my career I’ve gotten stuck. There is only so much you can learn in a vacuum. The solution every time was to surround myself with other people. These people ideally have differing opinions, background, and experiences than you. This was especially effective when I found people that were willing and able to build into me. 

One place I was able to find people like this was at user groups and conferences. Getting involved helped to get a different perspective outside the bounds of my day job. I learned about tech and processes that my company wasn’t using, yet. For example, I was working in a waterfall enterprise and learned about Agile through these interactions. I was able to challenge the status-quo with data from the larger industry, and start to make small inroads into shifting methodologies. 

The other big benefit of participating in these groups was networking. Please don’t be scared of networking in this context. It’s just nerdy passionate people having conversations. These other people also gave up their Tuesday night to come learn the basics of Web Assembly too. What’s scary about that? Yes, it might be a bit frightening at first to put yourself out there in a sea of unfamiliar faces, but in no time, at least in Cincinnati’s tech scene, you will know the people that come regularly.

After getting involved and forming friendships I realized that I had a much broader pool of knowledgeable friends that I could tap into by simply asking for help. More important to this discussion, it has helped me land me several job prospects and offers throughout my career. 

When you get stuck in your career search out those that can give you perspective or guidance. 

Wrapping It Up

A successful path is one marked by passion, a drive to continually learn, a willingness to stretch, and finding other like minded people. Yes, it really is that simple and yet somehow that complex too. 

With the exponential growth of tech out there, be humble knowing that you don’t know everything, be willing to admit that, and be curious to find the next thing you need to learn.


* The real world will look vastly different from company to company, and none of these should be taken blindly as best practices