Why I'm not an expert

Working in a technical profession I am compelled to keep abreast of new tools and techniques; however the sheer volume of new languages, frameworks, libraries and associated best practice can make this compulsion exhausting.

This article outlines why I feel it is not appropriate to become an expert and why the benefit of trying new things outweighs the lack of experience you may have.

In many ways I feel that the Facebook motto is similar to what I'm promoting here.

Move fast and break things

The motto has now been amended and as XKCD summarises it's not always appropriate!

Or to borrow from the lean move movement

Fail fast, fail often

Many years ago I took the conscious decision to opt for a breadth-first learning approach. You can listen to an excellent talk from Don Norman describing depth and breadth-first learning here https://www.ted.com/talks/donnormanondesignand_emotion/

Why I've chosen breadth-first over depth-first learning

Personally I encountered these approaches via a desire to understand as many options as possible before making a decision, but having found a term which matched what I considered a slapdash approach I continued to focus on learning new things versus becoming expert in one.

Respected industry guru's such as Jon Skeet are experts in their chosen technology and whilst I'm not suggesting they are only an expert in one area I feel that judging yourself against these standards is inappropriate.

I would suggest that following prominent tech representatives on something like Twitter can be largely depressing. You see all the great things people are doing, all the highlights from experts in hundreds of tech areas, specialist projects and funded commercial ventures and it's easy to feel like your knowledge is inferior in all ways.

The expert tag is a specific barrier to entry when people wish to learn a new skill. Colleagues I've spoken to have been put off investigating an idea or asking a question because they feel it may make them look stupid. I have certainly experienced arrogance from other people who feel that certain aspects of their specialism should be common knowledge and aren't as helpful as they could be when less experienced users attempt to ask for assistance.

Be a novice, it's good for you

I would suggest developers should aim to be as non-expert as possible as often as possible.

By opening yourself up to a novice state you focus on learning and new ideas. By intentionally being non-expert you are forced to asked questions to help you understand but more importantly you need to listen to those answers with an open mind.

There is so much value to be had for putting yourself out there by trying new things, engaging in the open-source community for example where you will meet some frankly miraculous people are often willing to devote their time to help you get their tool up and running.

Each time you choose to become an expert it is at the expense of experiencing something else. I'm not suggesting you don't try to learn what is necessary to succeed in the project or tool-set your currently using, but I am suggesting that spending too much time fixating on memorising the specific elements of a language or library is largely redundant. Being more aware of the general direction that the industry is heading and being able to recognise when something is becoming old hat is also a valuable skill for your career.

When you are open to trying new tools and technologies you allow yourself a mechanism to de-risk these things by experimentation. You can find ways to produce MVP's or proof of concepts with these tools and put yourself in the best position to critically analyse whether these are appropriate for your next large scale venture. You are also in a better position to leave a technology when you try more things as you will have less vested effort and aren't likely to be totally dependant on it.

Finally, the act of trying new technologies is fun! once you are able to get over any desire to be brilliant at something you will find yourself less frustrated at not being able to complete simple tasks, more tolerant of methods you're not familiar with, and accepting of needing more time to find solutions to problems. All of the previous points are valuable day to day developer qualities, re-read the previous sentence and ask yourself if those are things you'd value or not?

No one is an expert anyway

Over the years I have worked with several very talented colleagues and have learned a great deal from them. Over this time one thing has however become clear, whilst they may be an expert in certain areas they are certainly not in others.

More and more, developers are asked to cover a wider range of tasks ranging from dev ops, to design and user experience. Especially in smaller or medium-sized organisations where companies want multi-skilled developers able to fill multiple roles or be the Full Stack Developer. This article by Daniel Borowski outlines my point very succinctly.

Being a Full-Stack Developer doesn’t mean that you have necessarily mastered everything required to work with the front-end or back-end, but it means that you are able to work on both sides and understand what is going on when building an application

TLDR; It is commercially viable to be proficient in many areas but an expert in few.

At the end of the day, you will need to decide for yourself, do you aspire to focus all your time and attention in one area? or do you want to master the key points of many?

Being an expert is valuable in many cases but it's not for everyone and the overall point I wish to stress is that you can make a pro-active choice not to be expert and be happy and successful with this decision.