book review

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!


My notes from The Passionate Programmer

Chad Fowler - The Passionate Programmer

It’s been a while since I read Chad Fowler’s The Passionate Programmer.

Recently I found notes I did during reading it. I thought I would share them with you. It is tl;dr of every one of 53 chapters of the book.

1. Keep on radar bleeding edge technologies vs sunset technologies.
2. Follow job market requirements.
3. Understand business.
4. Be the Worst in the team so you can learn from others.
5. Learn/know different type programming languages (C#, C, python, prolog…).
6. Avoid fear-driven career choice.
7. Keep on radar known tech/platforms vs unknown(to learn).
8. Learn what is under abstraction layer of your programming language.
9. Use different technologies.
10. Log your excitement level over days.
11. Everyday learn something new about tech/tools you are using.
12. Learn how business work.
13. Have/find a mentor.
14. Be a Mentor.
15. Practice (Google Code Jam, Project Euler, Code Katas).
16. Know/learn Software Development Methodologies.
17. Read other’s code (and criticize it).
18. Automate tasks.
19. Do it now!
20. Predict the future – possible requested features (make it easy to implement it).
21. Make daily review (problems, processes to improve).
22. Understand your manager/company goals.
23. Set goals for you current job (long term).
24. Make boring tasks fun!
25. How much are you worth?
26. Share you areas of knowledge in job (implemented modules, deployment process etc.). Make documentation.
27. Measure (by metrics), improve, measure.
28. Work as hard as you can (no fb, twitter etc.).
29. Learn how to fail.
30. Say ‘No’ when you know you cannot do something.
31. Don’t panic.
32. Say It, Do It, Show It.
33. Be aware what others think about you (managers, team mates etc.).
34. Don’t make people afraid of you.
35. Track you decisions and analyze them (diary).
36. In person communication over email/Skype.
37. Have elevator pitch (business benefits of your recent work).
38. Have the mission!
39. Be present on-line (blog, twitter, LinkedIn).
40. Care about your brand (google yourself).
41. Contribute to open source!
42. Be remarkable (do something what will take a week in one day).
43. Propose changes/features to software you are using (mail author).
44. Be up to date with current/new tech.
45. Try to do your job as you are your manager.
46. Path is more important than destination.
47. Create map of your past, current and future career (and what your learn, when you lost time).
48. Try to be alpha geek (or follow some of them).
49. Ask your coworkers for feedback.
50. Avoid monkey traps (do not be too confident in some things, or review them from time to time; know your enemy – play with technology you don’t like).
51. Avoid Waterfall career planning.
52. Be better every day.
53. Try to go independent (e.g. 2 hours/day after work hours) – how much did you earn?

This book helped me to drive my career, and I am sure it will help you with your career!

Have you read this book? What do you think? Maybe you know some other books you would recommend?


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!


The Expert Beginner

The Expert Beginner (Erik Dietrich)

A few months ago I read great article written by Erik Dietrich – How Developers Stop Learning: Rise of the Expert Beginner. After publishing this article, and receiving a lot of positive feedback, Erik has written multiple follow up articles. He also has written a book, which I decided to buy and read: The Expert Beginner ($5 for Kindle Edition!).

This book is a very interesting case study, in which Erik analyzes developer’s growth, and how some people get comfortable with their current knowledge, stop learning, and are not willing to step out of their comfort zone. Erik call this stage: “Expert Beginner”. This leads to stagnation, and no interest to improve. What’s worse it affects their coworkers.

I really recommend you to read “The Expert Beginner”. It’s quick read (68 pages), and may help you not fall into this trap.