Probably, everyone wants to become better. As a programmer, I want to grow better day by day. I bet every programmer out there wants the same. We all acknowledge that to get better at something, it calls for not only the will to become better but also needs one to build around great habits and get consistent.
There are easy career improvement goal to give oneself, but “become a kick-ass programmer” is not a simple goal. For one thing, saying, “I want to get better” assumes that you recognize what “better” looks like. Plus, too many people aim for improvement without any sense of how to get there.
So let me share a few working guidelines that can act as a flowchart to improving your programming skills.
1. Remind yourself how much you have to learn
The first step in learning something is recognizing that you don’t know it. That sounds obvious, but experienced programmers remember how long it took to overcome this personal assumption. Very many programmers tend to have an arrogant “I know best” attitude, a robust certainty that they know everything and the intense need to prove it. In other words: Your “I know what I’m doing!” attitude can get in the way of learning anything new.
2. Stop trying to prove yourself right
To become great—not just good—you have to learn from experience. But be careful, experience can teach us to repeat poor behavior and to create bad habits. We don’t wanna be the programmers with five years of experience … the same year of experience, repeated five times. Haha! To avoid that syndrome, look at everything you do and ask yourself, “How can I make this better?”Do not look at your code to admire its wonderfulness. It is a bad habit to write tests to prove that your code works. Instead, write tests with an aim to try to make it fail. Truly great programmers actively look for ways to make their programs fail—because they know that eventually, users will find the defects they missed.
3. “The code works” isn’t where you stop; it’s where you start
Yes, your first step is always to write quality software that fulfills the spec. Average programmers quit at that point and move on to the next thing.
But to stop once it’s “done” is like taking a snapshot and expecting it to be a work of art. Great programmers know that the first iteration is just a normal step. It works— congratulations!—but you aren’t done. Now, make it better.
Part of that process is defining what “better” means. Is it valuable to make it faster? Easier to document? More reusable? More reliable? The answer varies with each application, but the process doesn’t.
4. Write it three times
Good programmers write software that works. Great ones write software that works exceedingly well. That rarely happens on the first try. The best software usually is written 3 times:
- First, you write the software to prove to yourself (or a client) that the solution is possible. Others may not recognize that this is just a proof-of-concept, but you do.
- The second time, you make it work.
- The third time, you make it work right.
This level of work may not be obvious when you look at the work of the best developers. Everything they do seems so brilliant, but what you don’t see is that even rock-star developers probably threw out the first and second versions before showing their software to anyone else. Some times, Throwing away code and starting over can be a powerful way to include “make it better” into your personal workflow.
5. Read code. Read lots of code
This is indeed both the most common and the most valuable suggestion for improving programming skills. What is less evident are the reasons why reading others’ code is so important.
When you read others’ code, you see how someone else solved a programming problem. But don’t treat it as literature; think of it as a lesson and a challenge. To get better, ask yourself:
- How would I have written that block of code? What would you do differently, now that you’ve seen another solution?
- What did I learn? How can I apply that technique to code I wrote in the past?
- How would I improve this code? And if it’s an open source project where you are confident you have a better solution, do it!
- Write code in the author’s style. Practicing this helps you get into the head of the person who wrote the software, which can be very helpful.
Warning: It’s easy to read a lot of code without becoming a great programmer, just as a wannabe writer can read great literature without improving his/her own prose. Plenty of developers look at open source or other software to “find an answer” and, most likely, to copy and paste code that appears to solve a similar problem. Doing that can actually make you a worse programmer since you are blindly accepting others’ wisdom without examining it. (Plus, sometimes, it may be buggier than your own code, but because you didn’t take the time to understand it, you’ll never recognize that you just imported a bug-factory. Haha!)
6. Write code, and not just as assignments
Working on personal programming projects has many advantages. For one, it gives you a way to learn tools and technologies that aren’t available at your current job, school, etc, but which make you better and sharper. Whether you contribute to an open source project or take on startups with friends, you’ll gain tech skills and self-confidence. Plus, your personal projects demonstrate to would-be employers that you’re a self-starter who never stops learning (incase employment is your main aim).
Another advantage of writing code for fun is that it forces you to figure things out on your own. You can’t leave the hard stuff to someone else, so it keeps you from asking for help too soon.
Pro tip: Try as hard to figure most things out on your own (self-taught). It makes the curve less steep as you figure out your own ‘curriculum’. This is particularly important when learning new technologies.
7. Work one-on-one with other developers any way you can
It helps to listen to other people. That might mean pair programming, or going to a hackathon, or joining a programming user group. When you contribute to an open source project, pay attention to the feedback you get from users and from other developers. What commonalities do you see in their criticism?
I could keep going, but a key point of self-improvement is building consistency. This will breed a habit and eventually a lifestyle of growth.