Is ‘Code Sight’ the Missing Ingredient in your Engineering Team’s Success Recipe?

Every engineering leader struggles to identify and recruit strong technical performers.

Early on, I thought it just came down to finding individuals with strong fundamentals in computer science and competency in the right technologies.

Strong fundamentals and subject matter expertise, surely, were the only qualities I needed to start building a high-performing team. The rest could be built up over time, right?

Nope, not really.

I was surprised to learn that a group of engineers with strong fundamentals could struggle to perform as a product development team. As individuals, these talented folks could meet their deadlines and write code that worked perfectly for them. But once integrated into the whole, the system would be unstable.

What was going on?

I had hired smart, well-educated people. But my teams just literally couldn’t get it together.

After years of this, a colleague presented me with the concept of ‘code sight.’

Now, this colleague was an all-star engineering leader who built great teams. \ He came to me for advice on how to manage a team member who was “struggling” despite consistently delivering good code on time. I was confused. What was the struggle?

“He lacks code sight,” was the response.

“What is that?” I asked. “What is code sight?”

(Pro tip: It is always good to be honest if you don’t know something that an uber-smart person is talking about.)

As he explained it, I realized I had just found the missing ingredient in my team’s success recipe.

Code Sight Defined

Code sight is best described as big picture thinking. Or, in our case, it means seeing more than just your code and your task. It describes the ability to expand your focus and see how your work fits with all the code in the overall system, within the customer experience, and with the hardware as well.

It was the perfect term.

With my eyes now open to code sight, I realized that it is a way of thinking that is highly desired in many professions.

Code sight in practice

The NFL runs an event called the NFL Combine once a year where they test individual athletic skills, presumably to identify the most talented athletes. This is done to satisfy the belief that selecting the strongest athletes leads to building a championship team.

But many football experts have warned against putting too much value on the Combine results because they solve the wrong problem.

The goal should be to find the best football players, not just the best athletes. Maybe you can throw a ball better than anyone, but this skill is useless if you don’t know where it needs to go.

Consider Tom Brady. Tom did not have outstanding Combine results but (at the time of this post) is considered by most as the most successful player in NFL history. What happened?

What is usually argued is that the Combine missed Tom’s football IQ — his understanding of the overall sport, which is what led to his unparalleled career success. Were he a software engineer, I would say Tom had code sight.

A coder can make solid code that meets their task, and yet fail because they didn’t make it in a way that serves the final product. A software example of this can be seen in building UI.

Strong computer science fundamentals encourage an engineer to make code with an emphasis on performance and efficiency. They are encouraged to use tools such as Big-O notation to find efficient code by comparing the number of steps required per execution. Fewer steps equal more efficient code. This makes obvious sense.

However, when building UI, someone with code sight would emphasize flexibility often over performance. Why? Highly efficient code may be rigid and hard to change because it was optimized for a single task.

Consider this: Sports cars aren’t usually designed to transport four kids, hold the groceries to feed them, and carry all their sports equipment while maintaining in-city fuel efficiency. I know this firsthand; I was once a new parent with a Mini-Cooper! The sports car is built for performance, not daily family life. (I quickly changed to a station wagon!)

Anyone who has built UI knows that change is the only constant. In fact, given the recent emphasis on A/B testing and a growing culture of experimentation on UI, I would argue that flexibility in code is needed now more than ever. Rigid code slows teams down. They will either have to write around the code, replace it, or write really ugly adapters to talk to it.

Transferring this scenario to my Mini Cooper example, it’s akin to teams calling an Uber with more space, buying a new car, or pulling a trailer around town.

The sports car works as intended but doesn’t solve the needs of a large family. Similarly, rigid code developed in the absence of code sight will perform as engineered but won’t solve the need of the product.

Where do we identify this special skill?

I can’t say if code sight is learned or innate, nature or nurture, born or made. What I can say is I know it when I see it, and I do my best to find it when evaluating new engineering candidates.

Here’s how I do it:

1. I like to start by asking the potential candidate to build a simple piece of code, usually in a pairing style together. This is a good way to see the fundamentals of the engineer and collaboration model.
2. Once done with the first version, I will ask, “What would you change now that we have it working?” This usually leads right to optimization. However, some engineers will start to build out more testing around their code. Both are fine choices, and I will let them take this second pass in their own way.
3. Then, I test for code sight by adding scenarios to the problem:

• “If this code was running in a high-traffic API what would you change?”
• “If this code was running in a reusable UI component, what would you change?”
• “If this code was running on a thread, what would you change?
• “What would you like to know about the hardware running this code?”
• “What would you like to know about the cloud environment running this code?”

4. I follow up by asking, “Can you think of any other scenarios that this type of code may need to support and what would you change given these scenarios?”

Now, engineers without code sight will find this process very frustrating. They will insist that their highly optimized code is the one “Right” solution. I recommend that you avoid these engineers if you are building a product-focused team.

Engineers with code sight will thrive in this type of questioning! They will ask you more questions than you can ask them! They will love gaining an understanding of where their code fits and will demonstrate their ability to handle many different situations. They will make adjustments that fit the problems. They will build the best code for the software, product, and most importantly, the user.

Ah. The User. This brings us to the final element of testing for code sight: ‘Best fit.’

Engineers with code sight will present the Best Fit solution after examining many potential Right solutions. How do we know it is the best solution for the product and the user? Software is generally useless without purpose and most often that purpose is solving jobs for users in an engaging, meaningful, and impactful way.

5. So the fifth, and final question you should ask to determine code sight, is: “Now that we have a solid choice for the application, how is it good for the user?”

Most engineers will look at you with sudden panic at this point realizing that they have no idea who the user even is.

The engineer you want to hire is the one asking meaningful questions about user personas. Those with advanced code sight may have asked this earlier, but some need to be prodded at this point. In reality, many engineers don’t have experience with companies like Q4 that encourage everyone to think deeply about the product.

Engineers with code sight will be happy to explore this with you.

But those without code sight will say things like, “It doesn’t really matter does it?” or even, “Code should be agnostic to knowing the user.”

Sigh. In my view, the definition of code sight extends to caring about the user’s experience.

Ultimately, it is user empathy that will help your entire team succeed in creating products that users actually want, desire, and are willing to pay you to create.

Conclusion

If your engineers write good software that works well on their machine, or in their demo, but that doesn’t work when integrated, you may have a team that lacks essential code sight.

If your software seems to be unstable and takes too long to pass regression, you may not have engineers with code sight.

Sit them down and ask them how their code affects other components. Ask, “Where does it live? How does it drive strategic needs? How does it help the user?” If they can’t answer any of these questions, it is time to look for engineers with code sight.

You may also find it to be the missing ingredient in the recipe for your team’s success.