Blog‎ > ‎

Pragmatic Programmer and What I learned

posted Apr 13, 2015, 3:02 PM by Unknown user

I found this book really helpful towards the view of programming. I don't have much experience with software development, although I'm well on my way to learning how it's done. I think that this book was a great read since I'm gonna start implementing what I've learned as I learn how to code.

I'm assuming that people who normally read this book are people who have experience in the field, which means they have to change a lot of habits or “unlearn” several bad practices that they normally use. I on the other hand don't have that issue in most cases.

In other cases though, as I was reading the book I realized that all the programs I've written prior are utter crap. Even the programs written the first week did not follow the “guidelines” that I have started to become familiar with.

There were several aspects that were very technical and that I did not quite comprehend fully, but I believe that I was able to grasp a general idea of each chapter, and I compiled a list with the Tips that I found in the book.

This list I have saved on a file and will continually check it, refer to it, and make sure it becomes ingraned into my programming habits. Maybe not all at once, but continually getting better and improving the art of writing code. I have appended the list at the end of this document. 

I think the most important way that the book impacted me is in changing my mindset, accordingly with the Nearsoft Academy program. For as I was reading the book, I realized that a lot of the stuff mentioned has formed part of our training as interns. 

For example, we had a class with Julio about communication, which I believe was complemented with that section of the first chapter of the book. We saw a conference of the myth of the lone programmer, which I remembered as I read the section on pragmatic teams. 

One of the things that really stood out to me is the DRY principle, for a number of reasons. First off, my mentor mentions it when I sit with him and watch him write code. Secondly, this is a principle that I never included in my code. I always repeated myself, and even had a teacher who said “this is why copy-paste was invented”. I now realize that is an inefficient mistake, and a bad practice in programming. 

One of the things that I have been implementing as I read the book is to continually learn new things. It said that as a programmer it’s important to expand our personal knowledge database, which is something I’ve always enjoyed doing. 

Also In the third chapter there was a section that talks about learning how to use a simple text editor, and learning how to use it well. Therefore, during my time at NS I have been using vim to edit all my code, and even installed the plugin for Intellij so as to use vim commands to edit the text. 

I learned new stuff, like source code control, assertive programming and testing. Unit testing also being something that was implemented in our training program, and a concept I had never heard of before. 

Another key aspect that I learned about in this book is making code easy to read, and to build documentation in. I had never used documentation and my code has never been easy to read. My variables normally were three letters or shorter, to make writing it faster… and reading it a living hell. 

Once concept I did not fully comprehend was “tracer bullets”. I understand how they work in FPS games (Battlefield 3 FTW), but not quite how to implement it in code… I’ll have to revisit the book after having more experience “on the battlefield” to grasp a better understanding of how it works.

Last summer I took a class at the University of Arizona about systems thinking and requirements applied to any kind of engineering. I distinctly remember the teacher explained that the concepts were abstracted from software engineering, something which I kept remembering as I read the chapter on “Before the project”.

He always stressed the importance of writing good requirements and making sure the client agreed with those requirements. He also stressed on the importance of the iterative design-build-test cycle. I am now realizing where it all came from and why it’s implemented. 

Lastly, there is the lesson on being a team member, not being territorial in a “keep your paws off my code” sense. In this chapter, the book revisits concepts about the pragmatic philosophy in team views. 

I think the biggest challenge within teams would be the DRY principle, since several people are working on the same project. This book suggests appointing a librarian or focal points to parts of the project. In this manner, if someone has a question or an issue, they should speak first to the corresponding person in charge of that area. 

Another part of the book that changed my personal view was tip60, where teams are organized based on functionality, not function. Say, instead of grouping teams with all of the developers together and all testers together etc, group them by module. All of the people working on one specific function of the project together, to improve efficiency in communication. 

Those are the main concepts that I learned of this book this first time I read it. I’ll revisit it in a couple months to learn more about pragmatic programming, and keep it as a reference henceforth. Also, I’ll leave the list of tips I compiled in another post.