3 Simple Ways to Differentiate Yourself as a Developer
You would think these would be obvious. And in fact they are. You already know 3 simple ways to differentiate yourself as a developer, but you forget sometimes and so do I. Sometimes we just need a reminder. A reminder that the obvious things like these are very important.
If you think back for a moment about coworkers past or present who were an absolute joy to work with. Dollars to doughnuts these coworkers were outstanding in these 3 areas. I’ve certainly found this to be true in my career.
Is the suspense killing you yet? I didn’t think so. The bold subheadings kind of give away the plot anyway, don’t they.
Take Ownership
One of the best ways to differentiate yourself as a developer is to take ownership. This can be done in many different ways depending on the context. Doing so is incredibly valuable and makes you indispensable to not only your team, but to your company or client as well.
What does it mean to take ownership in this context? Essentially it means taking accountability for the completion of something, whether it be a task, a project, or an application to name just a few examples.
Granted, this can feel like a risky move. Especially if you’re taking accountability for something that resides outside of your immediate area of expertise. However, it’s important to note that taking ownership of a task doesn’t mean we have to complete it ourselves without assistance!
It’s natural to feel like we want to do everything ourselves. Particularly when we’ve publicly taken ownership of a task. This is where our egos can cause unnecessary pain by trying to heroically solve everything ourselves. Obviously, this is not beneficial to anyone least of all ourselves.
It’s much better to take ownership of a task and then shepherd it to completion. This usually means facilitating collaboration among coworkers to accomplish the task in a more efficient manner.
For example, imagine a task that would take you two weeks to do completely on your own. Now compare this same task that would take only two days to complete if you enlisted help from others. It’s easy to see which approach is better for your company and yourself. In both scenarios you’ve taken ownership of the task completion, but one approach saves a huge amount of time.
Be Reliable
After we’ve taken ownership it’s equally as important to be reliable. While being reliable can mean many things, in this context it primarily means following through with what we’ve said we will do. We all want to work with reliable people so we too must be reliable ourselves.
Taking ownership and being reliable are two concepts that are very tightly coupled. It bears repeating that it’s much more valuable to reliably shepherd tasks to completion than it is to do everything ourselves.
We should also strive to be reliable in our communications. If we say we’ll send an email to the project team by noon on Monday, then we must do it. Likewise, showing up late to meetings is unacceptable without a good reason.
If you have Stand-up at 8:30am every day, you can’t often miss it and say “I forgot” and expect to be taken seriously. This is just common sense, yet you’d be amazed at how often I’ve witnessed this level of flakiness in the workplace.
Moreover, your coworkers aren’t likely to confront you over these unreliable acts unless they’re particularly egregious. However, these things tend to add up over time and erode trust in you as a colleague that could be easily avoided. We have an endless number of software tools that will nag and remind us of important events so we might as well use them.
Be Considerate
Of the 3 simple ways to differentiate yourself as a developer, being considerate may be the most routinely ignored one in practice. We all have our own idea of what it means to be considerate in the workplace which complicates matters. It’d be far easier if there were a codified spec so we all could adhere to the same definition of “being considerate.”
However, there are a number of behaviors that most would agree are not considerate. For example, if you’re on a conference call and not talking, put your phone on mute!
I can’t tell you how many times I’ve seen someone not do this when calling in via a cell phone. Said person will have vibrate notifications on so every minute or so the buzzing comes through loud and clear over the bridge.
Obliviousness is not a good look. You may be a 10x Engineer, but if you leave your vibrate notifications on and don’t mute your line on conference calls, you will look like a turkey to your peers.
Similarly, just being friendly goes a long way in the workplace. Nobody wants to work with a jerk. It’s so much easier to get things done when we don’t dread having to collaborate with a surly colleague in DevOps.
It’s just human nature that we tend to avoid unpleasant people. The easier we can be to get along with, the easier it will be to work with us.
Trust is crucial. Considerate people are perceived as more trustworthy. Trustworthy people are easy to work with. People who are easy to work with make collaboration easy. Easy collaboration means work gets done better and faster.
Stephen Covey’s Speed of Trust illustrates these concepts well. You may need to overlook the overly corporate packaging of the ideas though to be fair.
Summary
3 simple ways to differentiate yourself as a developer are to take ownership, be reliable, and be considerate. These are fundamental characteristics of any good professional. However, it’s easy to overlook them with the mountains of technical minutiae we deal with as developers.
Consciously incorporating these 3 principles can make us invaluable to our team and our employers. Can you imagine a workplace that wouldn’t highly value someone who takes ownership and is both reliable and considerate?
The good thing is it doesn’t take any innate skill to exhibit these behaviors. Just a conscious acknowledgement of their importance and a commitment to embodying them.