It was long overdue that I started reading this marvelous book. The interns' batch right after me was lucky enough to have gotten this book as a part of their joining kit. But then, libgen told me not to worry about it.

I personally like reading programmer philosophy books, it gives a feeling of having a godfather who’s a programmer talking to you through those pages. Uncle Bob from Clean Code is one such example of that.

Following is my collection of gems from Chapter 1: Programming Philosophy from the book “The Pragmatic Programmer”.

Beautifully said! It’s kind of embedded into our minds where we think Programming = Coding. Take a step back and think about it, if you observe carefully, “Programming” is also derived from the word “Program”, which doesn’t necessarily have to be a piece of code, it’s just a set of instructions in a specific manner. Asking your dog to sit when you utter “sit” is also Programming and that would also make you a programmer, don’t laugh…it does. It’s just that we have accepted the world’s way of linking Programming with Writing computer programs, that being said, the main motive of this point was not to generalize programming but to make you aware that you’re not only a programmer when you code but also when you think! So, eat, breathe, talk, live and love programming from now!

I liked this so much that I shared it with my Team the next sec I reddit. I feel we don’t give our job the importance that it deserves. Since our industry as a whole is pretty big, it’s highly likely to fall under the same umbrella of "Software Engineer", but trust me, if you're reading this, you're no ordinary "Software Engineer", it's because of us, that world is turning "digital", look around you, I bet you can spot at least 10 things which wouldn't work without Software. So, make your job the biggest flex in your life. Be extremely proud that you- are a Software Engineer!

This quote deserved a LinkedIn post for itself, I think all of us are guilty of picking our comfortable stack for building something, well, I think it's partially not our fault, it's the way our brain has been designed, we think in the ways that we know, I call it the "Knowledge curse". But you know why only partially because it's upon us to expand that Knowledge of ours thereby expanding our minds. Keep expanding, Keep Thinking.

I could relate to this 100%, so recently, I was on-boarded into a project which had a tech stack that I wasn't familiar with. The architects decided to go through with it, so the devs had no chance but to oblige, they had all the answers for every minute "why" that you could point out. I was lowkey scared, as I was given tasks left and right, without knowing how to implement any of them. I conveyed the same to my lead, to set our expectations right. There was a junior in our team, who already worked on a project with the same stack, and hence was comfortable enough with all the tasks, at first I was hesitant to take help from him, I would waste my entire day trying to come up with my own way to implement it, only for my PR to be rejected. Then I decided, that it was OKAY if I appear weak, and started seeking help, Being surrounded by wonderful people, I was able to get help quickly and make progress. This is one lesson that I'll forever remember.

I recently asked my team this question, if anyone can describe the USPs of the product that we're trying to build, Only one guy answered, and that too, was the typical "low-cost pricing model" answer. I feel its absolutely necessary for your team to share the big picture, the vision that your software is trying to solve, I can bet that this would improve the way it's being built by at least 2x-3x because every piece of code then written will know where it's going to help and how will the end user get the most out of it, this is will result in better UI, performant and reasonable APIs, and most importantly will give a purpose to the team, A team without a purpose is no team at all!

Were you ever on a call with your senior and whilst explaining the problem, it hit you that the fix is actually pretty simple and you already know what to do? Well, if you weren't in such a situation before, then my friend, you should be open to asking more doubts, but if you were, then I feel you! This is where the "Rubber Duck" comes to your rescue! The rubber duck approach means to first try and explain your problem to yourself, and if it still doesn't make sense only then approach someone. I have an iron man figure that my friends had gifted to whom I try explaining my problem first, what do you have?

Read that quote again. All of us have been in a place where we ignored a bad piece of code just to get it working, I call it "Programmer Anxiety", we all have at it, but logically speaking, deadlines will always be there, and releases can afford to fall short, but as an Engineer, you should never ever compromise on the code you write. Discuss with your team, most of the time they will understand your problem and sensible folks would vote for fixing the current situation rather than patching it. Next time this Anxiety kicks in, remember me ; )

Ending with a self-explanatory quote!

Happy Coding!