Why I'll Never Be an Expert
Why I'll Never Be an Expert
As a software engineer, I'll never be able to legitimately call myself an expert. In fact it seems that the more I know, the more I know I don't know.
Join the DZone community and get the full member experience.Join For Free
See why over 50,000 companies trust Jira Software to plan, track, release, and report great software faster than ever before. Try the #1 software development tool used by agile teams.
I was watching Game of Thrones recently, and there was a brief mention in one scene of the expert blacksmiths who were used to forge some new swords out of Valyrian steel (which was apparently quite a rare and valuable skill).
I was immediately struck with a sense of envy of people who could legitimately call themselves experts. As a software engineer, I'll never be able to do that.
In fact it seems that the more I know, the more I know I don't know. I can't use the word expert without immediately thinking of at least 10 quite significant aspects of software engineering I am completely inexperienced in, which is quickly followed by the realisation that for each of those 10 aspects, there are almost certainly 10 more that I don't even know I have no experience with.
There is an excellent blog post by Steven Streeting about Why 'software engineering' is a misnomer. It makes some insightful points about the hidden complexities of software development, and why it is so different from typical engineering jobs. There are two points that I would like to add which I think summarise why it is so difficult to call yourself an expert software engineer.
The first point is that as a software engineer you are often solving a real world problem that you have little personal experience with. Whether it be designing an some internal business intelligence system, exposing business processes to customers via the web, or tracking down some obscure bug in an existing application, it is not uncommon for a software engineer to be exposed to the particular problem domain they have been tasked with solving for the first time. It is like being a star athlete who is given a few months to train for a competition in a sport they didn't even know existed.
The second point is that software engineering projects implicitly (and, in rare cases, explicitly) include an almost endless list of non-functional requirements. There are the big ones like performance, scalability, maintainability, security etc. But you only have to look at Wikipedia to see just how many dimensions there are to a software engineering project. Each of these non-functional requirements demands a level of expertise that, when combined, would take several lifetimes to actually achieve.
I think the post Don’t Believe Anyone Who Tells You Learning To Code Is Easy sums it up nicely with the quote:
What I forgot is that the most common state for a programmer is a sense of inadequacy. As a programmer, there is a limitless amount of stuff to learn. You can become a specialist in one language or framework, but if your job is to build things efficiently, you will constantly need to be learning new tools and constantly feel out of your depth. It helps to be mentally prepared for feeling stupid.
So, I'll never be an expert software engineer. As my experience and knowledge increases, at best I'll be able to more fully appreciate just how little I actually know in the grand scheme of things. But that does mean there will always be something new to learn and someone new to learn it from, which is maybe not such a bad thing after all.
Opinions expressed by DZone contributors are their own.