Cross-posted from Goodreads
The Pragmatic Programmer is a structured collection of tips and practical advice for programmers looking to get better at their craft. In it, I found answers to many of my own doubts and dilemmas that I’ve experienced as a programmer for over a decade: questions of whether a particular approach or design is the right way, an overkill, or half-baked.
This one’s another seminal book on programming—like Clean Code—that I should’ve read years ago. Or maybe not: the first edition was written in 1999, where a lot of the technology and code samples discussed have become obsolete today. The second edition (2019) is a modern rewrite and what I picked up. While all code samples, as well as recommended languages, frameworks, libraries, and tools, have been revised the core concepts about being a ‘pragmatic’ programmer were true in 1999 and remain true 20 years later.
The gist of being a pragmatic programmer is that you deeply care about the quality of your software, write your code as a master craftsperson, and always keep your users at the forefront, but at the same time you also respect time commitments and know to stay away from the overengineering trap.
Although a lot of advice will feel ordinary to folks who’ve been programming for a few years, there are plenty of rock-solid gold nuggets of wisdom that will make reading the book worthwhile. Besides, the concepts that we know now and take for granted—like DRY and orthogonality—were literally born in this book (in 1999!).
Cross-posted from Goodreads
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.
How you determine your age?
I was born in 1987 and this is 2011, so I am 24 years old right now.
How most computer systems determine your age?
Time passed since 1st January 1970 till now (2011)
Time passed since 1st January 1970 till when you were born (1987)
(well, again) 24
The date 1st January 1970 is the Epoch date for the computer, signifying the start of time for it. That’s why timestamps in most programming languages are the seconds/milliseconds elapsed since the epoch.
Since I landed in Bangalore, my schedule has been extremely busy. Yeah, I had heard in the past that the training period in an IT company, especially Accenture, is very tough, I am experiencing it only now. I have yet to take out some time to go out and explore that grand city that is Bangalore. Most of my time everyday is spent preparing for in-training tests. But anyway, the first phase of my training ends today, the last test of first phase being on 28th Sept.
A ray of hope in my frustrating daily schedule has to be me getting .NET stream, that is, I would be doing my second (and final) phase of training on Microsoft .NET technologies, and eventually be getting projects based on it. I am curious to begin my stream training, more because my stream is more web-development oriented (yippie!). By the way, it would be ASP.NET + C#.
That’s all for now. I’ll try to keep my blog as updated as possible.
I should have mentioned this earlier here — I switched to Java competency about a year ago. So I work on both Java and .NET assignments in my project now.
Continuing my Java learning stint, I started experimenting on RPM packages in the Granular 2008 repository by extracting meta data from them using various Java classes I had written for my on-going college major project. To give a shape (end-user interface) to these leisurely done Java programs, I used my existing project MyBlog to create a website that could display information (extracted by the Java programs) about every RPM package in the repository. In other words, the Java programs store information about each RPM package in a central database which in turn is used by a PHP-based website to display that information, and much more.
In the introduction to Granular Package Archive post I wrote on the Team Granular blog, I explained the various features it has to offer. My personal favorite is the ability to leave comments on individual RPM pages. Other than that, I am quite satisfied with the overall look-and-feel too. In another of my Team Granular blog post, I explained the working of this package archive system, and the way to use it with any other repository of RPM packages.
Some guys at the Unity Project are also contemplating the idea of using this package archive system with their repository too.