Being a successful software developer goes beyond writing great code. It’s also about understanding how to work in a team, how to effectively manage your projects, and how best to approach the process of code writing itself. Software developer, Robert Heaton, from Stripe shared the three key traits to becoming a successful software developer.
Trust is a cornerstone of teamwork. Cultivate trust by being someone your co-workers can count on: if you say you’re going to do something, do it — and do it as efficiently as possible. Additionally, keep approachability in mind at all levels of your career. Be the open, friendly person who’s available for answering questions, or just talking ideas through.
Robert Heaton, software engineer at Stripe, advises being mindful of who you choose to work with. “Working with people who are motivated and friendly — and who have more experience than you — is an extremely effective way to supercharge your development.” In short: work with good people!
When reviewing a co-worker’s code, it can be tempting to scan it and say, “I’m sure it’s fine,” rather than actually reviewing it. It might be fine — but it might not. You might miss an error that leads to a bug, and you might miss out on a learning opportunity. Take time to understand what the code is trying to do, how it fits in with the rest of the system, and consider how you’d tackle the same problem.
Aim for clarity in your own code before asking others to review it. Make it well-structured and easy to follow, and be considerate: avoid sending 1000 lines of new code that restructures several things at once — or you risk the, “I’m sure it’s fine,” response — which could result in bad deploys or bugs. Share manageable chunks and communicate exactly what you’ve done and the specific change you expect to happen.
If you, or someone on your team, writes some bad code — it’s alright. It happens. We’re human, and we’re real people often working under pressure and time constraints. Don’t expect your code, or anyone’s, to be a pristine, perfectly arranged masterpiece.
If you make a mistake, don’t declare to your team how terrible you are. This communicates you’d expect the same self-chastisement from them, creating a culture of blame. Rather than feeding into that, understand that mistakes are a key part of the learning process.
It’s easy to get overwhelmed at the start of what seems like a huge coding project. Begin by identifying the first thing you can do to move forward, and focus your energy on that one thing. Then the next, then the next. Build your code in increments. And, if there’s an element that you’re just not sure will work, don’t put it off — take a breath and tackle it head-on.
It’s good practice to write tools for anything you’re working on. Harnesses and scripts will evaluate how fast your code is, which lines are getting executed, and how the internals are working. Even just writing a small diagnostic tool is worth the effort, and it’s useful for the rest of your team, ensuring they really understand the system.
The last 10% of a project often demands 90% of the work, and it can be very hard work. Don’t let the allure of a new, exciting project turn your head! Fix the bugs, update documentation, and tend to the myriad of other tricky things that are required before you can sign off on a project.
Having several unfinished projects on the go is a huge drain on your resources, adding unnecessary pressure to your workday.
First of all, close Slack, or any other collaboration hub. Next, set a timer for 20 minutes, or 30, or 45 — whatever works for you — and focus. This way of working is often referred to as the Pomodoro Technique — take a look at the official Pomodoro website, or try an online time-tracker like Toggl. When your timer goes off, make a coffee, stretch, or take a longer break if you require it. Burn out is no fun at all.
Keep it simple
Never do anything complicated unless you really have to. In the same way that great writers don’t use a long word where a short one will do: don’t overcomplicate your code.
The key here is to work in such a way that each block of code is an isolated, modular thing: a contract between the code and the person using it. It’s a building block, but it’s discrete and well-defined. This way, you can change the internals of how a block works, without affecting the blocks around it.
As you work, minimize set-backs by testing your code — but also keep in mind that you can be surprised. Servers can crash, and systems can change the way they work. Help your code to deal with these things gracefully: have back-up servers, test as you go, and make it easy to roll back changes.
In fact…
Software development is so often about trade-offs: those decisions we make moment by moment based on the information we have at the time. Structure your code so that if you get something wrong, that code can be replaced without bringing the whole project to its knees.
Wherever you are on your journey as a developer, don’t get overwhelmed by how much you think you need to know before being considered a ‘real developer’. Robert Heaton experienced this himself and now notices it among the junior developers at Stripe. His advice for dealing with it is succinct: “don’t worry!”
The truth is, imposter syndrome exists at every level of experience and expertise. Avoid comparing yourself to others. Instead, be curious, follow your interests, and be open to learning and growing as you go.
Curious about this topic? Watch our expert webinar with Robert Heaton, software engineer at Stripe, to learn more. And if you're ready to start your career in software development, get started below.
Ariel is the founder & CEO of Microverse, an online school for software engineers. Read more about Microverse and how it can help you.
Career advice, the latest coding trends and languages, and insights on how to land a remote job in tech, straight to your inbox.
