10 Exemplary Habits of a 2x Developer

16 min read
10 Exemplary Habits of a 2x Developer

Before we start considering what a 2x developer actually means, it might be helpful to sort out what the mythical 10x developer means. According to techopedia entry.

A 10x developer is an individual 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.

Maybe a factor of ten is a bit exaggerated, but surely I was lucky enough to come across a few engineers that were significantly more efficient than... oh yes... this is another good question - what do we mean by 1x developer?

1x Developer

1x developer should be our baseline. I think seniority should play a marginal role here, as I imagine both juniors and seniors can be 1x developers - I guess we should be looking for a definition of "average", "acceptable" or "standard" programmer instead. So what are the qualities of a 1x developer that would be helpful in our context? To me, a 1x 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, it is somebody you normally would not mind working with. It might not be a superstar programmer, a high-performer or somebody focused on intense growth, but the job gets done, and this is what ultimately matters, right? Yes. However, with just a little bit of extra effort, even a 1x programmer can make a huge difference, Pareto's Law (20/80) style.

2x Developer

Usually, being 10x developer usually is all about expertise combined with efficiency and requires having the right set of both problem-solving and technical skills, experience, creativity, etc., turning yourself into 2x developer in most cases just requires discipline or a skill of building, changing, retiring and following habits. It might sound simple, yet not everybody finds it that easy. To cut the long story short, let me present you my take on a selection of 10 habits I find game-changers when working with some of my team members.

Habit Picking the right task

Before starting a task, you need to pick one. Sure, tasks could be assigned to you or free to pick, even pre prioritized. a 1x programmer does not think about it too much, and even sometimes picks the task that "feels right" for the moment (maybe something easy you can chill while working on).

However, 2x developers look critically at the backlog and pick the tasks that will have the most positive impact on the mission (project, sprint). Maybe the simpler task will be better for more junior colleagues? Maybe doing a particular task, even if not very exciting, will unblock a huge batch of other tasks? Maybe addressing this particular, complex, risky thing will de-risk further development? Those are just a few sample questions that might pop up in a 2x developer's mind, before deciding what to focus on next. Maximizing impact and efficiency matters.

Habit Understanding "why?"

Where a 1x programmer would just start a task with little to no questions asked, a 2x developer would strive to understand why a given work item was requested in the first place. How does it fit into the big picture or overall plan? Who and how is going to benefit from it? A 2x developer is not only not afraid of asking so called "stupid questions", but also formalises the answers in the task itself (if those were not already there). "Why?" would you ask? Good question! In many cases, knowing the purpose behind a given task can help you deliver better solutions and overall experience, which in turn translates to less rework resulting from QA and/or customer rejections. On some occasions, it can even result in proposing more effective alternatives, potentially driving the cost down. For project management nerds, it can noticeably drive the %C&A (%Complete and Accurate) factor up.

Habit Filling in the blanks

While "the purpose" was our first (and common) blank to fill, in many cases, this is not the end of the story. The quality of the task description varies, and we might be missing some important aspects there. Maybe the acceptance criteria are poorly written or missing altogether. Maybe for a given task, it's worth having a wireframe or mockup to make requirements crystal clear. Maybe there is a copy missing or some obvious constraints are not specified. Again, you can do the extra work, provide those missing pieces to the best of your understanding, and communicate that up to the project manager. This way you are reducing the likelihood of delivering the wrong thing downstream.

Habit 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 1x developer usually cares very little about communicating progress on the task, besides of what is expected from him.

2x 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. 2x developer communicates this and other relevant information in a brief, optimized form - not when requested, but anticipating the question instead. When doing so, one uses the most relevant communication channel - the one that plays well with the manager. Messaging / Chat solutions like Slack usually work best for this. Besides that, 2x developers pay extra attention to keeping all relevant systems updated (headed by Project Management / Ticketing systems).

Habit Caring about estimations

There is one specific piece of information that seems to be particularly neglected by many 1x developers, and those are hourly estimations. It applies a bit less to story points, as in contrast to those, hourly estimations are more convincing to product owners and customers - this is because an hourly estimation directly translates to delivery date and cost. Delivery date and cost are what our customers usually care about, and that means our managers care about them as well.

While hourly estimations are essentially guesses / hypotheses, it does not mean those do not require attention both when initially created and later when continuously verified. 1x developers usually do spend little effort on estimating, on many occasions increasing estimation significantly to protect oneself from being challenged. 1x developer also rarely communicates when the estimation needs to be updated and why, not to mention exceeding the estimation.

2x developer on the other hand deeply understand the role of hourly estimations. Not only does 2x developer take extra care to realistically estimate a given task initially, but also understands that estimations are hypotheses in need to be verified and keeps a close eye on how the situation develops along the way. Above all, 2x developers clearly and as early as possible communicate when original estimation is at risk of being exceeded, thus leaving both project manager and product owner the room for maneuver.

Habit Self-testing

In software development, we should constantly fight with waste. One kind of such waste, and a very nasty one, is when a work item is rejected downstream. It is so nasty, as it generates unplanned work, interrupting a steady flow of work through the value stream. It can be a developer rejecting confusing requirements, a reviewer rejecting messy code, a QA rejecting a feature not working according to acceptance criteria, or even worse - a customer's client rejecting what we have built for any reason - be it a bug or poor UX. 1x developer does only what is expected of him in this matter, on some occasions even leveraging feedback and rejections as typical workflow, limiting the need to put effort into planning and testing.

2x developers know 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 own solutions rigorously by means of automated and/or manual tests. While doing so, 2x developers step into customer shoes and look at the solution from its consumer perspective. This way 2x developer not only manifests the understanding of how rejections negatively impact flow of work, but also respect for customer and other team members time.

Habit PR Descriptions

When creating a pull/merge request, a 1x developer pays little attention to preparing a helpful description, usually resorting to just ensuring a meaningful name for the PR.

On the other hand, 2x developer, are aware of the needs of people responsible for processing the PR down the line. Therefore, for fellow developers acting as code reviewers, he leaves extra information in the context of the task so the code review can be more meaningful / valuable without navigating to the project management system.

For QA or project managers, one might leave extra screenshots / videos of how the deliverable looks and even maybe a few words on how to use it. For operations, in turn, 2x developer might leave a checklist of steps necessary to integrate this PR with the master codebase. Also in each and every case, a good name, proper tagging, and providing a reference to the right ticket work item's origin are good starting points.

Habit Reviewing code

When we are on the topic of pull requests, I guess we can tackle code reviews too. There are differences between 1x and 2x programmers from the perspectives of both parties involved in code reviews.

Let's start with the perspective of 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 for?" 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, thus minimizing the need for another review when the fixes are integrated.

The code itself is the most important thing, though. 2x programmer reads through his code, looks for all typos, formatting issues and other easily fixable problems and fixes those immediately. After that, he looks 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 context 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. The reviewer's output is... reviewed code - yet this simple statement hides a lot of intangible impact such a person may have on the overall success of the project. Reviewers' responsibilities include the following:

  • Roughly scanning for logical problems in the code - this can prevent serious bugs from leaking to production
  • Analyzing code for maintainability issues - invalid abstractions used, problems with naming, lack of updates to documentation, not adhering to best practices or established standards... Addressing any or all of these can reduce or prevent struggling with the code in the future
  • Roughly analyzing code from an end-user functionality perspective - looking at templates, labels etc. Does all of that make sense for the end-users?
  • Typos, code standards, invalid whitespace, etc. should be covered. automatically, where possible
  • Finally - identifying room for valuable refactorings, and thus not only improving the solution itself, but also the skillset of the fellow author of the code

Such deep analysis requires significant effort. This effort is even greater, the bigger the PR is. Keeping such a high quality of reviews consistently also requires discipline. A 1x programmer usually tends to deliver code review halfway, especially when the workload necessary to do a proper code review is high. 2x programmer on the other hand knows how important this process is, and employs all of his skills and experience to deliver code reviews to the best of his ability.

Habit Maintaining 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 1x programmer is concerned about.

For 2x developer on the other hand, the question if documentation should be updated is always present on the pre-delivery checklist. Not only does a 2x developer provide necessary updates to all relevant kinds of documentation related to his work at hand, but also backfills missing documentation pieces as soon as those blanks are identified.

Habit RSVPs

I would like to close this list with something really trivial, yet neglected by a surprising number of people. Those are RSVPs. 1x developer usually has one opinion about meetings - those are to make his life harder. 2x 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. Something 1x developer rarely bothers doing as he seems not to understand how confusing it may be when the meeting is about to happen, and others are not sure if he is going to be there... especially when the answer is: no. Always RSVP... it is usually just one click away.

Cheatsheet

1x developer

  • Picks tasks most comfortable for him
  • Does not really care about the reason for doing a given task
  • Puts little to no effort into covering 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 right away
  • Does not self-test solution thoroughly before handing it further to QA (or customer)
  • Provides as little details in the PR description as expected of him
  • Does not self-review the code before handing it to the reviewer. also 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, he does not bother to RSVP to meetings he is invited to

2x developer

  • Picks tasks in a way to provide the most positive impact on iteration/project success
  • Always seeks to understand why a 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, provides the most realistic ones, and takes extra care to communicate 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 description for fellow reviewers to maximize their effectiveness in code review. Always thoroughly reviews others code - never accepts PRs mindlessly
  • Always asserts if in the context of a given task, the documentation needs to be updated. also backfills documentation with missing information when such a case is identified.
  • Always RSVPs to meetings he is invited to

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. 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 a 2x 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.

Is it a habit...

  • Makes other jobs easier?
  • Makes others look better?
  • Respect others' time and focus?
  • Addresses others' worries?
  • Answer certain questions before they are asked?
  • Positively impacts 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 a 2x developer may not only be relatively simple, but also easy. Yes, it is true that 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. 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 has better or worse days. Not always we will 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 20x developer. As a professional developer, I can see no point in not aiming there.