Are you doing the right things for becoming a better coder?
Programming is like any other human activity — there are going to be child prodigies on the extreme right of the bell curve, there are going to be people of average ability, and there are going to be people on the far left.
I believe the only people who are unable to reach a level of programming competency are those with mental handicaps, which prevent them from competency in most kinds of human intellectual activity.
So, assuming you have average cognitive abilities, can you become a great coder? An obvious necessary requirement to becoming great at something is to first acquire basic competency.
There are many more things to programming than just being a rather nerd about studies and trying new codes without knowing them.
When met with a roadblock, most people I’ve interacted with react with either frustration or curiosity. Sometimes both.
But more curiosity and less frustration tends to lead to a better learning curve. And programming requires constant learning.
It’s not something which you will read the first day and build an empire the second. It’s gradual learning process that speeds up with your curiosity.
By taking away all assumption that their code is semantically and syntactically correct, the better programmers tend to catch and fix their bugs quickly.
Be ready to accept your mistakes, because they make you understand where you went wrong and what you can improve.
What doesn’t kill you, simply makes you stronger.
Programming is a simple process, once you get a hang of it, you’ll never want to leave.
Programming changes so quickly compared to other industries. What was best practice yesterday might not be best practice today.
For example, in the world of front-end JavaScript libraries, React and Redux brought the immutable state philosophy, and Vue/Vuex are already bringing on the “let’s mutate state” philosophy.
Much like a tree in a windstorm, if you sway with the wind, you will remain standing.
The gap between the best software engineering practice and the average practice is very wide– perhaps wider than in any other engineering discipline.
This is like the way that years of practice puts you in the state where you do not have to think about each individual finger position while playing a musical instrument.
Once you know what you want a piece of code to do, the code just seems to flow out of your fingertips onto the keyboard.
Study the foundations of computer science: how hardware works, how a compiler does its job, how different algorithms work.
Learn how to analyze an algorithm in terms of how much time, memory, and I/O access it will require, as a function of the size of the problem; this may tell you if your approach is even practical.
Do you know what “NP Complete” means? You should.
What?
No wait, here me out first!
The greats don’t just solve coding problems. The greats create tools that others can leverage to solve problems.
Whether those downstream of you are in your organization or not doesn’t really matter.
What matters is that your code is readable, comprehensible, usable, extensible, compatible, amiable, likeable, etc.
Middling and good programmers can create APIs, components, and frameworks that other teams can interact with on an ongoing basis, but it will typically take coordination, modification, and collaboration.
Great programmers can build APIs and components, drop the mic/keyboard, walk away, and still have an impact.
Think of what a good API looks like. Interfaces self-document, allocation and resource retention semantics are coherent, threading concerns are cleanly managed and consistently expressed, etc.
What about components? Capabilities scale cleanly, integration burdens drop, interfaces allow for natural extension, problems that the component author never dreamed of can be solved concisely, etc.
This is the reason that people take computer science classes.
You can arguably learn this information on your own, but it is much, much harder because you do not know what is important, and you don’t know how to present the information to yourself in a way that makes it effective to learn, and builds on what has been learned.
Learning any one computer language is not a substitute by any means. For software, you need to know the following topics well. At least, you should be able to make yourself understand what is happening and why is it happening.
You need to understand how to write a coherent description of the problem to be solved (“requirements”) without committing to a solution (except where dictated by your customer, and even then you should resist).
You must understand how to compose system elements to achieve a solution to the problem (this is where “coders” do not make great engineers: they think the problem is about code).
Also, I think you should want yourself to be a better Software Engineer, rather than a coder.
Often you need to decompose complex requirements into smaller pieces, invent solutions to the parts, and then recompose the partial solutions to achieve a full solution.
I don’t know of great ways to learn how to do this, Polya’s book “How to Solve It” is a classically good place to start.
I think the AI community dives deeply into this, and I would take basic AI classes to get this background in a more structured way.
I also like the “MIT Model”: propose 10 solutions before you choose one. Problem solving applies both to designing the overall solution, and to low level coding.
There are many great coding languages out there, one of the best is Java, which is used in tons of industries.
You can’t just stop at what you learned in school. Pursue and read technical literature on computer science, software engineering, your specialty area.
Always be ready to understand and learn from others, that’s what makes you a team player and a better coder in future.
There are tons of professional societies and technical journals out there. Choose several and try to keep up with the firehouse of information.
You can’t, but you’ll be much better for trying. Attend conferences relevant to what you do.
Discipline is a subtle and inherent aspect of a habit. Learning how to program will require you to write or read code nearly every day.
This level of discipline is challenging, until it becomes a habit. Habits are almost unconscious, and become part of your daily routine.
Like going to the gym in order to get fit, writing or reading code for an hour a day needs to become part of your routine.
These are some of the ways to become a good programmer, but all this is not just the end. It’s just the direction to you.
Working hard, understanding concepts and being rather conscious of your work and code are obviously more important things.
To sum up you can perform this to evaluate yourself (this is just light humour with basic facts, not real):
Do you still make mistakes?
If NO > You are not a good programmer.
If YES > Are those different from what you use to make earlier?
If NO > You are not a good programmer.
If YES > Are those mistakes different than that of syntax or language?
If NO > You are not a good programmer.
If YES > Are you still learning new concepts?
If NO > You are not a good programmer.
If YES > Do you follow Stack overflow and have good understanding about memory, how to use it and how it works?
If NO > Start following and you will be a good programmer.
If YES > Awesome. You are a good programmer.
Peace Out!