Becoming a Better Coder

There are all sorts of pedagogies and philosophies for improving yourself. It doesn’t matter what field. It’s a common for classical musicians to start entire schools based around their personal pedagogies. In light of this, I’d like to present my personal method for becoming a better coder. This is the routine that I follow.

Whether you’re a new developer or an experienced one, I encourage you to read this. Even if you’re the best coder in the world, I’d like to know your thoughts on if my philosophy is useful / boring / unnecessary / etc. And hey, you might gain a new perspective.

Philosophy

I believe that the best programmers are ones who have domain expertise but are flexible. Often, I’m asked, “What languages do you know?” I can’t help but think that this is a pointless question. Programming evolves on a day-to-day basis, and different languages suit different problems. If you only know one language and cannot adapt to fit a new situation, you’ll be a one-trick pony.

That being said, there is a lot of merit in knowing one engine inside and out. The hardest problems cannot be solved by Googling, and will require a deep knowledge of not only how a system works but why.

My personal pedagogy is designed with these two concepts in mind. I’m training myself to be the best I can be in the field of my choice, but with a diverse enough toolkit to tackle any problem.

I believe that we should practice coding the same way one practices music. Even the greatest pianists do technical exercises every day. Similarly, I believe that no matter how good or accomplished you are, there are fundamentals you need to train every day.

I break down programming into four main components.

Programming Theory

This refers to developing an aptitude for the act of coding itself. This means learning languages, libraries, APIs, and so on. No matter how good you are at a language, there is always more to learn. If you’ve been comfortably using Javascript in webpages, push yourself to make apps and learn closures. If you’ve never seen ES6, learn that. If you know everything about ES6, read a style guide. If you’ve read every style guide, learn a library. There’s always something to do.

This section also includes learning a new language. I feel like learning the advanced aspects of a language you’re familiar with is similar to learning a language you’ve never seen before. I encourage exploring known languages further and learning new ones. I think it’s important to always be doing both. Essentially, this section refers to the engineering part of programming. If I’m given any problem and I’m told to use any platform, can I understand all the tools available, identify the best one, and use it to construct a solution?

I find that a good rule of thumb is one concept a day. For Javascript, you might do closures one day, then prototypes the next. Make sure you really spend the time to understand the concept fully.

Computer Science

This refers to, essentially, data structures and algorithms. These are things you can learn with a pencil and paper (but not implement). This is the abstract side of programming, while programming theory is the concrete side.

The implementation is just as important as the understanding. Every language has its quirks that necessitate a certain algorithm being implemented in a certain way – whether it’s with using pointers, stateful functions, etc. I try to regularly learn and implement new algorithms.

I try to learn and implement an algorithm a week. I try to not use the same language too many times, so that I can become fluent in multiple languages.

Demos

Demos are essentially small projects. They are usually used to demonstrate understanding of a particular topic, often showcasing a neat usage of one algorithm. The point of demos is to keep you creative. I feel like just being a good engineer is boring. The ability to generate ideas, connect concepts, and create applications is inherently tied to creativity and imagination. However, contrary to popular belief, these skills are very much learnable.

For reference, ‘demo’ refers to something of about this size.

I try to do one to two demos a week. I often end up making demos for the algorithms I’ve just learned. Also, another advantage of consistently doing demos is that it quickly builds up a portfolio to send to potential employers.

Projects

Projects are the bulk of coding and are the most important part. They’re what coding is spiritually about. Projects are the things you make. This includes both your work / job and personal projects. I lump them all into this category – they’re long-term pursuits with no clear end and often involve many languages and algorithms at once. They’re things that you’d be happy to publish and/or monetize.

Spending lots of time on theory is no use if you can’t put it into a project. No matter your skill level, even if you’re a total beginner, you should always be working on a project. I don’t care if you’ve read the whole Java spec start to finish, if you’ve never made a project, your skills are worthless.

One issue that I’ve personally observed often is the lack of focus on project work in the AP Computer Science curriculum. Schools treat coding like any other class, when in reality it is more of a skill than a subject. Sure, computer science is often very much like math – but AP CS in high school barely teaches any computer science at all. In general, high school CS education is broken. Hell, the AP test is taken with a pencil and paper! What results is a slew of high-scoring CS students who can barely code.

You should spend as much time as possible working on a project. If it’s a project you care about, it’ll keep you up at night.

Scheduling

How you schedule your work day is entirely up to you. These are just guidelines, but I’d recommend spending an absolute maximum of one-third of your time on non-project stuff. Even if you’re in a rush to finish, spending time away from your project can actually accelerate the development process.

You can read about relevant algorithms or learn the engines you’re using more in-depth. Often, this will actually save you time in the long run, especially if you learn a key paradigm or model. For instance, writing an app with or without MVC philosophy is an entirely different experience. Just don’t forget to make time for demos.

When I’m not in school, I probably spend about 10 hours a day coding. Out of those 10 hours, 8 will be project work.

Conclusion

Well, that’s all for me. This is what I tell people who ask me for help, and this is what I stand by. Feel free to contact me with your thoughts – I’d love to hear what your learning strategies are, whether you agree with me or not.