Over the past year I’ve taught myself to code. I’ve built and launched four web applications, taken courses from front-end to back-end, can work with APIs, and know what a Promise is.

Yet for some reason, I still don’t feel like a developer.

I thought this feeling would slowly fade over time as I learned more, built more, and code no longer looked so foreign. But to this day, this identity still doesn’t seem to fit and it’s unclear when it ever will. I’m left wondering...

When will I feel like a developer? When will I “become” one?

I’ve been thinking more about why I still feel like an imposter. Is it due to a personal perception, an external one, or another reason entirely? I decided to reach outside of my own world to find out.

TL;DR

When do you become a developer? No one knows!

The Golden Question

I decided to poll hundreds of people to see when they thought this inflection point happened. Was it when you…

  • Wrote your first line of code?
  • Got your first user?
  • Created your first project?
  • Got hired as a developer?

Or perhaps it could be something else entirely? When you...

  • Understood the difference between X and Y?
  • Could teach another person development?
  • Moved past “Mount Stupid”?
Image Source: Manzoor's Thoughts

Candidly, I was expecting the responses to fall more heavily within “Woah IDK”, since I was so unsure of the answer myself. Interestingly enough, many people seemed to have concrete views on this. However, what was perhaps just as telling was that those views diverged from one another. All answers received ~20-30% of the votes and from a quantitative perspective there wasn’t any more clarity as to what the “right” answer was. Perhaps that was the answer in itself.

A “Developer” Perspective

First, I’d like to share some of the responses from those who did have a defined point of view.

Write first line of code (17%)

From Quora: “You can consider yourself as a programmer when you are able to write at least one line of code. We don’t care about the length of the line, but this line of code should produce something which is correct.”

Create first app (33%)

Get hired as one (22%)

Woah IDK (28%)

Other

How to Save the World

The results of this thought experiment reminded me of a video that I saw in the earlier days of the social media﹣back when Vine was a thing.

The video was titled “How to save the world”. Naturally, you’d expect something highly enlightening about the state of the world and/or our future, but instead you get a boy who says:

  • "How to save the world"
  • Search for world
  • Click on an image
  • And “save” the world (as he’s saving the image to his computer)

Obviously this is a joke, but perhaps an unintentional lesson that we don’t always need to take things at face value. Perhaps there are more interesting interpretations of what "a developer” is or "how to be a developer" that we can dream up and maybe learn a thing or two while we’re at it.

“What do you do?”

I started to think about what software developers really do. Upon further consideration, it became apparent that software development often doesn’t have the same enforced credentials as some other occupations. For example, there are rarely self-taught doctors or open source construction projects.

Sure, there are many software engineering degrees, but there are also a significant number of paid/non-paid contributors in the software industry that do not have any sort of certification.

With so many people "coding without a degree", I’ve put some thought into why some roles require a degree and others do not. I came to the following two thoughts. A profession that requires a degree...

  1. Has an agreed upon, correct approach to get to a specific outcome
  2. Has a certain set of steps required to learn said approach

For example, someone who is a doctor needs to learn a discrete set of theory, do a discrete set of surgical procedures, and when push comes to shove, they need to know the “right” answer. Of course, there are some situations with ambiguity, but in many cases there is a correct order.

What I find so interesting with software is that there are a myriad of approaches that can be taken to get to a myriad of solutions. In other words, there are many wrong methods, but also many correct methods﹣and you can get to these correct methods without being formally trained. This is partially due to the democratization of information, but also that software development is in many ways the act of problems solving without a single correct answer. Therefore, there is no single approach to learning it.

For example, there are software engineers who can create similar solutions with completely different inputs (ex: languages, frameworks, tools, functions, etc.), while others are also creating wildly different solutions with the same inputs (ex: unique applications with the same underlying tooling). This rings true for other creative industries as well. For example, if you gave two people a canvas and paint, they could create wildly different things in which neither would necessarily be incorrect.

“So, are you a coder? Well, are you a problem solver?”

Nth Degree of Correctness

I think we can further this idea, through the concept of certain roles having an “Nth degree of correctness”. What I mean by this, is the varying degree of approaches that will get you to a “correct” solution. For example, with data entry there is one correct solution: the data getting input correctly. Sure there are variables like speed, but ultimately, there is only one correct outcome. As we’ve already identified, software engineering almost always has multiple correct solutions.

"In fact, no one understands as well as a computer scientist that in the face of a seemingly unmanageable challenge, you should neither toil forever nor give up, but as we’ll see, try a third thing entirely." – Algorithms to Live By

We can start to visualize some of these roles and their “degrees of correctness” in an effort to gain some clarity regarding how jobs or industries may evolve.

The further to the left (the fewer “correct” solutions), the more that particular skill can be trained and repeated. This is also similarly true for the skills which can eventually be trained by a computer to learn and repeat.

On the contrary, the skills on the right rely more on problem solving, discretion, and ultimately the lower barrier to entry opens up new approaches to learning which we’re seeing in many spaces like design, development, and marketing.

The Beauty of Development

As aforementioned, in order to participate in some industries, you need clear accreditation. This in itself has compounding effects on the difficulty for independent parties to contribute and advance the space.

Perhaps that’s something so beautiful and optimal about software development. Its lower barrier to entry is what enables so many people to contribute and perpetually keep the industry growing and thriving.  

That’s inherently why no other industry can keep up with the level of innovation that software allows, not just due to its function, but it’s openness. When you have millions of people openly contributing to something, those contributions inevitably result in progress and with that constant evolution, there will always be something new to learn. This results in an infinite learning curve which I think is beautiful.

Keep Your Identity Small

The concept of “becoming a developer” also had me thinking about identity. Paul Graham, well-known YC co-founder, has given the advice to “keep your identity small”. Perhaps we can utilize that idea to further understand the implications of the original question.

Starting with a definition taken directly from the WWW, a software developer is:

A programmer, developer, dev, coder, or software engineer is a person who creates computer software.

Notice that the definition doesn’t include any information about degrees or projects or status, but instead focuses on the act of creating. If software development doesn’t require a formal degree and all it really means is to create software, why do so many people have trouble considering themselves one.

Perhaps that’s because more often than not, a different picture is painted. Instead, there’s an image (for some) that to be a “developer” you need 10+ years of experience and can code with your eyes closed. I’m being facetious here, but you get the point. There’s some degree of gatekeeping that exists, whether intentional or unintentional, and I believe that plays into our ability to see ourselves as developers, even as we are indeed developing.

For example, someone on Quora mentioned:

I had a professor who once said, "you can't really call yourself a programmer until you understand recursion."

While it’s good to understand the fundamentals, these sentiments or requirements for being a programmer often prevent people from being able to identify with a subject and not everyone is able to effectively “keep their identity small”.

The act of gatekeeping or drilling home the fact that someone is not a developer until X step, results in people (like myself) feeling like imposters. And when someone feels like an imposter, they are unsurprisingly less likely to continue or even start in the first place.

Redefining a Developer

Hopefully I’ve convinced you by this point that there is no specific instance when someone becomes a developer. More importantly, building these barriers can be potentially damaging for people as they’re unable to view themselves in the lens of that identity.

Two concepts emerged from this thought experiment that I like:

  1. A reflection on the beauty of development. The open source nature of both learning and creating is what I believe will continue to make the software industry thrive for many years to come, due to the systems in place which allow for open contribution. There is truly no single path to becoming a software engineer or steps to become a programmer.
  2. The concept that perhaps we should remove “titles” or base them on your level of contribution versus your level of prior knowledge. In other words, your affinity to learn, create, and build. Whether it’s through open source projects, creating tools for the community, writing articles, or mentoring someone, I think that the act of engaging more accurately defines a developer.

In short, it’s now clear to me that especially in software development, titles do not matter. Instead of a one-time designation like a degree, being a “developer” should be measured by whether you’re still adding value.

Perhaps that’s why the word development is so synonymous with evolution.

PS: If you liked this article, you might enjoy my podcast or my latest project.

Related posts about Tech: