Lessons learnt from Software Development Practices
When you are working a job, there are certain things that make you efficient. These things you sometimes read in an articles and or a book but cannot completely relate to, unless you’ve seen them change the way you work.
I have spent close to 5 years in the IT industry, honing my software craftsmanship. I belong to the category of developers that find more pleasure in solving a problem the right way as opposed to the ones who find more joy in the technology used. During this short stint there are many things I’ve learnt but a few stood out. Not only relevant to my current field of work but even to life in general.
There is no such thing as magic
When I started as a developer, I’d see code as some magic that works. There were so many moving parts that I wouldn’t understand and I’d believe that somehow, it all works. As soon as this idea was established, my common sense would go for a stroll. I’d copy paste code and wonder why the functionality is broken.
Once I was able to get past this habit, and realize that at the end of the day it is just another piece of code written to solve a particular problem, things became so much simpler. Now I actually tried to understand why something was working to begin with and what would need to change to achieve what I want. I started understanding libraries and frameworks better, I wasn’t hesitant to look inside library code and see where the functionality was coming from. I was more drawn towards reading documentation and code.
Most of the times it was difficult to understand and work on code because of abstraction. It is in that sense a friend and a foe, I feel abstraction does make things easy for us and we shouldn’t fight it but at the same time it shouldn’t stop us from understanding code as just code.
The ultimate understanding that there is no magic (the muggle inside me still weeps)and I should keep questioning and looking till it doesn’t look like magic anymore paved path to a broader understanding of things and much more growth in learning.
Keep the bigger picture in mind but work on one thing at a time
The best programmers I have worked with have always followed this principle. This was one of the biggest struggles I had when I started my career. Often the software problems we try to solve are big. The most common approach to problem solving is divide and conquer. A requirement is broken down to a feature, a feature broken down to stories, which when as a developer you start working on you break further down into tasks.
The task might require multiple changes to your code. There has been times when I started working on a story. I was clear on it, but as soon as I started coding I identify a refactoring and before I go ahead to do it, I identify the approach might not be the most performant and by the time I decide the approach I see the existing data structure of the code might not be the best suited for the problem. And in no time I used to end up in an analysis paralysis situation, where there are so many things I wanted to do, I would end up not doing what was even required to begin with.
Some of the best developers I’ve work with create a logical task list when they encounter things rather than diving straight to work on them. If there is a change that is needed but isn’t really blocker for the current task, instead of ignoring they would rather pin it to that task list and focus on only one change at a time.
Once I saw the value of it, I realized how efficient a way or working it was. Needless to say it soon became a technique that I now religiously follow. I still sometimes get lost but this habit always helps me get back on track. Not only for coding even while problem solving and discussion, it remains one of the best habits I have learned. Keeping the bigger picture in mind, but working on only one thing at a time.
If the problem is getting too complex to solve, you probably approached it wrong
This is an aspect that I have truly learnt from my software practice. If there are too many conditionals, how much ever hard you try to find a solution and if the problems just keep on coming, often times the approach to begin with was not right.
There is a phrase that we keep using during software development, let’s take a step back what it has helped me with is to realize either we got too deep in a rabbit hole or it is not really the problem we wanted to solve but a problem that exists because we chose to solve the actual problem a certain way. Evaluating the approach taken, at that point of time solves a lot of problems which otherwise could have resulted in complex and unnecessary over engineering.
Simple solutions are one of the best solutions that exist for a problem. Simplicity in software systems and code is something that I now aspire for.
I truly believe software development is a craft and though there are different tools for the craft, but a strong foundation and tricks and techniques under the sleeves of a true craftsman, makes the job much more simpler and joyful.
