Coding is an art which does not has a finite way of expressing. Each programming problem can be dealt in several different ways. Some good, some not so good and some disastrous. While all the approaches get the job done in the short term, but it is vital to not just focus on the immediate result but the long term picture. Not only this will help you become a better programmer but also will greatly determine the maintainability of the software and hence the business.
While the Business and requirement is decided by others, the programming is in the hand of developers. And no one other that the developer can understand how a certain way of coding can determine the long term health of the projects. And how can a developer make sure taking the correct decisions at the correct time? By relentless practice, paying attention to details, taking extreme care of the code we write, and more. But how do we reach that point where we can do all this?
We are all apprentices in a craft where no one ever becomes a master. – Ernest Hemingway
We all aspire to become an Ace programmer but hardly know the right path to reach there. Honestly, there isn’t any predefined fixed path. It all boils down to how you take your small decisions everyday. The small things determine the final outcome. Yes, you might need to learn new technologies and upgrade your knowledge based on the changing tech market. But there are somethings which will not change with whichever technology you learn or whatever project which you work on. It’s the small things which people generally ignore dazzled with the huge and exciting task they are doing. So, lets take some time out to look at some very small changes that can be used by programmers of any level of experience to do your small bit towards improving.
Copy paste coding : There are usually two scenarios when programmers hit that Ctrl + C button to copy a piece of code. Either we found some code which solves a problem which we are trying to implement or we are implementing something similar which was implemented earlier in the project and now we need that at another location. If you are doing it for the first reason, then take a moment to understand what that code is doing and then write it yourself. The reason being you will be aware of exactly what the code is doing and you will not paste some code having naming which does not fits with your code. If it’s the latter case and you need similar code at multiple location, better to think about abstracting that logic so that you are writing reusable code. Remember, keep it DRY (don’t repeat yourself).
Think but don’t overthink : It is good to have a clear vision for analyzing long term issues. But coding for them is probably not the right thing to do. Let’s say you need to build a login functionality and your requirement states that you can use your framework’s native authentication mechanism. Now, you as a developer think that it would be cool to have oAuth built in as well. But is it really required? Good to have but not a must have. So, instead of over planning for future, just do the simplest possible thing you can do right now. Ok, maybe not the best example but the idea which I am trying to bring on the table is don’t be lured by what you Can do but focus on what you Need to do. Remember YAGNI (You aren’t gonna need it).
Test your code : If you are not into writing Unit Tests yet, you need to seriously start writing them. I know initially it is a bit confusing to come up with the right unit test cases, but it is a necessity. Just imagine the kind of confidence you will have when you make a change or enhancement, run the test suite and know if you have broken any other module with the changes. Not only will the development process become very reliable but will also save a lot of time and money in the long run. Once you start writing these tests, you will also realize that your code quality will also improve, as you will have to write code which is decoupled and testable. If you are just starting, I highly recommend reading The Art Of Unit Testing by Roy Osherove.
Pair program : Try this if you haven’t already. It is always easy to spending hours coding without actually knowing how productive you have been. Having a paired programmers pushes you slightly off your comfort zone but it also adds the expertise of another programmer and speeds up your work. Also, you will be less likely to get trapped in your own known ways of doing things and get new perspective of others. This can greatly help you increase your knowledge and experience. It is important to find the right pair who can help you up your game vs slow you down. Check this Martin Fowler article to get more clarity.
Keep learning. But what? : Developers face with the challenge of constant learning due to the dynamic nature of tech industry. You learn certain framework’s version 1 and they completely change the product in version 2. But there are some other leaning goals which developers sometime overlook. These are learning about software craftsmanship, development ideologies and processes. Now, these are not specific to a particular framework, programming language or technology. So, it is something that is going to stick with you longer. And you will evolve gradually to make right decisions and pick up and learn new tech. A few good books to start with are Clean Code by Uncle ‘Bob” and Refactoring: Improving the Design of Existing Code by Martin Fowler.
A journey of a thousand miles starts with a first step, these are the very basic, small steps that you can start implementing right away. Do you already follow some or all of these? Do you have a better step that can fit in here? Or for any other opinion feel free to use the comment section below. If you choose to try some of these, do let me know your experience and feedback.