Post Overview: This post summarizes the author's suggestions and how i plan to apply them.
Table of Contents
- Chapter 1: A Pragmatic Philosophy
- Chapter 2: A Pragmatic Approach
- Chapter 3: The Basic Tools
- Chapter 4: Pragmatic Paranoia
- Chapter 5: Bend, or Break
- Chapter 6: Concurrency
- Chapter 7: While You Are Coding
- Chapter 8: Before the Project
- Chapter 9: Pragmatic Projects
Chapter 1: A Pragmatic Philosophy
Topic 1. It's Your Life
Author's Suggestion
You have the ability to make choices and take actions that affect your software development career. Be proactive to get where you want to be; change yourself, change your environment, and if you can't change your environment move somewhere else.
My Application
I take a proactive approach to my software development career. I continuously update my skills and seek the optimal environment where I can thrive and make the greatest contribuition.
Topic 2. The Cat Ate My Source Code
Take responsibility for yourself and your actions as programmer, especially regarding your learning and career growth. Things may go wrong in software development, even on the best projects with strong testing, documentation and automation. Don't be afraid to admit your shortcomings -- whether mistakes or gaps in knowledge. Own them professionally, and be direct and honest.
Team Trust
Author's Suggestion
To achieve success in any team, your teammates must be able to trust and rely on you -- and you on them.
My Application
I take responsibility, and my team can trust and rely on me, just as I do on them.
Take responsibility
Author's suggestion
Provide solutions, not excuses. If you need something to achieve your goal -- such as training, resources, more input from the user -- don't be afraid to ask for it.
My Application
Whenever something goes wrong and I've already taken the responsibility after considering all implications, it's my duty to provide alternatives -- no excuses -- and to have contigency plans in place for the unexpected. I'm also about my needs in order to deliver results.
Reflections
- When someone comes up with a lame excuse, I feel disappointed; I may think they are incompetent, and it leaves a bad impression of their company, so I must not be that person.
- When I don't know something, I acknowledge it honestly, take responsibility, and say, "I'll find out". This shows a professional attidude.
Topic 3. Software Entropy
Entropy is a concept in thermodynamics, that measures the degree of disorder in a system. Entropy tends to increase over time. Software behaves similarly. One major factor is the psychology of the project (neglect), illustrated by the "broken window" analogy: in software, a broken window can be a bad management decision, poor design, or poor code. If one exists, it naturally leads to many more.
Author's Suggestion
Don't allow broken windows; a broken window in software can be a bad design, poor code or bad decisions. When you discover one broken window, fix it as soon as possible, or at the very least implement a temporary workaround to prevent further damage.
My Application
Whenever I encounter a broken window, I either fix it as soon as it is discovered or implement a temporary workaround--refactor code, comment out problematic code, etc. to prevent further damage in the project.
First, Do no Harm
Author's Suggestion
If there's a fire raging (deadline, release date, etc.), don't be the first to make a mess and inflict additional damage.
My Application
Whenever I have some compromise such as deadline, or release date, I ensure i follow the quality needed.
Reflections
- Two very common examples of broken windows in code are unclear variable naming and repeated code. We can address unclear naming by giving variables meaningful names. Repeated code can be fixed by applying the DRY principle whenever needed to prevent the code base from growing too large.
- When a broken window first appears, it usually happens because of bad practices. My natural reaction is surprise, followed by taking action--either by fixing it myself, or if it was the result of someone else's decision I'd let them know, if we can address it, we do.
Topic 4. Stone Soup and Boiled Frogs
Author's Suggestion
Stone Soup tells the story of soldiers who start a soup with just stones and show it to villagers. When asked if it's ready, the soldiers--acting as catalysts for change--suggest adding ingredients. Through collaboration, everyone contributes, synergy emerges, and the soup becomes delicious, with the stones removed. Start with something minimal yet useful, ask for what's reasonable, develop it, show it, and suggest improvements--soon you'll have collaborators.
My Application
As a proposer, I would start by showing something useful, ask for reasonable contributions, demonstrate results, and suggest improvements--this approach helps build solid, collaborative teams.
The villager's side
Author's Suggestion
In the story, the villagers, initially too focused on the stones, missed the bigger picture until guided. The lesson: never lose sight of the bigger goal while driving change. The boiled frog metaphor reinforces this idea: small, gradual changes can go unnoticed until it's too late, while obvious problems trigger action. By paying attention to even minor shifts, we stay aligned with the bigger picture and ensure meaningful results. Every small change matters on the path to impactful outcomes.
My Application
On the other side, as a team member, I would keep the bigger picture in mind, be proactive in my suggestions, and stay conscious of how even small changes may impact the overall outcome.
Reflections
- When acting as the catalyst--"the deceiver" who drives change--you can either create benefit or cause harm; this judgment is entirely subjective.
- Develop the habit of observing and paying attention to the context of your project.
Topic 5. Good-Enough Software
Author's Suggestion
Nothing is perfect, and software is no exception -- it is never completely bug-free. Many factors contribute to this, such as project constraints and human behavior.
Nonetheless, good enough is the sweet spot for delivery. It benefits users, developers, and future maintainers, enabling productivity while keeping users happy. Good enough software is not sloppy. For good enough software we understand software that must meet their user requirements, as well as basic performance, privacy and security standards.
Thus we just need to ask ourselves if we have satisfied the user needs as defined in requirements.
My Application
I accept that life is messy, yet I aim for good enough software, good enough in meeting user needs, thus being more productive and having happy users.
Involve users in your Trade-Off
Author's Suggestion
We create software for people. Typically, we ask users what they want. But also we need to know how good they want it, it is very different to build critical medical software versus a brand-new consumer product, each has its own requirements and quality. In a brand new product, there are user expectations, marketing sold product, money gets involved, we have be professional. Avoid adding unnecessary features, overengineering, or compromising basic engineering quality just to meet deadlines.
The scope and quality of a system should be discussed as part of the systems requirements.
Trade-offs are inevitable. Many users prefer a good enough solution today rather than waiting a long time for a perfect one, because user needs may have changed by the time you deliver, and if you deliver fast good enough software, you have the advantage of getting feedback as user use the software.
My Application
I have communication with the user to know their needs in terms of quality, not just what they want, so I can define them clearly in the system requirements.
Know When to Stop
Author's Suggestion
Like an artist, a programmer must know when to stop. Avoid overengineering or overembellishing software. Let it be -- in its own imperfection, software will never be perfect.
My Application
I accept the imperfection yet beauty of life, wabi-sabi philosophy at my core, embracing imperfection, impermanence, and the incomplete, while finding beauty and value in it.
Reflections
- Many software that is being used everyday, is imperfect, organizations and teams are ok with it, is also my preference having non-perfect complex software with some bugs, rather than a basic free bug software or just waiting for them to fix all bugs.
- Modularization greatly impacts software quality and delivery. A monolithic software will take a lot of time, as it's tightly coupled, it becomes a headache to work it in a team, making team collaboration difficult. On the other hand, with microservices you have loosely coupled software, allowing for efficient quality achievement since teams can work independently. The disadvantage is that we need solid team communication and we must also account for the consideration of issues like latency and consistency. Monolith systems may allow faster delivery but time taken to grant quality may take longer.
- Feature bloat occurs when software accumulates too many features, and we often just need a specific one, one software in such category is Microsoft Word, it has many options which can introduce bugs and security vulnerabilities. It is crucial to carefully decide which features to include and consider their implications.
Topic 6. Your Knowledge Portfolio
Author's Suggestion
Your knowledge and experience are your most important professional assets--but they're also perishable. New techniques, languages and tools are constantly emerging, and market forces may quickly make your experience less valuable. In today's fast-paced technological world, this obsolescence can happen rapidly.
As your knowledge becomes outdated, so does your value to your company.
Key Insight: Your ability to learn new things is your most important strategic asset.
My Application
I stay aware of industry changes to identify opportunitys early. I'm proactive about what I learn, when, and how, ensuring my knowledge remains relevant.
Your Knowledge Portfolio
Author's Suggestion
A Knowledge Portfolio includes everything you know about computing, the domains you work in, and your professional experience. Managing a knowledge portfolio is similar to managing a financial portfolio:
- Serious investors invest regularly--it becomes a habit.
- Diversification is key to long-term success.
- Smart investors balance their portfolios between conservative and high risk, high rewards investments.
- Investors aim to buy low and sell high for maximum returns.
- Portfolios should be reviewed and updated periodically.
Key Insight: To succeed in your career, you must invest in your knowledge portfolio using the same principles as a financial portfolio.
All of this can be learned by developing a consistent routine--one that becomes ingrained in your mind--to continuosly expand your knowledge.
My Application
I recognize that managing my knowledge portfolio is like managing a financial portfolio. I invest deliberately, diversify wisely, and regularly review my portfolio to maximize its long-term value.
Building Your Portfolio
Author's Suggestion
Here's what to invest in and when:
Invest regularly
Just like in financial investmenets, small but consistent investments in your knowledge add up, and the habit of consistent learning is as important as the knowledge itself. Set aside dedicated time and create a focused environment.
Diversify Technology evolves rapidly. What is valuable today may be obsolete tomorrow. Learn multiple technologies and domains to stay adaptable . Non-tech skills--communication, leadership--are as important as the technical skills.
Manage risk Technology exists on a spectrum from high risk, potentially high reward, to low risk, low reward. Just as in financial investments, it's unwise to invest entirely in risky technologies--or only in conservative ones --and miss out on opportunities. Don't put all your technical eggs in one basket.
Buy low sell high
Learning a new technology before it becomes trendy can be as challenging as finding an undervalued stock, but the payoff can be substantial. Learning a programming language early can position you ahead of the curve.
Review and rebalance
The tech industry is very dynamic. Technologies that are hot today may be cold tomorrow. It may be time to brush up skills you haven't used in a while or learn that programming language that improves your position for new opportunities.
The simplest action is the most important: Invest regularly
My Application
- I make it a habit to invest in my knowledge portfolio, dedicating time to it every day.
- I diversify across multiple domains and technologies to approach problems from different perspectives.
- I explore high-risk, high-reward emerging technologies and their applications.
- I read about new technologies and their potential across domains.
- I constantly review and rebalance knowledge that needs reinforcement, while continuing to explore new areas.
Goals
Author's Suggestion
This section answers the "how". Here are some suggestions on the best ways to acquire the intellectual capital needed to grow your knowledge portfolio:
Learn at least one new language every year
Languages help you solve the same problem from different perspectives. Learning a new language each year broadens your thinking and prevents you from getting stuck in routines.
Read a technical book each month
Short-term answers are available on the internet, but for deep understanding, you need long-form books. Make it a habit to read an interesting technical book related to your project each month. Once you have mastered that, switch to unrelated technical books that interest you.
Read nontechnical books, too
Computers are used by people, so we need to understand and satisfy their needs. Working with people is the human side of the equation, which requires a different set of skills--the so-called "soft skills".
Take classes
Look for interesting courses at a local or online college, or attend nearby trade shows and conferences.
Participate in local user groups and meetups
Isolation can be detrimental to your career. Discover what people are working on outside your company, and don't just attend passively; actively participate.
Experiment with different environments
If you primarily use Windows, try out Linux. If you've only used a terminal and text editor, try a sophisticated IDE, and vice versa.
Stay current
Stay current by reading news and posts about technologies different from those used in your current project.
My Application
- I plan to start learning Scala in October 2025 and continue into 2026.
- I am currently reading *Designing Data-Intensive Applications" by Martin Kleppmann to gain a strong understanding of handling massive data in real-world applications.
- For non-technical reading, I am interested in How to Make Your Brain Your Best Friend: A neuroscientist's Guide to a Healthier, Happier Life by Rachel Barr. I believe this book will help me take better care of my well-being and, as a result, improve my relationships.
- I am finishing CS50's Web Programming with Python and JavaScript, and I plan to take additional courses in cloud computing, backend development, data engineering, and DevOps.
- I am willing to attend technology meetups to collaborate with others, build new connections, grow my knowledge portfolio, and support people starting their careers.
- I plan to read the following sources regularly:
- Techmeme -- daily updates on "what's happening."
- Stratechery -- top analysis of business and tech ecosystem shifts.
- Hacker News -- early developer signals; if something repeatedly appears, it may be trending.
- ArXiv Sanity / MIT Tech Review -- curated AI, ML, systems and distributed computing papers by Karpathy.
- GitHub Trending -- tracks which tools, libraries, and frameworks are being adopted by developers.
- Product Hunt -- showcase new apps, tools, and startups; highlights early-stage innovation.
- a16z Future -- insights into emerging tech trends, markets, and strategic shifts from Andreessen Horowitz.
It's important to keep investing in your learning. Once you become comfortable with a technology, move on to the next one to continue growing. It doesn't matter whether the technologies you've learned are used in a project or listed on your résumé--the process of learning itself expands your thinking and opens your mind to new approaches.
The cross-pollination of ideas is powerful: apply what you've learned to your current projects, even if they don't directly use that technology. For example, understanding functional programming can change how you write object-oriented code, allowing you to combine the best of both worlds.
Opportunities for Learning
Author's Suggestion
If someone asks you something and you don't know the answer, it's okay to admit it--but treat it as a challenge and take the time to research it. If you still can’t find the answer, reach out to someone who can. Doing so expands your network and often leads to unexpected insights and solutions to other problems. This is how your knowledge portfolio continues to grow.
Whenever you have the chance or some "dead time", use it for reading or learning--anything that helps you grow.
My Application
I’m not afraid to admit when I don’t know something; doing so helps me avoid stagnation in my knowledge portfolio and continue growing as a professional. I'm open to asking for help and building new connections--developing relationships with people I can rely on, and who can rely on me in return.
I enjoy reading and making the most of my "dead time", using it productively rather than mindlessly.
Critical Thinking
Author's Suggestion
Critically evaluate what you need to read and hear. Make sure the knowledge you add to your portfolio is accurate and not simply marketing. Be skeptical of people who insist their approach is the only solution--what works for them may not apply to your project. Never underestimate the power of commercial interests: people pay to get visibility and better positioning.
Critical thinking is broad; here are some practical starting points:
*Ask the "five whys" Keep asking "why?" to dig deeper into a problem until you reach the root cause.
Who does this benefit Follow the money--check whether the incentives and benefits align with your goals.
What's the context Everything happens in context. "One-size-fits-all" solutions rarely hold. Ask: best for whom? What are the prerequisites? What are the short- and long-term consequences?
When or where this would work Under what circumstances does this approach apply? Is it the right time? Use second-order thinking: instead of asking "What happens next? ask "What happens after that?"
Why is this a problem? Is there an underlying model? How does it work?
My Application
I actively study and practice critical thinking to dig deeper into ideas and filter the knowledge I add to my portfolio. This helps ensure that what I'm learning is accurate, relevant, and free from hype or bias.
Reflections
- I'm starting to learn Scala this week to broaden my skills as a programmer.
- I plan to read a new book on a topic relevant to my current projects, after finishing this book.
- I'm stepping out of my comfort zone to discuss techonology with people outside my current projects.
Topic 7. Communicate!
Author's Suggestion
It's not what you've got; it's how you package it. Having the best ideas is useless unless you can communicate with other people. A good idea is an orphan without effective communication.
As developers, we communicate on many levels:
- We spend hours in meetings, listening and talking.
- We work with end users, trying to understand their needs.
- We write code that communicates our intentions to the machine and documents them for future generations of developers.
- We advocate our ideas within a team, suggesting new practices or modifying existing ones.
- We write proposals and memos within a team, justifying requests for resources, reporting status, or making recommendations.
Treat English as just another programming language. Write natural language as if it were code: honor DRY, favor flexibility to make it easier to change (ETC), and use automation.
My Application
I recognize the importance of effective communication as a developer, and I put effort into making my communication intentional and as effective as possible, following the author's recommendations.
Know Your Audience
Author's Suggestion
You're communicating only if you're conveying what you mean to convey--pure talking isn't enough. You need to understand the needs, interests, and capabilities of your audience.
You can pitch a solution to a problem in many different ways depending on your audience and keep them interested. For example, a third-party SMS provider in a system any:
- Excite end users with the potential to increase their revenue.
- Give marketing a fact they can use to boost sales.
- Allow managers and development managers to maintain the system without extra effort.
- Provide developers an opportunity to learn new APIs.
As with any communication, asking for feedback is important. Observe body language. One of the principles of Neuro-Linguistic Programming states, "The meaning of your communication is the response you get." This means communication is effective if and only if the expected outcome is reflected in your audience. Keep improving your knowledge of your audience as you communicate.
My Application
I communicate my ideas according to my audience, taking their interests into account. I ask for feedback to ensure my communication is effective, confirm that my point was understood, and continue improving.
Know What You Want to Say
Author's Suggestion
Probably the most difficult part of formal communication in business is figuring out what you want to say clearly. Plan what you want to say and write an outline. Then ask yourself, "Does this communicate what I Want to express to my audience in a way that works for them? Refine it until it does. Notice that this works not only in formal contexts but also in chats and meetings.
My Application
I write an outline of what I'm trying to convey, whether orally or in writing, making sure I am clear about what I want to communicate.
Choose Your Moment
Author's Suggestion
Make what you're saying relevant in both timing and content; the audience may be more receptive at certain moments.
My Application
I always look for the optimal time to convey an idea in order to achieve the best possible response.
Choose a Style
Author's Suggestion
Adjust the style of your delivery to suit your audience. Some people want a TL;DR version, while others want the full context. Consider your audience's experience and skills: Are they experts? Are they novices? Then adjust your delivery accordingly. If in doubt, ask.
You're half of the communication transaction, so whenever someone in the audience asks for a briefer explanation and you cannot provide one, giving that feedback is also a form of communication.
My Application
I adjust my communication style according to my audience's needs and capabilities.
Make it Look Good
Author's Suggestion
Your ideas are important; they deserve a well-designed vehicle to convey them to your audience. Many times, developers overlook the aesthetics of the written documents they produce and focus solely on the content--a big mistake. Your presentation is your "business card," and it must be treated as such.
My Application
I recognize that presentation matters when communicating in writing.
Involve Your Audience
Author's Suggestion
We often find the documents we produce less important than the process we go through to create them. If possible, involve your audience with early drafts of your document, ask for feedback, and pick their brains. This way, you build a good working relationship and will likely end up with a better document.
My Application
I involve my audience with drafts of my document to ensure they align with what the audience actually wants.
Be a Listener
Author's Suggestion
There is one technique that you must use if you want people to listen to you: listen to them. Encourage people to participate, ask them question, and have them restate the discussion. Convert the conversation into a dialogue; this way, you can express your point more effectively and even have the opportunity to learn something.
My Application
When communicating orally, I make sure to listen actively and ask questions to turn the conversation into a dialogue and achieve effective communication.
Get Back to People
Author's Suggestion
If you ask someone a question and they fail to reply, we may get offended. However, we often make mistakes ourselves, such as failing to reply to an email--life happens.
Therefore, get back to people; even a short message saying, "I'm on it; I'll get back to you ASAP," can make the other person feel considered and more forgiving if you occasionally slip.
What you say and how you say it are equally important. The more effectively you communicate, the more influential you become.
My Application
I make sure to respond to people who email me, recognizing that it is important not to ghost them.
Documentation
Author's Suggestion
Pragmatic Programmers embrace documentation as an integral part of the overall development process. Writing documentation can be easier by avoiding laziness, and keeping documentation close at hand--within the code itself. Apply all pragmatic principles to documentation just we do to code.
It is easy to produce documentation from comments in source code. Add comments to modules and exported functions to give other developers a leg up when they come to use them.
A bad practice is commenting every function, data structure, or type declaration, as it violates the DRY principle. Restrict non-API comments to explaining why something is done, its purpose, and its goal.
Commenting source code is also a great way to document parts of the project that cannot be documented elsewhere, such as engineering trade-offs.
My Application
I document my source code appropriately, knowing when and where it is necessary.
Reflections
- I plan to read the author's suggested sources for communication within teams over the next 18 months.
- Whenever I have to give a presentation or write a memo, I will follow the instructions of this topic: identify the audience, clarify what I need to communicate, and, if possible, ask for feedback to ensure my assessment of their needs was accurate.
- I will be mindful of maintaining decency in online communication.
Chapter 2: A Pragmatic Approach
Topic 8. The Essence of Good Design
Author's Suggestion
Something is well-designed if it adapts to the user. For code, this means that it's adaptable to change. This is where the ETC principle -- Easier To Change -- comes into play.
Every Design Principle can be seen as a specific application of the ETC Principle.
My Application
I aim to apply the ETC Principle whenever I write code, always making it adaptable to change.
ETC Is a Value, Not a Rule
Author's Suggestion
A value is something that helps you make decisions. When writing code, the ETC Principle serves as a guide, helping you choose between different paths. Like any other value, it should live in your subconscious -- but to get there, you may need some conscious reinforcement.
Take time to reflect on whether the changes you've made actually make the code easier to change -- even something as small as saving a file can be a good moment for that reflection.
ETC has an implicit premise: it assumes the person knows which path will allow smoother future changes. Common sense is often enough, but not always. When it isn't, consider these two approaches:
- Modify the code so it can be easily replaced in the future.
- Write down the situation -- the options for change you see, and your assumptions about how adaptable the code would be for each. Keep a reference in the source code so you can revisit and verify your reasoning later.
My Application
In my day-to-day work as a coder, I aim to always ask myself: Does this change make the code more adaptable to future changes?
I rely on common sense by default, and when the answer isn't clear, I either modify the code so it can be easily replaced or make my best guess, later tracking whether I was accurate.
Reflections
- Yes, Open for Extension, Closed for Modification Principle allows for easier changes because it enables adding new features without breaking existing code.
- Let's analyze how well the following paradigms work with ETC:
- OOP
- Positives for ETC: Encapsulation and polymorphism isolate changes.
- Negatives for ETC: Deep inheritance and over-abstraction create rigidity.
- Summary: Flexible if composition is favored over inheritance.
- Functional
- Positives for ETC: Pure, composable, immutable code is safe to refactor.
- Negatives for ETC: Harder to manage side effects and shared state.
- Summary: Excellent for logic; awkward for stateful systems.
- Event-Driven
- Positives for ETC: Decoupled via events; easy to add handlers.
- Negatives for ETC: Complex callback chains; hard to trace flows.
- Summary: Good for dynamic systems if structured.
- Reactive
- Positives for ETC: Data flows automatically propagate changes.
- Negatives for ETC: Debugging asynchronous data streams can be tricky.
- Summary: Excellent for live data and continuous updates.
- Procedural
- Positives for ETC: Simple and direct for small programs.
- Negatives for ETC: Global mutable state is fragile for large systems.
- Summary: Low ETC in large systems.
- Component/Modular
-
Positives for ETC: Clear boundaries enable replacement and reuse.
-
Negatives for ETC: Integration and versioning overhead.
-
Summary: High ETC if interfaces remain stable.
-
When coding, I can eliminate the negatives by avoiding actions that make code harder to change. To accentuate the positives, I aim for situations that support the ETC principle.
-
Remember: use your editor to provide reminders whenever you save your code to check if it remains easy to change.