Distinguishing Characteristics of a Pragmatic Programmer

• think beyond the immediate problem into the larger context
• take responsibility for what you do
• instigate change where needed, but don’t let gradual complacency to change claim you
• understand the context in which you work
• make your software good enough; refuse bike-shedding or perfectionism
• develop your knowledge
• communicate well

It’s Your Life

If you’re unhappy about something that you’ve tried to change, you can use the agency you have in your life to attempt to change it.

You can change your organization or you can change your organization.—Martin Fowler

If your skillset is outdated (or you’re looking to make a change), study interesting stuff in your own time. Your investing in yourself.

• [ ] How does this resonate with you—do you feel you have agency in your profession?

The Cat Ate My Source Code

A core tenet of the pragmatic philosophy is taking responsibility for yourself and your actions in terms of your career advancement, your learning and education, your project, and your day-to-day work. Admit ignorance and mistakes directly and with honesty. This helps to build trust, which is key to making an environment you want to work in.

Take Responsibility

Responsibility is something to which you actively agree—it’s your commitment that ensures your responsibility is done right. When something goes wrong (that happens!), don’t blame someone or something else; admit it and offer options, not lame excuses. To that end, you can rubber-duck the scenario to see how it will sound to your boss / client. Roleplaying the situation will help you find the low-hanging fruit of “Have you tried this…” and “Didn’t you consider that?”

• [ ] How does this sit with you—does it tend towards hard-nosed or professionalism?

Section Challenges

• [ ] How do you react when someone—such as a bank teller, an auto mechanic, or a clerk—comes to you with a lame excuse? What do you think of them and their company as a result?
• [ ] When you find yourself saying, “I don’t know,” be sure to follow it up with “—but I’ll find out!” It’s a great way to admit what you don’t know, but then take responsibility like a pro.

Software Entropy

Entropy in software is called “software rot”. Some people call it “technical debt”. The most important contributing factor is the psychology / culture of work on the project. Why do some projects successfully fight that tendency toward disorder? Hopelessness can be contagious. If you don’t think it can be fixed, you won’t try. The key to building a culture of hope is “Don’t live with broken windows.” Broken windows can be:

• bad designs
• wrong decisions
• poor-quality code

You can fight software entropy / rot / tech debt by choosing a problem to fix each time you work on the project. See Refactoring by Martin Fowler.

• [ ] Have you ever worked on project where entropy was winning? I.e, so much of the project was broken that you didn’t put forth your best effort in your work, because you knew that your best effort would be a waste given the current state of the software.

Section Challenges

• [ ] Help strengthen your team by surveying your project neighborhood. Choose two or three broken windows and discuss wit your colleagues what the problems are and what could be done to fix them.
• [ ] can you tell when a window first gets broken? What is your reaction? If it was the result of someone else’s decision or a management edict, what can you do about it?

Stone Soup and Boiled Frogs

Every now and then, you might need to emulate the soldiers from the Stone Soup folktale. You can summarize all of this as “Be a catalyst for change.” Here are the takeaways:

• You know what needs to be done, but if you ask for permission to do the whole thing, you’ll get denied / have to fight too hard for it (“start-up fatigue”).
• work out what you can reasonably ask for
• develop the MVP well
• show it to people
• say “of course, it would be better if we added…”, pretending it’s not that important
• People find it easier to join an ongoing success, so show them a glimpse of the future that you want them to rally around.

The other side of the folktale belongs to the villagers: they were a textbook example of gentle and gradual deception. Projects can slowly and inexorably get totally out of hand. Remember the big picture. Another witticism captures this well: boiling a frog. Don’t let the water temperature gradually increase until your project dies.

Section Challenges

• [ ] While reviewing a draft of the first edition, John Lakos raised the following issue: The soldiers progressively deceive the villagers, but the change they catalyze does them all good. However, by progressively deceiving the frog, you’re doing it harm. Can you determine whether you’re making stone soup or frog soup when you try to catalyze change? Is the decision subjective or objective?
• [ ] Quick, without looking, how many lights are in the ceiling above you? How many exits in the room? How many people? Is there anything out of context, anything that looks like it doesn’t belong? This is an exercise in situational awareness, a technique practiced by folks ranging from Boy and Girl Scouts to Navy SEALs. Get in the habit of really looking and noticing your surroundings. Then do the same for your project.

Good-Enough Software

Whatever this means, it doesn’t mean poor-quality software. It does mean that all software involves trade-offs. You should involve your users in that trade-off: how good do they want their software? The bottom line: make quality a requirements issue. Know when to stop, like an artist painting on a canvas. It will never be perfect, so you need to develop a sense of when software is good enough.

• [ ] How does this sit with you? Do you accept the idea that your software cannot be perfect, or do you think that’s a self-fulfilling mentality?
• [ ] Why would you want to involve your users in the trade-offs of “good-enough” software.

Section Challenges

• [ ] Look at the software tools and operating systems that you use regularly. Can you find any evidence that these organizations and/or developers are comfortable shipping software they know is not perfect? As a user, would you rather (1) wait for them to get all the bugs out, (2) have complex software and accept some bugs, or (3) opt for simpler software with fewer defects?
• [ ]Consider the effect of modularization on the delivery of software. Will it take more or less time to get a tightly coupled monolithic block of software to the required quality compared with a system designed as very loosely coupled modules or microservices? What are the advantages or disadvantages of each approach?
• [ ]Can you think of popular software that suffers from feature bloat? That is, software containing far more features than you would ever use, each feature introducing more opportunity for bugs and security vulnerabilities, and making the features you do use harder to find and manage. Are you in danger of falling into this trap yourself?

Your Knowledge Portfolio

Your knowledge and experience are important day-to-day assets. In tech these assets expire, because your knowledge becomes out of date as new techniques, languages, and environments are developed. Your ability to learn new things is your most important strategic asset.

The facts about computing, knowledge about application domains, and experience developing is called your knowledge portfolio. There are similarities to a financial portfolio:

1. serious investors invest regularly—as a habit
2. diversification is the key to long-term success
3. smart investors balance their portfolio between conservative and high-risk / high-reward investments
4. investors try to buy low and sell high for maximum return
5. portfolios should be reviewed and rebalanced periodically

• [ ] Do you find this an apt comparison?

Building Your Portfolio

The process of learning and staying current will expand your thinking, open new possibilities and ways of thinking. Philosophically, you’re aiming for:

• invest regularly: consistency is key
• diversify: technical and non-technical skills, not just your day-to-day tech—be T-shaped
• manage risk: go out on a limb—it may pay off, but have the stability that means that when a technology falls out of favor it doesn’t end you
• buy low, sell high: it’s about adding value to you
• review and rebalance: keep a sense of the field—what should you learn next?

Some goals you could set (not exhaustive; not prescriptive):

• learn at least one new language a year: it broadens your thinking
• read a technical book each month
• read non-technical books, too
• take classes
• participate in local user groups and meetups
• experiment with different environments
• stay current

Each time someone asks you a question that you don’t know the answer to you have a tremendous opportunity to learn. You should admit that you don’t know, but use that as a springboard to find the answer. Find someone who knows, because talking to other people expands your personal network. The Army tool of “hip-pocket training” is a good philosophy to make sure that you aren’t wasting time that could be used for investing in your knowledge portfolio.

It’s not enough to consume—you must think critically about what you’re consuming. You can practice this discipline by asking:

• the “five whys”
• who this benefits
• what the context is
• when or where this would work
• what makes this a problem
• [ ] Does this feel empowering or exhausting?

Section Challenges

• [ ] Start learning a new language this week. Always programmed in the same old language? Try Clojure, Elixir, Elm, F#, Go, Haskell, Python, R, ReasonML, Ruby, Rust, Scala, Swift, TypeScript, or anything else that appeals and/or looks as if you might like it.
• [ ] Start reading a new book (but finish this one first!). If you are doing very detailed implementation and coding, read a book on design and architecture. If you are doing high-level design, read a book on coding techniques.
• [ ] Get out and talk technology with people who aren’t involved in your current project, or who don’t work for the same company. Network in your company cafeteria, or maybe seek out fellow enthusiasts at a local meetup.

Communicate!

A good idea is orphaned without effective communication.

• know your audience: understand the needs, interests, and capabilities of your audience; from Neuro-Linguistic Programming (NLP), “The meaning of your communication is the response you get.”
• know what you want to say: plan what you want to say by writing an outline that communicates what you want to say
• choose your moment: make what you’re saying relevant in time as well as context (“Is this a good time to talk about…?”)
• choose a style: attempt to tailor your message to your audience (are they already SMEs?); when in doubt, ask
• make it look good: aesthetics are a signifier of trust
• involve your audience: the documents we produce are often less important than the process we go through while producing them—get feedback, bring people together, pick brains
• be a listener: ask good questions or ask people to restate the discussion in their own words; you might learn some amazing stuff this way
• get back to people: always respond, even if with something like “I’ll get back to you later.”
• [ ] Do you have any experience with NLP? What do you think of “The meaning of your communication is the response you get.”?
• [ ] What challenges do you face in communicating (written and orally) within your profession? What insights do you have to effective communication that would help the group?

Documentation

Build documentation in; don’t bolt it on. Keep code and documentation together (they have the same reason to change). Commenting source code well is a part of good documentation. Don’t comment so much that it loses value. For non-API comments (not public facing), discuss why something is doneits purpose and goal. The code itself should already show how it’s done.

I also find tests to be a good form of documentation.

• [ ] How and when do you comment your code? What are some good code comments, tests, or commit messages that have really helped you out when writing software?

Section Challenges

• [ ] There are several good books that contain sections on communications within teams, including The Mythical Man-Month: Essays on Software Engineering [Bro96] and Peopleware: Productive Projects and Teams [DL13]. Make it a point to try to read these over the next 18 months. In addition, Dinosaur Brains: Dealing with All Those Impossible People at Work [BR89] discusses the emotional baggage we all bring to the work environment.
• [ ] The next time you have to give a presentation, or write a memo advocating some position, try working through the advice in this section before you start. Explicitly identify the audience and what you need to communicate. If appropriate, talk to your audience afterward and see how accurate your assessment of their needs was.