How to Know When You’re a Good Programmer
When beginning a discipline, everybody wants to know what it takes to understand the technologies or programming languages and quickly get to the advanced stuff. People tend to gravitate towards what’s hip and trendy. Everybody wants to be efficient, shorter is better, absorb as much as you can so you can attain mastery in 6 months! Right?
Not necessarily. This article is going to highlight why diving head-first into a particular technology, design pattern, programming language, or popular technology will not make you a better programmer.
Why? Because programming is about problem solving. It’s about giving the users what they want. The technologies are only a means to doing so. If you rely too much on one technology or one framework, you will be limited by the scope of your tools.
So what makes someone good? A good programmer should be able to solve problems that even the framework itself cannot provide adequate solutions to. Once you’ve learned all that there is about a framework or a programming language, that still doesn’t necessarily make you good.
Programming heavily relies on experience. Despite object-oriented programming, design patterns, programming languages, best practices, agile/agility, guidelines, books, functional programming, and mentors, you cannot be a good programmer without making your fair share of mistakes. Nothing beats the raw visceral experience of utilizing the language/technique/design only to realize how wrong you were. Again, programming is one of those arts that relies heavily on experience. Why? Because it is inherently complex and the applications you’re going to write will be different. Will they share similar behaviors in certain areas? Yes, but the requirements that come from humans are unpredictable. There is rarely a clear-cut manual on how to write your real-world application. Let me emphasize this again, being wrong and making mistakes is very valuable in programming, because often times, it is the only way that you can truly appreciate and understand design. Most of our lessons comes from after we’ve made our mistakes, and this is especially true in the programming world.
Don’t get me wrong, design patterns are incredibly useful, but only when you can recognize the pattern. The mistakes that many people make is going into a project too eager to prove they know advanced concepts. This has the effect of forcing a structure on to your application from the get-go and creating an inherent flaw in the application. Not only does this make the application much more complex than it needs to be, it may make certain things infeasible to do because of time and cost constraints. Not only that, the structure which may have been simple to recognize at the beginning may turn out to be impossible to recognize later on due to the layers of needless complexity that has been cemented into your application.
The only reliable metric is program correctness and simplicity. If your program runs correctly and you have the metrics and the methodologies to confirm that, then you have a solid application. If your solutions are simple, it will allow others (and yourself) to understand it more easily, make changes to it, and consume it. These two qualities are also the cornerstone to all other engineering disciplines. They are timeless vastly underestimated compared to the more “advanced” or trendy topics in programming.
When you write good software that runs correctly and when you don’t force a structure on to it, the patterns will naturally emerge. If your code is clean and simple, you will be able to identify and refactor the patterns. Naturally, you will even find newer patterns. When you allow the program to flow naturally, the organic structure will be the design.
A good programmer should be able to detect and recognize all kinds of problems. They should (when necessary) be able invent their own systems such frameworks, operating systems, and even programming languages. I’m not saying that you’re not a good programmer if you don’t “invent” these things, but what I am saying is you should be good enough to know and distinguish what is suitable for use and know precisely why. You should never be stuck with one single solution; there should always be an option to create newer solutions. This is what distinguishes an ordinary programmer from a good programmer; their ability to problem solve, not just their technical skills.
This is the reason why top tech companies hire using computer science problems as a metric. Being able to problem solve allows you to create solutions and systems that are better; it also you to recognize the best existing solutions and use them.
Creativity is an important component in problem solving. Innovation is creative problem solving and it is highly sought after because it directly affects a business’s success. Take for instance, Tesla (electric cars), Amazon (online e-commerce), Google (search engine), Netflix (movies streaming), YouTube (online videos), Intuit Turbo Tax (tax software), and FaceBook (social media). At the end of the day, it is all about adding value and these companies have created innovations that add tremendous value to their users. With that being said — it should be no surprise that these innovation-driven companies value strong problem-solvers.
It is important not to shy away from mistakes. If you cannot afford to make too many mistakes at work, do them on your own. It is good to have an area of mastery or expertise within 5 years about a language or framework, but it is even more important to broaden that experience. What you’ll find is that you do not need to spend another 3 years to attain the same level of mastery because some of the experience and knowledge is transferrable into other domains. That’s not to say you wont spend years on newer concepts. Gaining different perspectives will allow you to recognize a diverse set of problems and allow you to solve them using the appropriate solutions. This will improve the time it takes to create correctly running programs and simple solutions.
On the other hand, if you fail to learn new problems, ideas, and paradigms, you will stagnate. Here are some important domains which you should consider (this is by no means an exhaustive list):
- Compiled Languages
- Scripted Languages (Shell/Web/Cross Platform)
- Web (RESTful Architecture, Full Stack, HTML5)
- Algorithms at Scale
- Realtime Constraints
- Object-Oriented Programming
- Functional Programming
- Desktop Platforms
- Concurrency & Parallel (Threads, Coroutines, Async/Await, Promises)
- Streams & Reactive Programming
- Cross Platform Constraints (Java/.Net Core/Qt/Web/Scripting)
- Mobile Platforms
- SQL
- NoSQL
- Assembly (Low Level Constraints)
- Data (Machine Learning & Deep Learning)
Some of these areas are actually very different from other areas. The fallacy a lot of programmers make is to entirely dismiss an area of study and double down on their area of expertise instead of continuing to widen their understanding over time. Don’t get me wrong, one should have an area of expertise first! Do not stretch yourself thin trying to learn everything all at once. It takes a slow and steady process to attain mastery. However, after several decades of experience, one can attain several domains of mastery (if they so wish). By doing so you get to have a much richer understanding of problems and the available solutions.
Why would one choose to stagnate? There could be many reasons. Most of the time it is driven by contentment and comfort. Learning is an unending process that requires us to “start over”, and people are not used to feeling that way. It takes a lot of effort to step out of the comfort zone, try new things, and take on newer perspectives. Younger individuals do this very well, but every individual at any age can choose to delve deeper and learn more. Learning requires us to humble ourselves and let go of things we thought we knew or understood. In the process of doing so, we gain a more realistic perspective of how things truly are. Many times this new perspective can be very different (and better) than what we imagined it to be. Innovation and creativity comes from these powerful new perspectives. As the saying goes, “the more you learn, the less you know”.
As you get better and as you gain more experience, you will begin to recognize patterns in the projects that you’ve completed. Especially parts in the application that was particularly hard to work on. These patterns are solutions to problems that you’ve faced in the past. When you distill it down to it’s core, it is simply a solution that can be implemented by any number of languages or frameworks. When you’ve accumulated enough experience, you will have, at your disposal, a number of these solutions to these complex problems. Regardless of the platform, programming language, or framework, you should know how to implement your solution for these constrains. This is what makes a truly good programmer. This is also what will make you valuable and indispensable. The more problems you are able to solve, the better programmer you will be, it’s that simple.
If you’re interested in learning more, visit our community…
