In the 20 years that I've been a programmer, I can safely say that there are things that you can do that can either make you a terrible programmer, or an amazing one. And I've done both. Alot.
And that's just fine as it is all a part of the whole learning process. So to save you some time and trouble in having to figure out what those things are (that make you good), here is my quick list of the top things that you can do right now, in order to become a much stronger programmer overall.
Starting with my personal favorite.
Stick to a single tech stack
I get it. You want to learn every and all things having to do with programming. That means multiple languages and the latest and greatest frameworks. There's nothing inherently wrong with that train of thought, really. I want to learn all of them myself. And I've attempted to do so for years now.
But after almost 20 years of programming, both professionally and personally, I can safely say that the total number of programming languages that I know super well, is 1. That's right. One. Uno. (Maybe 2 if we count JavaScript).
And if you're wondering whether I've struggled to get jobs or make ends meet during my career, then I can assure you that the answer is no. I've worked at plenty of organizations and have lead big projects during my career. But all of those jobs have revolved around the same programming language and same framework. I was hired specifically because of my knowledge in C# and .NET.
Because learning a single tech stack, and learning it well enough to work on large and complex projects, takes an enormous amount of time and energy. Typically this is on the range of multiple years and multiple projects.
Not to say that you can't learn more than one, because you totally can and at some point you should. But you shouldn't make the priority to learn as many as you can. The priority should always lie in learning a single technology stack to the best of your coding ability in order to make the most impact.
Read other people's code
The more you are exposed to different scenarios, and specifically different solutions to different problems, the better you will become at that thing.
And the simplest way to do that, is to simply look at somebody else's code to see how they approached a problem.
The goal here isn't to copy anybody's style or logic, far from it. You just want to see how they solved the problem. Often times other developer's methods are very similar to the one that you would have applied. But other times though, you might be surprised to find that the person took a whole different approach that you would have never thought of yourself.
They might have even used methods and properties that you were totally unaware of. Maybe a complex 10 line script, can easily be done with a single line arrow function. You just weren't aware that it existed.
The more code that you can read, the better prepared you will be for when you encounter something that you don't quite know.
I personally spend some portion of the day just reading through coding blogs, such as this one, looking at what other developers are getting their hands into. Often times it inspires my next idea.
Refactor your code
Code can get old and it can do so faster than you realize. Whatever amazing script you wrote last month that you couldn't believe came from your own hands, might be some of the worst code that you've written today.
And that's not wrong, by no means. If you are working towards getting better and better constantly, then you can expect this to happen time and time again.
That's where refactoring comes in. Refactoring essentially just means rewriting your code to improve overall performance. And this is usually done by removing duplicate code, creating more functions to call and by creating libraries where groups of functions can be sorted into.
But the biggest benefit of refactoring, isn't so much in the precious clock cycles that you will save. It's really in the amount of potential errors that you will find as you revisit your old code. Because I assure you, there's at least 1 in there that will cause problems down the road.
Refactoring is something that is best done sparingly though. Maybe after several weeks of constant code tweaking and deployments. And that's because it does take a considerable amount of time to do. At least, to do it well.
And there you have it everyone. There's alot more that's involved in being a good programmer / software engineer of course. But I find that these 3 are near the top when it comes to common mistakes that developers make.
So I hope you found it useful in some way and/or capacity. Be on the lookout for parts 2 and 3 of this list, where I go more in depth into the technical side of being an overall better developer.
Top comments (0)