books

The Clean Coder: A Code of Conduct for Professional Programmers

The Clean Coder (Robert C. Martin)

You are probably familiar with Uncle Bob’s classic: Clean Code. While Clean Code is about good engineering practices, and writing good code, The Clean Coder is more about communication aspect of developer’s work. It’s about how to behave professionally, be disciplined, and stick to good coding practices. What’s more, it demonstrates how to avoid common pitfalls in software development process. Such as underestimating time, undergo management pressure or cutting corners (AKA writing bad code).

In Clean Coder, Uncle Bob is explaining by example how to communicate at work. Don’t try to be just a “nice guy”. Be professional and responsible, while being polite. There is nothing worse than giving false promises just to make others happy. However, I have an impression that a lot of people are able to get away with that.

Does below sounds familiar to you?

Clean Coder - rush to complete

Do you remember a situation when you thought: “Damn, I wish I didn’t add this test. I would save a day”? What about situation like: “Damn, I wish I did add that test. It would cost me 1 day, but I would save 2 days I spent fixing the bug this test would guard against”? I’ll let you to deal with the answer.

If you don’t want to read entire book, read first 3 chapters. It is a great summary and advice on common wrong doing of most programmers that is not caused by their lack of proficiency, but rather not sticking to their professionalism and discipline.

Ohh…and if you have never heard about Uncle Bob checkout Every Uncle Bob Robert C Martin Video playlist on youtube, his blog, and SOLID principles. Uncle Bob is like your doctor who is telling you that you should eat healthy and exercise regularly. He has similar advises, but about how you should write code.

The Clean Coder is definitely one of the best books I’ve read about Software Development, and I’m adding it to my favorites.

Are you developer? What are your thoughts? Does some situations described in this book happened for you? Maybe you are business person? What do you think? Leave a comment!


Lean Startup

The Lean Startup (Eric Ries)

If you are building a product that is not yet released you should read this book. If you are building a product that is already released you should also read this book. If you are working on some overnight idea this is a must read! Why? In all cases it will help you to plan features, use data-driven approach for making decisions, and avoid waisting time by doing work that is not needed.

Eric Ries describes – on example of his own startup – how his team wasted weeks and months of development work, by working on features that turned out to be not needed nor wanted by customers. To avoid such pitfall, he is proposing different approach: create simplest possible prototype, release it and wait for users’ feedback.

Lean startup is not only for startups. It is for everyone working on some product. From 1 person to international corporation. Eric gives great advice on how to evolve products and how to maximize your ROI (Return of Investment). He emphasize the importance of ability to reacting to feedback fast, not focusing too much on vanity metrics, but focusing on long term vision instead.

This book goes to my favorite books list!

If you haven’t read it yet, I strongly encourage you to do so. If you did, share your thoughts in comments!


Working Effectively with Legacy Code

I haven’t publish any book review for a while. It does not mean I am not reading books anymore. I just didn’t feel that some of the books I read recently requires my recommendation, or I didn’t have any thoughts that I needed necessary to share right now.

I have added a few books to my favorite books list though. Check them out!

Working Effectively with Legacy Code deserves blog post because of a few reasons:

  1. Every Software Developer should read it
  2. It’s not really about legacy code
  3. Published in 2004 (12 years ago!) is still very up to date

Working Effectively with Legacy Code 1st Edition by Michael Feathers (Michael Feathers)

The book has three parts:

  1. Importance of unit tests when changing software
  2. Recipes for real World problems that we face when changing software (e.g., “I need to change a monster method” or “What methods should I test when introducing a change”)
  3. Dependency-breaking techniques catalog

The first part should be familiar to most of programmers these days. If it is not for you then you should read Agile Principles, Patterns and Practices (by Robert Martin), TDD by Example (by Kent Beck), and The Art of Unit Testing (by Roy Osherove). You can thank me later.

The second part is the essence of the book. It shows, by example, how to add new feature, make a change to existing code, or fix a bug. Most books about software development, present examples on very simple, clean code that we never see in real World. This book, takes some messy piece of code and shows how to make it testable, how to get rid of too many side effects, and clean it up by separating dependencies and responsibilities. Many times we want to test one functionality, and then we realize that we need to instantiate tens of objects that other method depends on. Sounds familiar? This chapter shows how to handle that.

The last part (Dependency-Breaking Techniques) is very similar to Martin Fowler’s Refactoring: Improving the Design of Existing Code. It’s a set of techniques, and step by step description how to apply them to existing code.

As I mentioned earlier. This book is not really about legacy code. I think it is more about evolving existing code. It is natural, when adding features, we add lines of code to the method. The hard part is to know when you should extract new method, or introduce a class, and refactor dependencies. It’s OK to have global variables. The problem is to keep track of them or localize them. How do you know, that adding a new functionality will not break something? You have 100% test coverage for every possible use case? That’s not possible because of complexity of software we are creating today. “What methods should I test” shows neat technique to backtrack effects, and side effects of a change that we are introducing.

There is much more, and you should check out this book. You don’t have to read it from cover to cover. I strongly recommend you, at least, to scan through part 2 (changing software), and I am sure you will learn something new that you can apply for your project today!


Soft Skills by John Sonmez

Soft Skills (Jon Sonmez)

Soft Skills: The Software Developer’s Life Manual by Jon Sonmez is a great set of advises about every aspect of programmer’s career and life. Take a look at the book content:

  1. Career
  2. Marketing yourself
  3. Learning
  4. Productivity
  5. Financial
  6. Fitness
  7. Spirit

This book is not a source of truth for everything, but it may give you useful ideas for some particular aspects of your career and life. John is explaining that programmer’s career is not only about coding. I especially like the fact that this book is not only about the work/career oriented things, but it puts work and life together. John explains the importance of living a healthy life (exercise and diet), and how this will help you with your career. He also showcases how to manage your finances throughout your career, and the importance of thinking “long term”.

For more, check reviews on Amazon and GoodReads.

Enjoy!

Have you read this book? What do you think? Share your opinions in comments!


Basecamp books: Getting Real, Rework and Remote

Getting Real: The Smarter, Faster, Easier Way to Build a Successful Web ApplicationRework (David Heinemeier Hansson and Jason Fried)Remote: Office Not Required (David Heinemeier Hansson and Jason Fried)

Recently I read 3 books written by founders of Basecamp (formerly 37 Signals): David Heinemeier Hansson (creator of Ruby on Rails framework) and Jason Fried:

Getting Real was written almost 10 years ago, and it talks about the same things as most recent Remote. So you can skip it. However Rework, and Remote are definitely worth to read. They present the new(?) approach for work, and productivity.

Rework focuses on pragmatic ways to improve your (and your company) productivity.

Remote presents how remote working can be applied in your company. All Basecamp employees are remote workers.

Of course authors present ideas that works for them, and may not necessary work for you. However, I am sure you will appreciate more than one of their advises.

This is one of my favorites quotes from Remote:

remote - quote

As a teaser you can watch Jason Fried’s Ted talk: Why work doesn’t happen at work. I also recommend David’s talk: Unlearn Your MBA (from Stanford University).

Both Rework, and Remote goes to my favorite books list.