10 Habits of Highly Successful Software Developers
10 Habits of Highly Successful Software Developers
If you are looking to develop your skills and grow your career, check out these habits that great software developers follow.
Join the DZone community and get the full member experience.Join For Free
Buckled up and all set to kick-start your Agile transformation journey? 10 Road Signs to watch out for in your Agile journey. Brought to you in partnership with Jile.
Imagine that you’re comparing the resumes of two software developers: Dev A vs. Dev B. Both candidates possess nearly identical backgrounds and skills: languages, frameworks, platforms, methodologies, industries, and so forth. They’re practically the same person—on paper. Yet there are certain things that could indicate that Dev A will likely be significantly more successful in their career than Dev B, by just about any measure. How does this compute?
It turns out that technical skills and experience will only get you so far. Highly successful software developers also cultivate critical behavioral characteristics and mindsets that set them apart from the crowd. We asked a variety of software professionals about the habits and traits that separate great developers from the rest of the pack. They came up with 10 habits that predict success:
1. You Write Clean, Reusable Code That’s Easier to Read and Test
There are plenty of ways to write clean code that’s easier to reuse, read and test—but no matter the method, it’s an increasingly crucial characteristic of high-quality software development. Andrew Magee, a software development manager at UK-based Enigma Digital, offers this starting point: assign only one purpose to each function.
“When you start coding it is common to begin writing line after line of code, into a function that gets bigger and bigger,” Magee says. That might seem easier at first, but it generates several problems: your code becomes harder to read, harder to reuse, and harder to test. “A function should do one thing and one thing only. If it does more than one thing, it lacks focus.”
Magee also advises assigning clear, meaningful names to variables and functions—something that should be simpler if you’re following the one function, one purpose rule of thumb. “As a developer, you spend more time reading your code than writing it,” Magee notes. “It is important that when you come back to your code weeks after writing it, you can understand quickly and easily what it is meant to do.”
2. You Understand How Your Code Helps Drive the Overall Business
There are lots of people who can write the code for, say, a company’s new mobile app. There are far fewer with the big-picture vision necessary to understand why the company is building the mobile app in the first place. Great developers “understand broadly how the company works at a business level, speak the business’ language, and master translating business language to technology and vice versa,” says Todd Stephan, VP of software engineering at Ask Applications. Similarly, Stephan adds that great developers can speak to the value of technology in business terms—in other words, in terms that the rest of the company, C-suite included, understands.
Jose Miguel Pérez, CTO at MarketGoo, shares a similar view on this trait of great developers: “They seek to have an understanding of the objective, goals, and impact of a project that is broad and goes beyond the part they play in it.”
Here’s a crucial step toward a better understanding of your code’s contribution to the big picture: focus on the user or customer. “Successful devs take responsibility for what they deliver—not just to the repository, but to the user,” says New Relic Developer Advocate Clay Smith. “Ninja devs do their shift carrying a pager.”
3. You Listen More Than You Speak—Or You at Least Listen Before You Speak
“If you’re in an office with other developers, listen first, then speak,” says Christopher Mendy, head of developers at Evus Technologies. “It’s the quickest way to learn.”
This requires humility, especially if you think you’re the smartest person in the room. Great developers have “the ability and willingness to admit when they do not know,” adds MarketGoo’s Perez. Moreover, he advises against being that programmer, the one who spews out a bunch of technical jargon instead of acknowledging they might not yet know the answer to a particular question.
4. You Are Disciplined
Talent, except maybe in overwhelming quantities, is not everything. Indeed, talent or skill is only part of the formula for success. “Discipline is the other part,” says Gady Pitaru, CTO at Badger Maps. “A highly skilled software engineer without discipline is like a veteran sailor without a map: really good at steering the boat, but can’t find the shore.”
Pitaru describes a disciplined software engineer as:
- Someone who does not sacrifice quality for speed. But when they absolutely must, “they are aware of the technical debt they are creating and fight to pay it back in the future.”
- Someone who embraces processes because they recognize they’ve been put in place to help devs succeed. For example: “They are fully present during code reviews and encourage constructive sprint retros.”
- Someone who knows the value of focused time for development work: “They figure out ways to ensure they get it, by using pomodoros, blocking off calendar time, or wearing headphones, to name a few examples.”
5. You’re Able to Deeply Focus on the Right Thing
New Relic Ruby Agent Software Engineer Katherine Wu shares a specific form of discipline that marks highly successful devs: the ability to focus on the shared goal of a particular project without getting sidetracked by nice-to-haves or pie-in-the-sky thinking that isn’t actually moving you closer to your target.
“I think it’s a pretty common habit to go down rabbit holes or get wrapped up in the edge cases of a particular technical implementation,” Wu says. She describes that mindset as “Wouldn’t it be nice if we could do X, Y, and Z?”—when the actual goals of the project are “A, B, and C.” It’s a natural thought process for engineers, to be sure, but one that needs to be reined in sometimes. “When you step back a little bit, you might realize that you’re putting a lot of effort towards something that is not actually that crucial to the broader goal that everyone is trying to achieve.”
It’s certainly good to be able to look forward at times, Wu says, so long as you’re able to refocus on the importance of what you know you need to get done versus what you might need to get done. Part of that is making sure you’re on the same wavelength as the rest of the team. As New Relic’s Smith notes, “Successful devs understand that innovation is a team sport.”
6. You Are a Persistent Problem-Solver
“Be stubborn—some problems are very hard,” Mendy points out. “With enough time and research there is always a solution, and finding the solution to a hard problem is the best feeling.”
7. You Get Help From Strangers on the Internet
Don’t confuse persistence with pride. Successful devs don’t let their egos turn a programming problem into an unnecessary productivity drain—especially not when a solution may be readily available online. Sometimes, asking for help—yes, Google counts—is the most efficient first step toward a solution.
“Get good at Googling,” Mendy advises. “Just about every problem in computer programming that you will run into has been solved. Somewhere out there someone has run into the same problem you are having, and they often post their solutions.”
Don’t think getting help online simply means copy-and-pasting code from a Stack Overflow thread, though. New Relic Developer Advocate Tori Wieldt points out that great devs take the time to understand the what, why, and how of any solution they find online. “Research what the code is doing and why it solves the problems,” she advises. “You can cut and paste, but without background knowledge, it may come back to haunt you.”
8. You Go Beyond Skill to Achieve Expertise, but Not Necessarily Mastery
When Ask is hiring dev talent, Stephan looks for expertise in a person’s prior experience, and it doesn’t need to be in areas that directly map to the job he’s trying to fill. “If a person had built expertise quickly before, it is a good bet the person can do it again with other skills and technology,” he says.
Pitaru at Badger Maps explains the difference between skill and expertise: “A good software engineer can write a Django database query, but a highly skilled software engineer will know how to most efficiently write that query so that one line of code scales.”
Distinguish between expertise and mastery, though. The latter suggests there’s nothing left for you to learn. “Don’t think you will ever master anything,” Mendy says. “Development these days is just continuous education.”
9. You Are Open to New Things
Another prerequisite for that continuous education Mendy describes above: being open to new things and embracing them as needed.
“Highly successful software engineers are constantly learning about new trends in the industry and applying them directly to their work,” Pitaru says. “There’s a constant stream of new languages, frameworks, and methodologies that successful software engineers know how to filter and sift through for what will help them continue to do their best and grow. Arguably the most important skill for a successful software engineer is knowing how to acquire new skills.”
Indeed, as Pitaru notes, the learning does not stop with the completion of a computer science degree or coding bootcamp, nor once you hear the words, “You’re hired!” Indeed, if you worry that’s happening to you, it may be time for a reboot.
“Be open minded. The worst thing you can do is focus on one language or tool,” Mendy recommends. After all, “if all you have is a hammer, then everything starts to look like a nail.”
10. You’re Comfortable With Being Uncomfortable
New Relic’s Wu says her evolving approach to ongoing education and skill development is partly inspired by the book Deep Work by Cal Newport. A key quote: true skill development requires “being able to sink deeply into a topic and confront the areas that are difficult about it—and persevering through those times of frustration so that you can really explore, really understand the thing that is in front of you.”
This can be tough for all manner of reasons, including all those things—email, Slack, meetings, and so forth—that often make us feel busy but don’t necessarily contribute to the kind of deep intellectual effort Wu’s describing. Wu, for example, had noticed a signal that she was struggling to understand a complex topic: her attention would start to drift. “I might be in the middle of reading a technical blog post, and literally in the middle of a paragraph, the middle of a sentence about some idea, my brain almost rebels—I wonder what’s on Facebook?”
In response, Wu puts her takeaways from Newport’s book into practice by setting aside blocks of time—say, two hours—and unplugging from distractions to focus on a singular goal. She likens it to a meditative practice, enabled by setting aside those blocks of time: “Noticing that urge for my attention to go away and gently redirecting it back to the task at hand so that I can struggle through and identify, ‘OK, what part of this do I not understand? How can I find an answer? Do I need to run an experiment? Do I need to code up a toy project and relate it to this? Do I need to identify an expert who can explain it to me?’ It involves trying to make progress very deliberately on difficult topics.”
To be clear, turning off email for a couple of hours won’t make you a better developer—it’s simply a mechanism for focusing on real progress and improvement. To get better, she says, “You have to be working on things that are difficult for you. Even if you are distraction-free and getting a lot of coding hours in, if you’re just building the same really simple app over and over again, that is not necessarily stretching the boundaries of your skills. And if you’re not deliberately stretching the boundaries of your skills, you may not be trying to structure skills in the direction that will help you really grow as a technical contributor.”
Published at DZone with permission of Kevin Casey , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.