Skip to content

Blog

Expert Programming Is Not Knowing Everything

06.29.2023 | Expert Programming | Reginald NeoWilliams
Expert Programming Is Not Knowing Everything

 

There is a common misconception that expert software engineers know exactly how to solve every problem they face. That they simply sit down in front of a computer, open a notepad or terminal, and write perfect code. In my observations over my nine years in the field, this is simply not the case. Instead, expert software engineers know how to find solutions and use their tools effectively. In fact, an effective programmer’s most valuable skill is knowing how to find answers.

One of the first questions I ask myself when facing a programming problem is “Do I know how to do this?” I’ve found that my answer tends to fall into one of the following five categories:

  1. I don’t even know how to google that
  2. I know what to google to learn how to do that
  3. I know parts of how to do that and how to google the rest
  4. I know how to do that but I need an IDE to help me
  5. I know exactly how to do that without tools or help

These categories do not apply to the programmer as a person, but specifically to the current problem that the programmer is trying to solve. Let’s look at each one in more depth.


1. I don’t even know how to google that

When I was a new programmer, nearly everything fell into this category. I know that finding answers is the most valuable skill a person can have, so the more years I spend developing my craft, the better I am at knowing what to Google. As a result, not seeing a starting point is a problem I face less and less frequently. My current most common experience of this is when I encounter some error and cannot find helpful results. In that case, I actually do know how to Google the error, but it is too domain-specific for Google to be useful, or I’m just not able to find the right keywords to get to an answer that works for my specific case, or it isn’t a solved problem. I wrote a previous post about the journey my pair and I went on when we encountered a problem and could not find a solution anywhere on the internet. Even when we find ourselves not knowing where to start, all hope is not lost! Asking others for help, starting with teammates or peers, is a great first step. This is why pair programming and seeing programming as a social endeavor is so helpful. Even using an AI tool can be a great way to get started.

2. I know what to google to learn how to do that

The vast majority of programmers can be effective by reaching just this level for about half of the tasks they need to do. When a programmer finds themselves landing here more often than not, they have started to be an expert on finding answers. Once I became comfortable with programming concepts, most problems started to fall into this category. This was my level when I first wrote a bot for the chat client Discord. I knew enough to find tutorials on how to get started, and when I had something functional, I knew how to search for implementation for specific features. I was working in node.js, which I had not touched previously, so while I had a good idea of how to find solutions, I didn’t have any that I knew. Another example of a problem that falls into this category is facing a common but unfamiliar exception, such as when I was doing dependency upgrades in Java and ran into a NoClassDefFoundError for the first time. I googled the error, read through a few Stack Overflow answers, and tried those suggestions. In a pretty short amount of time, I found myself with working code and an understanding of the error. Like with machine learning, the more patterns we see, the better our data set, and the easier pattern matching becomes. It might seem like a developer who approaches problems by googling and reading Stack Overflow answers doesn’t know what they are doing, but it is the primary strategy most of us use to avoid reinventing the wheel.

3. I know parts of how to do that and how to google the rest

When someone can categorize about ¾ of the tasks they face here, they are an expert software engineer, because they know a great deal and can easily find out what they do not know. With nine years of experience programming professionally, roughly ninety percent of my work falls into this category if I’m working solo. Some work ends up being in this category when an error pops up unexpectedly. Most commonly, this is just any task, such as adding a new feature or fixing a bug, where I have a good idea of how to start but know that there are aspects along the way that I’ll have to look up.

4. I know how to do that but I need an IDE to help me

This is much closer to what most would consider expertise, and expert software engineers do find themselves here for most of their common tasks. When combining my knowledge with another in paired programming, about eighty percent of small tasks fall into this category, and many larger tasks as well. For me, with my current level of experience, any code changes needed in a familiar code base tend to be here or in the previous category, with rare exceptions. The difference between this category and the previous one is that in this category, the things that need to be looked up are syntax or exact method names, things that can be found easily using a good integrated development environment such as IntelliJ. For instance, I frequently use my IDE to see what methods are available on an object instead of looking up documentation or to remind myself what the method to convert to string is in the language I’m currently using.

5. I know exactly how to do that without tools or help

This category only deserves a place on the list to talk about how rare it really is. I think those outside the field, or even very new to the field, think that a high percentage of programming tasks fall into this category for a high percentage of programmers. In my experience, this is just not true. It probably used to be, back when there was no such thing as a program that existed to help people write code. I’m sure people had to know exactly how to write their code to this level of precision when compilers were people punching holes in cards instead of automated programs. Nowadays, it simply isn’t a necessary skill for the vast majority of the time. Most of us with a few years of experience can think of something we can do that falls into this category, but it isn’t a skill we focus on maintaining because mastery is not memorization. Having this level of expertise for one solution isn’t a very valuable skill, because it is not widely applicable - that solution can only solve certain problems.

As mentioned above, these categories are not overall levels of skill for a person, but individual levels of difficulty for a task. Most programmers will reach the middle categories (2, 3, or 4) for the vast majority of their work. The same person has different skill levels for the same task in different languages. I have a skill level of 5 for Hello World in Java, but a skill level of 2 for Hello World in Ruby, because I’ve never worked with Ruby before. It’ll take more time and effort for me to solve the same problem in a new language even if I know exactly how to solve it in a familiar language, but I can do it by utilizing my skill of knowing how to find out.

This list is a helpful teaching tool when mentoring a newer developer, particularly when they think they must achieve complete memorized mastery of programming. It is also important information for a manager who expects their employees to be able to program without google. This list shows that even professionals who have been in the field for years still have more to learn and still look things up constantly. It is reasonable to expect an expert to be an expert, but particularly for the ever-changing field of programming, expertise does not mean knowing exactly how to do everything. It means knowing how to use all available resources to find an excellent solution to any given problem. Importantly, it also means understanding that solution instead of simply copying and pasting, but that’s another discussion!

Focused Labs has continuous learning as one of our three core values for exactly this reason.  Knowing how to learn, how to find answers, how to use your available resources, how to teach yourself a new solution on the fly - that is true mastery. That is the expertise the Focused Labs team brings to your project. That is the most valuable skill because it can solve any problem, even one in a completely unfamiliar language or industry. It is the single most important skill I have, not just in my professional career, but in my personal life, for everything from hobbies to home maintenance and well beyond.

Learn How Focused Labs Team Can Help Your Team Find the Answers to Your Tough Questions

If you would like to discuss the needs of your development project with the Focused Labs team, complete our Contact Us form, and we will set up a call with you and our experts.

Share