How to become a pro

I want to share some behaviors that I have observed amongst successful software developers and less successful ones that seems pretty independent of the size or organizational structure of the company. The ability to get past those behaviors is to me a good indicator of personal development as a software developer.


Flakiness

One of the defining qualities of kids is that they flake. When you’re a kid and you face some hard test, you can cry and say “I can’t” and they won’t make you do it. […] So one of the things employers expect from someone with “work experience” is the elimination of the flake reflex — the ability to get things done, with no excuses. — Paul Graham

Flakiness is to me a defining quality of a junior developer. The behavior can manifest itself under different forms, but they all end up with the same result: the work does not get finished until someone else does it.

At its most basic level, it’s the flakiness as described by pg, the “I cannot do it” which has more to do with “you cannot force me to do it” than actual ability; this is usually quite obvious when you see it, so I will not spend much time on it.

A more subtle pattern I have seen is blaming others (the company, management, teammates, etc…) for not giving enough training for the developer to be able to perform the work. While on the surface it may seem plausible, it avoids the question: what has the developer done to get the necessary knowledge ? If the manager has declined a request for formal training without providing a credible alternative, then there is probably a case to be made (but then would you want to work for a company like that?). Yet if the developer has a genuine intent on getting better, (s)he will see gaining the knowledge as one of the milestones to achieve the outcome. More often than not the ‘lack of training’ excuse hides the expectation of the developer to be told how to do the work.

A variant of the ‘lack of training’ pattern is when a less experienced dev gets paired with a more experienced mentor. The path of least resistance for the newer dev is to ask the one who has been there for a while how to do the work. After all, they know, right ? The thing to watch out for is the lack of willingness to learn what is needed to do the work (‘but she is so much better than me at doing this, it would be faster if she did it’).

So good you can do it with your eyes closed

The developers who get past the junior stage and can deliver reliably most likely have learned enough about a domain to be effective at it may hit a second plateau in their personal development, which I will call the wannabe expert. This is the idea that you are so good at your job that it comes easy for you.

Some developers think that being comfortable is a sign that you are an expert; on the opposite, I believe the trademark of a pro is the ability to be ok with being uncomfortable.

I see software development as a creative art; knowledge worker does not quite capture the delicate balance between the ability to deliver software which works as expected (even better enjoyable to use), gets in the hands of customers on time, is maintainable by the people following in your footsteps, scales/performs to the size of your user base. Good software is just hard to produce.

In this classic book The War of Art, Steven Pressfield introduced the concept of resistance. Resistance is the force that prevents you from getting your art in the world. It is the excuse that you give yourself to procrastinate, that little voice that says that your art is not worthy.

Resistance is what causes an artist the discomfort every time he pushes forward. Resistance is what you experience when you grow your comfort zone.

Resistance as a compass

And herein lies the secret of becoming a pro:
1- listen to the voice of the resistance.
2- do the opposite of what that voice tells you

An amateur says: I have worked for 10 years in Java, I will look for a Java architect job where I can tell people what to do.
A pro says: I have worked for 10 years in Java, but I am going to work for a Ruby shop with a bunch of people who are way better than I am even if that makes me look less competent.

An amateur looks for projects to show off her expertise
A pro looks for projects where she can learn

An amateur suffers from the feeling of not being good enough and gets paranoid about it. A pro recognizes that feeling as a sign of personal growth.

So next time you have a choice between a project where you can be the expert or another one where you can contribute, but be uncomfortable about it, recognize that discomfort is the voice of the resistance.

It is in those moments that you can choose to become a pro.

A single golf clap? Or a long standing ovation?

By clapping more or less, you can signal to us which stories really stand out.