Edition 2

How to get ahead of 99% of Developers (Starting Now)

Today Iā€™m going to show you how to get ahead of 99% of developers.

Software engineering is becoming increasingly popular over the years, there are more people than ever learning coding and moving over to software jobs. So you need to stay ahead of the pack.

Unfortunately most developers fail to progress because theyā€™re just like the 99% of other developers.

To become a part of the 1% you have to be willing to do what the 99% will not

Iā€™ve been fortunate to work with some incredible developers during my 12 years in development. So today Iā€™ll share with you:

For those who want to excel then keep reading:

They played to their strengths

The best developers Iā€™ve worked with all had very broad technical skillsets. You could put them on most projects, whether itā€™s backend or frontend, using one language or another but they would always excel in one particular area.

And when working in a team they would always try and lead in the areas they knew they could do their best work.

Whether it was due to previous experience tackling the same or similar problem or because their technical skills were well suited to the area. You would always find them building great software by combining experience, technical skills and genuine passion for the craft.

Bruce Lee once said:

I fear not the man who has practiced 10,000 kicks once, but I fear the man who has practiced one kick 10,000 times.

Itā€™s one of my favourites and great developers know that playing to their strengths benefited the honing of their craftsmanship and the team by delivering their best work in the areas itā€™s needed most.

Make sure each day you spend time honing your craft and continuing to build upon your greatest strengths.

They had deep knowledge

This is something that only comes with time but the best developers Iā€™ve worked with all possessed deep and useful knowledge.

Attained through hard work, effort and dealing with a wide variety of difficult problems.

It might have been in a particular language or framework. Or it might have been invaluable domain knowledge for systems in the business they worked in. Whatever the case it was always highly valued by the team around them as they became the go to person in that area.

Now they didnā€™t try to hide or horde this knowledge for a sense of security, instead they always tried to share it with others and document their knowledge. Realising that hording useful information only benefits the individual and has the downside of creating a bottleneck in the team and a single point of failure.

Next time youā€™re at work have a look around for areas and problems youā€™re inherently interested in and are valuable to the business. Then spend time going neck deep in whatever it might be to build and collect deep knowledge in that thing that so you can improve and share with others.

They tackled the hard things

Simple fact, most people are not willing to tackle truly difficult things. And thereā€™s a couple of dimensions to this.

Difficulty is not simply how technically complex something is but is a combination of complexity and friction the person experiences

Simply put, whatā€™s difficult for one person might not be difficult for a different person and vice versa.

And the best developers Iā€™ve worked with all tackled difficult problems that were both in and out of their comfort zone. They tackled some problems that created so much friction but they never gave up in trying to solve the problem.

They were willing to persist and break through that barrier not matter what.

And they didnā€™t always do it alone, they knew when to reach out for help from other people. Determination isnā€™t about hard headed stubbornness, itā€™s about never giving up but realising that you might need a different approach or some backup to assist.

Look around you and see what difficult things are people avoiding but shouldnā€™t. What issues or projects are people ignoring because theyā€™re too difficult? Those are the issues you want to go after. If you can begin to tackle those problems, or even better, gather a team of like-minded disciplined people to take on those problems then youā€™ve shown your ability to persevere and to lead people to solve a valuable and difficult problem.

They invested time

Iā€™m going to get some flack for this I know but if you want to be truly great at something then you need to put in the time.

A lot of people talk about work life balance but the truth is you have more chance to reach the top if you simply put in more time.

Very few talented individuals reach that level of greatness through putting in the average amount of time like everyone else does.

Instead you see the great in any area and you know what they do? They put in the time and then some!

Software engineers are no different. Go read Bounce: The Myth of Talent and The Power of Practice by Matthew Syed to understand why time trumps talent.

But itā€™s not just about time for times sake, itā€™s about purposeful time spent. And the best developers spend their time wisely. They block out their time for purposeful practice and give themselves enough time to sink into deep work.

Dan Koe (a prolific online writer and entrepreneur) agrees on having large time blocks of deep work.

Because if youā€™re going to tackle big difficult things then youā€™re going to need time to do that.

The path through learning is not a straight line so you need time to lose the path, get over the obstacle and break through the barriers along the way.

Invest time each day or each week in the thing that will benefit you the most over the long term. Whether itā€™s studying for that AWS exam you said you would complete, tackling coding challenges or learning a new language. Invest the time that the 99% wonā€™t.

They read the docs

Itā€™s a meme at this point but simply read the documentation.

Post by @coding.genius

View on Threads

The fact that very few people actually do this is startling.

An yes I know not all open source (or even closed sourced) code has great documentation but if they have any documentation at all then you should start there when you encounter your first problem.

The great developers Iā€™ve worked with always go back to the documentation first to discover what they needed. Most of the time theyā€™d find what they were looking for, fix the problem and the move on.

Also they didnā€™t just read it, they would test their knowledge and understanding of what theyā€™d just read by implementing a similar example or by looking at what theyā€™d already done and seeing if it matches the way it was meant to be used.

Iā€™d say get good at reading and testing your knowledge from documentation to improve your understanding and ability to solve your own problems when you encounter them.

They were incredible at debugging

Weā€™ve all had that moment in production where the alerts are going off, Pager Duty simply wonā€™t stop calling everyone, management is in a tizzy and people are scrambling to identify the problem.

The great developers absolutely shine in these situations mainly due to one key skill. Their ability to analyse and debug problems.

Itā€™s one thing to be able to write software itā€™s a totally different thing to be able to debug and fix it.

Temperament plays a big part in this one because those same great developers usually have the ability to stay calm and analyse the situation without the noise, distraction and pressure affecting them.

They know their tools, they know their logging, they know their software and they know how to go about finding the problem. Because the first 50% of solving a problem is understanding what the problem is.

This debugging workflow chart from Nikki Siapno is a nice frame of reference.

Spend time learning your debugging tools in your code editor and browser, understand your application logs and donā€™t shy away from the next production issue.

Three simple steps everyday to outdo the 99%

So weā€™ve talked all about what great software engineers do that other donā€™t.

So what should you do to start making progress?

Hereā€™s three steps you can take everyday to create compound interest for your self improvement as a software engineer.

1. Dedicate 2-3 hours each day to deep work

Whether itā€™s during work time by switching off distracting comms and dedicating time to true concentrated focus at work or in your spare time, make sure to spend time everyday in a deep work state to build long term memory and knowledge.

2. Prioritise the most difficult tasks first

Our energy depletes throughout the day. Both mental energy and physical energy. If you have identified a problem at work or have a difficult coding challenge or concept to learn then make that the first thing you tackle each day. Setup yourself up for success by utilising your peak energy time, the morning, as the time that you tackle the important and difficult things.

3. Read other peopleā€™s code

If itā€™s true that in order to be a good writer then you must read then it makes sense that in order to be a good programmer you must read a lot of code. Itā€™s useful to see how different people code the same or similar tools or to see how open source projects write their documentation. Read enough and youā€™ll start to get a sense of what good and bad code and documentation look like.

Thanks for reading

I am not a top 1% software engineer, and I may never be but I will strive to be the best I can be.

I hope my learnings from other developers much better then myself has been useful.

Thanks for reading.

Knowledge for the healthier, wealthier, long term developers

Sign up to my weekly newsletter for software engineers/developers that want to grow. I share my past successes and failures so you can get a head of the rest.