Book review - The Developer's Code: What Real Programmers Do

The Developer’s Code, by Ka Wai Cheung, is one of those books that you must read for fun, expecting to learn a thing or two on the way. This book is a big collection of essays about software development, some of which are common sense (even boring) and others that will leave you really inspired. It’s totally worth reading because of those inspiring essays and the precious career advice you may find on them (depending on your professional experience).

Book on Amazon: http://www.amazon.com/The-Developers-Code-Wai-Cheung/dp/1934356794

My personal notes

Metaphor

• Follow metaphors with care: they can make us value things that aren’t important while undervaluing things that are.
  • The traditional architecture as a process to build software (“cascade”) can imprison us.
• Plan enough, then build: in software, you can take benefit of planning little and building several times.
• Launch is just the first release: software lives and matures over time.
• The “Ivory Tower” Architect is a myth: code is the glue that binds each role. Regardless of where you are in the development hierarchy, keep coding.
• Throw away your old code: it helps keep the codebase lean, and it’s still on version control.
• Diversification over specialization: there’s no need to focus on something.
• Metaphors hide better ways of thinking: wireframes and specifications take time away from building and reviewing the real thing.

Motivation

• If you’re not motivated to write code, get out. You can kill a software project.
• The perks are in the work: to passionate programmers, long-lasting motivation comes from the work they do!
• Being where you love to begin: the hardest place to find motivation is at the very start.
  • Don’t focus on the big opening, start writing something in the middle of the story, at the point that’s most interesting.
  • We can always refactor later.
• Be imperfect: our products line through our users, and they morpth as the user base grows. Trying to be perfect can be exhausting.
• Stop programming: get outside a little. Stop before your code starts to get a bit sloppy.
• Test your work first thing in the morning: that’s when you’re freshtest and the most motivated to build something good.
• Work outside the bedroom: there’s no separation between work life and real life, and efficiency drops. Find a confined area to work, where you can physically leave.
• First impressions are just that: don’t care much about them, they are usually not “real”.
• The emotional value of launch: it’s just another release in the lifespan of software, but it gives a powerful dose of motivation.
• Find an argument: find a topic that you passionately agree with, or one you unabashedly disagree with, and speak about it.

Productivy

• Productivy is the tangible measure of success.
  • Corporate productivity: how much we do.
  • Real productivity: the quality of what we do.
• Just say “no” to the pet project. Time is the most important parameters in maintaining a passion for writing software. Create a real schedule and follow it. Set a deadline, even if it’s arbitrary.
• Constrain all your parameters: cap costs - it will help you use resources more efficiently. Set up and obey the walls around you.
• Cut the detail out of the timeline: plan with less detail, don’t be a slave of your timeline.
• Improve your product in two ways daily: it’s a good exercise to keep those large projects moving forward.
• Invest in good enviroment: invest in good hardware, have multiple monitors, etc.
• Keep a personal to-do list: it’s no more than a simple checklist.
  • A personal list for programmers must have the following qualities:
    • Only one list.
    • It has four buckers: Today, Tomorrow, Two days from now and Future.
    • It’s not nested.
    • It’s easily modified.
    • It’s online and easily accessible.
    • It’s composed of short tasks.
• Create “off time” with your team: basic events in a workday are distractions (phone calls, meetings, etc). Off-time = no emails, no calls, no meetings, only code.
• Work in small, autonomous teams: familiarity helps us interact without fear of hunting each other’s feelings. Decisions and processes become faster.
• Elimitante the “we” in productivity: when you communicate with your co-workers or clients, don’t say “we”, say exactly “who”. Responsabilities should be given to clearly define people/groups.
  • When you direct questions at somente, people get moving.
  • Delegate responsability to a single person.

Complexity

• Complexity always grows over time due to the maturing of software.
• Sniff out bad complexity: it’s something that should not be there. Consider what you could possibly remove from your software and still have it function the same.
• The simplicity paradox: simplicity doesn’t cheapens your worth. Complex software usually have lots of unusual features.
• Complexity as a game of pickup sticks: each new feature increases complexity. Try your best to circumvent this by following good habits: code encapsulation, limited variable scope, patterns and modular code.
• Keep complexity under the surface: you don’t need to expose inner workings to the user, just keep you software simple and usable.
• “Hard to code” might mean “hard to use”: sometimes complexity hurts both the coder and the user. The best solution can be the simplest and easiest to understand.
• Know when to refactor: don’t try to predict the future - abstracting stuff, abusing patterns and trying to solve future problems won’t help you now.
  • Anticipatig logic in the future will lead to unintened complexity.
  • Patterns should be implemented as needed.
• Develop a programming cadence: the more we code, the less efficient we become. When that happens, it’s time to refactor, abstract or implement a pattern.

Teaching

• Teaching is hard. You have to think like your audience.
• Teaching is unlike coding: we rarely code linearly; coding let us worry about the details of our stream of thought later. Teaching a newbie is different: every missed detail is a lost detail.
• Beware the “Course of Knowledge”:
  • Once you’ve become an expert in a particular domain, it’s nearly impossible to understand what it feels like to not understand that domain. E.g.: explain color to a person born blind.
  • When you’re teaching a newbie, teach twice as slowly as you would want to. Explain obvious things. Ask your student if things are making sense.
• Teach with obvious examples: for newbies, good examples are devoid of abstractinos - they provide good context.
• Lie to simplify: let go the intricate details of the domain at first. Reveal only stuff that will get your student most of the way to understanding a concept well. A solid foundation of understanding is motivating, and motivation will get people to move faster.
• Encourage autonomous thought: when we begin to master a subject like programming, we stop analyzing the rules to guide our work. We use intuition and start to think more abstractly. This kind of thought must be encouraged.

Clients

• Working with clients will start with understanding the view form their end so that we can teach them how things works from ours.
• The tough client is ubiquitous: we are all clients at some point, and we just want things done. That’s why clients make requests on code that they don’t know.
• Demystify the black magic of software: teach clientes how we do what we do.
• Define the goals of your application
  • Good clients put the application above themselves. Each feature decision can be scrutinized by simply asking a question: “Does this make the application better?”.
  • Establish the app goals at the beginning of the relation.
• Be enthusiastic and opinionated: engage your client with intricate details of your labor.
• Be forgiving and personable: understand the view from above the hood while you’re entrenched working under it. Explain stuff to clients and offer alternative solutions. Make it a habit to talk to them in person.
• Value is much more than time:
  • By simply basing cost on time, we equate a value of a piece of software with the time we spend building it.
  • From a client’s vantage point, value can be measured as flexibility, education, personality, expertise, speed and timeliness.
  • Charge for a product rather than a service.
• Respect your project manager: project management is primarily people management.
• Good client management is often achieved through our own self-worth.

Code

• Unlikely any other kind of builder, we have an infinite suply of our own material (code).
• Write code as a last resort: most time answers aren’t found in the brute force solution of writing more code. Always ask the following questions:
  • Has someone already done this task before? Can I use of the shelf code to take care of the dirty for me?
  • Is this piece of functionality really important to the goals of the app? Is the task already there bust just through a different user experience?
  • Is there a simpler way to code it?
  • Can I automate this task?
• A plug-in happy culture
  • While writing great code is difficult, once it’s written it can be redistributed easily.
  • We can almost find a tool to our every need.
• Code is the ultimate junior developer: it doesn’t get lazy, it doesn’t get bored, it doesn’t forget it, it’s cheap, it’s fast.
• Separate robot work from human work:
  • The quicker we can focus on the more interesting problem if we push tedious, algorithmic work off our plates.
  • Instead of repeating even a small scripting task, we can write a program to do that for us.
• Generating code at its core:
  • How do we write a generator?
    • Define your input source (JSON, XML, terminal).
    • Choose the right programming language.
    • Extract your input source into something usable.
    • Combine your input source provider with templates.
  • Keep all generators as separate libraries.
  • Know what not to generate: consider things that are automatable and tedious, not just tedious.
• The case for rolling your own: why would you ever roll your own framework, plataform or plugin if there’s something out there potentially as good?
  • You have an intimate understanding of the problem space, and can code based on your needs.
  • You can always do it better to fit you.
  • Programmer hubris: mine is better.

Pride

• Coding can be a soothing escape from reality. You build something out of nothing, like a craftsmen.
• Programmers have bad marketing, and this ought to change.