A project manager once asked me, "How long would it take me to learn coding well enough to review a PR?"
I gave a quick answer on the spot but I've thought a lot about that question since it was asked. It's a valid question with a complex answer. At the time, we were swamped with work, as all startups are, and a few members of the product team had the idea that they would study and learn enough C# to be able to review pull requests and reduce some of the workload on the developers.
Coding Is A Small Part Of Software Development
Baked into the question is the assumption that understanding code is all that is required to review a PR. But coding is more than just understanding syntax. Take the following contrived example (and assume these variables and functions exist):
foreach (var user in users)
{
foreach (var user2 in otherUsers)
{
if (user.Id == user2.Id)
{
await UpdateUserDifferencesInDbAsync(user, user2);
}
}
}
The syntax is valid but unless you understand what's happening behind the scenes you may not see the potential issues in that code. Evaluating code requires not just understanding the syntax, but understanding what the code causes to happen. What are the effects that the code has on the application, or the database, or any other components involved? Is this being run for 10 or for 10 million users, and does that matter?
The Hardest Part Of Software Development
Programming is about more than just understanding syntax enough to read or write it. It's also about understanding the effects that the code will have. Not only is coding a small part of software development, but it's not even the most difficult part. In my opinion, the 2 most difficult parts of software development are:
- Convincing non-technical stakeholders of the importance of engineering-driven initiatives.
- Transforming business requirements into a technical plan.
Before code can be written, we need to understand what exactly we're building.
- What tech stack or tools are we using?
- Do we need to provision any new resources?
- What does the data flow look like?
- How do we handle errors or malicious use?
- What is our risk mitigation strategy?
- Will this scale and how?
- What kind of observability do we have or will we need?
- Does this require any database changes?
The above is not meant to be an exhaustive list. It is some of the common questions that need to be answered when building a new application or feature. Once all these, and possibly other, questions are answered, the code then becomes incidental. The code is simply instructions. Figuring out what instructions need to be delivered is the harder part.
Code is similar to writing in that sense. Just because you can put together a paragraph in MS Word doesn't mean you can be a best-selling author. Writing is about much more than understanding language. Similarly, programming is about much more than understanding code.
So How Long Does It Take To Learn To Program?
As someone who has done both, I would say that learning to program is similar to learning to play an instrument in terms of the amount of effort and length of time required. Rather than a specific skill, they both encompass a wide scope of knowledge and multiple skills about which countless books can and have been written. It takes time to achieve a minimum level of proficiency. So how long is that?
The short answer is:
It depends.
- How much time are you willing/able to devote to learning?
- How motivated and disciplined are you?
- How much do you enjoy it?
That last question is very important. When learning to code or learning to play music--and I imagine most other things that require a high degree of effort to master--you will encounter times when you hit a wall and are so frustrated that you consider throwing in the towel. Do you enjoy the thing enough to push through the frustration and keep going? If the answer to that question is "No", then the harsh truth is that you will likely never be good at it. I'm not saying it (coding, playing music, whatever) has to be your life's passion, but you have to enjoy it enough to want to keep doing it. Being good at something complex requires a willingness to suck at it for a while.
Can you be good after 6 months? Sure, anything is possible. Maybe you have a natural knack for it and can pick it up quickly, but I would argue that if that were true, you would already be doing it.
Are you likely to be good after 6 months or even a year? For most people, the answer is no, and that's okay. It doesn't make you a bad programmer or bad musician if you're not good after a year of learning. Most people aren't.
Any halfway decent developer is continually learning and improving. Most developers are horrified by their own code from 1 or 2 years ago. And that first time you review someone else's PR, you'll likely not feel like you're ready.