Blog‎ > ‎

Summary of the book: The Pragmatic programmer, from journeyman to master

posted Mar 12, 2012, 6:44 PM by Unknown user
This book is a recompilation of Knowledge acquired over the years by Andrew Hunt and David Thomas, using entertaining anecdotes to explain the way they made his workflow more efficient and very productive.
If you feel that your potential is not fully exploited or even your teammates are more efficient than you are, this book is for you. But don’t get confused, this book don’t have the solution for all the problems, but helps you to improve your approach to certain project and the way you code.
The pragmatic programmers are different from the rest, they think different, manage different approaches in certain problem, spend more time than the most, learning and solving problems earlier, to  save effort, time and resources. 

Their confidence comes from the experience.
They always are asking: why do things in this way? Or why you prefer some technology over the others? Trying to implement the best resources they can. Actually they can estimate the benefits of implement approaches, or how much time they expend developing the project and at the same time they are interested in other topics that can strengthen their knowledge.
Have no sense be a programmer if you don’t want be a good one.
Until this moment the meaning of the book sounds like a very difficult stuff to implement, but it guarantee that the hardest part it’s begin and suddenly you will find yourself implementing all the advices.

Teams
Inside of the team always got to be an independent people, they use an example based on the construction of the greatest churches in Italy, those were made by people whit different skills and they build their craft based on their personal approach. The constant efforts to obtain this skills is just the way to get it, if you water your lawn every morning for 500 years, you will have the most beautiful lawn like those in the British Universities, constant pragmatic behavior is the key.

In chapter 1 the pragmatic philosophy, tray to introduce you into the philosophy, exposes you the way of think, and gives to you a taste of the abilities and the qualities of the pragmatics programmers. One of those qualities is to be honest about of the real situation of the project, if you can’t finish at the deadline or maybe you are experienced some problems give to your boss a possible solution for those problems, don’t make child excuses like: the cat eats my code…

Always collect some feedback of the bad experiences, try to find were you was wrong at the first time and in what point it gets worst, and find a solution to resolve this problems in the future (automation, better testing, design, best practices, etc..)

In “the broken window”, they explain who an entire neighborhood gets down to the misery, all caused for a broken window, how suddenly brings another broken window and people start to be negligent whit the buildings, then appears graffiti and  it was too late to repair thing when everything was a complete disaster. The same thing happens whit our code, if we left bugs to be repaid at the end of the project, maybe could be too late make it, and soon you will be collecting the bits of code from the floor.
In the other hand we have case of the firefighters, who doesn’t want to mess a burning down house, only because it was perfectly clean, full of valuable things, it was because it was kind of perfect and no one wants to be the first to mess beautiful things. The same happens in our projects, if you test and repair all the bugs, relay good documentation whit comments, a modular and scalable feature, no one want to be the first adding a poor code and downgrading you feature.

In “the stone soup”, two hungry soldiers’ tricks to the habitants of the village, who doesn’t want to give them some food, making a “delicious” stone soup, the villagers dying because of their curiosity was tricked making then bring more vegetables to make the soup even more delicious. In the same way pragmatic programmers, got to impress the sponsors for get an inversion of them, if no body trust in your project, make a prototype to demonstrate the functionality, everyone wants to jump into the ship of victory. Be a catalyst for change
In the other hand we have the tale of “boiled frog”, the book says that a pragmatic programmer got to be aware of the main problems of the project, even if it is a big project whit many developers consider the whole picture, and be able to refactor when things aren’t well, if you continue developing a system that is a closed street then you wouldn’t be able to see you are getting slowly boiled, like happened to the frogs.

Good enough software
Sometimes we can´t continue tuning our projects, because many factors are involved in, like deadlines and budgets, but if we have an application whit all the requirements satisfy, well designed, tested and scalable we have to recognize that our project is finished and understand that nobody write perfect code. Do not give priority to the fancy features over the requirements.
The most of the companies are agree whit this concept: is better a great software today than a perfect software tomorrow, involve your users in the in the process of develop, every now and then give them something to play whit, this make them happy and solid relationships.

Eaten worm: if we neglect our Knowledge we are in danger to become obsolete for our company, even if it is about older technologies, we have to be always in the craft, don’t be the early worm eaten by the early bird. Make an inversion in our knowledge always is amply rewarded.

Manage you knowledge portfolio like a business portfolio, always make an inversion on it, diversify it, try to be an eminence in one technology and then learn about others, make a risk inversion but keep resources to be financially secure, and always make a review of that programming language that is full of dust sometimes its returned to be used for some companies.
Addition to the knowledge portfolio, this first character is full of advices, like: learn a programming language per year, read a technique book of something else once a year, keep in contact whit people out of your work (maybe an older friends), take some courser in technology events, join actively a group of knowledge a participle often, try with different environments like linux if u use only windows or whit some new framework for your preferred programming languages, and even more.
Always take a chance to learn helping others to solve their problems.

Keep a critical thinking, always spend some time researching for the best technologies, sometimes it isn’t in the surface, and the first products in the advices of your browser pay to be there.

Keep in contact whit your guru, internet allow us to be in contact whit people in the craft of the most of the developing environments, so take advantage of this an send them an email, but remember be polite and ask well defined answers.

Keep in touch, we need to communicate in so many levels, whit our boss, whit our team, the users, the clients, if we don’t do it correctly all our knowledge is a waste of time.

Know what you want to say, always think if that you want to ask is the real question, remember a good communication is the key to save some important time, no matter if is only a e mail or a phone call, have some respect for the time of the others.

Know your audience, try to be aware of the level of Knowledge of the people that is hearing you, if they don’t understand or the conversation have no interest to them and then the communication does not exist.

Choose your moment, if your boss is in an important meeting or he is stressed by some problem, maybe is not good time to ask for a better salary or increasing the bad news, so wait for a better moment, sometimes you know what they are going to say, so avoid them an awful conversation and work on you problem.

Choose your style; you need to know the people that you are having communication whit, some of them like an extensive summary in paper, and some of them just a simple e mail whit the main information resumed in a list.

Make it looks good, the information needs a good format, if looks unordered it will be ignored.

Listen to your audience; take some feedback of the people who reads you or your coworkers, maybe get online a website whit a contact form is a good way to expand your network.

Always answer to the people, if you have a large list of emails without review, it’s time to start to answers them; maybe your answer is more important to them than the offence of your late.

In the chapter two: A pragmatic approach, the authors give us some tips and approaches that we can deploy in our developing.

The evil of duplication:
Inevitable duplication, sometimes it looks like it is inevitable repeat some parts of our code, but take a different approach of our initial idea let us know that we don’t need copy our previous process, and make a good documentation about our handle avoid us to repeat the same mistakes.

Inadvertent Duplication, sometimes we don’t relay that we are making a duplication of our information, is better to use variables than static values to calculate some result, in this way does not matter what is the value of the variable it always will work.

Impatient duplication, if we have a deadline maybe we will be seduced for the need of duplicate our code to finish in time, remember that the shortcuts the most of time result in a big problem.

Interdeveloper duplication, sometimes you will be tempted to copy a bit of code that your coworkers implement in a likely situation,  remember the y2k problem, it happened only because a programmer forgot to add some digits to dates in the OS.

Orthogonality
Orthogonal environments are usually seen like to be by default in a system, something that you don’t have to learn, but how independent is your entire system? If you remove some feature it still works correctly? Orthogonal environments eliminate the non sense relationships between the modules that compose it. And always remember in non orthogonal environments does not exist something like “local debugging”.
An orthogonal system increases the productivity of the team, if you need to add new features it can use functions adequately separated, risk are decreased by allowing us to isolate little parts of our code that can be “sick” just to name it in some way.

You can calculate the orthogonality of your project just looking how many people have to join the party in some debugging case, if people in every section (DB, front end, back end etc.) have to perform some change and then you have non orthogonal system.
A well designed system, can improve some modules and only perform some changes in the related section of the system, for instance, you can add a voice recognition and a touch screen in the Graphic user interface (GUT) without a problem to manage the database or the backend. And if we can add some new tools to the system without it notice and perform some trouble for this reason we have a well designed orthogonal system.

It´s time to coding?
Make your code a listener only for the things it has to know, independent and scalable, avoid the global variables and similar functions and make of these practices a habit.

It´s time to test?
Also will be a good time for probe how orthogonal is you system, making unit test and automating test, if the bugs affects only the section it belongs then is a good sign of a good modular system.

Tracer bullets
Like a solider shoot whit a tracer bullet in the dark to see what is hitting and find his target, the tracer code is a functional tribal structure that performs our system in a basic way, if it is not what the client is looking for then the feedback will help us to find our target and when we find the real goal, the we have a functional short version of our project ready to add modules and make it scalable.

Prototypes
The prototypes are a good tool to but we have to delimitate the scopes of them, in the automobile industry they use a prototype for the design, other for the aerodynamic tests, and so on, in develop we can use it in the same way but always be clear whit you partners, managers, and sponsors, the prototype is disposable and it wouldn’t be part of the real structure of the project, and if they insist, you can use the analogy of the automobile and say to them: you make aerodynamic test whit a cardboard prototype but you don’t use it in the highway.

Domain Languages
In the most of the meetings you will find yourself trying to explain how your develops works, people in the meeting do not understand the code and have not the abstraction level to follow your conversation, that´s why you have to create a pseudo code, easy to understand and even your team meeting will write some, and then create an interpreter to convert this pseudo code in a real programming language like java or c++.

Estimating
We need to be very careful when we estimate a deadline, for instance, you have a project that will bring up whit some problems in the middle of the develop process. It’s very important be clear whit your clients about it is just an estimated time.

In chapter 3: The basic tools, we can read an analogy about a woodworker, they choose careful their basic tools, like saw, hammer, etc… when they doming this tools they can add new ones. Like chainsaw and laser guide saw. In the same way pragmatic programmers need to feel their basic tools like an extension of their hands. At first try some basic tools like an IDE (integrated Develop Environment) and some languages to be a master, our preferred OS and so on.

Plain text, keep our code in a pain text is a good and sheep way to keep it safe, a disadvantage is that the plain text needs more memory to save it than a binary code and it is more difficult too to be interpreted by a machine. But plain text it’s a insurance against the obsolete technologies, if some technology change you always have a backup safe.

Shell Game; learn to use a command prompt is a great way to improve our performance bay reducing the time we expend searching for some files, we can filtrate our search by date, name, extension, and so on, even we can install or modify features in our OS that we can’t do in the GUI.

Power editing, we need to be familiar whit the IDE we want to use for all our projects, know it shortcuts, and is strengths and it weakness, but is we use a pretty basic one, we are losing our productivity and if we choose a complex one it will be a big nightmare.

Source code control, it is like a super undo button, you can go back so far as you want to make a review of you procedures and change that you made wrong, but a source code control go beyond of that, you can create a tree whit different versions of your project and continues deploying new features and debugging while your users are using a release of the project and then add the new features when it’s ready, all this without affect your final product.

But my team isn’t using a source code control, well then it is a good time to evangelize them and be the innovator whit great ideas, and if they don’t implement it, at least you will be the most productive.

Debugging, as soon as we accept tar every one made some bugs, more quickly we will be more productive developers. We got to start making test at the beginning of the project always making a shy programing.

Text manipulation, we send and receive information all the time, in our e mail, maybe in a intranet in our workplace and sometimes a local storage were everyone can access. It is necessary implement some text manipulation language like HTML or XML, the efficient flow of the information is necessary everywhere.  

Chapter 4 Pragmatic Paranoia; a pragmatic programmer is like a good driver, while other drivers are distracted whit their cellphones, reading the paper, listen music in high volume, we are careful and respectful of the other cars.

Designing by contract, our develop have to be like a business contract, they are required to do what their requirements specify, but anything else. And the control classes only have to require that, not more than the methods it’s for.

Dead programs tell no lies; sometimes we have system errors, like memory performance or maybe a problem that spouse it will never happen, then you don’t only catch it in an exception, and let it pass to the final testing, you can use exceptions to find what the problem is but no to ignore the problem. At least a dead program is less dangerous than a sick one.

Assertive programing, when we find an error that suppose it will never happen, in some programing languages we have the ASERT function it is only for this exceptional errors, not for every kind, if our language have not this function we have to create one likely.

When to use exceptions, prove removing all the exceptions in your code, if it runs correctly then you are making a good use of the exceptions, it is for exceptional errors in the system, not for every kind. 

How to balance resources, it follows a few simple rules:
The function that allocate the resource need to be the functions that deallocate it too.
If you allocate some resources to your code, deallocate it in inverse order to avoid some conflict.
If you will allocate the same resource in many places deallocate it in the same order.
The same rules can be applied at constructors and destructors of an object, were dynamic memory is allocated by nodes.
Like pragmatic programmers, we always have to check for overload our resources like memory, CPU, data buss  and so on, there exist a lot of programs that do this for us, and if is pretty difficult deallocate resources, we can create a stack to determinate when the resource is free to be deallocate. 

Chapter 5: bend or break,
Decoupling and the law of Demeter, keep a modular and orthogonal system is a good way to write shy code, then the decoupling is part of this principle, a good practice is creating functions only to call methods but this will take so many resources, so you have to prioresses you project needs a decoupling system is scalable and easy to handle, but a coupled system save resources and can be faster.
The law of Demeter states that any method of an object should call methods belonging to it.

Metaprogramming, we need to use metadata to preserve the functional changes that users can make to the GUI. And use it have some collateral benefits.
More flexible and adaptable program.
More robust and abstracts designs.
You can customize the application without recompiling it.
Metadata are more expressive at the time to solve a problem.
You will create an application engine useful in many projects.

It’s just a view, our classes only have to be conceit of what they need to know, not how the other classes make the process, only the result of that process, using the MVC (model view controller) is a good way to start, in the model we process all the information, in the controller, we ask for some data procedures and send the information to the view were the user can use it.

Blackboards, in the same way of a detective chief put the evidence in a blackboard to let other detectives use the information and add a new one, without the need of the detectives know each other, you can use a blackboard to add all the sections of your project, databases, backend requirements, third party software, front end requirements, and so on, an add every evidence (requirements) you need to solve the case (a good design).

Chapter 6: While you are codding
In the craft of programming is necessary to have an active participation in the possible resolution of the problems, if we code mechanically we will produce ugly, unscalable and bad performed system.

Programming by coincidence, do this is like a solider trying to successfully cross a mined field, at first he walk so slow and hitting the floor to in front of him trying to not step over a mine, then when he was walking slow for a while, he earn some confidence and star to walk faster, to finish him in little pieces.
Only because we are doing our job pretty well, it doesn’t means that we will continue doing it well, so we always have to test our code and be able to recognize when it is a mined field.
Make the wrong test will show as a result false data, and it will take us for different paths, that we don’t want to walk.
Our older code don’t have to be a limit for our new code, we got to be able to scale over our system.

Algorithm speed, the “O” notation says that the running time will increase for the nested functions (like loops) we have to perform an process, in this way O(n²) where O = process and n = functions.

Code that’s easy to test, make a unit test is a great way to improve the performance of our project, insolating that part we want to test we can find bugs that belong only for this part and when it is debugged we are certain that this part works correctly in our whole project.

Evil wizard, we don’t need to use a wizard only because our guru is using it, he probably knows everything about it and about the code that the wizard generate, if we don’t then its very important do not use it, because it’s code belong to us and the application it creates will be limited if we don’t know how to modify the code.

Chapter 7: before the project

If before to start we don’t know if we can carry whit the problems that the project will bring to us, it’s time to be honest and save some money and time to our sponsors, but if we decide take the risk it’s time to Know how to estimate.

The requirements pit, the requirements are grounded and we have to dig to find them, if only looks for them in the surface you maybe aren’t taking the real requirements, for instance, if your client says that only the supervisors are able to see all the employers record, this is an company politics and the politics change (for experience), then you have to create a user permission control.
Sometimes to have the real requirements is necessary to observe them in their workplace, maybe for one or two days, off curse, don’t bother them.

Solving impossible puzzles, sometimes the we have to take a different approach to resolve some problem that looks very difficult, like Alexander the great slide in bits the Gordian’s knot, the history says that a man how can undo the knot will rule Asia, and Alexander do it of course using a different approach.

No until you’re ready, you need to know when to start your project, a good symphonic leader knows when to rise his arms and let the musicians start to play music, if he does it well you will listen a piece of art.

The specification trap, do not make of every requirement a specification, you have to know what is the real problem of your clients and then start to code based in a good design.

Circles and arrows, it isn’t a bad idea to use an older design methodologies if it allows you to made a good modular and scalable system, but always is good to be in the craft of the new features.

Chapter 8: pragmatic projects

As soon as we are in a project with more than one person, it’s time to establish rules, delegating responsibilities.
Pragmatic team; fortunately all the advices above can be applied to our team, the same responsibilities and compromise that a pragmatic programmer have individuality, applied to a team will improve exponentially our performance.

Ubiquitous automation, it is indispensable to have an IDE to automatize documentation, design, and testing, even in off hours you can make test and generate results to be send to your email. 

Ruthless testing; always make an earlier testing and for every bit of code that is complete, the most of programmers let this to the final step of the project, but that is a bar practice.

All is write, everything we code need to have a documentation, an external one and internal one, inside de code explain why you use some approach, do not explain the code does because it is explained in the code itself and then you will duplicate. The external documentation is like everything you write related whit the project, drafts, manuals and even some post in your personal web.

Always keep a great expectations of yourself and your project, if you can’t, then don’t take it and do not confuse your pride whit your ego, that can prejudice your performance.
Comments