Great developers write -10 lines of code a day

Often, there are quite significant differences between the good and the great developers. In order to become a good dev, you have to follow certain guidelines and it is a very hard work. However, if you’re trying to reach greatness, you have to break some habits or even change your mindset by 180 degrees. A lot of good devs are struggling with this and do not understand the dynamic of this process because it is sometimes counter-intuitive.

It is like karate: First, you have to learn kata perfectly. Only then can you start fighting others and level up. One day, when you become a master, you can forget everything and build your own karate.

Anonymous: Programmers deserve to feel confident that their code works

Develop quickly a happy path and delegate whole testing to testers and releasing to infrastructure people is unforgivable behavior of some good devs who get used to work this way. Great devs guarantee that their code works end-to-end and consult possible regressions and edge cases with testers, sys-admins or security experts. They never abandon testing and releasing. They know that the release is a key activity and they never give up control over it at any level of continuous integration and delivery. They are like Michelin-starred chefs who check every meal before it is served.

Anonymous: There is no secret weapon

Devs who share their knowledge/experience in order to help others grow are real gold for any team. They are like rising tide that lifts all boats. On the other hand, devs who keep their knowledge to themselves as their competitive advantage, or those who are not able to teach/mentor/coach other peers, can certainly be good but never great. They are like footballers who do not pass the ball.

Jeff Bezos: Be stubborn on the vision, but flexible on the details

Without a vision, you just have a backlog of thousands of tasks to do. Bikeshedding, where good devs are dragged into never-ending discussions about insignificant details over principal stuff are like Kryptonite which sucks energy from them. In contrast, great devs deeply understand the vision, priorities, and they are able to steer the discussion in an actionable way to address principal stuff.

Rob Myers: If your process requires no mistakes, it will fail

Mistakes are opportunities to learn. Great devs build systems rather small, simple, scalable and resilient (or even anti-fragile) over crazy, robust, and over-engineered systems where mistakes are not acceptable.

Jocko Willink and Leif Babin: No bad teams, only bad leaders

If a team is failing, the lead should ask: What context did I fail to set? Leadership can be challenging for some good devs, because it requires working with people, talking in public, or taking a strong standpoint at stakeholder’s meetings. There are just a few things that really matter. Therefore, great devs as leaders take full ownership and lead! They practice what they preach. They are honest and fair at 1:1s, they take/give feedback daily, they listen a lot and take notes, they make sure that good things happen and they take regular time to think things through.

Donald Knuth: Premature optimization is the root of all evil

Great devs first make something work and then make it work better. There are only a few situations where optimal, functional, and scalable code is simpler than the first solution. In general, each optimization brings a new level of complexity and doing premature optimization before we’re sure that it’s working for the end users is a very common and expensive error of many good devs.

Uncle Bob: We can do it sooner not faster

Working smarter and using creativity to adjust the scope (not just working harder), is a common sign of great devs. They also know that high-quality code is always faster than dirty-hacked one. On the other hand, delivering bad code at any price only to make managers happy or gain popularity in some gamification contest is unprofessional and a misuse of many good devs’ coding skills.

David Allen: You can do anything, but not everything

Make managers frustrated with promises but happy with the delivery rather than the other way around. The top 10 great devs in the world say NO very often and they choose very carefully where they put their energy and which battle they want to fight. In other words, they manage their managers and set real expectations if needed and they keep their promises. Lots of good devs are still trying to do everything and make everyone happy instead of taking the “path of greatness”. Saying NO is hard for many good devs because they don’t feel comfortable arguing (computers never do that). On the other hand, managers love confrontation and argumentation fire-fights because they are used to working with people (using debate as API) and this is their way of trying to find the truth (e.g. Will it take 10 minutes or one week?).

Anonymous: Busy is the new stupid

Good devs are always busy with emergencies and top priorities, fighting with time management, and being the slaves of a huge backlog that’s constantly building up. Very often, they are the crisis heroes and heroines being shouted out at company meetings. But it is very common that “firefighters also wear lighters” and they’re locked in this wheel of busyness caused by “I don’t have time to do it right”. Great devs, on the other hand, do more by focusing on less. They are able to manage their time and get things done the right way. They manage crises so that the rest of the company doesn’t even notice that something was wrong.

Anonymous: Prevention is the most effective weapon

A lot of good devs tend to avoid the prevention from various reasons: it is hard convince management to get approvals/budgets, it is invisible/boring job with zero recognition and there are usually tons of other fires to solve . On the contrary greats devs deeply understand the power of the prevention and regularly invest time and money into it.

Anonymous: Everybody knows how good bread looks and tastes like but only few can bake it

Being the only one in the room who really knows how to “bake” a good bread is a privilege and responsibility of great devs who have historical evidence of successful decisions and implementations. Good devs can see the difference between the good and the bad code but they are still struggling with delivering only the good one. They understand which framework is better but they never dive deep enough to write such a framework.

Albert Einstein: If you can’t explain it simply, you don’t understand it well enough

Good devs translate complex functionality into complex code. Great ones make complex functionality look simple and easy to understand while maintaining the complexity. They know that a complex system can only evolve from a simple one, never vice versa.

Anonymous: Agree on the problem

Good devs strive for a compromise about the solution, great devs strive for a consensus on what the problem is. This is a very common mistake of the good devs, they fall in love with a solution without fully understanding the problem. It further amplifies the risk of delivering a perfect solution without solving a real problem.

John Snow: Not under my watch (ref: GOT)

Good devs stay on the big wall and look to the South, watching the known lands. They tend to protect the code they know and they focus on developing in areas of their expertise where they can easily excel. But the enemies are coming from the North, from the unknown, orphaned and hostile code they unconsciously avoid or delegate to others. Great devs look to the North, explore the unknown and fight the uncertain. They delegate only the good code and take ownership of the problematic one. Everybody knows that nothing wrong can happen while they’re on the watch.

Doc Norton: Refactoring is small steps to simpler solutions. If you’re ripping out a whole chunk at once to replace it with your clever new solution, you’re probably not refactoring.

There is a chasm between the good and the great when it comes to refactoring. Every good dev sometimes runs into a situation where they produce a good code but after optimizations and iterations it actually becomes ugly. Next, they improve unit and integration tests to keep it working and make the code okay for business. Then they make a series of failed attempts to refactor it during weekends in their spare time. Finally, they try to rewrite it during vacation but fail there too. That ugly code sometimes remains in production for many years. Great devs can handle these kinds of situations in an elegant and successful way because they’ve mastered the art of step-by-step refactoring without an expensive rewrite.

Anonymous: More strategic more odds

Good devs align with the strategy and they very often care only about the things that bring value in the short-term. Great devs create strategy and they care about the things that bring value in the long-term.

Steve Jobs: You can’t connect the dots looking forward; you can only connect them looking backwards

Often, good devs have only a narrow focus on the tech stuff. But without a more diverse view and experience, they are not able to connect the dots, associate ideas, or see the bigger picture. Great devs constantly look for experiences in traveling, music, or sport. They also educate themselves in non-tech disciplines to embrace more aha moments in their life.

NOTE:

In the title I have mentioned numbers of lines. Honestly, there is no direct causality between lines of code and greatness. But, great devs regularly simplify code they are touching and delete unused one. This leads very often to negative score at the end of the day.

#CodeIsOurNativeTongue