After reading that book I feel like my knowledge about the industry, and specifically the software developer role, has solidified. I didn’t know exactly before buying if it’s going to be full of coding exercises and practices that Software Craftsman do, or rather a story based book. It turned out to be the latter. I enjoyed when Sandro shared his personal stories and what he learned from them. While reading, it felt like receiving advice from experienced dad, who worked in the industry that you are about to join now as a fresh man. I loved it even more, because the language used in the book and the believes about how professional software developer should behave and work, align with my vision of who I want to be in my career. I certainly don’t like to slap labels on and call myself a software Craftstman / Master / visionary / you name it. When Sandro went on to define the Craftsman in the book, he equates Craftsman with professional. A professional software developer with a spine, this is who I want to be.

X-ray of the book:

Personal story

I relate with the author as a second language user and expat, living in the same city - London. Our paths are totally different but knowing what people go through and how they achieve their goals fuels and recharges my energy packs to continue my own mission. Thank you Sandro for showing me it’s always possible.

What modern developers need to know in order to be considered senior / craftsman’s

Here Sandro explains and talks about the developer from 20 years ago, where he only was focusing on writing code and not talking to anyone about it and compares that with the nowadays developer who is highly connected with his business and teams around with who he speaks continuously to be able to understand their needs, therefore assign best technology to deliver software solution that is perfectly crafted for the purpose. If business wants to change and iterate, he’s ready for it. That’s professionalism. Key things the modern software developer should know these days:

  • how to speak to customers
  • automate tests and deployment
  • make technological choices that may affect the entire business
  • work in distributed teams
  • help clients to define and prioritize requirements
  • report progress
  • manage changes and expectations
  • present products to potential clients or partners
  • help with pre-sales
  • estimate time and costs
  • interview new team members
  • design and evolve the software architecture
  • deal with non-functional requirements and service level agreements
  • understand business goals
  • make decisions based on trade-offs
  • keep an eye on new technologies and better ways to do things
  • worry about the value delivered to their customers
“We don’t do Agile, Either we are Agile or we are not.”

Learning and reading about Agile is certainly a good idea, especially if it comes from a person who lived and breathed it. Sandro explains concept of Agile working practices and how & why to go around it amazingly well. He also warns that without a technical excellence, every software project will be a painful, frustrating, and expensive experience. I personally, as an aspiring software developer, struggle to find this perfect middle point between knowing I am valuable and being a burden and not ready for the job yet.

“Software Craftsmanship is about professionalism in software development.”

This definition is authors view on what ultimately software craftsman “badge” means. It’s a non stop improvement, iteration and perfection as a person. As you read the tasks above, loosely describing modern developers job, you can clearly see that there’s lot to learn about and to work with.

“not to waste time and money”

It’s the main reason I picked up this book. I would not want to wake up one day, couple of years later and realize I have wasted quite a few years to figure out best way to learn how to be and eventually become a professional software developer. I’d like to apply SC (Software Craftsman) principles and work with SC’s to create best code I can from the very beginning and skip the part where I have to forget my old and useless coding habits as a mediocre developer. That’s why I want to learn from a Software Craftsman from the beginning of my journey.

“If we think that a piece of cod we wrote some time in the past is still good enough today, it means we didn’t learn anything since.”

A powerful quote. I wanted to make a not of this as this is a crucial part of what it means to constantly develop your ways of working and writing code. It means it needs to be, at least slightly, daily, weekly, monthly pruned. Like a garden. There’s this metaphor along the book, where code is compared with garden and legacy code many times being the neglected and not taken care of garden.

“Developers who rely only on their companies to provide them knowledge are not professional developers.”

Author asks question: Who owns your career? Many times we might think it’s not within our hands to do something about our career. The opposite thought is so much more true. We need to acknowledge our responsibility to grow and invest in ourselves even if others don’t. Sandro lists many ways to polish our knowledge. I particularly enjoyed how he describes books and divides them into groups, giving advince on what kinds of books to read at the beginning of your software development career.

Some of the books that I will want to explore (and author recommends), since they are the revolutionary books:

  • The Pragmatic Programmer
  • The Mythical Man-Month
  • Design Patterns (GoF)
  • Test-Driven Development: By Example
  • Extreme Programming Explained: Embrace Change
  • The Clean Coder
  • Software Craftsmanship
  • Refactoring
What if I don’t know what I don’t know, how to improve from that point?

A good question raised by author. Many times we don’t know what is it that we need to know. It might seem easy to know from a perspective of person who already has experience. Things don’t look so perfectly clear when you’re starting out or simply never heard about that tool or framework. A couple of ideas about how to approach this blockade is to speak to random colleagues and ask them how they keep up with the progress in industry. Go to technical community and user group events. Show your code to other people. Ask for help even when you think you don’t need it. Try to figure out which aspects of your current project you and your team have not explored yet, then start discussions about it or even write a proof of concept. You can always ask uncle Google or duck duck if you’re not happy to share your privacy data ;)

Saying no without providing options does not help much

I loved this little sub chapter as it contained a story about a businessman that after arriving in new town, ordered his PA’s to get him fresh orange juice. One PA went and came back within 5 minutes with empty hands and reported that local shops don’t have fresh orange juice. The second PA took 20 minutes to come back. Annoyed businessman asked why did it take you so long to figure out that they don’t have orange juice? PA answered “They don’t have orange juice but they have pineapple and apple juice. The pineapple juice is fresh but the apple juice is bottled. I also asked around and discovered that there is a supermarket a little bit further away where I could buy some fresh oranges and could make you a fresh juice. I can get you a pineapple or apple juice in five minutes or, if you prefer, I can make you a fresh orange juice in 30 minutes. I just need to know which one you prefer.”

Which PA did their job better? Which left businessman to do the job? Which took more of your time? I guess the answer is clear and it correlates with any profession and it shines as an example of how developer should do her job. They should always strive to deeply understand what business needs and supply their colleagues with information and alternatives if things can’t be done in a certain way. Don’t just say “No”.

Random thoughts that caught my eye

“Attitude is a little thing that makes a big difference”
-Winston Churchill

A quote in regards to legacy code and how can we perceive this. We can either see it as an interesting problem to solve or a pain in the neck. I believe the former is more productive and I am genuinely curious when I have that perspective rather than the “oh” and “ah’s” about how stupid someone was when they coded it in the first place.

“If a piece of software is expected to live and be maintained for more than a few weeks or months, neglecting its quality is order to go faster is an illusion.”

“spotting bad code takes as long as spotting cancer and afterwards nothing really can be done about that”

This is my paraphrase but it gives you enough to understand how crucial it is to code well as it’s very easy to fall into a trap and only get to know that when it’s too late.

Using TDD == smart ?

I guess the answer should be obvious to developers but not always as obvious to business owners and stakeholders. Developers job is to make it clear to those people that it’s vital to use TDD. So firstly developers and their managers need to be sold on TDD. How can you achieve that?

I spend couple of years selling things to people and if I was to say one thing I learned about how to sell things, would be ask good questions. What good questions can we ask in regards to TDD?

  • What if we could press a button and be confident, after a few minutes that our entire application is working?
  • How long does it take us to test and deploy our application to production?
  • If a bug is found in production, how quickly can we fix the bug and have a new version of the application deployed?

  • TDD and it’s business value p.98
  • Book recommendation: p.99
  • p.105 quote from Pragmatism subtitle
  • good questions to ask business managers or owners in order to sell them the idea of XP practices p.106
  • knowledge is forever quote from p.112
  • amazing example of bad politics in big corporations and how it escalates and thus drives companies out of business p.114-115
  • p.123 - link to articles on job description anti-patterns - www.tlnt.com
  • p.130 - Software Craftsman recommendation quote

I loved chapter about interviewing and the perspective author shared, both as a recruiter and potential employee. Questions like: Was the job add written by a hiring manager or HR? What type of technology is being used in company and what implications does this present? Have you been talking to developers or hiring managers on interview? Are company employees trying to top up project with more developers or are they looking for specific talent? Why? and many more. I believe that knowledge shared in this one chapter is alone worth it for any junior developer who would like to avoid bad choices on their career.

  • chapter about interviewing and looking for best fitting roles out on the market - share my thoughts on this p.140, quote p.141
  • what Sandro is looking for when hiring for existing team? p.149
  • research “adolescent surety”
  • p.188 quote
  • p.190 quotes that go along my personal values very well
  • p.204 quote about responsibility and accountability
  • p.212 on how approach refactoring
  • p.218 four rules of simple design downgraded to 2 rules
  • p.222 pragmatic craftsmanship chapter summary - extremely well said
  • p.224-5 what it means to be a craftsman and how it aligns with my personal values
  • p.229 what to ask yourself before choosing a job

Want to read the whole book?