Part 1: The Pragmatic Programmer

I recently read📖 The Pragmatic Programmer — By Andy Hunt and Dave Thomas and this blog post is a summary🗞 of the learnings from the book and how I interpreted those learnings🎏.

1. Care About Your Craft 🤗
There is no point in developing software unless you care about doing it well.

I have been preaching “build solutions for problems you can relate to”🛠. We can’t really build a solution to a problem which is not ours. We will never be able to judge if the solution we are providing really solves the problem or not? More importantly is the problem only limited to what we are thinking it to be or is much broader?

2. Think! About Your Work 🤔
Think about what you’re doing while you’re doing it.

Sometimes we take a task, and it takes a lot of time⏳ to complete it. But later we realize the output we got doesn’t make much sense. We should look at the bigger picture and the impact our action will make to achieve that end goal and then only decide if the time we are about to spend on it worth it or not?
There should ideally be 80% thinking and 20% code.

3. The Broken Window — Make Quality a Requirements Issue 🕵️‍
One broken window, left unrepaired for any substantial length of time, instills in the inhabitants of the building a sense of abandonment — a sense that the powers that be don’t care 🤷‍️ about the building. So another window gets broken. People start littering. Graffiti appears. Serious structural damage begins. In a relatively short space of time, the building becomes damaged beyond the owner’s desire to fix it 👷🏼️, and the sense of abandonment becomes reality.

In Karma🎯 we didn’t bother to fix the initial two, three bugs🐛 we came across but kept on building features on top of them. This ended up making the whole code beyond repair and in the end we had to abandon the project.

4. The Frog🐸 story — Remember the Big Picture
They say that if you take a frog and drop it into boiling water🔥, it will jump straight back out again. However, if you place the frog in a pan of cold water, then gradually heat it, the frog won’t notice the slow increase in temperature🕯 and will stay put until cooked.
Note that the frog’s problem is different from the broken windows issue discussed. In the Broken Window Theory, people lose the will to fight entropy because they perceive that no one else cares. The frog just doesn’t notice the change. Don’t be like the frog. Keep an eye🧐 on the big picture. Constantly review what’s happening around you, not just what you personally are doing.

5. People find it easier to join an ongoing success🥳. Show them a glimpse of the future 🤖 and you’ll get them to rally around.

Most of the crypto💰 companies started by showing users a neat roadmap. When we visit their websites we just see a roadmap. That roadmap does make a lot of sense, but the company didn’t had anything other than that roadmap to future to show. But to the utter surprise, people were investing millions of dollars in these companies. 🤯
It was all because these people found the idea exciting and were able to see a glimpse of the impact it would create in the future.🤖

6. When disorder increases in software, programmers call it “software rot.”⛓

When we were making Karma🎯, the code started becoming unreliable beyond control. The code was really hard to read and understand. We were no longer able to understand why a certain thing is happening🤨. We had no other option but to abandon the project.

7. You may be in a situation where you know exactly what needs doing and how to do it🤓. The entire system just appears before your eyes — you know it’s right. But ask permission to tackle the whole thing and you’ll be met with delays and blank stares. People will form committees, budgets will need approval, and things will get complicated. Everyone will guard their own resources🥴. Sometimes this is called “start-up fatigue.”

Steve Jobs once said — ‘the best companies in the world🌍 after making there product, work on improving the process of making the product.’
Easier the process is, better and faster are the results.

8. Provide Options, Don’t Make Lame Excuses💡
Before you approach anyone to tell them why something can’t be done, is late, or is broken, stop and listen to yourself. Talk to the rubber duck🐥 on your monitor, or the cat🐈. Does your excuse sound reasonable, or stupid? How’s it going to sound to the other person?

I had too many thoughts to write in a single blog 😛. Find the second part of the blog here.

Thank you for reading. If you like the article give it a clap 👏

Do consider Buying me a Coffee https://www.buymeacoffee.com/ananya, If you loved the article.

ABOUT ME:
I am Ananya Agrawal. I am currently working as a software engineer at Gojek. I am working on building Feature Monkey a customer feedback tracker that can be used for feature request tracking, internal feedback, public roadmap, etc.
Reach out to me over https://twitter.com/AgrawalAnanyaa.