The Pragmatic Programmer is a book a friend of mine (LB) let me know about 4 years ago. He taught me almost everything I know about programming and he strongly recommend me to read the book, thing that I did. At that time, though, I didn't know almost anything about... nothing (as if I knew what I'm doing now ¬¬). I learned some ideas that I've been using since then, but at the time I didn't fully understand most of the concepts of the book. LB told me that he read the book form time to time to remember some of the stuff he should already be doing but forgot.

So that will be the second time I'll be reading the book - I've read the first chapter so far and I think is full of wisdom, has awesome analogies and I'm really having a good time rereading it. If you haven't read yet, just do it.

I'll be summarizing some of the points that the book makes but I really encourage you to read it. Here we go.

Chapter 1

Take responsibility

Take responsibility and be consistent with it. Don't make excuses, assume responsability when something is wrong and don't blame anyone but you; more important than that is to provide possible solutions to the actual situations. Don't focus on the problem, focus on the solutions.

The greatest of all weaknesses is the fear of appearing weak

Fix 'software rot'

Don't let a project to get disordered and chaotic. If something is not working, fix it; the reason is simple:

If you find yourself working on a project with quite a few problems its all too easy
to slip into the mindset of "All the rest of this code is crap, I’ll just follow
suit."

[...]

By the same token, if you find yourself on a team and a project where the
code is pristinely beautifulcleanly written, well designed, and
elegant - you will likely take extra special care not to mess it up

Encourage people to always improve

Try to make other people get engaged in the improvement of projects, processes, documentation, etc by stimulating their curiosity. "What we have is great but it would be better if we added..."

On the other hand, though, you don't want to let down people people by always saying something can be improved or is not OK as it is. I've experienced for myself the 'I encourage you to do something that never will be good enough' and it really sucks. You end up getting burned out. And in the other hand an always 'nah. Improve it? Why?'. As a boss I had always said:

Virtue is at the midpoint (rough translation)

Better good and now that perfect and never

Its difficult to decide when to ship a product, or when to release a feature but try to do it soon instead of taking ages developing and fixing bugs. It does not means that you must sell buggy software, but depending on the clients they will be happy if they can use a 95% of the project bug free and a non finished 5% with some bugs or that needs some polishing.

A sentence about software (taken from, I reckon, Don't Make Me Thing book):

A peace of software is done not when you don't have anything more to add,
but anything more to remove.

It means: stay small, simple, clear and more stuff doesn't mean better stuff.

Knowledge is power

An investment in knowledge always pays the best interest - Benjamin Franklin

Your knowledge is portfolio. With the experience is the most valuable asset you have. Unfortunately, (some) (technical) knowledge expire, and you must preserve it buy reading books, be on mailing lists, be in touch with gurus who are on the lead, learn about new technologies, take classes, read non technical books, stay tuned... "Invest regularly in your Knowledge Portfolio" they say.

Opportunities for Learning

Do not waste any opportunity to learn new things. Be honest if you don't know about something and be curious, both asking questions to people and answering some doubts you may have. Go and find the answers yourself, be active.

Communicate

We are tech people, but always remember that we are social beings, and we need to communicate with each other. Try to know what you want to say beforehand; if we are talking about writing documentation, having a conversation or in a email. You also must know the audience to be more extensive or short depending on how they want to consume the information. Choosing the right moment to talk with somebody is really important, and to have both a good style in the document making it look good is an extra point. You don't want the people to judge your ideas based on the quality of the documents you are presenting.

If you are writing something for an audience, it could be a good idea to get them get involved in the process of creation of the document/presentation. Feedback is essential to focus on important things. Again, listen the other people and get back to them if they have further questions or doubts.

My personal opinion is that communication is key to be a good professional. Not just with your colleges and bosses but with your customers, providers, etc. Having good communication skills is a must because you transmit your ideas better, you can engage people on doing things more easily and reduces friction early.