A lot of what holds people back from becoming software developers is their being unaware of simple truths about the field. Now, most myths about software engineering prevent people from ever bothering to learn to code in the first place. However, there's one myth that prevents some from becoming a software developer even after they've successfully learned to code. This myth is so dangerous, that it holds people back from applying to coding jobs even though they already have the ability to code.

This myth is the belief that software engineering is similar to most other white collar careers. Specifically, in most careers, there's an expectation that the employee is completely proficient in their line of work before they begin their job.

After all, don't we expect an accountant to know what they're doing before they're hired to do accounting work? And we wouldn't really be okay with hiring a lawyer who is just "winging it". And the idea of coming under the knife of a surgeon who will "figure it all out as they're doing it" is one we'd rather not think about.

Naturally, then, most people assume that software engineering is similar. That is, people assume that one has to be truly proficient in software engineering before being eligible for a software engineering role.

But this is not the case. Every day of the week, companies hire software engineers who are expected to learn on the job and not know everything up front. And this isn't true just for entry-level developers, but for senior-level ones as well.

Why is this the case? Here are four reasons:

1. Accountants needs to know exactly what they're doing because there's this thing called GAAP - Generally Accepted Accounting Principles. This is a standard of conventions that accountants need to adhere to, and major problems will occur if they don't. A lawyer, needs to follow - well - the law, so a lawyer better know the law well. And a surgeon better follow standard procedures or else.

With software engineering, however, there aren't any set of accepted standards. There's no one right way to solve a given problem - anything is fair game. Of course, there are tradeoffs to consider, and one needs to make informed choices about a software decision, but there's no governing body that dictates how a software engineer is supposed to write code. The software engineer, therefore, has the liberty of researching and designing their own solution on the spot without upfront knowledge.

2. With standard white collar careers, there is a finite set of tools and techniques used within a given role. When it comes to programming, though, the options are limitless. There are so many languages, frameworks, and programming tools out there that it's not reasonable to expect a single person to know them all. Every company uses a different set of tools, and can't expect to hire someone who is proficient in all the tools they use. Rather, the expectation is that a new hire won't come in knowing everything; instead, they are expected to learn the tools on the job.

3. Yet another reason why software engineers have the leeway to learn on the job is that the cost of failure is often not as high as in other careers. Bad accounting can easily topple a company, and so can bad lawyering. And mistakes in surgery aren't par for the course. However, a bug in code can usually be easily and quickly fixed. And often, there are systems in place that help catch major bugs in the first place before they have the opportunity to do real damage. Can a software bug ruin a company? It is possible, but it's rare.

Facebook used to have a motto among their software engineering team: "Move fast and break things." This is because they wanted features built quickly even at the risk of introducing bugs. Again, this is because the damage caused by bugs on Facebook hardly meant irreversible damage. If a bug occurred, and say, users couldn't see photos properly, the bug would be reported to Facebook right away by their users, and Facebook would fix it right away. The result would have been some annoyed users who would quickly forget about this blip and move on with their lives.

4. All the above reasons why software developers aren't expected to be proficient at everything are valid. But here's the most important one: The job of an accountant is to prepare financial documents, and the job of a surgeon is to perform surgeries. The job of a software engineer, however, is to solve problems. Yes, a software developer builds software, but every piece of software is unique, which often requires solving new problems that have never been solved before.

Any software developer will tell you that they spend most of their day "figuring things out." They have to figure out why a piece of code is buggy, they have to figure out how to use this new framework, and they have to figure out how to design the most efficient algorithm. Because the craft of software development, by its definition, is learning new things and figuring things out, no one expects a software developer to know everything up front - because that's not what software development is. It's about learning new things - and that's something everyone can do at their level.

New computer science or coding bootcamp grads may be intimidated by the fact that they don't know everything, and don't feel ready to apply to software development jobs. But what they don't realize is that it's not expected of them to enter a job with proficiency. Rather, the expectation is that they come in to the job with the ability to learn and figure things out, and after some time, become a useful contributor to the team.