The long way through Software Craftsmanship

Books read in 2017Q3

Sep 30, 2017 - 5 minute read - Comments - bookreading2017Q3self-studycoduranceaprendicesreading-club

Read this quarter:

  • the senior software developer; Copeland, with the aprendices reading club
  • Scandal in Bohemia, a; Doyle: a short novel by Sir Arthur Conan Doyle, mentioning Irene Adler and the king of Bohemia
  • Getting things done, …; Allen (+): A book on productivity, where Allen explains his method of GTD and how to apply it. Explains what has worked and not worked for him in his many years of consulting and coaching clients.
  • Nature of Software Development, the; Jeffries: Jefrries explains what he sees as ‘the Natural way’ of software development: agile-based, good technical practices-based, to produce software in an iterative incremental way, with a sustainable pace and not much technical debt.
  • Clean Coder: A Code of Conduct for Professional Programmers, the; Martin: a set of principles, values, and practices for the professional programmer (as compared to the 9-5 amateur programmer).

Note: re+read means I’m re-reading this book. The (+) stands for one-or-more times, as in the regexes.

backlog (partially sorted):

  • unsorted V
  • The Machine That Changed the World: The Story of Lean Production
  • Haskell Programming
  • Software Architecture in Practice
  • The five disfunctions of a team: a leadership fable; Lencioni
  • Phoenix project, the ; Kim, Behr, Spafford
  • lucha por la desigualdad, la; Pontón; non-technical
  • psicología del dinero, la; Hammond; non-technical
  • Invirtiendo a largo plazo; García Paramés; non-technical
  • Well-Grounded Java Developer, the; own-it
  • Quién domina el mundo; Chomsky; non-technical
  • Learn You a Haskell for Great Good!; own-it
  • camino al 18J, el; Payne; non-technical
  • Cartas desde la revolución bolchevique; Sadoul; non-technical
  • Java Performance: The Definitive Guide
  • Why programmers work at night
  • Shogun: The Life of Tokugawa Ieyasu; Sadler; non-technical
  • Scrum and XP from the trenches, 2nd edition;
  • Els jueus i Catalunya; Villatoro; non-technical
  • El problema de los tres cuerpos; Liu; non-technical
  • Amazon Web Services in Action; own-it
  • Clojure Programming - Practical Lisp for the Java World
  • Mature optimization
  • XUnit Test Patterns
  • Let Over Lambda
  • The Haskell Road to Logic, Math and Programming
  • Types and Programming Languages
  • Fundamentals of Object-oriented Design in UML
  • Clojure for the brave and true
  • How to Solve It: A New Aspect of Mathematical Method
  • Conceptual Mathematics: A First Introduction to Categories
  • Understanding Computation: From Simple Machines to Impossible Programs
  • Programming in Haskell
  • Programming Languages: Application and Interpretation
  • Doing Math with Python
  • Perfect Software: And Other Illusions about Testing
  • Computability and Complexity - From a Programming Perspective
  • Thinking Forth: a language and philosophy for solving problems
  • Concepts, Techniques, and Models of Computer Programming
  • Bridging the Communication Gap; Adzic
  • Specification by Example; Adzic
  • Cucumber book, the; Adzic
  • Software Architecture for Developers; Brown
  • Object Design: Roles, Responsibilities, and Collaborations
  • RESTful Web APIs
  • RESTful Web Services Cookbook
  • Building Maintainable Software
  • Serverless - Patterns of Modern Application Design Using Microservices (Amazon Web Services Edition)
  • A Pattern Language; Alexander
  • Types and Programming Languages, TAPL; Pierce; own-it
  • Speed Reading Book: Read More, Learn More, Achieve More, the; Buzan
  • Cómo crear mapas mentales (Crecimiento personal); Buzan
  • First things first; Covey
  • What’s best next; Perman
  • problems of philosophy, the; Russell
  • Requiem for the American dream; Chomsky
  • sun also rises, the; Hemingway
  • travels, the; Polo; non-technical
  • Homo Deus: A Brief History of Tomorrow; Harari; non-technical
  • Books by Aristotle; non-technical
  • Books by Plato
  • Books by Descartes
  • The idea of culture; Eagleton
  • Hereditary Intelligence; Galton; non-technical
  • Lean Software Development: An Agile Toolkit; Poppendieck
  • Peopleware*; De Marco
  • Chaos Monkeys: Obscene Fortune and Random Failure; Garcia Martinez
  • Implementing Lean Software Development: From Concept to Cash; Poppendieck
  • Joel on Software; Spolsky
  • Death March; Yourdon
  • Psychology of Computer Programming, The; Weinberg
  • Introduction to General Systems Thinking; Weinberg
  • Lao Tzu : Tao Te Ching : A Book About the Way and the Power of the Way; Tzu, Le Guin; non-technical
  • Gay Science, the; Nietzsche; non-technical
  • Being Geek; Lopp
  • Finance for Freelancers; Retallick
  • Object-oriented software engineering: a use case driven approach; Jacobson
  • Patterns of Enterprise Application Architecture; Fowler; own-it
  • Thinking fast and slow; Kahneman
  • Emotional intelligence; Goleman
  • Ética a Nicómaco; Aristotle; own-it, non-technical
  • Romeo y Julieta; Shakespeare; non-technical
  • Computer Systems: A Programmer’s Perspective; Bryant, O’Hallaron
  • My Journey to Lhasa: The Classic Story of the Only Western Woman Who Succeeded in Entering the Forbidden City; David-Néel; non-technical
  • Cathedral and the bazaar, the ; Raymond
  • Coding dojo handbook, the; Bache; own-it
  • Making software; Oram and Wilson; own-it
  • Code complete; McConnell
  • Soft skills; Sonmez; own-it
  • DSLs in action; Ghosh; own-it
  • purely functional data structures; Okasaki; own-it
  • Working effectively with unit tests; Fields (+); own-it
  • First Nazi, the; Ludendorff
  • Greatest story ever told … so far; Krauss; non-technical
  • Master algorithm, the; Domingos; non-technical
  • Invention of Science, the; Wootton; non-technical
  • Tesla: Inventor of the electrical age; Bernard Carlson; non-technical
  • Psychology in minutes; Weeks; non-technical
  • Alan Turing: The Enigma; Hodges; non-technical
  • How to think more about sex; de Botton; non-technical
  • Piccolo manuale di persuasione; Taylor; non-technical
  • arte de la guerra, el; Sun Tzu; non-technical
  • Piccolo manuale di leadership Confuciana; Adair; non-technical
  • How to Stop Worrying and Start Living; Carnegie; non-technical
  • Uomo - Guida allo stile; Roetzel; non-technical
  • Unwritten Laws of Engineering: Revised and Updated Edition; King
  • Test-Driven JavaScript Development (Developer’s Library); Johansen
  • Test Driven Development: By Example; Beck
  • Arquitectura Java JPA Domain Driven Design; Alvárez, Peláez
  • End of loyalty, the; Wartzman; non-technical
  • Basic Economics; Sowell; non-technical
  • Introduction to Economic Analysis; McAfee; non-technical
  • Patterns of Software; Gabriel
  • Coders at work; Seibel
  • Clean architecture; Martin
  • How to Be a Stoic: Using Ancient Philosophy to Live a Modern Life; Pigliucci; non-technical

unfinished (unsorted):

  • Release It! - Design and Deploy Production-Ready Software; own-it
  • Refactoring (+); Fowler; own-it
  • The Leprechauns of Software Engineering; Bossavit (+); own-it
  • Domain-Driven Design: Tackling Complexity in the Heart of Software; Vernon (+); own-it
  • Pragmatic Thinking and Learning: Refactor Your Wetware; own-it
  • Functional Programming Patterns in Scala and Clojure; own-it
  • Readings in Database Systems, 5th Edition; own-it
  • Structure and Interpretation of Computer Programs (SICP); Abelson, Sussmann, Sussmann; own-it
  • La Sociedad De Coste Marginal Cero (Estado y Sociedad); Rifkin; non-technical
  • Odisea; Homero; non-technical

wip (3):

  • Working Effectively with Legacy Code (+); Feathers; own-it
  • Effective Java; Bloch; own-it
  • Nonviolent communication; Rosenberg; own-it, non-technical


  • Senior software developer, the; Copeland; own-it
  • Scandal in Bohemia, a; Doyle; own-it
  • Getting things done, …; Allen (+); own-it
  • Nature of Software Development, the; Jeffries; own-it
  • Team Geek; Fitzpatrick, Collins-Sussman; own-it
  • Aprendo Yoga; Van Lysebeth; non-technical, own-it
  • Clean Coder: A Code of Conduct for Professional Programmers, the; Martin; own-it
  • ML for the working programmer, 2nd edition [5th chapter only]; Paulson; own-it


Self-Study in September 2017

Sep 1, 2017 - 2 minute read - Comments - self-study-aggregationseptember2017androidbelen-albezacarchantal-panozzochip-heathclipboardcodingcomparisoncopy-pastecore-valuedanielle-kurtzlebendavid-piercedecisiondecision-makingearly-retirementeconomyenergy-managementfinancefinancial-independenceformatfrugalityhotspotimprovementindependenceinvestmentiosiphoneliving-standardmatt-burroughmobile-deviceopinionphoneretirementrulesecuritysocial-securityswitzerlandten-ten-ten-ruletime-managementususavalueway-of-livingwindowswork-life-balance

How the Clipboard Works, Part 1

I’ve read this article, by Matt Burrough, on how the clipboard works on windows.

Explains how the API works and how the different formats and priorities are organized so the new application can decide which format to accept.

Tags: windows, clipboard, matt-burrough, format, copy-paste

Top developers can have a life outside coding

I’ve read this article by Belen Albeza on how top coders don’t need to spend all their time programming or with activities related to programming.

Explains some techniques to make the most of the working hours and some strategies to balance your work-non-work life.

Tags: belen-albeza, coding, time-management, energy-management, improvement, opinion, work-life-balance

Your phone is your most vulnerable gadget. protect it now

I’ve read this article by David Pierce on how the phone device is vulnerable and what options we have available to make it a secure computing device.

Either switch to a branded-as-secure phone or stick to the main options (Android, iPhone) plus activate some options (updates to the apps and operating system), stay away from public hotspots, don’t lend it to strangers and use some apps to monitor what resources apps are using

Tags: david-pierce, security, phone, mobile-device, hotspot, iphone, android, ios

Living in Switzerland ruined me for America and its lousy work culture

I’ve read this article by Chantal Panozzo comparing the way of living and the economic standards in Switzerland and the US.

Mainly about the topics of the social security network, provided by the state, taxes and owning a car

Tags: chantal-panozzo, comparison, way-of-living, living-standard, car, social-security, usa, us, switzerland, economy

The 10/10/10 Rule For Tough Decisions

I’ve read this article by Chip Heath on a technique to make hard decisions: the 10/10/10 rule; How would you feel 10 minutes, 10 months and 10 years after having applied the actions from that decisions?

Tags: decision, decision-making, rule, ten-ten-ten-rule, chip-heath

How to retire in your 30s: save most of your money and rethink your core values

I’ve read this article by Danielle Kurtzleben on how to retire early or achieve financial independence early in your career: save a big percentage of your salary, invest wisely and reduce costs.

Tags: danielle-kurtzleben, investment, frugality, early-retirement, retirement, financial-independence, independence, finance, value, core-value

Finding all pending work in progress (WIP) in your workspace

Aug 7, 2017 - 1 minute read - Comments - bashtoolopen-sourcemicroservicepending-workwipwork-in-progressleanvaluepracticecontinuous-deliverycontinuous-integrationworkspace

It is a good practice to push your local work at the end of the day. Be it for increasing the bus factor (more people have the code), be it for reducing the lifespan of the branches (less time without integrating) or just enabling visibility (your teammates to see what has been developed). If you’re using Continuous Integration (CI) or Continuous Delivery (CD), this is even more often

You can even do it more often: for example before going to lunch, before a meeting, before a demo, etc.

Working with many repositories (e.g. a microservices environment/architecture), it is often the case where you will have multiple folders with work, possibly work in progress (WIP).

This is why we have created a small tool to detect git repositories that have local changes that haven’t been pushed yet: Find WIP

Feedback is more than welcome.

Self-Study in August 2017

Aug 1, 2017 - 3 minute read - Comments - self-study-aggregationaugust2017adrian-colyeramazonamazon-web-serviceamir-salihefendicanalogyappastasyncattack-surfaceawsbitcoinbusinesschatchris-dixonchristian-kellnerchromechromiumcljsclojurescriptcommunicationcomparisoncontractcryptocurrencydebiandeep-workdefectdistributiondistrodoistemacsethereumflashglaciergooglehackhueinge-solvolliotjames-forshawjavascriptjslinuxlspmarko-karppinenminerminingmoocomonline-communicationpassive-incomephilipsphilips-hueppapiprivate-networkproductivityproject-zeropublic-networkquoterasqreactreagentreal-timerelease-noterustsaku-panditharatnesecurityside-businessside-projectslacksmart-contractstretchtodoisttokentwistwin32win32kwindowsworkzigbee

How I ended up paying $150 for a single 60GB download from Amazon Glacier

I’ve read this article by Marko Karppinen that explains how a mistake in understanding the pricing model of AWS Glacier cost 150$ instead of the expected 0.86$

When cloud providers use uncommon and/or unpredictable pricing models, even your informed hunch about the cost can be off by several orders of magnitude, like the price differential between an iPad and a Ferrari.

The only way to avoid this is by reading, very carefully, through the laughably long passages of meandering technical trivia that constitute the Glacier FAQ or, indeed, this Medium post.

Tags: quote, glacier, amazon, aws, amazon-web-service, marko-karppinen

Debian 9 Stretch released

I’ve read the release notes for Debian 9 “Stretch”. By the Debian team

Tags: debian, release-note, stretch, linux, distribution, distro

Why we’re betting against real-time team messaging

I’ve read this article by Amir Salihefendic on why they have created a tool for online async communication, where the online presence icon is disabled and communications happen around threads.

Trying to transform the online (from real-time to async) communications to leave spaces for deep work.

Tags: amir-salihefendic, deep-work, todoist, doist, twist, app, slack, online-communication, communication, productivity, async, real-time, work, chat

Crypto Tokens: A Breakthrough in Open Network Design

I’ve read this article by Chris Dixon that explains what is a crypto currency, what is a smart contract and how this can revolutionize the market.

Also explains public vs private networks and tokens

Tags: chris-dixon, public-network, private-network, token, ethereum, bitcoin, cryptocurrency, contract, smart-contract, miner, mining, comparison

JSX vs Clojurescript: the showdown

I’ve read this article comparing the Reagent vs React (clojurescript vs javascript), going into details for both technologies. By Inge Solvoll

Conclusion: Code vs Data

Hopefully I managed to show you a few things that Reagent brings to the table:

  • Concise and compact
  • Creating functional style components is super easy
  • Immutable data is the default
  • But the thing that fundamentally separates it from React/JSX is the data focus.

JSX creates instructions: React.createElement(‘div’). Reagent creates data structures: [:div]. The former is opaque, hard to inspect at runtime. The latter is highly transparent, and easily inspectable in more than one way.

Your app is declared using nothing but pure data, using nothing but plain functions to manipulate the data. The very rich Clojure standard library with functions like map, filter and reduce at your disposal, without any funky new syntax to learn.

Tags: clojurescript, comparison, javascript, react, reagent, om, cljs, js, inge-solvoll

IoT goes nuclear: creating a ZigBee chain reaction

I’ve read this article by on the security of Philips Hue lightbulbs, a kind of IoT device that has been hacked using a defect in their protocols

Tags: adrian-colyer, zigbee, philips, hue, philips-hue, iot, defect, hack, security

Breaking the Chain

I’ve read this article by James Forshaw, in which they explain how the Chrome browser does not use the Win32k system calls (under certain conditions), to reduce the attack surface

Tags: attack-surface, rasq, security, chrome, chromium, project-zero, win32k, win32, windows, google, flash, ppapi, james-forshaw

Language Server Protocol (lsp), rust and Emacs

I’ve read this article by Christian Kellner about a common way of operating with a program’s Language Server Protocol (LSP) so all languages could benefit from standard tools. Then, a new editor would just have to implement the bindings to LSP to support those.

Similar to what LLVM is to some languages: once you specify your syntax in terms of LLVM, you can benefit from the improvements that LLVM provides.

Tags: christian-kellner, lsp, emacs, rust, ast, analogy

How to Create a MOOC in 28 Days

I’ve read this article by Saku Panditharatne on how she has created a massively open online course (MOOC).

Tags: saku-panditharatne, mooc, passive-income, business, side-project, side-business

The Nature of Software Development: Part I

Jul 9, 2017 - 7 minute read - Comments - bookron-jeffriesquotereading-breadcrumbthoughtnature-software-developmentpartagilemanagementsoftware-processthinking-processminimum-marketable-featuremmf

The Nature of Software development: reading breadcrumbs, quotes, thoughts


The Natural Way serves end users well because it delivers value to them sooner.

serves the business […] because it provides important information quickly, and because it provides the ability to adjust direction as needed.

serves management […] see what’s really going on inside the project so that when action is needed, there will be time to act. And it reduces management’s problems by making information visible […]

[…] easier for developers. […] clear direction and allows them freedom to use their skills to build what the organization needs, when it’s needed.

(p. xv)

Part I: The Circle of Value

Chapter 1: The search for value

Value. “what you want.”

(p. 5)

On the building blocks of value or to produce value:

Guiding. We produce value by creating teams with responsibility for creating value.

(p. 5)

The value in guiding is not related to creating value in itself, but to help others so they can create value.

Therefore, the value of guiding depends on the value of the value-producing people

Organizing […] We organize around features, because features give us the ability to plan and build value most rapidly

(p. 5)

Planning […] selecting the features we need, in the order we need them.

(p. 5)

Building […] product feature by feature

(p. 5)

Slicing […] smallest possible value-bearing size

(p. 5)

Quality […] always has a good design and that it is as nearly defect-free as possible

(p. 5)

Chapter 2: Value is What we Want

we generally get value by delivering features. Features that have value. Features that we want.

(p. 7)

software can save time or money. Software can help us earn money

(p. 7)

I think of value as simply what we want […] Each choice gives us something we value

(p. 7)

A project delivers value only when we ship the software and put it to use

(p. 8)

Since most users don’t use all the features, a smaller set of features can provide real value, and provide it sooner.

(p. 10)

pieces that make sense to us, and to our users. […] minimal marketable features (MMFs)

(p. 12)

Chapter 3: Guiding Goes Better “Feature by Feature”

With a monolithic project, late in the game we can’t do much to cut costs. We have already written requirements for things we’ll never get

(p. 22)

We laid out this project with an all-or-nothing mentality.

(p. 22)

When our projects grow feature by feature, we can respond to what’s really happening. We can respond to the changing needs and inputs of the business and of management.

(p. 24)

Chapter 4: Organizing by Feature

To get the work done, different parts require different skills. The work won’t be done […] until it has had the attention of people with each needed skill.

If we organize teams by skill-set, each piece of work will need to be passed around among teams

(p. 26)

organize into small teams, each of which builds features that the Product Champions can understand. Make sure that each team has all the people and all the skills necessary to build the entire feature, not just part of it

(p. 27)

[…] we can allocate work across teams easily […] Responsibility and authority are aligned.

(p. 27)

the people belong to the feature teams.

(p. 30)

You belong to your family; you’re a member of the golf club

(p. 30)

A highly paid expert shouldn’t be highly paid just because she’s an expert. She should be highly paid because she is helping other people become experts.

(p. 30)

Chapter 5: Planning Feature by Feature

Vision is about big ideas, not tiny bites.

(p. 32)

General Eisenhower said, “Plans are useless, but planning is indispensable.”

(p. 33)

We do need to plan. We don’t need a detailed list of what will happen and when

(p. 33)

[…] software people are terrible at estimating, because humans are terrible at estimating.

(p. 34)

set a time and money budget; produce the most valuable features first; keep the product ready to ship at any time

(p. 34)

It’s not good enough to plan just at the beginning

(p. 36)

I don’t recommend working with larger stories and breaking them down into technical items, often called tasks

(p. 36)

Stick with stories

(p. 36)

[…] break down stories into smaller stories, each making sense to the business-side people.

(p. 36)

the team itself should decide how much work it can accomplish in the next two-week interval

(p. 37)

The point isn’t to make good estimates—the point is to do good work at a consistent pace.

(p. 37)

There are some serious risks to estimates: we have an almost irresistible desire to “improve” them, or to compare them. […] business and management get the best results by selecting the work to be done and the work to be deferred

(p. 38)

Is prediction better than steering?

(p. 38)

Planning with “stretch goals” is destructive.


Hurrying, they’ll inject more defects. Since defects take longer to fix than they do to prevent, hurrying will slow you down. […]


Dirty code slows you down as well […]

Pressure is destructive. Avoid it.

(p. 39)

[…] estimates are likely to be wrong, and they focus our attention on the cost of things rather than on value.

(p. 40)

Chapter 6: Building the Product, Feature by Feature

We need to sharpen our vision of what the product must do—and what’s just “nice to have.”

(p. 45)

To be sure we’re free of defects, we need to check everything, all the time […]

(p. 48)

[…] grow the design as we go. If we design too much, we won’t get as many features, and that will show up. If we design too little, features will be hard to do, we’ll slow down

(p. 49)

Chapter 7: Build Features and Foundation in Parallel

Each feature needs a solid foundation of design, a solid “infrastructure.”


We need to do as little work as possible to deliver the best possible product by our delivery date…and we need to do that work as soundly as we can afford.

(p. 53)

Developers are often trained to try to design a system up front

(p. 59)

Chapter 8: Bug-Free and Well Designed

Our product is made up of a growing set of correctly working features, built on a growing, evolving foundation of design.

(p. 61)

Defects amount to negative features. Progress is uncertain. Eliminate defects to provide clarity on what’s done.

We’re trying to plan by features, grow by features, and manage by features

We cannot work effectively in a world of defects.

(p. 62)

At the end of every iteration, we need to have the software as close to defect-free as possible. The only way to get there is to test it.

We test at two levels, with “Business” tests and “Programmer” tests.

(p. 65)

If we don’t check something, we don’t know whether it works

(p. 66)

We need to have a good design at all times. A bad design slows us down, because it is hard to change […] We need a high-quality design at every moment.

(p. 71)

Chapter 9: Full Circle

  1. Value is what we want. Features deliver value. Delivering features early gives us value sooner.
  2. Managing by looking at value works better than managing by dates or artifacts that don’t deliver value.

  3. Planning features is easy enough to do. Estimate if you must. Selecting the work based on Yesterday’s Weather works better.

  4. Building by features requires us to build a small, complete product, every couple of weeks. That product must always work correctly, and it must always be well designed.

  5. Development must deliver real working features. The product must be well tested. Business-side people and developers contribute to testing. The product must be well designed. Developers keep the design alive all the time.

[…] A commitment from the top of the business, down to the individual managers and developers […]

(p. 77)