This is probably the single best advice there is regarding agile software development, offered by the authors of The Pragmatic Programmer under section “The Essence of Agility”. Having worked in agile and pseudo-agile teams myself, I believe this is a valid point conspicuously disguised as a rant. Teams often tend to follow some off-the-shelf agile model as a written-in-stone guidebook, and in doing so inadvertently move away from the very essence of agile.
Just the following four deceptively simple values should apparently put one on a path to true agility:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
In my experience, I’ve found #2 and #3 to be the most difficult to comply with as they often involve setting expectations with the client which can be tricky, unpleasant, or downright impossible.
These four values should guide not just project managers and analysts on a team but also developers. The art of creating good software doesn’t only lie in writing clean code but also in enforcing inclusive and structured communication patterns.
If you are a software engineer and think, like so many others, that writing clean code is trivial and a skill that could be picked up anytime, this book will be a BIG eye-opener for you.
The book is written by a group of authors led by Robert C. Martin (aka Uncle Bob). As you will find out yourself, they are highly skilled professionals who are very serious about their craft and do not take code smells lightly. They follow the Boy Scouts Rule and go out of the way to ensure they leave code in a better state than they find it. These are the folks who have helped establish modern software engineering practices & patterns such as Agile and SOLID. The chapters where they rip apart popular and highly respectable open-source software (JUnit and Apache JCommons) are especially enjoyable as you get to see how good code could still be bettered.
Being a software engineer myself for a while now, I had a hundred questions regarding code quality and structure. I found all the answers here. Some were a confirmation of my beliefs, while others were new lessons to be learned.
I wholeheartedly believe in the book’s central tenet — writing clean code is an art, a sign of a software craftsman. Overall, it’s a great read and a time investment with a multi-fold ROI.
There’s a bunch of technical books sitting in my Amazon wishlist for quite some time. Poor books! They could not end up in my shopping cart for a myriad of reasons, laziness to read being chief amongst them.
The importance of reading technical books simply cannot be overstated. Or reading articles, for that matter. Reading is what helps you to improve your craft, keeps you up to speed with the topics you care about, makes you a better version of yourself in your desired skill. Personally, I’ve found books to be more useful than online courses. I have nothing against online learning, I’m all for it. I have end-to-end finished a tonne of courses on Udemy, Pluralsight, Coursera, etc. The things that go for me with books are that I can take them anywhere (even where there’s no Internet), highlight important parts, scribble my own thoughts and most importantly learn without distractions. The thing about books being little portable time machines is true.
Recently when I was casually digging my Twitter timeline, I came across this book called “Clean Code”. Someone had written life-changing praises about it. Out of nowhere, I decided to order. Out I went to Amazon.in, found the book, read a few reviews, noticed that there was no discount, and hit the Buy Now button.
I am a little more than halfway through the book, and boy, it is life-changing. It’s written in an authoritative tone by a bunch of regarded software engineers with decades of development experience. The experience clearly shows! Chief among the authors of the book is Robert C. Martin, who is one of the founders and foremost popularizers of SOLID principles and Agile methodology. I have thoroughly enjoyed the book so far, and am looking forward to finishing it. It’s safe to say that this book has reignited my craving for technical books. Next up I’ll probably pick up a Martin Fowler.
Using the learned clean code principles, I was able to transform this ugly chunk of code at work in a beautiful verse below it. The code is customization on top of Sitecore‘s JSS Node Proxy open source program.
The Microservices architecture seems to be something that everyone is talking about but only few understand it well, let alone implement it and that too following all best practices. In this second episode, we are joined by a fellow DF member Ashwat to try and demystify the concept. Once we have the general definition out of the way, we’ll dissect a couple of real-world examples to see how the microservices architecture fits and solves their problems.
IRCTC, one of India’s most visited websites, is a great case in point. And so is Netflix, a company that sort of championed the use of this new architecture. We further discuss how the scaling cube works, and then take a look at decomposition, a key technique in deciding how to break a big application into micro services. Other topics discussed are bounded context, single responsibility principle (SRP), and common closure principle (CCP).
P.S. Apologies for the occasional background noise. Since this was a ‘live’ podcast, a few others from the DF community had joined to listen, learn, share and ask. I didn’t use the ‘mute by default’ setting because of which some mics made some noises. Will not happen from next time.
The first-ever episode of a brand new podcast series called Dev Blabber. It’s an initiative that I came up with as part of the awesome Digital Futurists community, where a bunch of geeks, entrepreneurs and seasoned executives discuss technology and software like crazy.
There was a discussion last week in the Coding channel””one of many channels within the DF community, and the one that I lead””regarding the topic of our next knowledge-sharing session. 4 topics were proposed, ranging from React performance optimization to cybersecurity. But this one, about building open-core startups, rose as the clear winner. While deliberating the format of this session, I thought of making it in the form of a podcast. The idea was instantly liked by most in my channel, and thus was born Dev Blabber.
I hope you enjoy this episode, which being the first one is very loosely structured and borderline chaotic. At least it’s true to its ‘blabber’ name.
P.S. More details about DF and how to join are coming soon. Watch out!