Who is a Zen programmer? – Someone who can write incredible solutions by getting into the zone, at any time, at any place.
Is programming really an art? How do you get ‘into the zone’ while programming, and is that consciously possible to achieve? How do you write the best solutions that you can be proud of? ... Ever had such questions? I don’t know about you, but I had such questions, a ton of them over the years as I grew as an engineer and a programmer. In this multi-part blog series, I will go over some tips and skills to focus on mastering the art of simple programming and becoming the best version of yourself - a Zen programmer.
This is part II of the multi-part blog series. In case you missed the last part, then here is your link.
Don’t shy away from learning the advance language skills and tricks
Okay, you got the basic programming skills, got the domain knowledge, and visualized the end-product. Now, you are all set to do the actual programming. You also completed your research upfront and started coding. But during programming, you realize that you need some specific algorithm in your code, but you don’t know exactly what to do (like syntax and constructs wise), so what do you do? Typically, you will open your favorite browser and then google a language-specific solution for the problem at hand. You are very likely to find StackOverflow or similar website-based answers. Should you copy solutions you find there and use them as-is? Or should you just modify variable names to adapt to your software and still use as-is? Well, all those fancy forms are plagiarism!
Here’s the Oxford dictionary meaning of plagiarism:
~A piece of writing that has been copied from someone else and is presented as being your own work
Plagiarism, irrespective of how fancy form it is, will make your code stoop to the level of programmer efficiency who shared the original solution. Many of the websites you copy code from being started initially as a means to guide others in the right direction, give hints, and not share tested code-base. It is also not tested most times for the problem where you want this to run, as the original sharer of the code has no idea of your product or requirement. Keep in mind that using a third-party GPL library from a site like GitHub is different and is not plagiarism while copying code (with whatever modifications) from StackOverflow is! I have seen some seasoned programmers copy code from websites that are purely meant for programming practice, where a novice may share a code. Doing such nasty copying will only yield bad issues in your code and overall inefficient code, so do not copy code from any website. It’s okay to google algorithm to get an idea of what can be done and use it to create alternatives to problems at hand. Once you know what to do, then write code from scratch (unless you end up using GitHub library that does the job for you). It will avoid unintentional plagiarism with code and make your code more unique and efficient to your problem’s solution.
One another best way to avoid plagiarism is to reduce your dependency on solutions suggested by others. The more you need google to tell you ‘what’ to do for the problem at hand, the more you reduce your value as a programmer. Ask this – if Google (and for the sake of the question, internet-based solutions) was unavailable for one day, will you be able to complete the day-to-day job you are supposed to do for your role in where you work? If the answer is no, you have to start over and learn language basics and then advanced language skills. Learn how design patterns help create a robust design and how they are implemented in the language. Achieve mastery of the language. Learn specific areas of language which you often use for your day-to-day job. Find out any built-in or third-party libraries offered in those areas. For example, if you often use Python and databases, then every database client has a library wrapper for Python. Learning those libraries, design techniques, and advanced language constructs for the language you use day-to-day is time worth investing – you will thank yourself just a few weeks down the line as you start investing much time in learning.
How often do you purchase a book on Amazon for language and design and other advanced constructs for the language you use daily? If you didn’t so far, you miss out on a crucial investment that will bear you fruits with your brighter career.
The best review is self-review
Code reviewing is an art, and like any other art, the more you practice, the better you will get in it. Many seasoned programmers think that they can master it by reviewing code for others, but you have to start with yourself in reality. The best way to improve your code is to do self-review first and then run through someone else.
Consistency is more important than perfection.
Frequently, during self-review of code, many programmers are tempted to find spots where they can replace code with something new. It is far more tempting if you are changing existing code done by someone else, but tame your horses, as consistency is far more important than perfection. You may be changing code that is five days old and sometimes five years old. Will you treat both codes the same way? Absolutely not. If your five-year code is running smoothly in production, everyone in your team who potentially works with that code has gotten well versed in it, then unless you have a solid reason to change it, then changing it is selfish. You will reset the learning and understanding of others for the code, adding to their learning of new code. The new risk of regressions for such unintentional changes is also far more than any value that such code change can bring. So before changing existing code, understand intention and context as to why it was done a certain way. You can find original design documents or other forms of code documentation around the code, including often a discussion with the original author of the code, and if you still find changes you have in mind, will cater to the new requirement as well as improve the existing code in a certain way, then go ahead. Avoid urges to use something new as you just learned it and want to show off, as you will soon have time and place to use that new knowledge, so you don’t have to forcefully apply that new knowledge when there is no need. You will have time and place to show off your new learning, so keep some patience.
The self-review is the right place to ask such questions. If you do a self-review of your code before your unit testing, you will find that you have even fewer compile issues over time. If you use interpreted languages like Python, then runtime issues will also go down during your unit testing. Use the self-review phase to cross-question yourself, in much harder ways, whether every decision you took for modified/new code is the right one and if that is the best solution in all available alternatives. It’s also a good idea to do self-review after code completes and gets ready for unit testing before submitting it for review by your other team buddies. The improved self-review will yield outstanding results for you over time.
Evolve with Daily Learning – with your own and others
We are humans, and we make mistakes. There is no area of life where this is not applicable. The programming life is no exception. If somebody tells you otherwise, they are lying. What is important is learning from your own mistakes as well as those of others.
Learn from the mistakes of others, as you can’t live long enough to make them all yourselves! - Chanakya
If you find yourself getting repeated code review comments, then add them to your learning area. If you find that comments are around using better language constructs, or using design patterns or alternative code designs, change those comments to learning tasks. Shying away from learning is shying away from progressing in your career. Don’t defend your solution against better suggestions when deep down know it has better alternatives, which is what your code reviewer, who is often a seasoned programmer in your team, may be trying to point. Keep an open mind, even if your code reviewer is someone junior to you. In such cases, the worst you can do for yourself is defend a shitty code just to end up replacing it with the suggested solution as your code hits day-1 of production.
Is code review the only learning place? Nope. You can learn from all phases of software development in your team, irrespective of which development your team follows (waterfall, Scrum, Kanban, etc.). Be an active participant in design and other review meetings, as you never know that the design you are reviewing for someone else today may be something you end up extending as your next assignment! Being an active contributor to your team’s efforts also means you learn from bugs created by others too. Keep a tab on what is happening with your team and product and the issues you are getting from production usage. Be an active listener for forums like daily standups. Offer help when you can. Essentially, all that is learning from mistakes and gathering invaluable knowledge, which would positively impact your future design and execution with your team. So keep an open mind and keep learning with every opportunity you get – bug, design issue, customer feedback, review comments (for you and others), etc. The possibilities for learning with an open mind are endless and that is one of the sure shot ways to be a Zen programmer!
(To be Continued)