You may be picking the wrong programmers

What do first dates, cocktail parties, and programmers have in common? They all require self control.

Studies have shown that having self-control – rather than giving in to internal instincts – is a powerful indicator of success. The famous Stanford marshmallow experiment, which goes back to the 1960s, was an important study on the subject. Nursery school students were given the choice of immediately eating one small reward, such as a marshmallow, or waiting about 15 minutes and getting two rewards. Years later, the researchers followed up with the students and found that the children who showed self-control in the study and waited for the larger reward generally fared better in life. Those participants were less likely to have behavior, obesity, and drug problems in high school, and they scored an average of 210 points higher on the SAT.

Resisting short-term gratification can be a big differentiator in the workplace. I’ve seen this firsthand throughout my years in software engineering observing standout performers. These individuals are able keep their conscious brains in control rather than falling prey to typical human instincts.

Here are five areas where programmers with good self control outdo their peers:

1. Depth v. Breadth: Software is a bit like magic — you add a bit of code or follow certain instructions and voilà, you’ve created something from nothing. This can feel like a great accomplishment at first, but as the inexperienced engineer goes from dabbling with Django to becoming a Python domain expert, the effort required to make substantial improvements increases dramatically (learning curve is logarithmic). The human tendency is to pursue the path with the fastest perceived growth, which encourages developers to constantly start new projects and learn new technologies. But high performers are skilled at resisting those urges and strive to develop depth instead. These individuals slow down and take the time to understand and investigate how things work. While the “magic” might not happen as quickly, by truly learning the ins and outs of different technologies, they will have a much bigger impact over time.
 
2. Output v. Input: The instinct is often for engineers to tout their input – how many hours logged in the office, how many lines of code created, how many bugs fixed, etc. The bottom line is that working longer hours doesn’t necessarily drive impressive results. Therefore, it’s important to shift the focus from input to output, which may be harder to quantify but is much more meaningful. When employees focus on the larger challenges at hand, there won’t always be measurable progress at the end of the day. However, that doesn’t mean you can’t calculate individual contributions. For every feature we build at Graphiq, we think instead about external metrics. For example, if we are building features to better support customer engagement, we measure the output: Are users writing more reviews? Are people returning more regularly? Or, if we’re working on improving back-end website speed, we look at response times.
 
3. Parallel v. Serial: Many problems in software engineering are complex and sequential, requiring individuals to solve one issue before moving on to the next. This can be a time-consuming process, creating situations that mandate staring at a screen for an hour or more, or consuming detailed literature to determine logical next steps. The human tendency is to take a break and switch to other priorities. This approach of “jumping ship” can hinder momentum or block progress altogether. Top engineers resist this temptation, focusing needed attention on the task at hand to see the project through to completion at a much faster speed.     
 
4. Self-Motivation v. Delegation: Most new grads are used to being told what to do: Show up to class, do some homework, study for a test. Additionally, because of the natural instinct to preserve energy for as long as possible, most wait until the last minute to get started, and once the task is completed, wait for the next assignment. On the contrary, high performers resist the natural urge to procrastinate, displaying tremendous amounts of self-discipline. They look to preserve energy, too, but do so by looking for efficiencies rather than procrastinating. They apply that thinking not only to their own jobs, but also those of their managers. Watch out – these employees find themselves quickly moving up the food chain.

5. Core v. Extracurricular: In college, the thinking was that the more extracurricular activities you participated in, the better. Why not? Exposure to new activities provides access to new skills, new people, and new experiences. The urge to participate in as many extracurriculars as possible often carries over to the workplace – particularly in startup environments with plenty of fun perks. Rather than being detrimental, extracurricular involvement is a magnifier of both success and failure. Consider a scenario where a developer didn’t meet an important deadline because she had to write a speech for toastmasters — what would her manager and peers think? Conversely, imagine an engineer who, in addition to demoing a great new feature to the entire company, organizes a 100-person hackathon; now that’s impressive. The best engineers embrace extracurricular leadership opportunities only after first mastering their core competency.

In all of these areas, a hiring manager has to resist his or her natural bias to prefer breadth of knowledge, diversity of interests, ability to multitask, etc. to find the highest performers. Resisting that natural bias is no easy feat. It starts with being aware that these instincts exist, making a conscious choice to resist these traps, and learning to accept that it will take time until such thinking is ingrained in our daily development efforts. After all, we’re only human.

Ivan Bercovich joined the engineering organization Graphiq (formerly FindTheBest) during the startup phase and is now Vice President of Engineering. He manages about 30 people in the software development, infrastructure, data engineering/analytics, and design teams.