Skyrocketing your perceived value and becoming an uncommon developer cannot be considered without honorable mention of the concept of 10x developer first.
According to Techopedia, a 10x developer is someone who is thought to be as productive as 10 others in his or her field. The 10x developer would produce 10 times the outcomes of other colleagues, in a production, engineering or software design environment.
A 10x developer is also known as a 10x programmer or 10x engineer.
A 10x developer is the very top 1% of all developers - someone exceedingly rare. However, to skyrocket your value you don’t actually need to be a 10x developer. You can stand out by picking up some pretty simple habits that most “baseline” developers don’t have. But…wait…what’s a baseline developer? Let’s start there.
Baseline developer
For starters, you need to have a measuring stick - something to measure yourself against. In our case, this will be our typical developers we will call “baseline developers.” I think seniority should play a marginal role here, as I imagine both juniors and seniors can be classified as such. How does this idea of a “baseline developer” relate to our understanding of what an "average", "acceptable" or "standard" programmer looks like? What are the qualities of a baseline developer?
To me baseline developer is a professional who, adequately to his current expertise level:
- Delivers work items as requested of him...
- ...with reasonable quality
- ...in most cases on time
- ...following most of the established processes
- ...and does not have any negative influence on the team (i.e. by being a jerk or something)
Basically, this is a type of person you would definitely not mind working with. It might not be a superstar programmer, high-performer or somebody focused on intense growth, but they get the job done.That’s what ultimately matters, right?
The uncommon developer
With just a little bit of extra effort, baseline developers can quickly become what we will call “uncommon developers”. In most cases it’s less about building high levels of technical expertise and more about having the discipline to build new habits and change or ditch ones that aren’t working.
It’s a surprisingly simple (not easy) process to quickly up-level your positive impact on your team and project success, where 20% of effort will translate to 80% of result.
Having over 10 years of experience in project management behind my belt, this is my take on the 10 habits that can be game-changers for both new and experienced developers.
Top 10 habits to skyrocket your value
Start picking the right tasks
Before starting a task you need to pick one. Sure, tasks are sometimes directly assigned to you. But often, you’ll find you are free to pick tasks or prioritize tasks from a long list. Baseline programmers don’t think about picking their tasks very much. They might pick tasks randomly or pick tasks based on what “feels right” in the moment or what looks the easiest.
The uncommon developer, however, looks critically at the backlog and picks the tasks which will result in the most positive impact on the mission (project, sprint, etc). To help pick the right tasks, start asking yourself the following questions:
- Which task is most appropriate for me based on the strengths of others on my team?
- What task will help unblock a huge batch of other tasks?
- What task will help de-risk further development?
- What task will help provide maximum impact on the project?
Focus on how you can maximize your impact on the project at hand.
Understand the "why?"
A baseline programmer would just start a task with little to no questions asked, an uncommon developer would strive to understand why a given work item was requested in the first place.
Start asking yourself questions like:
- How does it fit in the big picture or overall plan?
- Who is going to benefit from it?
- How will it translate into a better user experience?
Don’t be afraid of asking so called "stupid questions”. Asking these types of questions shows you’re invested in the big picture, and can help you deliver a better solution and overall user experience. This will ultimately translate into less rework during QA and fewer customer rejections. On some occasions it can even result in proposing more effective alternatives, potentially driving the project cost down.
Fill in the blanks
In habit #2, we discussed the importance of asking for the “why” (i.e. purpose) behind a given task. While "the purpose" is the most obvious blank you should fill before undertaking a new task, it is not the end of the story. The quality of task descriptions vary, and we might be missing some important aspects such as:
- Is the acceptance criteria properly written? Is anything unclear?
- Should a wireframe or mockup be created to make requirements crystal clear?
- Is all of the copy available or do you need to request some from the client?
- Are there constraints that aren’t specified?
Start to think about how you can fill in these blanks, and document the findings as you go. This will help you to wrap your head around the task at hand and clarify areas where you have questions. Any questions that you do have should be communicated up to the project manager before you proceed. All of this work to fill in the blanks for any given task will help to reduce the likelihood of delivering the wrong thing downstream. This is the uncommon developer way.
Provide updates along the way
"Silence is golden" does not necessarily apply to software development. This is usually why we have "stand-ups" aka "dailies". A baseline developer is usually not very concerned about communicating progress on his or her task, besides what is explicitly expected from him or her.
An uncommon developer, on the other hand, knows how to care about his manager's oversight and peace of mind by providing regular updates on the progress, challenges, blockers, expected delivery time etc. These developers communicate this and other relevant information in a brief, optimized form - not when requested, but in anticipation of the questions, instead.
When providing this level of communication, you should do so in the most relevant communication channel - the one that plays well with the manager. Usually this is in a messaging or chat app like Slack. Besides that, an uncommon developer pays extra attention on keeping all relevant systems updated (headed by Project Management / Ticketing systems).
Care about the impact of your estimations
There is one specific piece of information that seems to be particularly neglected by many baseline developers: hourly estimations. Hourly estimations may be very important to product owners and customers because the hourly estimation almost directly translates to delivery date and cost. In turn, delivery date and cost is what our customers usually care about the most, and that means our managers care about those as well.
While hourly estimations are essentially guesses / hypotheses, it does not mean they do not require attention both when initially created, and later, when continuously verified. Baseline developers usually spend minimal effort on estimating, and in many cases, drastically overestimate…you know... "just in case". Such developers also rarely track and/or communicate when an estimation needs to be updated and why.
The uncommon developer, on the other hand, deeply understands the role of estimations. Not only do they take extra care to realistically estimate a given task initially, but they also understand that estimations are hypotheses that need to be verified and watched closely along the way. Above all, an uncommon developer clearly, and as early as possible, communicates when their original estimation is at risk of being exceeded, thus leaving both project manager and product owner the room tor adjust the project plan.
It’s important to note that it is equally as important to take the time to estimate accurately as it is to take the time to clearly communicate your estimates with your manager or project lead. This communication piece is critical because no estimate will ever be 100% accurate, so you embrace a mentality of communicating often as you learn more about the project and adjust your estimates accordingly.
Self-test first
In software development we are constantly fighting to reduce waste. One kind of waste, and a very nasty one, is when a work item is rejected downstream. It is nasty, because it generates unplanned work, interrupting a steady flow of work through the value stream.
It can be caused by a developer rejecting confusing requirements, a reviewer rejecting messy code, QA rejecting a feature that isn’t working accordingly to acceptance criteria... or it can be a customer, or even worse - a customer's client rejecting what we have built, literally for any reason - be it a bug or poor UX. A baseline developer does only what is expected of him in this matter, on some occasions even leveraging external feedback and rejections as typical workflow, limiting the need to put effort into planning and testing.
The uncommon developer knows that everybody is responsible for the quality of the solution and always strives to deliver impeccable results downstream. One of the steps towards this goal is testing your own solutions rigorously by means of automated and/or manual tests. It might seem boring, but it’s a really important habit to build if you want to deliver more value. When you do this, you step into the customer’s shoes and look at the solution from their perspective. This way you not only manifest the understanding of how rejections negatively impact flow of work, but also have respect for the customer’s and other team members’ time.
Include detailed PR descriptions
When creating a pull/merge request, the uncommon developer is fully aware of the needs of the people responsible for processing the PR down the line. There may be a variety of groups who are downstream, but for some of the most common, this is my suggestion for what to include in the PR description:
- Fellow developers acting as code reviewers: Leave extra information to provide context for the task. Doing so allows the code review to be more valuable and eliminates the need for the reviewer to navigate to the project management system.
- QA team or project manager: Leave extra screenshots or videos of how the deliverable looks and maybe even add a few words on how to use it.
- Operations team: Leave a checklist of steps necessary to integrate the PR with the master codebase.
In all cases, as a best practice, you should provide a good name, include proper tagging and provide a reference to the right ticket work item that the task originated from.
Reviewing code
When we are at the topic of pull requests, let’s tackle code reviews, too. There are differences between baseline and uncommon programmers on both sides of code reviews.
Let's start with the perspective of the person requesting the code review. We have already covered related topics of providing good PR descriptions and self-testing to limit rejections down the line. What else can be done, then?
I find it useful to ask myself a question: "Based on my experience, what are the avoidable reasons one might reject my PR?". One such reason might be a mess in commits - especially commit names. "WIP", "typo", "fix" are all candidates for squashing / rebasing.
Then goes CI - did any of our linters or automated tests fail? Fix those before the actual code review happens to minimize the need for another review when the fixes are integrated.
The code itself is the most important though. Uncommon programmers read through their code, look for all typos, formatting issues and other easily fixable problems, and fix them immediately. After that, they look at the code from a maintainability perspective. Are all the changes self-explanatory and really needed? Where possible - corrections are provided. In other cases extra information on the context for the change is added in either the PR description, review comments or directly in the code. This is all to help fellow reviewers do their job effectively down the line.
The perspective of the reviewer is also important. A reviewer's output is... reviewed code - yet this simple statement hides a lot of intangible impact that this person can have on the overall success of the project. Reviewers responsibilities include:
- Roughly scanning for logical problems in the code. This can prevent serious bugs leaking to production
- Analyzing code for maintainability issues. This includes the use of invalid abstractions, problems with naming, documentation that is lacking updates, a lack of adherence to best practices or established standards. Addressing any or all of these can reduce or prevent struggle with the code in the future
- Roughly analyzing code from end-user functionality perspective. This includes looking at templates and labels and making sure they will make sense for the end-users.
- Checking for typos, code standards, and invalid whitespace. Etc. Ideally, these should be covered automatically.
- Identifying room for valuable refactorings. This not only improves the solution itself, but also the skillset of the fellow author of the code
This type of deep analysis requires significant effort. This effort increases based on how big the PR is. Keeping such a high quality of reviews consistently also requires discipline.
Baseline programmers may, even if occasionally, tend to deliver code review halfway, especially when the workload necessary to do a proper code review is high. However, the uncommon programmer knows how important this process is, and employs all of his skills and experience to deliver code reviews to the best of his ability each and every time.
Maintain documentation
Roughly mentioned in the previous point was the issue of documentation. Well maintained documentation can prove itself invaluable when the project and team grows over time. It is even more important when a project is handed off to another team. This being said, updating documentation is rarely something a baseline programmer is concerned about unless it is a part of an enforced process.
For an uncommon developer, on the other hand, the question if documentation should be updated is always present on the pre-delivery checklist. Not only do they provide necessary updates to all relevant kinds of software documentation related to their work, but also backfills missing documentation pieces as soon as those "blanks" are identified.
RSVP
I would like to close this list with something really trivial that is neglected by a surprising number of people: RSVPs. A baseline developer usually has one opinion about meetings: they are there to make his life harder.
An uncommon developer, on the other hand, not only takes initiative to maximize the utility of all the meetings he participates in, but above all, always lets others know if he is going to be there or not. Always RSVP... it is usually just one click away. Something so simple, yet sadly, uncommon.
Cheatsheet
A baseline developer:
- Picks tasks most comfortable for him
- Does not really care about reason for doing a given task
- Puts little to no effort to cover missing information related to the task at hand
- Provides no or rare updates along the way
- Gives little thought to estimations, by default estimates very cautiously and forgets about estimation importance up front
- Does not self-test their solution thoroughly before handing it further to QA (or customer)
- Provides only the bare minimum description in PR descriptions
- Does not self-review the code before handing it to the reviewer.
- Exerts little effort when reviewing others code, often just accepting the code and hoping for best
- Rarely thinks about documentation, let alone updating it when necessary
- On many occasions does not bother to RSVP to meetings he is invited to
An uncommon developer
- Picks tasks in a way to provide the most positive impact on iteration/project success
- Always seeks to understand whya given task needs to be done, so the best approach can be taken
- Gets and formalizes missing information/criteria around a task to keep everybody on the same page
- Provides updates along the way in a regular fashion, adequate to the situation
- Knows what the estimations are needed for and takes care to provides the most realistic ones and communicates the likelihood of exceeding the estimation on the first signs of it
- Self-reviews and self-tests both the code and the actual functionality before handing it further
- Provides useful context in PR descriptions for fellow reviewers to maximize their effectiveness in code review.
- Always thoroughly reviews others code - never accepts PRs mindlessly
- Always asserts if the context of a given task requires the documentation to be updated and backfills documentation with missing information.
- Always RSVPs to meetings he is invited to
When everybody is uncommon, then who really is?
You may say that if everybody on your team embarks on this journey towards being uncommon and succeeds (which is what I sincerely wish), then... well, nobody will be uncommon anymore.
That is correct. This is called "setting high standards." I would guess you want to be part of such a team, right?
You need to be aware that this translates to making your whole team uncommon in comparison to other teams or even companies. Another good thing, right?
Last but not least, you need to remind yourself of one critical thing - all of those habits were not to make you look great. That was meant to be only a side effect of helping your whole software development team be more effective in fulfilling its mission. Does such a goal sound reasonable?
Regardless of that, if you really feel you have plateaued and in need of more habits, you can build your own!
Need more habits?
The list above is by no means exhaustive and might not be adequate to each and every context. Therefore, it should not be treated as such, but rather as a framework or a starting point for building one's own one list of habits.
To be honest, it seems that many of the habits presented above can be adapted with little to no modifications to roles outside of software engineering or event IT. You can easily become an uncommon marketeer, manager, HR, operations person etc.
To come up with other habits and validate if those are really useful, it might be helpful to use the following list of questions.
Does the habit...
- Make others’ jobs easier?
- Make others look better?
- Respect others’ time and focus?
- Address others' worries?
- Answer certain questions before they are asked?
- Positively impact progress towards established goals for the project and/or team?
The common theme for all of the questions above is that it is not about you, but about the team and the mission. It is only about you in the context of being a role model and your personal and/or professional growth, nothing else. Good habits are usually also related to qualities like, among others: initiative, communication, quality and dependability.
Conclusion
Becoming an uncommon developer may not only be relatively simple, but also easy. Yes, it is true it might require discipline to build the necessary habits in the first place (on this occasion I cannot recommend Atomic Habits by James Clear highly enough), yet those habits will repay manyfold in the future, even in your personal life. And it has to be pointed out again, that those habits usually have little to do with technical expertise.
Also it is worth mentioning that each and every one of us have good and bad days. We won’t always be able to meet the standards we have set for ourselves with before-mentioned habits. And that is ok. The key is to set the path, and always do our best to stay on it. The path towards both deep expertise and excellent soft-skills. The path towards being a 20x developer. As a professional developer myself I can see no point in not aiming there.
