I am a computer science undergraduate and I have recently completed the second installation of programming methodology at my university. After the two-part series of introduction to programming and the data structures and algorithms module, I gained a better understanding of programming concepts and also grew to like the two instructional languages used: Python and Java.
While learning about Streams and CompletableFuture in Java, I came across a series of talks by Dr. Venkat Subramaniam (an award-winning author, founder of Agile Developer) on Youtube. Not only were the videos highly educational, but they were also fun to watch. Today I finished another video by Venkat that talked about the twelve ways to make code suck less.
(Embedded at the end if you want to watch the full talk)
I thought it would be a good time for me to reflect on some of the pointers mentioned in the talk, as a way to review and consolidate my learning.
1. Reduce State & State Mutation
One of the key takeaways from the modules that I took is to write immutable code. Instead of modifying the properties of an object, return a new object with updated properties. Instead of writing a class starting with properties and then proceeds to methods, do it the other way round to reduce introducing unnecessary states.
3. Give Good Meaningful Names
I know this is such a cliche but it really helps in code comprehension. I spent an entire semester writing Java code in Vim, without code hinting. There were many times when I needed to reference variables/properties with long, descriptive names and I wondered why did I make it so troublesome to type them out. However, I also found myself spending less time questioning the meaning of the pieces of code that I wrote. I would say good meaningful names (that may sometimes be necessarily long), are good investments that pay dividends.
5. Comment Why, not What
When we have proper variable names, the need to comment reduces dramatically. This is because most of the code that we write becomes self-explanatory. Instead of commenting on how a piece of code works, we should therefore move on to explain why it works. When the code is clear enough, we remove comments entirely. A practical lesson that I learned about comments is to always remove code that we made changes to, instead of commenting them out so that we might want to use them again. Just remove them altogether!
9. Program with Intention
Code is ideas initiated in our brain and then manifest on our screens. Recently I was writing code for an assignment and I had to provide some methods and properties that were shared by a class of objects. Instead of making them static properties and static methods, I decided to just add them as instance methods and instance properties because of all the instance methods that I was creating at that moment. So I knew that it was not a good idea but I told myself to wait till it became a problem.
As I developed the program further, I needed to add in more shared methods and properties that were supposedly static. And that had resulted in a long chain of parameters that I had to pass into the constructor of some classes in order to carry information over. The program had grown to be unpleasant to look at and even more difficult to make changes to. I told myself to stop before it's too late and refactored it overnight. After removing all the noise from the program, I was able to make the right adjustments in order to make it run as intended. Either you go fast and be forced to go slow, or you go slow deliberately so that you can go fast later on.
12. Schedule Time to Lower Technical Debt
The moment that we know our design sucks, that's probably the best time to start repaying our debt. This is especially important when working with other developers because not only do we make it hard for ourselves, we are going to watch others suffer in agony.
I also learned two important lessons about learning:
1. Learn through teaching
I wrote a series of articles on OOP and Java that directly correspond to the lessons that I learned from my classes. On top of that, I also spent quite some time trying to explain concepts to others in doubt. While constructing answers to those tough questions, I had to make sure that I know my stuff. Those were the moments when I researched and attained a deeper understanding of the subjects.
2. Learn through restricting
I am now at a comfortable level using Vim as a code editor, and this came from the fact that it was the only option available for the module that I took. Another interesting example occurred when I was learning Java's Optional API. When .get() and isPresent() were explicitly forbidden, I was forced to look for other suitable methods to use instead of trying to take the value out of the optional. This is the first time that I had to really study the Java documentation and understand all the available methods that are already provided in the JDK. Sometimes when conditions are imposed on us, we become more alert and willing to explore alternatives.
Appendix
Twelve Ways to Make Code Suck Less by Venkat Subramaniam
Top comments (0)