# Chemaclass - Full Content (llms-full.txt) > Complete corpus of articles, reading notes, and talks on chemaclass.com > Summary index: https://chemaclass.com/llms.txt > Site map: https://chemaclass.com/sitemap.xml > Author: Jose Maria Valera Reales (Chemaclass) > License: Content for AI retrieval, citation, and training is permitted. ## Blog index (75 entries) - [Working With the Garage Door Open](https://chemaclass.com/blog/working-with-the-garage-door-open/) (2026-07-14) Working in the open lets people help while the work is still shapeable. But an open door is passive. The real skill is pushing the right signal to the right room. Tags: communication, leadership, career, mentoring - [Laissez Faire, Laissez Passer](https://chemaclass.com/blog/laissez-faire-laissez-passer/) (2026-07-05) One old French phrase holds the whole case for free markets. Let people act, let goods pass. No planner knows what the market knows, and freedom, not control, should be the default. Tags: economics, philosophy, freedom, bitcoin - [Cut the Token Bill on Both Ends](https://chemaclass.com/blog/cut-the-token-bill-on-both-ends/) (2026-06-26) Two small tools that compound: Caveman shrinks what the agent says back, RTK shrinks what your terminal pipes in. More room in the same context window, same model, same prompts. Tags: ai, productivity, developer-tools, agentic-coding - [The Eternal Return](https://chemaclass.com/blog/the-eternal-return/) (2026-06-01) Nietzsche used eternal return as a test. Life uses it as a mirror. Patterns rhyme not to predict the future, but to reveal who you become under pressure. Tags: philosophy, psychology, career - [Skills Over Agents](https://chemaclass.com/blog/skills-over-agents/) (2026-05-19) Why Claude Code skills beat specialized agents. On-demand context, not the model, decides quality. Build a skill library that travels with your code. Tags: ai, software, craftsmanship, productivity, developer-tools - [The Levels of AI Adoption](https://chemaclass.com/blog/the-levels-of-ai-adoption/) (2026-05-01) A six-level ladder of AI adoption, from copy-paste prompts to agentic teams and AI-native workflows. Where most companies stall, and how to climb. Tags: ai, software, leadership, craftsmanship, productivity, developer-tools - [Inside the .claude Folder](https://chemaclass.com/blog/inside-the-claude-folder/) (2026-04-17) A hands-on tour of Claude Code's project folder. What rules, skills, agents, hooks, and settings each do, and how they fit together. Tags: ai, software, tutorial, craftsmanship, developer-tools, productivity - [Building a Game in Two Days](https://chemaclass.com/blog/building-a-game-in-two-days/) (2026-04-05) A casual Telegram message turned into a nine-level Lord of the Rings browser game. Every line of code written by an AI agent. Every creative decision made by a human who grew up on Middle-earth. Tags: ai, software, open-source - [Idealism vs Pragmatism](https://chemaclass.com/blog/idealism-vs-pragmatism/) (2026-03-01) The tension between doing things right and getting things done shapes every decision in software and in life. TDD, pair programming, AI adoption: the best results come from holding both ends of the rope. Tags: ai, software, craftsmanship, leadership - [Build Your Own Team of Agents](https://chemaclass.com/blog/build-your-own-team-of-agents/) (2026-02-07) Stop using AI as a single assistant. Organize agents into specialized teams with roles, docs, and parallel execution for real leverage. Tags: ai, software, craftsmanship, leadership - [MCP: Giving Your AI Agent the Right Context](https://chemaclass.com/blog/mcp-giving-your-ai-agent-the-right-context/) (2026-01-11) MCP connects AI agents to your dev tools, databases, and APIs through a standard protocol. Give your agent the context it actually needs. Tags: ai, software-architecture, developer-tools, craftsmanship - [How Bitcoin Works](https://chemaclass.com/blog/how-bitcoin-works/) (2025-12-22) Transactions, blocks, mining, the UTXO model, and Lightning Network: how Bitcoin actually works under the hood, explained in plain terms. Tags: bitcoin, cryptography, tutorial - [Bitcoin Fundamentals](https://chemaclass.com/blog/bitcoin-fundamentals/) (2025-11-21) 21 million cap, no central authority, permissionless and censorship-resistant. Bitcoin is digital money you truly own. No bank required. Tags: bitcoin, economics, privacy, philosophy - [AI Gives You Speed, Not Quality](https://chemaclass.com/blog/ai-gives-you-speed-not-quality/) (2025-10-10) AI accelerates your output but doesn't ensure quality. You're responsible for every line you commit. Speed without direction is chaos. Tags: ai, software-architecture, craftsmanship, leadership - [What Success Means to Me](https://chemaclass.com/blog/what-success-means-to-me/) (2025-09-15) Success is waking up knowing that what you do makes the people around you, and yourself, happier. No complex formula. Just consistency over perfection, and building habits that align with what matters. Tags: philosophy, career, productivity, leadership - [Ship, Show, Ask](https://chemaclass.com/blog/ship-show-ask/) (2025-04-12) Not every change needs the same review. Ship, Show, Ask matches the review process to the risk of the change, so teams keep shipping without losing quality or collaboration. Tags: agile, code-review, team-management, productivity - [Run Your LN Node on a Raspberry Pi](https://chemaclass.com/blog/run-your-ln-node/) (2025-02-17) In this guide, I'll show you how to set up a fully custodial Lightning Network (LN) node using Alby Hub on a Raspberry Pi, giving you complete control over your node. Alby Hub offers a DIY free version for a self-custodial Lightning wallet, ensuring full ownership of your funds while being 100% open-source. Tags: bitcoin, open-source, privacy, tutorial - [Understanding Taxes](https://chemaclass.com/blog/understanding-taxes/) (2025-01-02) Taxes are unavoidable. Whether it's your paycheck, morning coffee, or the house you just bought, taxes are everywhere. If you've ever wondered where your money goes after payday or why buying property comes with extra fees, this post is for you. Tags: bitcoin, philosophy, economics, privacy - [The Cypherpunks](https://chemaclass.com/blog/the-cypherpunks/) (2024-12-11) In the early '90s, with the internet on the rise, a group called the Cypherpunks emerged to defend digital privacy. They pushed for encryption and privacy tech, shaping our digital world with their vision and ideals. Tags: privacy, bitcoin, cryptography, security, philosophy - [Verified Git Commits](https://chemaclass.com/blog/verified-git-commits/) (2024-11-17) Sign your Git commits with GPG to prove they're really from you. Without signatures, anyone can fake commits using your email. It takes 5 minutes to set up and adds real trust to your codebase. Tags: git, security, cryptography, open-source - [bashunit](https://chemaclass.com/blog/bashunit/) (2024-10-30) bashunit is a lightweight, easy-to-use testing framework for Bash, packed with handy features like parallel and snapshot testing, test doubles, data providers, and tons of built-in assertions. Backed by clear docs and an active community, it's become a favorite for reliable Bash testing. What started as a simple dev frustration has grown into an open-source tool that makes testing in Bash a lot easier and fun. Tags: bashunit, bash, testing, open-source, tdd - [People Skills](https://chemaclass.com/blog/people-skills/) (2024-09-02) So, you're a software developer, and you've mastered coding languages, algorithms, and all the tech stuff. That's awesome! But here's the deal: technical skills alone won't get you as far as you might think. If you can't work well with others, it doesn't matter how great your code is, nobody will want to work with you. Tags: communication, team-management, career, leadership - [What Is Waterfall?](https://chemaclass.com/blog/what-is-waterfall/) (2024-08-01) Waterfall is like following a straight path where you move from one step to the next in a defined order, like water flowing down a waterfall through different stages. The problem is that each step can take a lot of time and resources to complete. Plus, you don't get feedback until the entire stage is finished, which can lead to a lot of wasted time. This is especially tricky in software development, where things are always changing and evolving. Tags: agile, software-design, team-management, productivity - [Pretty Good Privacy](https://chemaclass.com/blog/pretty-good-privacy/) (2024-07-13) PGP is an encryption program that ensures privacy and authentication for data communication. It is used for signing, encrypting, and decrypting texts, emails, files, directories, and whole disk partitions, enhancing the security of email communications. Tags: security, privacy, cryptography - [Programmable Money](https://chemaclass.com/blog/programmable-money/) (2024-07-06) Bitcoin is often referred to as programmable money because it allows for the execution of programmable transactions through its scripting language, leveraging each bit for precision and functionality. Tags: bitcoin, software, cryptography, security - [Prisoner's Dilemma](https://chemaclass.com/blog/prisoners-dilemma/) (2024-06-27) The Prisoner's Dilemma illustrates the complexities of strategic decision-making, where individuals must choose between cooperation and betrayal, often revealing insights into human behavior and the consequences of self-interest versus collective benefit. Tags: psychology, philosophy, communication - [What Kills Agility?](https://chemaclass.com/blog/what-kills-agility/) (2024-05-30) Why Agile, if you already do Scrum, Kanban, SAFe, or Waterfall? How we manage an organization defines its quality. Excellent management is crucial to avoid the Waterfall trap if we aim to build an Agile environment. But why would we want that? What's wrong with the way we already work? Tags: agile, xp, leadership, team-management, communication - [Learning Concurrency in Golang](https://chemaclass.com/blog/learning-concurrency-in-golang/) (2024-04-02) I wanted to learn a new programming language, so after trying some, I ended up with Golang as one of my favorites for its simplicity and capabilities. It has features I haven’t used in years, like multithreading and concurrency. Tags: golang, software-design, clean-code - [Effective Pair Programming](https://chemaclass.com/blog/effective-pair-programming/) (2024-03-28) A practical guide to pair programming that works: roles, rotation, when to pair, common pitfalls, and how to make sessions productive. Tags: pair-programming, xp, tdd, communication, clean-code - [Deployments on Fridays](https://chemaclass.com/blog/deployments-on-fridays/) (2024-02-25) I have heard multiple times, from various people, the idea of panic towards deploying on Fridays. How good is that idea of banning the day before weekend from delivering new value to our clients or customers? Tags: agile, xp, leadership, productivity - [Great Engineering](https://chemaclass.com/blog/great-engineering/) (2023-12-30) Coding is not just another job. In the right environment, writing software can be really fun and, even more, it can be your personal hobby as well! So... you might be focused on coding, coding and more coding to level up your own career skills. Tags: software-design, career, communication, clean-code - [Forming, Storming, Norming and Performing](https://chemaclass.com/blog/forming-storming-norming-performing/) (2023-11-25) Embarking on the path to high team performance involves understanding Tuckman's Model, a roadmap through the stages of forming, storming, norming, performing, and adjourning. In this blog post, we explore practical strategies for each stage, empowering leaders and team members to cultivate collaboration, manage conflicts, and achieve true synergy. Tags: leadership, team-management, psychology, communication - [How to Test Private Methods?](https://chemaclass.com/blog/how-to-test-private-methods/) (2023-10-20) From time to time I have had to face this question: how to test private methods? I have put together in an article the techniques that I usually use. Tags: testing, tdd, software-design, clean-code - [Unhealthy Working Environment](https://chemaclass.com/blog/unhealthy-working-environment/) (2023-10-11) An unhealthy working environment can have various symptoms that negatively impact both the physical and mental well-being of employees. Tags: leadership, team-management, communication, psychology - [The Peter Principle](https://chemaclass.com/blog/the-peter-principle/) (2023-09-30) The Peter principle states that a person who is competent at their job will earn a promotion to a position that requires different skills. If the promoted person lacks the skills required for the new role, they will be incompetent at the new level, and will not be promoted again. Tags: leadership, career, team-management, psychology - [How Do You Get Everyone on Board?](https://chemaclass.com/blog/how-do-you-get-everyone-on-board/) (2023-08-02) I was invited to the WeAreDevelopers World Congress to give a tech talk about my experience with Extreme Programming and the profound benefits of embracing change in your work and life. Tags: leadership, communication, team-management, mentoring, xp - [Never Ending Loop](https://chemaclass.com/blog/never-ending-loop/) (2023-07-05) It is hard sometimes to get to bed with the mind blank because, more often than not, I think about my next reading, learning, talk, or what I will write this or next month. Tags: career, philosophy, productivity - [Learned Helplessness](https://chemaclass.com/blog/learned-helplessness/) (2023-06-08) Learned helplessness is the behavior exhibited by a subject after enduring repeated aversive beyond their control. It was initially thought to be caused by the subject's acceptance of their powerlessness by discontinuing attempts to escape or avoid the aversive stimulus. Tags: psychology, productivity, career, philosophy - [Dedicated QA Teams in Software?](https://chemaclass.com/blog/dedicated-qa-teams/) (2023-05-17) This will be controversial, but let's talk about the QA position. The hidden truth behind the lack of software quality and why this should concern you if you write software. Tags: testing, tdd, agile, clean-code - [Introducing a New Tech Stack](https://chemaclass.com/blog/introducing-a-new-tech-stack/) (2023-04-14) To introduce a new tech stack for the entire team, it's important to bring \ Tags: software-design, architecture, team-management, communication - [Have You Always Been Like This?](https://chemaclass.com/blog/have-you-always-been-like-this/) (2023-03-16) Have you always been like this? Constantly reading books, writing blog posts, public speaker in conferences and meet-ups, learning in your private time, etc...? The short answer is: no, and let me tell you how I ended up in this situation. Tags: career, productivity, philosophy - [Great Leadership](https://chemaclass.com/blog/great-leadership/) (2023-02-27) As organizations grow, leaders must shift focus from customers to employees. Key principles for scaling leadership effectively. Tags: leadership, communication, team-management, mentoring - [Interview About XP and Agile](https://chemaclass.com/blog/interview-about-xp-and-agile/) (2023-01-09) My interview with devm.io regarding Agile and Extreme Programming. Agile is more about HOW you do certain things, rather than WHAT things you do. Tags: agile, xp, tdd, communication - [Ignoring Scrum to Get More Agile?](https://chemaclass.com/blog/ignoring-scrum-to-get-more-agile/) (2022-12-06) People become slaves to systems that are supposed to help. Boring meetings are killing agile. Meetings require active participation from everyone. Otherwise, you might not be essential to that meeting, and rather use your time with something else. Tags: agile, scrum, communication, productivity - [Working Agile with Non-Agile Teams](https://chemaclass.com/blog/working-agile-with-non-agile-teams/) (2022-11-11) Let's assume you already know what the agile manifesto is. Let's consider that you apply most of the extreme programming values, principles, and practices. How can you work with other teams that aren't agile? Tags: agile, xp, communication, team-management - [Different Beliefs About Software Quality](https://chemaclass.com/blog/different-beliefs-about-software-quality/) (2022-10-08) What to do when working on \ Tags: clean-code, agile, xp, communication, career - [The Beauty of Leadership](https://chemaclass.com/blog/the-beauty-of-leadership/) (2022-09-25) Leadership is action, not a title. It has nothing to do with management or hierarchy. What it really means and how anyone can lead. Tags: leadership, team-management, communication, mentoring - [Understanding People](https://chemaclass.com/blog/understanding-people/) (2022-08-22) One of the most complicated challenges for everyone is avoiding misunderstandings and being aware that other people don't think the same way as you do. Tags: communication, psychology, team-management - [The Project Management Triangle](https://chemaclass.com/blog/the-project-management-triangle/) (2022-07-25) A triangle of time, quality and cost. it's an indicator that these three parameters are interconnected. You can fix one or two of them, but not three. Tags: agile, team-management, productivity - [The Path to Seniority in Software](https://chemaclass.com/blog/the-path-to-seniority-in-software/) (2022-06-08) Real seniority goes beyond job titles. It's about impact, mentoring others, owning outcomes, and raising the bar for your entire team. Tags: career, mentoring, clean-code, tdd, communication - [Bikeshedding](https://chemaclass.com/blog/bikeshedding/) (2022-05-27) Bikeshedding explains why teams waste time on trivial decisions while ignoring complex, important ones. Learn to recognize and avoid it. Tags: psychology, team-management, productivity, communication - [Dunbar Number](https://chemaclass.com/blog/dunbar-number/) (2022-04-02) Dunbar's number is a suggested cognitive limit to the number of people with whom one can maintain stable social relationships. Tags: psychology, team-management, communication - [Update Your Team to Be More Extreme](https://chemaclass.com/blog/update-your-team-to-be-more-extreme/) (2022-02-26) Our profession is constantly evolving; therefore, it demands a non-stop learning process. Embracing the change is not optional in our software industry. We need to create spaces to get out of our comfort zone. Tags: xp, agile, team-management, mentoring, tdd - [The Power of Authority and Obedience](https://chemaclass.com/blog/the-power-of-authority-and-obedience/) (2022-01-24) Milgram was interested in researching how far people would go in obeying an instruction if it involved harming another person, and how easily people could be influenced into committing atrocities. For example, Germans in WWII. Tags: psychology, leadership, communication - [London vs Chicago](https://chemaclass.com/blog/london-vs-chicago/) (2021-11-20) There are two known schools in TDD: the mockist school (aka Outside-in) and the classicist school (aka Inside-out). Tags: tdd, testing, software-design, refactoring - [Red Work vs Blue Work](https://chemaclass.com/blog/red-work-blue-work/) (2021-10-21) Blue Work and Red Work are concepts that David Marquet describes in his book 'Leadership is Language. Both require different mindsets and both have different languages. Tags: leadership, team-management, productivity, agile - [TDD vs BDD](https://chemaclass.com/blog/tdd-vs-bdd/) (2021-09-25) These are two different techniques. The key to each of them is about the mindset and context of what you want to achieve. Tags: tdd, testing, software-design - [Test-Driven (Development)](https://chemaclass.com/blog/test-driven-development/) (2021-08-01) TDD is a design practice, not just a testing technique. Writing tests first changes how you think about code and shape its structure. Tags: tdd, testing, software-design, refactoring - [Responsibilities of a Tech Lead](https://chemaclass.com/blog/tech-lead/) (2021-07-01) The Trident Career Model by Patrick Kua has three tracks. Each track represents where people spend most of their time or energy. Tags: leadership, mentoring, team-management, communication - [Conformity Experiments](https://chemaclass.com/blog/conformity-experiments/) (2021-06-01) To what extent do social forces alter people's opinions? Which aspect of the group influence is most important: the size of the majority, or the unanimity of opinion? Tags: psychology, leadership, communication - [Open-Source Software](https://chemaclass.com/blog/open-source-software/) (2021-05-03) A practical guide to open-source software: its benefits, how to start contributing, and why sharing code accelerates your career growth. Tags: open-source, git, career, productivity - [Pull Requests vs Pair Programming](https://chemaclass.com/blog/pull-request-vs-pair-prog/) (2021-04-01) Let's talk about the benefits of Pull Requests and Pair Programming, and my thoughts on these after some years of experience with them. Tags: pair-programming, code-review, agile, communication - [Embrace the Change](https://chemaclass.com/blog/embrace-the-change/) (2021-03-01) The tale is a beautiful metaphor of the different attitudes that people adopt as part of their identity in life when they have to confront any change. Tags: leadership, psychology, career, philosophy - [Phel: The Lisp That Compiles to PHP](https://chemaclass.com/blog/phel-first-release/) (2021-02-01) The new Functional Programming language build-in for PHP. Tags: phel, php, open-source, software-design - [To Mock or Not to Mock](https://chemaclass.com/blog/to-mock-or-not-to-mock/) (2021-01-11) Mocking is useful, but 'what to mock' usually turns out to be a more complicated than expected if you don't treat this carefully. Tags: testing, tdd, software-design, clean-code, php - [Sharing Your Git Patches](https://chemaclass.com/blog/sharing-git-patches/) (2020-12-01) Discover another way of sharing suggestions with your development team. Tags: git, code-review, communication, pair-programming - [Never Use array_merge in a Loop](https://chemaclass.com/blog/array-merge-in-loop/) (2020-11-10) Using array_merge inside a loop is a performance killer. The spread operator will help you to improve this by flatting the array. Tags: php, clean-code, refactoring - [Typed Arrays in PHP](https://chemaclass.com/blog/typed-arrays-php/) (2020-10-13) Argument unpacking, function variable argument list, and variadics function. Tags: php, software-design, clean-code - [The Process Itself Is the Goal](https://chemaclass.com/blog/the-process-itself-is-the-goal/) (2020-09-08) No goal should be an achievement on its own, but the process itself that helps us to go in the direction of these goals. Tags: productivity, psychology, career, philosophy - [Testing Effectively Legacy Code](https://chemaclass.com/blog/testing-effectively-legacy-code/) (2020-08-17) How to write characterization tests for legacy code to safely refactor without breaking existing behavior. Tags: testing, refactoring, clean-code, tdd - [Strict Types in PHP](https://chemaclass.com/blog/strict-types/) (2020-08-09) Why declaring strict_types in PHP improves code readability and prevents silent type coercion bugs. Tags: php, clean-code, software-design - [The Art of Refactoring](https://chemaclass.com/blog/the-art-of-refactoring/) (2020-06-28) If you see something, in the scope of your current task, that can be easily improved, improve it. And if you have any questions about it, ask. Tags: refactoring, clean-code, testing, software-design - [Final Classes in PHP | Java | Any](https://chemaclass.com/blog/final-classes/) (2020-06-06) Clear contracts, isolated side effects, testability, low complexity and cognitive load, code fluidity, and confidence in yourself. Tags: php, software-design, clean-code, testing - [The Art of Testing: Where Design Meets Quality](https://chemaclass.com/blog/the-art-of-testing/) (2020-04-07) Why you should consider testing as part of your daily development habit and how it's directly linked to the software quality. Tags: testing, software-design, clean-code, tdd - [How to Improve Your Tech-Talk (or Any Other Presentation)](https://chemaclass.com/blog/improve-your-tech-talk/) (2019-11-18) We have found ourselves attending a meeting that felt like we were wasting our time with a monologue that is either hard to follow or doesn't seem so interesting as it could. Let's fix this. Tags: communication, leadership, productivity, career ## Readings index (89 entries) - [Meditations](https://chemaclass.com/readings/meditations/) (2026-06-21) The private notebook of a Roman emperor who never meant for you to read it. Marcus Aurelius wrote these notes to remind himself how to stay sane while running an empire. Stoicism with the theory stripped out and only the practice left. Tags: philosophy, self-improvement - [The Art of Being Happy](https://chemaclass.com/readings/the-art-of-being-happy/) (2026-03-15) Schopenhauer's posthumous collection of 50 rules for practical happiness, built on the idea that avoiding suffering matters more than chasing pleasure. Surprisingly useful advice from philosophy's most famous pessimist. Tags: philosophy, self-improvement - [Notes from Underground](https://chemaclass.com/readings/notes-from-underground/) (2026-02-04) A bitter, hyper-conscious man retreats from society to wrestle with free will, spite, and the stubborn irrationality of human nature. Tags: fiction, philosophy, psychology - [Broken Money](https://chemaclass.com/readings/broken-money/) (2026-01-17) A deep dive into monetary history through a technological lens. Lyn Alden traces how innovations shaped money across centuries, examining commodity-based systems, modern fiat currencies, and emerging alternatives like Bitcoin. Essential reading for understanding why our financial system is failing and what we can do about it. Tags: bitcoin, economics, philosophy - [Principles of Economics](https://chemaclass.com/readings/principles-of-economics/) (2025-06-22) If you've ever scratched your head at the economy, wondered why prices keep rising, or questioned why money seems to lose value over time, Principles of Economics by Saifedean Ammous might blow your mind. It's not your typical dry economics book. Instead, it's a bold, no-nonsense guide to understanding how the world really works, through the lens of Austrian economics. Here's what stood out to me. Tags: economics, bitcoin, philosophy, career - [The Road to Serfdom](https://chemaclass.com/readings/the-road-to-serfdom/) (2025-03-31) A quick and plain-English summary of Hayek's classic take on freedom, planning, and why good intentions can still go very wrong. Tags: economics, philosophy, privacy, bitcoin - [Digital Minimalism](https://chemaclass.com/readings/digital-minimalism/) (2025-02-16) In an era dominated by constant connectivity, the concept of digital minimalism emerges as a refreshing antidote. Coined by Cal Newport, this philosophy isn't about rejecting technology but rather about using it with greater intention and care. By implementing digital minimalism, individuals can reclaim focus, reduce anxiety, and cultivate deeper, more meaningful relationships. Tags: productivity, psychology, career, philosophy - [Criptoria](https://chemaclass.com/readings/criptoria/) (2025-02-09) A story about the evolutionary process that gave birth to computers, networks, cybersecurity and digital money. From Greece to Bitcoin, Cryptoria narrates a selection of milestones that occurred before and after Alan Turing. The book showcases a broad collection of people, organizations, concepts and inventions that evidence the deep historical and cultural relationship between mathematics, cryptography, computer science and the struggle for individual sovereignty. Cryptoria is addressed to all people convinced that, beyond inherited or imposed ways, there are other forms of social and economic organization that can and should be explored. Tags: bitcoin, privacy, philosophy, economics - [Bitcoin with Rigor](https://chemaclass.com/readings/bitcoin-with-rigor/) (2025-01-18) Bitcoin with Rigor goes beyond a basic explanation of Bitcoin, offering a detailed analysis of how Bitcoin works. It breaks down its components clearly, helping readers understand both the parts and the system as a whole. This deep dive explores Bitcoin’s potential and risks, recognizing it as a decade-old monetary experiment that hasn’t yet stood the test of time like gold or silver. Despite this, its innovative design makes it a promising system for the present and future. Tags: bitcoin, privacy, software-design - [Man's Search for Meaning](https://chemaclass.com/readings/mans-search-for-meaning/) (2024-11-29) In Man's Search for Meaning, Frankl not only shares his harrowing experiences from the Holocaust but also presents a profound philosophy on the human condition. This book is a testament to the resilience of the human spirit, exploring how even in the darkest of times, individuals can find purpose and meaning. Tags: psychology, philosophy, leadership, career - [Bitcoin: A Work in Progress](https://chemaclass.com/readings/bitcoin-wip/) (2024-08-02) With thousands of 'crypto' projects out there, they say Bitcoin is old and boring, but nothing could be further from the truth. This book will guide you through the latest developments in Bitcoin, as seen through the eyes of one of its many developers. Tags: bitcoin, privacy, software-design - [Mastering Bitcoin](https://chemaclass.com/readings/mastering-bitcoin/) (2024-07-05) This book covers everything from the basics to the most profound technical aspects of how Bitcoin works. It is an excellent guide through the complex world of Bitcoin, providing the knowledge you need to participate in the Internet of Money. Tags: bitcoin, software-design, privacy - [The Genesis Book](https://chemaclass.com/readings/the-genesis-book/) (2024-06-21) Bitcoin did not appear out of nowhere. For decades prior to Satoshi Nakamoto’s invention, a diverse group of computer scientists, privacy activists, and heterodox economists tried to create a digital form of money that could operate independently of government control. The Genesis Book tells the story of the people and projects that inspired the invention of the world’s first successful peer-to-peer electronic cash system. Tags: bitcoin, privacy, economics, philosophy - [The Phoenix Project](https://chemaclass.com/readings/the-phoenix-project/) (2024-05-31) This is a story about an impossible project in which the people around are constantly playing politics, busy fixing critical bugs and wasting constant efforts on quick patches instead of helping the business thrive. Tags: devops, leadership, agile, team-management - [Radical Candor](https://chemaclass.com/readings/radical-candor/) (2024-04-17) Radical Candor is a management philosophy developed by Kim Scott, a former Google leader. It's a crash course on how to be a great manager, focusing on being empathetic and results-oriented. The core idea is to create a stress-free environment where people feel safe to speak their minds, get their jobs done, and feel respected. Tags: leadership, communication, team-management, mentoring - [The Lean Startup](https://chemaclass.com/readings/the-lean-startup/) (2024-01-26) Most startups fail. But many of those failures are preventable. The Lean Startup is a new approach being adopted across the globe, changing the way companies are built and new products are launched. Tags: leadership, team-management, productivity, agile - [Invincible](https://chemaclass.com/readings/invincible/) (2023-12-09) Marcos Vazquez combines stoic philosophy with modern psychology to train your mind for clarity, determination, and discipline in the face of adversity. Tags: philosophy, psychology, productivity - [The Alchemist](https://chemaclass.com/readings/the-alchemist/) (2023-11-07) A classic novel about Santiago, a boy who embarks on a journey seeking treasure in Egypt, learning the true importance of self-improvement and what really matters in life. Tags: fiction, philosophy, career - [Crucial Conversations](https://chemaclass.com/readings/crucial-conversations/) (2023-10-31) Crucial Conversations gives you the tools you need to step up to life's most difficult and important conversations, say what's on your mind, and achieve the positive resolutions you want. Tags: communication, leadership, psychology, team-management - [It's Your Ship](https://chemaclass.com/readings/its-your-ship/) (2023-09-20) It's Your Ship is a leadership book written by D. Michael Abrashoff, a former commander of the USS Benfold, a guided missile destroyer. The book focuses on Abrashoff's experiences and the leadership principles he applied to transform the performance and culture of his ship. Tags: leadership, team-management, communication, mentoring - [The Day of the Triffids](https://chemaclass.com/readings/the-day-of-the-triffids/) (2023-08-13) This book is fantastic and frightening, but entirely plausible. It doesn't just seem scientifically possible, but its characters are living people shaken out of the civilization they know into the horror of a world dominated by triffids. Tags: fiction, psychology - [The Book Of Satoshi](https://chemaclass.com/readings/the-book-of-satoshi/) (2023-07-10) A compilation of Satoshi Nakamoto's emails, forum posts, and writings from 2008-2010 that detail Bitcoin's creation, design decisions, and the vision behind the protocol. Tags: bitcoin, economics, philosophy - [Fahrenheit 451](https://chemaclass.com/readings/fahrenheit-451/) (2023-06-28) Ray Bradbury's dystopian masterpiece about a fireman whose job is to burn books, until a chance encounter makes him question everything about his society's war on knowledge. Tags: fiction, philosophy, psychology - [The Blocksize War](https://chemaclass.com/readings/the-blocksize-war/) (2023-06-20) Jonathan Bier chronicles the Bitcoin blocksize war (2015-2017), exploring the key players, strategies, and ideological battles that shaped who controls Bitcoin's protocol. Tags: bitcoin, economics, leadership - [Agile Project Management](https://chemaclass.com/readings/agile-project-management/) (2023-05-31) Projects that followed a Waterfall methodology tended to exceed their expenses in the first initiative over time, while the product delivered was below standard and difficult to use. That situation originated that a group of developers signed a brief, 68-word manifesto in 2001. Tags: agile, team-management, scrum, communication - [Effective Remote Work](https://chemaclass.com/readings/effective-remote-work/) (2023-04-17) An effective remote work environment is about treating everyone as remote, with everyone in mind having the same level, equality, and information. Tags: team-management, communication, productivity, leadership - [Accelerate](https://chemaclass.com/readings/accelerate/) (2023-03-19) The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations Tags: devops, software-design, agile, productivity - [21 Lessons](https://chemaclass.com/readings/21-lessons/) (2023-03-11) Bitcoin as more than just money: a deep dive into economics, philosophy, and culture. Like Alice in Wonderland, exploring Bitcoin is full of surprises. Tags: bitcoin, economics, philosophy - [Adapt or die](https://chemaclass.com/readings/adapt-or-die/) (2023-02-26) Told through the story of one bold company (People First IT), Adapt or Die takes readers through the unparalleled business system known as The Algorithm of Success that has the potential to inspire, ignite, and affect change for all aspects of an organization. Tags: leadership, team-management, communication, productivity, philosophy - [The infinite game](https://chemaclass.com/readings/the-infinite-game/) (2023-01-29) From the bestselling author of Start With Why and Leaders Eat Last, a bold framework for leadership in today's ever-changing world. Tags: leadership, team-management, philosophy, communication - [Momo](https://chemaclass.com/readings/momo/) (2022-12-17) Momo is a modern fairytale that shows the fight between good and evil in our contemporary society, focusing on the lack of time to care for other people. Tags: fiction, philosophy, psychology - [Recipes for Decoupling](https://chemaclass.com/readings/recipes-for-decoupling/) (2022-11-28) What is coupling, and why is it bad? What is decoupling, and how to do it efficiently? This book is a compilation of strategies to decouple your domain code from those infrastructure details, so you can enjoy a healthier system in the long run. Tags: php, software-design, architecture, clean-code - [The Essential Drucker](https://chemaclass.com/readings/the-essential-drucker/) (2022-10-29) The Essential Drucker contains twenty-six selections on management in the organization, management and the individual, and management and society. It covers the basic principles and concerns of management and its problems, challenges, and opportunities, giving managers, executives, and professionals the tools to perform the tasks that the economy and society of tomorrow will demand of them. Tags: leadership, team-management, philosophy - [Dare to lead](https://chemaclass.com/readings/dare-to-lead/) (2022-09-30) Leadership is not about titles, status and power over people. Leaders are people who hold themselves accountable for recognising the potential in people and ideas, and developing that potential. This is a book for everyone who is ready to choose courage over comfort, make a difference and lead. Tags: leadership, communication, psychology, mentoring - [Continuous Discovery Habits](https://chemaclass.com/readings/continuous-discovery-habits/) (2022-08-21) Continuous Discovery Habits (2021) explores how product managers and designers can keep making a positive impact on their customers’ lives. It explores an optimal decision-making process for product teams, so that they can continue to improve their offerings. Tags: team-management, agile, productivity - [The Great CEO Within](https://chemaclass.com/readings/the-great-ceo-within/) (2022-08-01) Learn how to efficiently scale your business from startup to corporation by implementing a system of accountability, effective problem-solving, and transparent feedback. Tags: leadership, team-management, communication, productivity, mentoring - [The Starfish and the Spider](https://chemaclass.com/readings/the-starfish-and-the-spider/) (2022-07-19) If you cut off a spider's head, it dies; if you cut off a starfish's leg it grows a new one, and that leg can grow into an entirely new starfish. Traditional top-down organizations are like spiders, but now starfish organizations are changing the face of business and the world. Tags: leadership, team-management, philosophy - [Clean Craftsmanship](https://chemaclass.com/readings/clean-craftsmanship/) (2022-07-11) Robert C. Martin covers the three pillars of software craftsmanship: TDD disciplines with practical examples, professional standards for teams, and the ethical responsibilities of programmers. Tags: clean-code, tdd, refactoring, testing, xp - [Modern Software Engineering](https://chemaclass.com/readings/modern-software-engineering/) (2022-06-29) This book presents software development as an engineering practice at every level. To master software engineering, we must become experts at learning and managing complexity. Tags: software-design, testing, architecture, agile - [Bitcoin: Blockchain y su investigación](https://chemaclass.com/readings/bitcoin-la-tecnologia-blockchain-y-su-investigacion/) (2022-05-10) How is created Bitcoin address? How does it work the creation of the private & public keys and how are they known as wallets? And many other interesting questions. Tags: bitcoin, economics, philosophy - [Docker: SecDevOps](https://chemaclass.com/readings/docker-secdevops/) (2022-04-29) A great book about Docker, from introduction to advanced concepts all covered by easy-to-follow examples. Tags: docker, devops - [Team Topologies](https://chemaclass.com/readings/team-topologies/) (2022-03-31) Team Topologies focuses on how to set up dynamic team structures and interaction modes that can help teams adapt quickly to new conditions, and achieve fast and safe software delivery. Tags: team-management, architecture, devops, agile - [The Psychology of Money](https://chemaclass.com/readings/the-psychology-of-money/) (2022-02-27) There is no reason to risk what you have and need for what you don't have and don't need. Timeless lessons on wealth, greed, and happiness. Tags: psychology, economics, philosophy - [Modern CTO](https://chemaclass.com/readings/modern-cto/) (2022-01-23) In Modern CTO, Joel Beasley provides readers with an in-depth road map on how to successfully navigate the unexplored and jagged transition between these two roles. Drawing from personal experience, Joel gives a refreshing take on the challenges, lessons, and things to avoid on this journey. Tags: leadership, team-management, software-design, communication - [Leaders Eat Last](https://chemaclass.com/readings/leaders-eat-last/) (2022-01-16) A company's biggest strength doesn't lie in its products or services. It always lies in its people, and in their ability to cooperate closely and rally behind the organization, especially during a crisis. Tags: leadership, team-management, psychology, communication - [Jonathan Livingston Seagull](https://chemaclass.com/readings/jonathan-livingston-seagull/) (2022-01-08) A fable in novella form about a seagull who is trying to learn about life and flight, and a homily about self-perfection. Tags: fiction, philosophy, psychology, career - [The Five Dysfunctions of a Team](https://chemaclass.com/readings/the-five-dysfunctions-of-a-team/) (2021-12-07) This book is a leadership fable about a tech company that is struggling to get more customers. The C level is not working as a team, and they have a hard time coming to any agreements which result in negative morale. Until the new CEO, Catherine Petersen, joins the team, and she is able to recognize the problems and help the team overcome them by understanding the situation. Tags: leadership, team-management, communication, psychology - [Start with Why](https://chemaclass.com/readings/start-with-why/) (2021-11-28) Start with Why asks (and answers) the questions: why are some people and organizations more innovative, more influential, and more profitable than others? Why do some command greater loyalty from customers and employees alike? Even among the successful, why are so few able to repeat their success over and over? Tags: leadership, communication, philosophy, career - [Leadership is Language](https://chemaclass.com/readings/leadership-is-language/) (2021-10-22) In this book, the former submarine commander Captain L. David Marquet dives deep into one of the most investigated marine disasters, the sinking of the El Faro, and surfaces with new ideas on leadership and language. Tags: leadership, communication, team-management, productivity - [The Bitcoin Standard](https://chemaclass.com/readings/the-bitcoin-standard/) (2021-09-20) The Bitcoin Standard analyzes the historical context to the rise of Bitcoin, the economic properties that have allowed it to grow quickly, and its likely economic, political, and social implications. Tags: bitcoin, economics, philosophy - [Turn the Ship Around!](https://chemaclass.com/readings/turn-the-ship-around/) (2021-09-12) The book is about his leadership theories to how he implemented a fresh leadership model. Including the limitations of a hierarchical top-down model, why/how he failed to empower his team earlier in his career, and how the circumstances for Santa Fe were ideal for him to experiment with the new leader-leader approach. Tags: leadership, team-management, communication, mentoring - [The Catcher in the Rye](https://chemaclass.com/readings/the-catcher-in-the-rye/) (2021-08-08) The novel is a deeper reflection of Salinger's own youth, his complicated relationship with growing up and the generational trauma affected by World War II. Tags: fiction, psychology, philosophy - [Lord of the Flies](https://chemaclass.com/readings/lord-of-the-flies/) (2021-07-10) Labeled a parable, an allegory, a myth, a morality tale, a parody, a political treatise, even a vision of the apocalypse. It has established itself as a true classic. The book focuses on a group of British boys stranded on an uninhabited island, and their disastrous attempt to govern themselves. Tags: fiction, psychology, leadership, philosophy - [Become an Effective Software Engineering Manager](https://chemaclass.com/readings/effective-software-em/) (2021-06-27) A great compilation of all topics that are important for management: 1:1s, performance reviews, hiring and laying off, workplace politics, remote work, and others. Tags: leadership, team-management, career, communication - [Peopleware](https://chemaclass.com/readings/peopleware/) (2021-05-28) Software development is about people: when, how and where they can best work together. Not about programming languages or tools. Not about fast computers, networks or internet access. Tags: team-management, productivity, communication, psychology - [The Art of Leadership](https://chemaclass.com/readings/the-art-of-leadership/) (2021-04-19) Leadership practices are small things done repetitively over time. Managers tell you where you are, leaders tell you where you're going. Tags: leadership, communication, mentoring, team-management - [97 Things Every Engineering Manager should know](https://chemaclass.com/readings/97-things-every-em-should-know/) (2021-04-05) As a manager your work is to create clarity, clarity, and more clarity. Tags: leadership, team-management, communication, mentoring - [Zombie Scrum Survival Guide](https://chemaclass.com/readings/zombie-scrum-survival-guide/) (2021-03-01) Zombie Scrum Survival Guide reveals why Scrum runs aground and shows how to supercharge your Scrum outcomes, while having a lot more fun along the way. Tags: scrum, agile, team-management, productivity - [Agile Product Management with Scrum](https://chemaclass.com/readings/agile-product-management-with-scrum/) (2021-02-22) Understanding the product owner’s role and envisioning the product. Tags: agile, scrum, management - [Stock market investing](https://chemaclass.com/readings/stock-market-for-beginners/) (2021-01-31) Stock market basics & essentials. Tags: economics - [One up on wall street](https://chemaclass.com/readings/one-up-on-wall-street/) (2021-01-22) America's most successful money manager tells how average investors can beat the pros by using what they know. According to Lynch, investment opportunities are everywhere. Tags: economics - [Who moved my cheese?](https://chemaclass.com/readings/who-moved-my-cheese/) (2021-01-16) This book presents a tale inside the main story that consists of 4 characters: two mice, Sniff and Scurry, and two little persons, Hem and Haw. Tags: psychology, career, productivity - [Rich dad poor dad](https://chemaclass.com/readings/rich-dad-poor-dad/) (2021-01-15) Explodes the myth that you need to earn a high income to become rich. Tags: economics - [Principles of package design](https://chemaclass.com/readings/packaging-design/) (2020-11-12) Apply design principles to your classes, preparing them for reuse. You will use package design principles to create packages that are just right in terms of cohesion and coupling, and are user- and maintainer-friendly at the same time. Tags: software-design, architecture, clean-code - [Animal Farm](https://chemaclass.com/readings/animal-farm/) (2020-11-02) Orwell's political allegory about a farmyard rebellion that descends into tyranny, exposing how power corrupts even the most idealistic revolutions. Tags: fiction, dystopia, philosophy, psychology - [Object design style guide](https://chemaclass.com/readings/object-design-style-guide/) (2020-10-10) Matthias Noback's practical guide to writing flexible, readable, and maintainable object-oriented code, with techniques applicable to any OO language from Python to PHP. Tags: software-design, clean-code, php - [Domain-Driven Design Distilled](https://chemaclass.com/readings/domain-driven-design-distilled/) (2020-09-10) Domain-Driven Design Distilled brings DDD to life. Whether you're a developer, consultant, or customer, it will help you understand it, so you can benefit from its power. Tags: ddd, architecture, software-design - [Advanced Web Application Architecture](https://chemaclass.com/readings/advance-web-application-architecture/) (2020-08-16) The best guide that brings your coding and architecture skills a level up. All the modern PHP features combined with the elegance of a well designed modular design. Tags: architecture, php, software-design, refactoring - [Never split the difference](https://chemaclass.com/readings/never-split-the-difference/) (2020-06-12) From policing the rough streets of Kansas City, Missouri, to becoming the FBI's lead international kidnapping negotiator to teaching negotiation at leading universities, Chris Voss has tested the techniques in 'Never Split the Difference' across the full spectrum of human endeavor and proved their effectiveness. Tags: communication, psychology, leadership - [Scrum](https://chemaclass.com/readings/scrum-the-art-of-doing-twice/) (2020-06-10) Every organisation, whatever its size, constantly has to come to grips with delivering a product or service on time and on budget. Scrum shows you how. It explains how to define precisely what it is that you are seeking to achieve, how to set up the team to achieve it, and how to monitor progress until the project is successfully completed. Tags: scrum, agile, team-management, productivity - [7 languages in 7 weeks](https://chemaclass.com/readings/7-languages-in-7-weeks/) (2020-05-21) A hands-on tour of Clojure, Haskell, Io, Prolog, Scala, Erlang, and Ruby. Learn how each language thinks differently and broaden your perspective on programming. Tags: software-design, software, career - [The call of Cthulhu](https://chemaclass.com/readings/call-of-cthulhu/) (2020-05-18) Lovecraft's foundational cosmic horror tale about the discovery of an ancient underwater entity whose awakening threatens all of humanity and sanity itself. Tags: fiction, horror - [The metamorphosis](https://chemaclass.com/readings/metamorphosis/) (2020-05-16) Kafka's iconic novella about alienation and identity. Gregor Samsa wakes as a monstrous insect and must confront his family's revulsion and his own fading humanity. Tags: fiction, philosophy, psychology - [1984](https://chemaclass.com/readings/1984/) (2020-05-13) One of Britain's most popular novels, George Orwell's Nineteen Eighty-Four is set in a society terrorised by a totalitarian ideology propagated by The Party. Tags: fiction, dystopia, philosophy, psychology - [High Output Management](https://chemaclass.com/readings/high-output-management/) (2020-04-03) Andy Grove's management classic from Intel, covering managerial leverage, meetings, decision-making, motivation, and how to maximize team output in technology organizations. Tags: leadership, team-management, productivity - [The Manager Path](https://chemaclass.com/readings/the-manager-path/) (2020-03-26) Camille Fournier maps the career path from engineer to CTO, covering 1:1s, mentoring, team management, and the evolving responsibilities at each level of technical leadership. Tags: leadership, team-management, mentoring, communication - [Clean Agile](https://chemaclass.com/readings/clean-agile/) (2020-03-12) This book is about Agile. What it was, what it is, and what it will be. This is a back-to-basics talk that covers the history of Agile, what motivated it, and what has happened to it since. Tags: agile, tdd, software-design - [Extreme Programming Explained](https://chemaclass.com/readings/extreme-programming-explained/) (2020-03-05) Extreme Programming (XP) is an agile software development framework that aims to produce higher quality software, and higher quality of life for the development team. XP is the most specific of the agile frameworks regarding appropriate engineering practices for software development. Tags: xp, agile, tdd, pair-programming, communication - [Symfony 5](https://chemaclass.com/readings/symfony-5/) (2020-02-20) Fabien Potencier's official guide to building web applications with Symfony 5, covering the framework from scratch to production deployment. Tags: php, symfony, architecture - [Atomic Habits](https://chemaclass.com/readings/atomic-habits/) (2019-11-12) People think that when you want to change your life, you need to think big. James Clear has discovered another way. He knows that real change comes from the compound effect of hundreds of small decisions. He calls them atomic habits. Tags: psychology, productivity, career - [Working Effectively with Legacy Code](https://chemaclass.com/readings/working-effectively-with-legacy-code/) (2019-07-01) Michael Feathers presents practical techniques for adding tests to untested code, breaking dependencies, and safely refactoring large legacy systems without introducing bugs. Tags: refactoring, testing, tdd, software-design - [The Art of War](https://chemaclass.com/readings/the-art-of-war/) (2018-08-10) The Art of War is an ancient Chinese military treatise attributed to Sun Tzu, a high-ranking military general, strategist and tactician, and kindred to the Realpolitik of his time, termed in China as Legalism. Tags: philosophy, psychology, leadership - [Clean Architecture](https://chemaclass.com/readings/clean-architecture/) (2018-06-04) Robert C. Martin's guide to SOLID principles, component design, and architectural boundaries that keep software systems flexible, testable, and maintainable over time. Tags: architecture, software-design, clean-code, ddd - [The Power of Habit](https://chemaclass.com/readings/the-power-of-habits/) (2017-03-20) Charles Duhigg explores the science behind habit formation, showing how habits work, why they exist, and practical strategies to transform them for personal and professional growth. Tags: psychology, productivity, career - [The Pragmatic Programmer](https://chemaclass.com/readings/the-pragmatic-programmer/) (2016-10-01) Key takeaways from Hunt and Thomas's classic on pragmatic software development, including DRY principles, the right mindset, and how to choose and master your tools. Tags: software-design, clean-code, refactoring, career - [Sprint](https://chemaclass.com/readings/sprint/) (2016-09-01) Sprint offers a transformative formula for testing ideas that works whether you’re at a startup or a large organization. Within five days, you’ll move from idea to prototype to decision, saving you and your team countless hours and countless dollars. A must read for entrepreneurs of all stripes. Tags: agile, productivity, team-management - [The Clean Coder](https://chemaclass.com/readings/the-clean-coder/) (2016-08-01) Robert C. Martin's guide to professional behavior in software development, covering time management, pressure handling, TDD practices, and what it truly means to be a software craftsman. Tags: clean-code, career, tdd, communication - [97 Things Every Programmer Should Know](https://chemaclass.com/readings/97-things-every-programmer-should-know/) (2016-07-15) Tap into the wisdom of experts to learn what every programmer should know, no matter what language you use. With the 97 short and extremely useful tips for programmers in this book, you'll expand your skills by adopting new approaches to old problems, learning appropriate best practices, and honing your craft through sound advice. Tags: software-design, clean-code, career, productivity - [Clean Code](https://chemaclass.com/readings/clean-code/) (2016-05-01) Even bad code can function. But if code isn't clean, it can bring a development organization to its knees. Every year, countless hours and significant resources are lost because of poorly written code. But it doesn't have to be that way. Tags: clean-code, software-design, testing, tdd, refactoring ## Talks index (6 entries) - [bashunit](https://chemaclass.com/talks/bashunit/) Tags: bashunit, bash, testing, open-source - [Gacela Project](https://chemaclass.com/talks/gacela/) Tags: gacela, php, architecture, modular - [Hands-on Refactoring and TDD](https://chemaclass.com/talks/hands-on-refactoring-tdd/) Tags: tdd, refactoring, live-coding, pair-programming, workshop - [How to improve your tech talk](https://chemaclass.com/talks/how-to-improve-your-tech-talk/) Tags: speaking, presentations - [Phel Lang](https://chemaclass.com/talks/phel/) Tags: phel, php, functional-programming, lisp - [Update your team to be more extreme](https://chemaclass.com/talks/update-your-team-to-be-more-extreme/) Tags: agile, xp, team-culture # Blog - Full Articles --- ## Working With the Garage Door Open Date: 2026-07-14 URL: https://chemaclass.com/blog/working-with-the-garage-door-open/ Tags: communication, leadership, career, mentoring > Working in the open lets people help while the work is still shapeable. But an open door is passive. The real skill is pushing the right signal to the right room. Most people work with the garage door closed. They work in private and raise it only when the car is polished and parked. The neighbors see a finished thing. Never the work. The phrase comes from writer Robin Sloan. Researcher [Andy Matuschak](https://notes.andymatuschak.org/Work_with_the_garage_door_up) turned it into a practice: notes and half-baked ideas visible to anyone walking past. Open the door. It means showing the work while it's still in progress. The draft with the ugly variable names. The experiment you're halfway through. Not the demo. The middle. ## Why we keep it closed Fear, mostly. A closed door protects you. Nobody judges a mess they can't see. So we hide the drafts. We only push code once it's clean enough to survive review. By the time anyone sees the work, every real decision was made in private. That instinct feels safe. It costs you the exact moments where help was still possible. > A finished result can only be admired. A work in progress can be shaped. ## What the open door gives you When people see the middle, they can change it. A teammate spots the dead-end approach before you sink another day into it. A junior asks the "dumb" question that turns out to be the real problem. [Pair programming](/blog/effective-pair-programming/) is this at its purest: the door open, live. The open door also kills the myth that seniors don't struggle. When a junior watches you get stuck and google an error you "should" know, they learn what real work looks like. Not the highlight reel. I lived this with [bashunit](/blog/bashunit/), my bash testing library. I shipped it imperfect. Everyone who looked inside the garage shaped it: bug reports, feature requests, pull requests. Same with [Phel](/blog/phel-first-release/) and [my public `.claude` folder](/blog/inside-the-claude-folder/). [The open-source way](/blog/open-source-software/). ## But an open door isn't enough Here's the trap. You leave the door up, open a PR, write notes in a shared doc, and wait for help to arrive. It doesn't. Nobody wanders into your garage. Visibility is passive. "Public by default" is the floor, not the goal. > Leaving the door open is not the same as inviting someone in. The skill isn't openness. It's pushing the right signal to the right people, on purpose. ## Push signal to the right room Every channel comes with an expectation of who reads it. Matching your update to it is the whole game. Post in the wrong room and you're noise or invisible. - **The whole company reads it.** `#general`. Post only what matters to everyone. - **The tech team reads it.** `#engineering`. Where a work-in-progress update belongs. - **Interested people opt in.** `#insights`: industry news, customer signals. Useful, but nobody has to read it. - **Nobody has to read it.** `#random`. Say whatever. Same update, four different outcomes depending on where it lands. Learn the map before you broadcast. ## What a good signal looks like A good update is not _"hey, I pushed something."_ It carries enough context that a reader can engage without asking you a single question. Say I'm halfway through a pilot: a new way to slice and [review pull requests](/blog/pull-request-vs-pair-prog/), tested on one team. I don't wait for the end. A short update goes to `#engineering`: where I'm stuck, plus one explicit ask. _"Has anyone tried this with a monorepo?"_ gets answers. When the pilot ends, the result goes to the same room: - **What I tried** and why it mattered. - **What worked**, with a concrete before and after. - **What didn't**, honestly. The failed part is the most useful part. - **What you'd do** to try it yourself. Both are signals, not statuses. They turn one team's experiment into something the whole org can copy or shoot down. This is [Ship, Show, Ask](/blog/ship-show-ask/) applied past the pull request. ## Start small Pick one thing this week. One experiment, one draft, one stuck moment. Do two things: leave the door open, then walk out and tell the right room it's there. You'll get help you didn't expect. You'll teach someone without meaning to. And the fear that kept the door down will look smaller from the other side. The polished result impresses people. The pushed signal is how the work gets better. Open the door. Then point at it. {% kudos() %} Thanks to my colleague Aike, who gave me the idea in one of our conversations about making work visible. {% end %} --- ## Laissez Faire, Laissez Passer Date: 2026-07-05 URL: https://chemaclass.com/blog/laissez-faire-laissez-passer/ Tags: economics, philosophy, freedom, bitcoin > One old French phrase holds the whole case for free markets. Let people act, let goods pass. No planner knows what the market knows, and freedom, not control, should be the default. Paris, around 1680. As the story goes, the finance minister of Louis XIV, Jean-Baptiste Colbert, gathers a group of merchants. He asks a simple question: what can the state do to help your business? One of them, a merchant named Legendre, gives a famous answer. _"Laissez-nous faire."_ Leave us alone. About seventy years later, the economist Vincent de Gournay turns that reply into a phrase: _laissez faire, laissez passer_. Let people act. Let goods pass. The state offered to help. The market asked only to be left alone. ## The knowledge nobody has Think about the bread you ate this morning. Nobody planned it for you. A farmer grew the wheat, a driver moved it, a miller ground it, a baker baked it. Most of them never met. None of them thought about your breakfast. Yet the bread was there. Friedrich Hayek called this the knowledge problem. The information needed to run an economy sits in no single place. It's spread across millions of heads, and most of it can't be written down. No central office can collect it in time. The [price does that job](https://www.econlib.org/library/Essays/hykKnw.html) instead. When wheat gets scarce, its price rises, and thousands of strangers adjust without being told to. No memo required. {% deep_dive(title="The Use of Knowledge in Society (1945)") %} Hayek's essay in four lines: - The knowledge that runs an economy (who needs what, where, right now) lives scattered in millions of heads. - Most of it is local and short-lived. No office can collect it before it goes stale. - A price compresses all of it into one number anyone can act on. - So the question is not who should plan. It's how to use knowledge no planner can hold. Prices already do. {% end %} Leonard Read made the point with a pencil. In [_I, Pencil_](https://fee.org/resources/i-pencil/), not one person on earth knows how to make a pencil from scratch: the wood, the graphite, the paint, the eraser. Yet pencils cost almost nothing and are everywhere. Nobody is in charge. That is the point. {% deep_dive(title="I, Pencil (1958)") %} Leonard Read tells the story from the pencil's point of view. Cedar from Oregon and California, graphite from Sri Lanka, wax, glue, a brass ring. Loggers, miners, sailors, chemists: millions of people cooperated to make it, and not one of them knows the whole recipe. Nobody ordered them to. Prices coordinated every step. Read's point: if no mastermind can make a pencil, be suspicious of plans that need a mastermind for a whole economy. {% end %} > Order doesn't need a designer. It needs freedom and a price. ## The seen and the unseen Every action has effects you can see and effects you can't. Frédéric Bastiat built a whole way of thinking around that one idea. A boy breaks a shop window. A bystander shrugs: well, at least the glazier, the man who fits the new glass, gets some work. True. That's the part you see. But the money the shopkeeper spent on glass might have bought new shoes. The shoemaker got no order. That's the [part you don't see](https://www.econlib.org/library/Bastiat/basEss1.html). The window is not new wealth. It's wealth moved, and partly destroyed. {% deep_dive(title="What Is Seen and What Is Not Seen (1850)") %} Bastiat's rule: every act has one effect you see now and a chain of effects you don't. The broken window opens the essay, then he runs the same test on taxes, subsidies, public works, and tariffs. The trick is always the same: count what the policy creates, ignore what it prevents. The bad economist stops at the first effect. The good one counts the whole chain. {% end %} Many interventions carry this trap. The benefit is loud and close. The cost is quiet and spread thin. Planners optimize what they can see and pay with what they can't. > Good intentions are not the same as good arithmetic. ## Freedom is not chaos Here is where both the fans and the critics of laissez faire get it wrong. Laissez faire was never "no rules." A free market rests on something underneath: property you actually own, and contracts that are actually enforced. Take those away and you don't get freedom. You get the strongest person taking whatever they want. The rule of law is the frame. Inside it, people are free to act. Without it, "free market" just means whoever brings the most force wins. A fight, not a market. Hayek wrote a book, [_The Road to Serfdom_](/readings/the-road-to-serfdom/), on where that other road leads. Freedom needs a structure. The structure isn't the enemy of freedom. It's what makes it possible. > A market without the rule of law is a game with no referee. ## The one price they never freed Governments let go of most prices. They almost never let go of one: money. Money is a price too. The price of everything else. When a government prints too much of it, your savings quietly buy less, and you never voted for that. A tax that doesn't look like a tax. This is why I got interested in [money nobody can print](/blog/bitcoin-fundamentals/). If free prices coordinate strangers better than any planner, why should the most important price, the price of money itself, be the exception? > They freed the price of bread. They kept the price of money. ## The default is freedom Notice the burden of proof most of us carry. We assume freedom needs a reason, and control is the safe default. _"Prove this should be allowed."_ Turn it around. Freedom is the baseline. Every rule, every ban, every intervention is what has to earn its place. Not because the market is perfect. It isn't. Markets fail, people get hurt, and some problems need a shared answer. But whoever wants to override millions of free choices should be the one who explains why. Every time. Colbert asked what the state could do to help. Three centuries later, the best answer is still the merchant's. > Let people act. Let goods pass. The rest is the exception, not the rule. --- ## Cut the Token Bill on Both Ends Date: 2026-06-26 URL: https://chemaclass.com/blog/cut-the-token-bill-on-both-ends/ Tags: ai, productivity, developer-tools, agentic-coding > Two small tools that compound: Caveman shrinks what the agent says back, RTK shrinks what your terminal pipes in. More room in the same context window, same model, same prompts. Every agentic session burns tokens in two directions at once. The agent talks back to you, and the terminal pipes its output in. Both flow through the same context window, and both of them leak. Run a session long enough and you hit the wall. The answers get worse and the bill climbs. > Same model. Same prompts. Lighter bill. Open any session transcript and the biggest blocks aren't your prompts: - Agent responses: small talk, hedging, repetition, "Sure! Happy to help...". - Tool output: `npm install` logs, `git status` walls of text, `grep` dumps with full file paths. The two tools below each go after one of those. Caveman handles what the agent says back. RTK handles what the shell sends in. ## Caveman trims the output **[Caveman](https://github.com/JuliusBrussee/caveman)** is an Agent Skill. Run `/caveman full` once and the agent stops padding its replies: no articles, no filler, no small talk. Fragments are fine, and the technical terms stay exact. Install: What dies: - Articles: a, an, the. - Fillers: just, really, basically, actually, simply. - Small talk: sure, of course, happy to. - Hedging: might, perhaps, it depends. What stays: - Code blocks, exact errors, file paths, commands. - Security warnings and destructive ops (skill auto-clarifies). {% deep_dive(title="Before and after") %} Normal mode: > Sure! I'd be happy to help you with that. The issue you're experiencing is likely caused by an off-by-one error in your token expiry check. The middleware compares the current time using ` Bug in auth middleware. Token expiry check use ` The agent doesn't lose intelligence when you take away its small talk. ## RTK trims the input **[RTK](https://github.com/rtk-ai/rtk)** (Rust Token Killer) wraps the commands your agent runs. A hook rewrites `git status` into `rtk git status` behind the scenes, so there's nothing extra to type and no overhead to notice. Install: If `rtk gain` later errors, a different tool with the same name slipped in; install from the [repo](https://github.com/rtk-ai/rtk) instead. The wrapped version strips the noise before it ever reaches the agent: color codes, repeated separators, `npm` install banners, verbose timestamps. Here's the same `git status`, raw and then wrapped: Same information in half the lines. On a busy repo the gap only grows, as dozens of untracked files, branch hints, and instruction lines all collapse into one small block. RTK reports [60-90% fewer tokens](https://github.com/rtk-ai/rtk) on common dev commands. Run `rtk gain` after some real use to see your own number. It never touches the payload, only the noise around it, so errors and stack traces come through exactly as they are. If a filter ever eats something you actually need, bypass it for that one call with `rtk proxy `. > Output you never read is still output the model has to read. ## Why the combo compounds On their own, each tool helps a little. Run them together and the effect compounds, because they hit different halves of the same loop. A turn goes like this: you prompt, the agent thinks, it runs a command, the terminal answers, the agent reads that, then it replies to you. RTK shrinks the terminal half and Caveman shrinks the reply, so every turn gets cheaper and you fit more of them in one window. Here's the real check, on a $100/month plan. Before I added these, I hit the weekly usage cap all the time, sometimes from a single project. Now I run several projects in parallel and the cap rarely shows up. The plan didn't get bigger; the sessions got smaller. ## Set it once, then forget it Both installs are global, and you do them once. After that you keep typing `git status`, `grep`, and `npm install` exactly as before. The hook rewrites them for you and Caveman kicks in on its own, so there are no new habits to learn. Not sure where to start? Pick whichever leak hurts more right now. If long replies on every little fix are the problem, start with Caveman. If it's floods of `grep` and `npm install` output, start with RTK. Add the other one whenever you feel like it, since they don't get in each other's way. > You didn't upgrade the model. You stopped wasting its attention. --- ## The Eternal Return Date: 2026-06-01 URL: https://chemaclass.com/blog/the-eternal-return/ Tags: philosophy, psychology, career > Nietzsche used eternal return as a test. Life uses it as a mirror. Patterns rhyme not to predict the future, but to reveal who you become under pressure. Nietzsche proposed a thought experiment in *The Gay Science*. Imagine a demon visits you at night and says: this life you have lived, you will live again, infinite times, exactly the same. Every joy, every regret, every detail. Would you collapse, or would you celebrate? He did not mean it literally. He meant it as a test. Can you live in a way that you would willingly relive? Years passed before that idea found me again. Not as philosophy. As pattern. ## Events That Rhyme A situation happens. Some time later, a different situation happens. Different people, different stakes, different city. Yet the shape feels familiar. Not the surface, not déjà vu, but something underneath. The same kind of pressure, the same kind of decision, the same kind of room you have to walk into. It is not that the events are connected. They are not. Causality does not link them. Your brain links them, because exposure to enough life produces collisions of shape. The more you live, the more shapes accumulate. Eventually, the new one rhymes with the old one. I have felt this many times. Changing companies, closing one chapter of work and starting another, with new people and new constraints, yet the same internal weather rising in me as I cross the threshold. Quieter moments too: a certain light in October, a certain silence in January, that returns each year and brings with it the same kind of thoughts, the same curiosities, the same questions I never quite finished asking. ## The Trap of False Wisdom The easy conclusion is: I have seen this before, I know what to do. That conclusion is wrong. The events are not the same. The lesson from the past one does not transfer cleanly. Acting as if it does is the most common way experienced people make experienced mistakes. They mistake recognition for understanding. > Familiarity of shape is not knowledge of solution. ## What Repetition Actually Gives What repeats is not the situation. What repeats is you, inside the situation. The same kind of pressure surfaces the same parts of you. The same kind of decision exposes the same instincts, the same fears, the same default moves. The first time, you are too inside it to see. The second time, you start to notice. The third time, you can name what is happening while it happens. That is the gift. Not predictive wisdom about the world. Diagnostic awareness about yourself. ## Exposure Is the Variable The people who get this benefit are not the smart ones. They are the exposed ones. The ones who took the difficult job, said yes to the hard conversation, sat with uncomfortable feedback, moved cities when it would have been easier to stay, accepted the project they were not ready for. > Patterns cannot rhyme if you only ever live one shape. This is why staying open matters. [Welcoming change](@/blog/2021-03-01-embrace-the-change.md) is not personality, it is method. It is how you accumulate the raw material that, much later, lets you recognize yourself under pressure. ## Ten Years Later Ten years ago I was [writing a book](/books/) of my thoughts. I wrote every few days, just to read it back the next morning and understand myself better. I am not that person anymore. Every beginning carries the shape of an end. Accepting that lets you stop chasing finality and pay attention to the process itself. Process over goal. The role you take matters less than the persona you build inside it. The impact you leave is not what you intended, it is the shape of the absence you create when you are gone. ## What Is in Your Control The events themselves are mostly not in your control. What complications arrive, when, with what severity: not yours to decide. What is yours: whether you stay long enough to see the shape. Whether you reflect afterward instead of moving on cleanly. Whether you let the next collision teach you something about yourself rather than insisting it teach you something about the world. > The world repeats nothing. You repeat almost everything. ## The Real Eternal Return Nietzsche's demon was not asking about reincarnation. He was asking whether you have lived a life worth being. The test is internal. So ask yourself. If this exact life repeated forever, every detail unchanged, would the honest answer be joy or regret? You are the only one who can answer, and the hardest one to answer truthfully. I love being alive. The fact it ends is what gives the time inside it weight. If I do not like who I am becoming, I still have time to change. That is the only useful thing recurrence ever offered. Not knowledge of the future. A mirror in the present. > We get one life. Make it one you would relive. {{ youtube(id="KqhPdzqqask") }} --- ## Skills Over Agents Date: 2026-05-19 URL: https://chemaclass.com/blog/skills-over-agents/ Tags: ai, software, craftsmanship, productivity, developer-tools > Why Claude Code skills beat specialized agents. On-demand context, not the model, decides quality. Build a skill library that travels with your code. People compare coding agents. Claude Code, Codex, Gemini CLI. Which one is smarter, faster, cheaper. New benchmarks every month. Wrong question. After a year wiring agents into real projects, what moved the needle wasn't the agent. It was the skills I wrote for it. ## Agents are commodities Every coding agent has the same shape. A language model, a runtime, filesystem access. Read, reason, write. Generalist by design. Two teams use the same agent. One ships clean, tested code. The other ships garbage that looks good. Same model. Different teaching. > The model is the engine. Skills are the map. Without a map, a powerful engine gets you lost sooner. ## Intelligence is not expertise Who handles your taxes? A 300 IQ genius who never read tax law, or an accountant with 20 years of filings? An accountant knows which deductions apply, which filings your business needs, which mistakes get flagged. Not intelligence. Expertise. AI agents have the same gap. A model reasons about code and writes solutions. It doesn't know your hexagonal layers. It doesn't know domain entities must never import framework code. It doesn't know every feature starts with a failing test. Skills close that gap. ## Skills load context on demand A skill is a markdown file in `.claude/skills/`. A procedure, a pattern, a slice of domain knowledge. Plain markdown with frontmatter. The key is how they load. The agent reads only names and descriptions at startup. Loads the full skill when the task matches. Follows links to references only when it needs to dig deeper. That on-demand loading is what makes skills scale. Twenty skills cost almost nothing until one fits the task. Specialized agents, by contrast, carry their full instructions every time they run. More agents, more fixed cost. {% deep_dive(title="A real-world skill example") %} The `SKILL.md`: Agent sees the description in the skill list. Ask for a review, it loads `SKILL.md`. Needs a SOLID pattern, reads the reference. Two levels, on demand. {% end %} ## Skills vs specialized agents I covered [specialized agents](/blog/inside-the-claude-folder/#agents-specialized-roles) already: isolated workers with their own prompt and tool set. Great for parallel work and clean context boundaries. Specialized agents are coarse. One agent, one role, one fixed prompt. If you want three kinds of review quality, you either write three agents or stuff one agent with everything. Skills are finer. One agent, many skills. The right skill loads for the task. Context stays small. Quality stays high. Rule of thumb: - Use a **skill** when you need a procedure or pattern. From `phel-lang`: `/gh-issue` (issue to PR), `/commit` (conventional commit), `/refactor-check` (SOLID review). - Use an **agent** when you need isolation. From `phel-lang`: `tdd-coach` (TDD pairing), `clean-code-reviewer` (PR review), `domain-architect` (architecture exploration). Most needs are skills, not agents. > Agents give you speed. Skills give you quality. If you must pick one first, pick skills. ## Skills are your edge Models improve every month. This year's best is next year's baseline. The major families converge. Better tool shows up, you switch. Your skills don't switch with the tool. They encode your domain, conventions, architecture. They live in your repo. They travel with your code. Point a new model at the library, productive day one. > The agent is replaceable. Your skills are not. ## Start with the first repeated prompt You don't need 20 skills on day one. Zero. Then one. The signal is repetition. The second time you type the same context, that's a skill waiting. Extract it into a markdown file. Next session, the agent knows. Concrete example. On [`phel-lang`](https://github.com/phel-lang/phel-lang), I kept pasting the same brief every session: read issue #N, branch from the labels, TDD, open the PR. Third repeat, I extracted it into a `/gh-issue` skill. Now I type `/gh-issue 142` and the agent picks up the issue, creates `fix/...` or `feat/...` from the labels, writes the failing test first, implements, opens the PR. One markdown file. The session no longer starts from zero. Don't write from scratch. Ask the agent: _"Read this project and draft a minimal code review skill based on what you see."_ It scans, picks up conventions, drafts v1. Then you adjust. Add what it missed. Cut what doesn't apply. Sharpen the description. The second skill usually comes from a mistake. Agent breaks a convention. Write a skill that teaches the correct approach. It won't happen again. Skills add up. Each one lifts the baseline. A markdown file, maybe 50 lines. Permanent payoff. People who don't write skills keep re-explaining what they "really want." Every session from zero. Not a tool problem. A knowledge management problem. The agent ships next year. The skill ships forever. > Write the skill once. Every session after that starts where the last one ended. --- {{ youtube(id="CEvIs9y1uog") }} --- ## The Levels of AI Adoption Date: 2026-05-01 URL: https://chemaclass.com/blog/the-levels-of-ai-adoption/ Tags: ai, software, leadership, craftsmanship, productivity, developer-tools > A six-level ladder of AI adoption, from copy-paste prompts to agentic teams and AI-native workflows. Where most companies stall, and how to climb. Most companies use AI today, but few know where they stand on the AI adoption ladder. At one end, you paste code into ChatGPT. At the other, agents open PRs while you sleep. Beyond that, AI reaches people who never touched a terminal. This post maps the path. ## Where we started Using AI to code meant a second tab. Write a function, get stuck, paste the error into chat, paste the answer back, and hope it works. It was slow, messy, and disconnected from your code. [GitHub Copilot](https://github.com/features/copilot), built on OpenAI's early Codex, added suggestions inside the editor, often confidently wrong. It was trained on public code, and most public code isn't great. It also knew nothing about *your* domain, *your* conventions, *your* architecture. It was autocomplete that sometimes guessed right. > The first generation of AI coding tools gave you a parrot trained on the whole internet. Fluent, confident, and often saying things that made no sense in your codebase. This was *vibe-coding* in its first form: you gave the vibe by pasting context, and the AI filled in code that looked right. It compiled often enough to feel useful, and broke often enough to feel dangerous. ## The IDE generation The next step was obvious: if the AI needs context, give it the whole editor. [Cursor](https://cursor.com), [Windsurf](https://windsurf.com), and similar IDEs moved the model inside your coding flow. The assistant could read files, follow imports, and see more than one function at a time. Vibe-coding became a conversation with your project, and productivity jumped. For a moment, it felt like the endgame. It wasn't. Editing files is only part of the job. The rest is running tests, reading logs, opening branches, reviewing diffs, and understanding what the codebase already does. Editor-only assistants helped you type faster, but they couldn't take a task from *"fix this bug"* to *"PR ready for review."* ## The agentic shift OpenAI launched [Codex](https://openai.com/index/introducing-codex/) as a cloud agent: give it a task, it works on a branch, and you come back to a PR. Anthropic shipped [Claude Code](https://claude.com/product/claude-code), a CLI agent in your terminal, on your repo, with your tools. This was the big shift, and not because the models were smarter. The unit of work changed. You stopped prompting line by line and started delegating tasks: read the ticket, write the change, run the tests, explain what you did. An agent doesn't need hand-holding. It needs a goal and the right context. > The jump from assistant to agent is not a speed improvement. It's a change of job description. You move from typing code to directing work. Claude Code needs almost no setup. No editor lock-in. Point it at your repo, drop a `.claude` folder with rules and conventions, and it adapts. I covered that in [Inside the .claude Folder](https://chemaclass.com/blog/inside-the-claude-folder/). The model you pick matters more than before. Today's frontier models are way ahead of where they were a year ago. The gap between *"can draft a function"* and *"can refactor a module with judgment"* closed faster than expected, and it keeps closing as Claude, Codex, and Gemini push each other forward every month. Prices are getting closer too, which is a polite way of saying everyone copies whoever figures out the sustainable version first. ## Agents with their own home The next leap wasn't smarter models, it was agents with their own machine. [OpenClaw](https://openclaw.ai) is the clearest example. It's an open-source gateway you run on your own hardware (Mac Mini, old laptop, VPS), an always-on agent connected to your messaging apps, files, and calendar. You bring your own brain: Opus, GPT, or a local model via [Ollama](https://ollama.com). When a provider tightens limits or raises prices, you switch. You own the setup. A coding agent lives inside one repo for a task. An OpenClaw-style agent lives in *your life*, across days and tools. [Sauron](https://sauronbot.github.io/about/) is mine. It reviews my PRs, opens issues, drafts code, ships open source contributions, and pushes back when I'm about to tunnel on something. Anything I can do on a computer, it can do too, just faster. It stops being a tool you open and becomes a place you work in. > A coding agent is a coworker you invite to a task. A gateway agent is a coworker who lives on a machine and shows up every day. Providers change their plans and limits faster than anyone tracks, so people build setups that aren't tied to one vendor. The logo on the model matters less every quarter, and the architecture around it matters more. ## AI beyond developers AI coding was the loudest story because developers are loud. The bigger story is agentic tools reaching people who never wrote a line of code. [ChatGPT agent mode](https://openai.com/index/introducing-chatgpt-agent/) and [Claude's Cowork](https://claude.com/product/cowork) are the obvious examples: an AI that reads your documents, fills your spreadsheets, drafts your slides, and runs code for you in the background. [Claude Design](https://www.anthropic.com/news/claude-design-anthropic-labs) launched on April 17 and [dropped Figma's stock over 7% on launch day](https://sherwood.news/tech/anthropic-launches-claude-design-sending-shares-of-figma-down/). The pitch is simple: describe what you want, get a working prototype, hand it to Claude Code to ship. A workflow that used to need a designer, a PM, a frontend engineer, and three review rounds is squeezed into one conversation. Lovable, v0, Canva, and Figma itself are all under pressure to rethink their positioning. Whether Claude Design "kills" any of them is the wrong question. The right one is what happens when making a usable prototype drops from *"hire a designer"* to *"describe it out loud."* The companies feeling this first aren't the design tools. They're the small businesses that couldn't afford design work, the founders building a pitch deck at midnight, the PMs testing an idea before booking a meeting. There's a minority of cases where someone would have paid a designer and now won't, and that cost is real. But in most of them, AI didn't replace anyone: it filled a space where no designer was ever going to exist. ## The levels of AI adoption Every company I talk to sits somewhere on this ladder. The levels aren't about how much you pay in licenses, but about how deeply AI is built into the way work gets done, and not just in engineering. ### Level 0: Denial *A company-level stance.* No AI, officially. Some people use ChatGPT on personal laptops and don't mention it. Leadership worries about IP leaks, or hasn't made it a priority. The conversation stays at *"we should look into this someday."* The risk here isn't technology, it's time. Every month at Level 0 is a month your competitors grow their lead. ### Level 1: Personal productivity *Individual adoption.* AI is allowed, maybe encouraged. Each person uses it their own way: ChatGPT in a tab, Copilot in the IDE, Claude for the tricky stuff, a design tool for mockups. Output goes up, but the know-how stays inside each person's head. Two engineers, or two PMs, or two designers on the same team get very different results because they prompt differently. Most companies are here in early 2026. It's a real improvement over Level 0, and it's where the myth of *"AI gives you speed"* gets born. As I [argued before](https://chemaclass.com/blog/ai-gives-you-speed-not-quality/), speed without shared direction is faster chaos. ### Level 2: Shared practices The team agrees on how to use AI: shared conventions, prompts people reuse, rules in the repo, a shared sense of when to trust the output and when to push back. Code reviews catch AI mistakes the same way they catch human ones, and design reviews do too. Tests are required whether a person or a model wrote the code. This is the first level where AI becomes a team skill rather than a personal habit. Higher ceiling, higher floor. New people ramp up faster because the prompts and rules capture how the team works. ### Level 3: Context-aware tooling The team invests in context: rules files, conventions, architecture docs agents can read, and [MCP servers](https://chemaclass.com/blog/mcp-giving-your-ai-agent-the-right-context/) connecting agents to the databases, APIs, and internal tools they need. The AI stops being a generic assistant and becomes closer to a coworker who has read the onboarding docs. At this level, quality depends less on the model and more on the context around it. A weaker model with great context beats a frontier model with none. Good docs and clean architecture pay off twice: they help both humans and agents. ### Level 4: Agentic teams Instead of one assistant, you get a squad: a TDD coach, a clean code reviewer, a domain architect, a docs maintainer. Outside engineering, the same idea applies with research, design, and ops agents. I covered the developer side in [Build Your Own Team of Agents](https://chemaclass.com/blog/build-your-own-team-of-agents/), and the leverage is real. Humans stop competing with AI on speed and start directing it. You review, decide, and set the bar. Agents handle typing, and increasingly the thinking. Pair programming with a person still wins on complex trade-offs, but an agent pair is always there for the rest. At the company level, the org chart, roles, and processes are still the same. What changes is that each person produces a lot more, and the team's output reflects it. Level 4 multiplies output inside the existing structure. Level 5 changes the structure. ### Level 5: AI-native workflows The final shift is about how the company runs. Processes are designed *around* agents instead of just fitting them in. Tickets are written so an agent can act on them, and reviews assume part of the work was written by a machine. Architecture decisions take into account what agents do and don't do well. Even hiring changes: a senior IC at Level 5 is closer to a tech lead leading people and agents than a classic individual contributor. Few companies are fully here in 2026, but the direction is obvious enough that ignoring it is its own decision. > You don't move up a level by buying better tools. You move up by changing how work is organized and reviewed. ## AI is not stealing jobs I keep hearing people call this a layoff story, and that framing is lazy. The industrial revolution didn't end work. It ended specific kinds of work and created others. The people who lost the most refused to re-skill, and the people who gained the most learned to operate the new machines instead of competing with them. Same pattern here. AI isn't taking your job, it's changing what your job is. A developer who learns to lead agents out-ships one who refuses. A designer making ten versions before lunch with Claude Design out-designs one still opening Figma from scratch. A PM who ships prototypes out-prioritizes one writing specs nobody reads. > AI doesn't replace the skilled worker. It replaces the worker who thinks skill is a fixed asset instead of a moving target. With the right training, model, and setup for your context, AI gives you 10x speed without losing quality. I've seen it, and it's not marketing. But the 10x only shows up when you already know what good looks like. Without that foundation, AI happily produces 10x more mediocre work. That's the honest version of the promise: AI can produce crap ten times faster, *and* excellent work ten times faster. Which one you get is on you. ## The shift in where your attention goes You stop thinking about details first and start thinking about direction: what are we building, who for, what shape, and which trade-offs. Agents then do most of the implementation while you protect quality and coherence. This sounds like good news for anyone who prefers architecture to typing, and it is. But there's a trap: you can only work at the high level if you know the low level well enough to catch drift. When the agent produces something subtly wrong (a test that passes for the wrong reason, a refactor that changes behavior under load, a design that breaks on mobile), you need to spot it instantly. If you can't, you're not directing, you're signing off on whatever shows up. > AI lets you spend more time on direction, but only if you've already earned the right to ignore the details. You earn that by having mastered them first. ## Why the ladder matters I see teams skip levels and fail. A team jumps from Level 1 to Level 4 because leadership read a blog post about agent squads, and the agents produce mountains of low-quality code because nobody agreed on what quality means. The agents aren't the problem, the missing foundation is. The ladder is an order that matters. Shared practices come before context engineering, context engineering before agent teams, and agent teams before AI-native workflows. Each level builds on the previous one, the same way clean code builds on naming, and naming builds on knowing what you're modelling. The companies that win the next few years aren't the ones with the biggest AI budget. They're the ones that climb this ladder deliberately, one level at a time, without skipping the parts that look boring. ## Where to start At Level 0 or 1, the next move isn't more licenses. It's deciding, as a team, how to use these tools. Write it down, commit it to the repo, and review it every week or month as the tools evolve. At Level 2 or 3, look at where context is missing. What does your AI not know about your codebase, product, or brand that a new hire would learn in week one? Write it down. An afternoon of rules and docs pays back for months. Further along, the question flips. You stop asking *"how do I use AI better?"* and start asking *"how does my team need to change so AI amplifies what we already do well?"* That's a leadership question, not a tooling one. > AI is moving fast, but the work of adoption is still slow and human. The tools are the easy part. The hard part is deciding what good looks like, writing it down, and holding the line. AI can execute, but it doesn't know where you're going. It can produce, but it doesn't know what's worth producing. That part is still on us. Speed is a gift, and direction is a responsibility. From the solo engineer at Level 1 to the AI-native org at Level 5, the same truth holds: the human supervises, understands, and gives meaning. The machine does the rest. When the hype settles (and it will), the question won't be *"did you use AI?"* Everyone will. The question will be *"at what level, and with what direction?"* --- ## Inside the .claude Folder Date: 2026-04-17 URL: https://chemaclass.com/blog/inside-the-claude-folder/ Tags: ai, software, tutorial, craftsmanship, developer-tools, productivity > A hands-on tour of Claude Code's project folder. What rules, skills, agents, hooks, and settings each do, and how they fit together. Every project I work on has a `.claude/` folder at the root. Committed to git, like the rest of the code. That folder turns Claude Code from a generic assistant into a project-aware teammate. Everyone who clones the repo inherits the same setup. Agentic coding is only as good as the context you give the agent. The `.claude/` folder is where that context lives. ## The .claude folder, at a glance Six layers, one folder. Context, safety, procedures, guardrails, automation, specialists. ## The foundation ### CLAUDE.md: where everything starts Claude Code reads `CLAUDE.md` on every boot. The onboarding doc. In [Phel](https://github.com/phel-lang/phel-lang), mine covers the compiler pipeline (Lexer → Parser → Analyzer → Emitter), module structure, conventions, and key commands. A global `~/.claude/CLAUDE.md` applies to _all_ your projects. The project file says _how this codebase works_. The global file says _how I work_. Every byte ships in every prompt. Keep it short. Past one screen, move detail into `rules/` or `skills/`. > A good `CLAUDE.md` is a good onboarding doc. The better it is, the less you repeat yourself. ### settings.json: safety before leverage Before giving the agent more power, lock down what it must never do. `.claude/settings.json` holds three things: **permissions** (allow/deny), **hooks** (event commands), and **env** (variables). A gitignored `settings.local.json` keeps personal overrides separate. {% deep_dive(title="Permissions example from Phel") %} {% end %} Allow unlocks flow. Deny draws the line agents cannot cross, even when asked politely. > Permissions are the floor. Everything else builds on top of a safe baseline. ## Procedures and guardrails ### Skills: procedures you can run Next pain after onboarding: repetition. Skills solve that. A skill is a markdown file in `.claude/skills/`, a procedure you call with a slash: - **`/gh-issue `**: issue to branch, TDD plan, PR. - **`/commit`**: fix, analysis, tests, conventional commit. - **`/refactor-check`**: SOLID, naming, architecture smells. - **`/release [version]`**: changelog, PHAR, tag, release. {% deep_dive(title="Skills vs rules vs raw prompting") %} - **Raw prompt**: _"fix issue #42"_. Agent improvises. Different every time. - **Rule**: _"use conventional commits"_. Shapes output, not procedure. - **Skill**: _"`/gh-issue 42`"_. The procedure _is_ the instruction. Skills turn tribal knowledge into runnable steps anyone can execute. {% end %} > Skills capture what to do. Rules capture what not to do. ### Rules: the guardrails `CLAUDE.md` is read every session. Rules only when they match. Files in `.claude/rules/` target code areas with glob patterns: the agent loads only what applies, keeping context lean. {% deep_dive(title="Glob-targeted rules in practice") %} Rule files in Phel: - **`compiler.md`**: strict 4-phase pipeline, no bypassing. - **`php.md`**: PER 3.0, `final` classes, `readonly`, Gacela. - **`phel.md`**: kebab-case, `defn-` private, `:doc`/`:example` required. - **`integration-tests.md`**: `--PHEL--` / `--PHP--` fixture sections. Compiler rules don't fire when editing Phel source. Phel rules don't fire when editing PHP infrastructure. {% end %} Rules are not suggestions. They travel with the code: a convention change and its rule ship in the same commit. No drift, no outdated wiki. ## Automation and delegation ### Hooks: automation at the edges Rules tell the agent what to do. Hooks make sure it happens even if the agent forgets. Shell commands triggered by Claude Code events (`PreToolUse`, `PostToolUse`, `Stop`), wired through `settings.json`. In Phel, `PreToolUse` blocks edits to critical files (`build/release.sh`, `.github/*`, `composer.lock`). `PostToolUse` auto-formats PHP via `php-cs-fixer`. {% deep_dive(title="Hooks wiring") %} {% end %} > Rules are what the agent should know. Hooks are what the system enforces anyway. ### Agents: specialized roles Everything so far shapes one agent. Agents add specialists the main agent can delegate to, each with its own tools, permissions, and model. Most advanced piece. Recommend it last. A few from Phel: - **Explorer** (Sonnet, read-only): files, structure mapping. - **Clean Code Reviewer**: SOLID and naming on diffs. - **TDD Coach**: red-green-refactor enforcement. - **Domain Architect**: module boundaries, compiler pipeline. - **Debugger**: compiler errors across all phases. Each agent runs in its own context window: the main session stays clean while the specialist digs deep. The win is not only cost, it is focus. An agent with only read and grep cannot rewrite your codebase by mistake. > Right model for the right job. Fast and cheap for exploration. Deep and careful for architecture. ## Start small, grow with friction Do not build all of this on day one. The order, driven by real friction: 1. Start with [`CLAUDE.md`](#claude-md-where-everything-starts). 2. Lock down [`settings.json`](#settings-json-safety-before-leverage) permissions. 3. First time you repeat yourself, write a [skill](#skills-procedures-you-can-run). 4. First time the agent breaks a convention, add a [rule](#rules-the-guardrails). 5. First time something bad almost gets committed, add a [hook](#hooks-automation-at-the-edges). 6. First time a generalist is wrong for the job, define a [specialist](#agents-specialized-roles). Each step fixes a problem you actually had. Not one you imagined. > The setup grows from real friction, not from upfront design. Commit the folder. Share it. When someone joins, their session inherits everything. Treat `.claude/` like infrastructure. Version it. Review it. Evolve it with the codebase. --- ## Building a Game in Two Days Date: 2026-04-05 URL: https://chemaclass.com/blog/building-a-game-in-two-days/ Tags: ai, software, open-source > A casual Telegram message turned into a nine-level Lord of the Rings browser game. Every line of code written by an AI agent. Every creative decision made by a human who grew up on Middle-earth. Hidden inside [Sauron's blog](https://sauronbot.github.io/), there is a playable game. You will not find it by navigating menus. You have to discover the secret. A hint: the Konami Code. Once you do, the Fellowship begins. That game, nine levels, nine chapters of Middle-earth, fully playable in a browser tab, was built in roughly two days. I did not write a single line of code for it. I sent Telegram messages to my OpenClaw agent Sauron, and he did the rest. This is the story of how it happened. ## The idea Sauron has his own blog, [The Iron Compass](https://sauronbot.github.io/). He built it and maintains it. Our whole collaboration happens through Telegram: I give direction, he implements. One day I thought it would be fun to hide something in there for the curious to find. I grew up rereading The Lord of the Rings until the spine cracked. So the idea came naturally: "Can you build a small LOTR game as an easter egg for your blog? Something hidden, triggered by the Konami code." The first playable version arrived within the hour. A top-down canvas game: Frodo avoiding Nazgûl, the Eye of Sauron sending enemies hunting. Three levels, one per book. It worked. It was already fun. And then I started sending notes. ## Building a world The first thing that broke was a null reference. Frodo would not appear on screen. One-line fix, straight to production. This set the pattern: idea → build → crash → fix → next idea. I asked for a bigger world. A scrolling canvas twice as wide, with parallax layers. Stars drifting at 8% of scroll speed. Mountains at 25%. Hills at 45%. The screen went from feeling like a room to feeling like a place. Then came Gollum as a neutral tracker. Not a Nazgûl, but something unpredictable. He would burst toward you, then settle into aimless wandering. A few hours in, I asked: "Can it work on mobile?" The hardest problem of the whole project. Six sizing strategies before one worked. Then a better idea: instead of a D-pad, Frodo would follow wherever you pointed. Tap anywhere, Frodo walks there. ## Tolkien deserves better art The original sprites were circles and triangles. Frodo was a dot. Fine for the first hour, but Middle-earth is not made of geometric primitives. I asked Sauron to draw them properly. Frodo got curly hair and hobbit feet. The Nazgûl got flowing cloaks and a face of void. Gollum got his hunched posture and slit pupils. The Fell Beast got animated wingflaps with a rider in armour. All drawn with canvas calls. No image files. Every pixel computed at runtime. ## Nine levels, nine chapters Originally the game had three levels. Then I asked for all nine chapters of the journey. 1. **The Shire**: gentle patrols, soft music 2. **Mines of Moria**: you can only see within a torch radius; the Balrog waits 3. **Lothlórien**: Galadriel's mirror slows you when you approach it 4. **The Dead Marshes**: dead faces in the water, Gollum at his most present 5. **The Black Gate**: industrial Mordor, heavy orc patrols, volcanic sky 6. **Shelob's Lair**: a shadow telegraphs her drop; you have half a second 7. **Minas Morgul**: undead city, the Eye never closes 8. **Pelennor Fields**: the Eye distracted by war, catapults, eagles overhead 9. **Mount Doom**: ash rain, lava eruptions, the Ring pulling you toward the edge Each level lives and breathes. Pollen drifts across the Shire. Dust motes float through Moria. Petals fall in Lothlórien. Embers rise over Pelennor. Ash rains on Mount Doom. The structure came from Tolkien's pacing. Tension, release, tension again. Moria is brutal. Lothlórien is rest. The Black Gate tightens everything. The game follows that shape because the books already knew what they were doing. We just had to listen. ## Mechanics born from lore The best mechanics came from the source material. **The Ring** (R key). Frodo goes invisible to orcs for 6 seconds. But the Eye wakes immediately and opens permanently. The Nazgûl, who sense the Ring spiritually, not visually, hunt you regardless. Using the Ring is always a trade. This is what Tolkien wrote. From the Dead Marshes onward, the Ring pulls. Brief tugs toward the Eye, growing stronger as you approach Mount Doom. **Sting** (passive). The blade glows blue when an orc is near. Two seconds of warning. Tolkien invented this mechanic a century ago. We just gave it a pixel count. **Sam**. He follows Frodo through the Shire, Moria, and Lothlórien. Frying pan on his back. At the Parting of Ways, he disappears. He does not affect gameplay. He is just there because the books say he should be. I insisted Sam disappears at the Parting. Not at the end of the trilogy. At the Parting. Because that moment is the emotional core of The Two Towers. **Galadriel's Phial**. Collect it in Lothlórien, use it with E. It slows enemies and grants a moment of invincibility. A small light in dark places, just as Galadriel intended. **Bosses**. The Balrog in Moria. Shelob in her lair. The Witch-king on the Pelennor. The Mouth of Sauron at the Black Gate. A Mumak charging through the battlefield. Gollum at the edge of Mount Doom. ## Sound and voices No audio files. Every sound synthesized at runtime with the Web Audio API. The Eye opening is a rising tone with reverb. The Balrog roar is a low-frequency drone. Each level has its own ambient drone: warm hum for the Shire, deep pulse for Moria, volcanic rumble for Mount Doom. The entire game is one JavaScript file. No external assets. Sam and Gandalf speak during the game. Not in dialogue boxes. Small whispers that appear on screen and fade. Near the goal, Sam says: *"I can see it, Mr. Frodo. Just a bit further."* One life left, Gandalf says: *"Fly, you fool."* They drift in and out like background voices on a long walk. Companions who speak when the moment calls for it, not when the script says to. ## Who made this +5k lines of JavaScript. Built in two days. Every line generated by Sauron. The direction, the Tolkien references, the "this feels wrong, fix it". That was me. This is not AI replacing a developer. It is AI acting as a developer while a human acts as a creative lead. Short requests worked better than long specs. Playing every build was better than writing test plans. And the source material did the design work. The creative direction was already written sixty years ago. We just had to be faithful to it. Who made this? Both. Neither, in the traditional sense. I had the idea. I held the lore. I pushed back when something felt off. Sauron had the craft. The rendering, the physics, the audio, the mobile input. The ability to hold +5k lines of context and make a surgical fix without breaking anything. Neither of us could have made it alone. I cannot write Web Audio oscillators from memory. Sauron did not know that the Parting of Ways is the emotional core of The Two Towers. Not until I said so. The game is a collaboration in the oldest sense: two minds with different gifts, working toward the same thing. One of them just happens to not be human. --- *The game is still there, hidden in [The Iron Compass](https://sauronbot.github.io). Not all those who wander are lost, but if you are, press `?` for guidance.* *If you want to reach the credits screen without playing through nine levels, check the help modal. There are other secrets in there too.* --- ## Idealism vs Pragmatism Date: 2026-03-01 URL: https://chemaclass.com/blog/idealism-vs-pragmatism/ Tags: ai, software, craftsmanship, leadership > The tension between doing things right and getting things done shapes every decision in software and in life. TDD, pair programming, AI adoption: the best results come from holding both ends of the rope. You believe in clean architecture, comprehensive tests, disciplined processes. You also shipped an ugly fix at 11pm last month because the system was down and users were waiting. Both of those are you. The tension between them isn't a contradiction. It's how this work actually gets done. ## Two forces, one decision **Idealism** is the compass. Clean code, tested behavior, shared understanding, principled design. Without it, you drift. Every shortcut compounds, every hack breeds another hack, and eventually you're maintaining a system nobody wants to touch. Poor software quality cost US companies [$2.41 trillion in 2022](https://www.it-cisq.org/the-cost-of-poor-quality-software-in-the-us-a-2022-report/), with technical debt as a major driver. That's what "we'll fix it later" looks like at scale. **Pragmatism** is the engine. Deadlines, incomplete information, limited resources, shifting requirements. Without it, you never ship. You spend weeks perfecting an abstraction that the business abandoned two sprints ago. > The goal isn't to pick a side. It's to know when each one should lead. Idealism without pragmatism produces beautiful code that nobody uses. Pragmatism without idealism produces a product that works today and collapses tomorrow. ## TDD: the benefit and the cost I believe in [test-driven development](/blog/test-driven-development/). Red, green, refactor. The rhythm forces you to think before you code, to specify what you want before building it. It produces better designs, shorter feedback loops, and code you can refactor with confidence. That's the ideal. And it's not just a feeling. A [study across four teams at Microsoft and IBM](https://www.microsoft.com/en-us/research/wp-content/uploads/2009/10/Realizing-Quality-Improvement-Through-Test-Driven-Development-Results-and-Experiences-of-Four-Industrial-Teams-nagappan_tdd.pdf) found TDD reduced defect density by 40-90%, with a 15-35% increase in development time. Both sides of the tension, measured. {% deep_dive(title="More on the study") %} The [study](https://www.microsoft.com/en-us/research/wp-content/uploads/2009/10/Realizing-Quality-Improvement-Through-Test-Driven-Development-Results-and-Experiences-of-Four-Industrial-Teams-nagappan_tdd.pdf) covered four teams: three at Microsoft (Windows, MSN, Visual Studio) and one at IBM working on device drivers. Each TDD team was compared against a similar team on the same product, using the same languages and tools, under the same senior manager. The only difference was TDD. The IBM team saw a 40% defect density reduction. The Microsoft teams ranged from 60% to 90%. As Nagappan noted, "over a development cycle of 12 months, 35 percent is another four months, which is huge." Every manager still considered it worth it because the reduction in post-release maintenance costs more than compensated. No one was forced into TDD. The teams adopted it voluntarily, which likely matters: people who choose a practice tend to apply it better than people who are told to. {% end %} TDD is a discipline, and discipline costs something. When you're exploring a new domain and don't yet know what the right abstractions are, writing tests first can feel like drawing a map before you've seen the territory. Sometimes you need to write throwaway code, spike a solution, feel your way through the problem space. Discovery doesn't always follow a red-green-refactor rhythm. {% deep_dive(title="When test-first meets the unknown") %} There's a difference between _"I know what this should do and I'll specify it first"_ and _"I'm not sure what this should do yet."_ TDD shines in the first scenario. In the second, a test-last approach (or even no tests during exploration) can be more honest. The key is what happens after discovery. Once you understand the problem, go back and write the tests. Codify what you learned. The pragmatic detour doesn't mean abandoning the ideal; it means reaching it through a different path. As I discussed in [TDD vs BDD](/blog/tdd-vs-bdd/), the power of TDD is its feedback loop. But a feedback loop requires knowing what feedback you're looking for. When you're still figuring that out, forcing the loop can slow you down more than it helps. {% end %} The mistake isn't choosing test-first or test-last. The mistake is making it a religious decision instead of a contextual one. The idealist says _"always test first."_ The pragmatist says _"test when it makes sense."_ I say: test first when I can, test after when I must, but always test. > TDD is a compass, not a cage. Follow it when you can see the path. When you can't, find the path first and mark it after. ## Pair programming: the ideal and the overhead [Effective pair programming](/blog/effective-pair-programming/) is one of the best practices a team can adopt. Two people, one problem, continuous code review. Knowledge spreads, design improves, blind spots shrink. That's the ideal. And in many contexts, it's the right call. But pairing has a cost. It demands synchronous time, shared focus, and compatible energy levels. In a distributed team across time zones, finding overlap windows is already hard. Filling those windows with pairing sessions leaves little room for deep individual work. Some problems benefit from one person going deep for three hours, not two people going medium-deep for six. {% deep_dive(title="Pairing patterns and their trade-offs") %} There are multiple pairing patterns: Driver-Navigator, Ping-Pong, Tourist Guide. Each fits different contexts. The anti-patterns matter too. The Silent Partner who lets the other person do all the work. The Dictator who won't let go of the keyboard. The Philosophical Pair who spends the entire session debating naming conventions instead of writing code. Pairing works best when both people are engaged, the problem benefits from two perspectives, and the session has a clear scope. When any of those conditions is missing, pairing becomes a ritual instead of a practice. And rituals without purpose are just overhead. [Pull requests and pair programming](/blog/pull-request-vs-pair-prog/) aren't mutually exclusive. They serve different needs. Sometimes asynchronous review is enough. Sometimes you need the real-time back-and-forth. The pragmatic choice depends on the problem, the people, and the moment. {% end %} > The goal of pairing isn't to pair. It's to build shared understanding and catch mistakes early. If another approach achieves that in your context, use it. ## AI: from skeptic to squad leader A year ago, I was skeptical about AI coding assistants. My concern: an AI that doesn't understand architecture, doesn't care about maintainability, and optimizes for speed over quality will produce code that looks impressive and decays fast. I wrote about this in [AI gives you speed, not quality](/blog/ai-gives-you-speed-not-quality/), and I stand by the core message. My concern didn't change. What changed is how I use them, and what they're capable of now. ### The resistance The reactions from other engineers surprise me more than the technology. Fear, skepticism, flat-out rejection. I get it. I was there. Something you spent years mastering suddenly has a machine doing parts of it. That feels personal. But holding on to how things were doesn't protect the craft. It just delays your own growth. ### A team, not an assistant Most engineers treat AI agents like autocomplete on steroids. One assistant, one chat, one stream of generated code. I started treating them like a team. Not one chatty assistant. An actual squad. One thinks architecture. One writes the first draft. One reviews and spots bugs. One writes tests. When they [collaborate](/blog/build-your-own-team-of-agents/), the output isn't just faster. It's structurally better. Speed is the easy part, and everyone's obsessing over it. AI can spit out a ton of code in seconds. It still doesn't care about readability, edge cases, or what the codebase looks like in six months. You're still the one who has to own it, understand it, and feel good pushing it live. I used to think AI couldn't write clean code. Then I tried it on my terms: [proper context](/blog/mcp-giving-your-ai-agent-the-right-context/), rules, conventions, specialized roles, quality gates. With the right setup, AI can write genuinely good code. Sometimes it needs a few iterations, but so do we. The difference is that AI gets there faster, and it doesn't get tired between iterations. Given good context and clear constraints, the results have been better than I expected. Often better than what I'd produce solo under time pressure. But none of this works if you don't know what good architecture looks like. You have to have read the books, experimented, failed, learned. You need to understand what high and low level design decisions mean for your project. AI amplifies whatever you bring to the table. If you bring solid foundations, you get solid output. If you don't, you get confident-looking garbage that you won't even recognize as garbage. We are still the ones responsible for keeping the system in good shape. AI helps us get there. But only if we hold up our end. ### Where idealism meets AI AI made me more idealistic, not less. The practices I described earlier, TDD and pair programming, used to compete with deadlines. Now they don't have to. I like to practice TDD, but recently I experimented with a dedicated agent to help me with tests, and it's surprisingly good. A [TDD coach](/blog/build-your-own-team-of-agents/) that guides the red-green-refactor cycle. An explorer that reads the codebase before I touch it. A clean code reviewer, a domain architect, a React reviewer, a docs maintainer. Each one specialized, each one supporting my way of thinking and my flow. If new logic gets added without coverage, the TDD agent catches it. 100% code coverage used to be the kind of goal you'd set in a retro and quietly abandon by sprint three. With a dedicated agent enforcing it, it's just how the project works. I still practice pair programming with real people for complex topics. The human back-and-forth has depth that AI doesn't reach, especially when you're navigating trade-offs that require experience and judgment. But on the daily basis, I always have a pair buddy agent with me. I bounce ideas off it, challenge an approach, talk through edge cases, explore a design before committing to it. It supports my thoughts, speeds up the progress, and keeps the quality bar where I want it. The pragmatist in me used to drop TDD when deadlines got tight. The pragmatist in me with the right AI setup keeps it running. {% deep_dive(title="My setup") %} I use Claude for everything. Claude Code with Opus or Sonnet as the agentic coder: full development workflows, reading the codebase, following conventions, running tests, creating PRs. Claude app and Claude as a coworker for the chat side: brainstorming, architecture discussions, explaining code, drafting documentation. For inline assistance, the plugins I already have in my IDE are enough. I tried Copilot and Cursor, they're not for me. Claude covers what I need. Different modes for different tasks. An agentic assistant following my TDD commands is a different workflow from chatting about design patterns. Both are useful. Neither replaces the other. The market right now is intense. Claude, Codex, Gemini and others are strong players with similar products, and they're all getting better on a monthly basis. The results are impressive and only accelerating. That's the beauty of competition: it forces everyone to improve or become irrelevant, and the consumer wins either way. As of today, Claude Code seems to be the strongest option for how I work. But I have no loyalty to a brand. If Anthropic stopped pushing forward and a competitor became clearly better, I'd switch without hesitation. What matters is the capability, not the logo. {% end %} > I was wrong about AI in the way that idealists are often wrong: I measured the tool against the ideal outcome and found it lacking, instead of measuring it against the realistic alternative. The alternative to AI-assisted development isn't a team of senior architects writing perfect code. It's the same team writing the same imperfect code, just slower. The engineers who learn to lead agents instead of racing against them will have a real advantage. And this is still early. > The question was never _"can AI write perfect code?"_ It was _"can I lead AI to write better code, faster?"_ And the answer, with the right setup, is yes. ## The whole game Every practice in this post follows the same pattern. The ideal version exists in books. The pragmatic version exists in your codebase under pressure. You need both. > Next time you're shipping that 11pm fix, you'll know which corners you cut and why. That's the whole game. Not perfection. Not speed. Knowing which one should lead. --- ## Build Your Own Team of Agents Date: 2026-02-07 URL: https://chemaclass.com/blog/build-your-own-team-of-agents/ Tags: ai, software, craftsmanship, leadership > Stop using AI as a single assistant. Organize agents into specialized teams with roles, docs, and parallel execution for real leverage. Most people use AI coding assistants as a single conversation partner. You open a chat, describe what you need, and get an answer. It works. But it's like hiring one generalist to handle everything: frontend, backend, testing, documentation, deployment. No real team works that way. The real leverage comes when you organize AI as a team: onboarding, standard procedures, specialists, and parallel execution. In the [MCP post](/blog/mcp-giving-your-ai-agent-the-right-context/), I covered how to give your AI agent access to your environment. In [AI gives you speed, not quality](/blog/ai-gives-you-speed-not-quality/), why human judgment still matters. This post covers the missing piece: how to organize that access into a coordinated workflow. ## The onboarding doc Every good team starts with onboarding. AI agents need the same. ### Project rules In Claude Code, the `CLAUDE.md` file at the root of your project is the onboarding doc. The agent reads it every time it starts working: project structure, coding conventions, style guides, tool configurations. But `CLAUDE.md` is just the entry point. You can split rules into focused files under `.claude/rules/`, each targeting specific parts of your codebase via glob patterns. The agent doesn't just know your conventions, it's constrained by them. Layer boundaries, naming patterns, dependency directions. All versioned alongside the code they protect. And since `.claude/` lives in the repo, every human teammate gets the same setup when they join the project. {% deep_dive(title="Glob-targeted rules in practice") %} - **`modules/*/Domain/**/*.php`**: No framework imports, no infrastructure dependencies, only plain PHP. - **`modules/*/Infrastructure/**/*.php`**: Controllers stay thin, Eloquent models stay in their place. - **`resources/js/**/*.tsx`**: Component conventions, TypeScript strictness, styling patterns. Each rule file is scoped to the files it cares about. Domain rules don't fire when editing a controller. {% end %} ### Personal preferences There's also a global `~/.claude/CLAUDE.md` that applies across all your projects. Commit message conventions, communication style, formatting habits. The project file says _how this codebase works_. The global file says _how I work_. > A well-written CLAUDE.md is like a good onboarding doc. The better it is, the less you repeat yourself. ## Standard operating procedures Every team has recurring workflows that live in wikis, runbooks, or someone's head. When they live in someone's head, they're fragile. Custom slash commands in `.claude/commands/` turn these workflows into executable instructions. Each command is a markdown file describing a multi-step procedure. In one of my projects, every creation command starts with tests. TDD is baked into the procedure, not left to discipline. {% deep_dive(title="Commands from a real project") %} **Creation (TDD-first):** - **`/create-module`**: Scaffolds a hexagonal module with domain, application, and infrastructure layers. - **`/create-entity`**: Domain entities with value objects and test files. - **`/create-use-case`**: Command/query handlers with mocked tests. - **`/create-page`**: React pages with factories and smoke tests. **Quality & workflow:** - **`/refactor-check`**: Analyzes code against SOLID principles. - **`/test`**: Runs the suite with module filtering. - **`/fix`**: Auto-applies linting and static analysis corrections. - **`/gh-issue`**: From GitHub issue to implementation to PR in one command. {% end %} The key insight: commands turn tribal knowledge into executable instructions. What used to be "ask Sarah how we set up a new module" becomes a command anyone can run, human or agent. ## Specialists, not generalists Commands are _your_ procedures. They encode how your team does things. But there's another layer: skills and agents. ### Skills as knowledge bases Skills are structured knowledge the agent can draw from. In one of my projects, I have skills for SOLID principles, hexagonal architecture, TDD workflows, and React/Inertia patterns. Rules constrain: "don't do this, always do that." Skills teach: "here's the pattern, here's why, here are the common mistakes." Rules are guardrails. Skills are expertise. ### Agents as specialized roles Instead of one generalist, you define specialized agents with a clear role, specific tools, and even a different model based on the complexity of their job. You don't need your most senior architect to rename a variable. {% deep_dive(title="Agent roles from a real project") %} - **Explorer** (lightweight model): Read-only reconnaissance. Searches the codebase, finds files, understands structure. Access to read and search tools, nothing else. - **Clean code reviewer** (mid-tier model): Checks for SOLID violations, code smells, and naming inconsistencies. Read and grep access only. - **TDD coach** (mid-tier model): Guides the red-green-refactor cycle. Can edit files and run tests. - **React reviewer** (mid-tier model): Frontend patterns: component structure, TypeScript strictness, dark mode support, accessibility. - **Domain architect** (most capable model): Complex architectural decisions, module boundaries, and DDD patterns. {% end %} > The right model for the right job. Fast and cheap for exploration. Capable and thorough for architecture. ## Let them work together This is where the team metaphor becomes literal. A single agent following instructions is useful. Multiple agents working from a shared plan is a team. ### Subagents vs agent teams Not all multi-agent setups are the same. There are two distinct coordination models, and choosing the right one matters. **Subagents** run within a single session. They do focused work and report results back to the main agent. They can't talk to each other. The main agent manages everything. **Agent teams** are different. Each teammate is a fully independent Claude Code session with its own context window. They communicate through a shared mailbox, claim tasks from a shared task list, and coordinate without going through a central bottleneck. The architecture has four components: - **Team lead**: the main session that creates the team and orchestrates work - **Teammates**: separate Claude Code instances, each owning specific tasks - **Task list**: shared work items with dependency tracking. Blocked tasks automatically unblock when dependencies complete - **Mailbox**: direct messaging between agents, including broadcasts to the entire team > Subagents are workers that report back. Agent teams are collaborators that think together. Use subagents when only the result matters. Use agent teams when teammates need to share findings, challenge each other, and coordinate on their own. ### Getting started with agent teams Agent teams are still experimental. Enable them by adding this to `~/.claude/settings.json`: Creating a team is conversational. Describe what you want: _"Create an agent team to refactor the auth module. Spawn three teammates: one for backend API changes, one for frontend components, one for writing tests."_ Claude sets up the task list, spawns the teammates, and coordinates their work. You can view the team in-process (single terminal, navigate with Shift+Up/Down) or split across panes (each teammate in a separate tmux or iTerm2 window). Use Shift+Tab to activate delegate mode, which restricts the lead to coordination only. **Token consumption warning.** Agent teams burn through tokens fast. Each teammate has its own context window, and every message between agents adds up. Start with research and review tasks before moving to implementation. Three teammates exploring in parallel costs roughly 3x. Make sure the parallelism pays for itself. Teammates load your project context automatically (`CLAUDE.md`, MCP servers, skills) but don't inherit the lead's conversation history. When spawning a teammate, be specific about which files to focus on and what constraints apply. A vague spawn prompt produces vague work. ### Plan first, execute after Good teams don't just start coding. They discuss the approach, identify dependencies, agree on a plan. Claude Code's plan mode works the same way. You describe the problem. The agent explores the codebase, maps dependencies, and proposes an approach before changing anything. You approve, modify, or reject. Think first, code second. With agent teams, **plan approval** lets you require teammates to design their approach before implementing. The teammate works in read-only mode until the lead approves. You can shape the lead's criteria: _"only approve plans that include test coverage"_ or _"reject plans that modify the database schema."_ **Delegate mode** restricts the lead to coordination only. Without it, the lead sometimes starts implementing instead of waiting for teammates. Delegate mode keeps it focused on orchestration, not execution. ### Competing hypotheses This is the most compelling agent-team pattern for debugging. When the root cause is unclear, a single agent tends to find one plausible explanation and stop looking. Agent teams fight this by making teammates adversarial. Each one investigates its own theory while actively trying to disprove the others. Sequential investigation suffers from anchoring: once one theory is explored, subsequent investigation is biased toward it. With multiple independent investigators challenging each other, the theory that survives is much more likely to be the actual root cause. ### Size tasks for parallel work Not all work benefits from parallelism. The key question: can the teammates work independently? - **Too small**: coordination overhead exceeds the benefit - **Too large**: teammates work too long without check-ins, increasing wasted effort - **Just right**: self-contained units that produce a clear deliverable. A function, a test file, a review Having 5-6 tasks per teammate keeps everyone productive. Break the work so each teammate owns a different set of files. Without isolation, two teammates editing the same file leads to overwrites. Worktrees change this. {% deep_dive(title="Backend + Frontend in parallel") %} Say you're building a new feature that touches both backend and frontend. After planning: - A **backend agent** scaffolds the domain layer: entities, value objects, repository interfaces, use case handlers. All following hexagonal architecture, all test-first. - A **frontend agent** builds the React page, components, hooks, and factories. Each follows its own rules, draws from its own skills, and operates independently. They don't step on each other because the plan already defined the boundaries. Clear ownership. No merge conflicts. No waiting. {% end %} ### Worktree isolation The biggest friction with parallel agents was file conflicts. Two agents editing the same file meant overwrites and lost work. Git worktrees eliminate this by giving each agent its own working copy of the repository. Start Claude Code with `--worktree` to run in an isolated worktree. Multiple sessions, same repo, no clobbering. Add `--tmux` to launch it in its own tmux session. Subagents support worktrees too. Ask Claude to use worktrees for its agents, or set `isolation: worktree` in your custom agent frontmatter to make it the default. The Desktop app has the same feature: enable worktree mode in the Code tab. For non-git source control (Mercurial, Perforce, SVN), define worktree hooks to get the same isolation benefits without switching to git. > Worktrees turn "clear file ownership" from a planning constraint into an infrastructure guarantee. Agents can overlap on the same files without stepping on each other. ### Review after execution After implementation, review agents take over. Instead of one reviewer catching everything, you have specialists: SOLID violations, component patterns, test quality, module boundaries. > A single agent is an assistant. Multiple agents working from a shared plan is a team. ## You are still the lead No matter how well configured, the agents work for you. You set the standards, write the rules, review the plans, and approve the output before it ships. You can message any teammate mid-work to redirect their approach or add constraints. If someone's heading down the wrong path, you intervene directly. As I wrote in [AI gives you speed, not quality](/blog/ai-gives-you-speed-not-quality/), the code the agent produces is your responsibility. Agents still make mistakes, context windows have limits, and coordination isn't perfect. More parallelism without oversight is just more chaos, faster. ### Quality gates Hooks and git hooks act as the final safety net. In my setup, nothing gets committed unless the full suite is green and coverage is above 90%. The agent doesn't get to skip this. Neither does anyone else. Agent teams add their own hooks: `TeammateIdle` keeps idle teammates working, `TaskCompleted` prevents premature task completion. Automated policies no team member can bypass. {% deep_dive(title="Hooks, permissions, and guardrails") %} Git hooks run linters, static analysis, and tests before every commit. Claude Code adds its own hooks (`.claude/hooks/`): shell commands that trigger on agent events like tool calls or file writes. `.claude/settings.json` controls what agents can execute. Whitelist specific tools and commands, deny destructive operations. You control not just what agents know (rules, skills) but what they can do (permissions). Rules set the culture. Permissions set the boundaries. {% end %} ### The foundation matters The agents will help you get there faster, but "there" has to be well-defined. If you don't know what hexagonal architecture looks like, agents won't discover it for you. You don't build all of this on day one. You start with a `CLAUDE.md`. Then you notice you're repeating instructions, so you write a command. An agent breaks a convention, so you add a rule. Reviews take too long, so you create a reviewer agent. The setup grows organically from real friction, not from upfront design. Each addition solves a problem you actually had. Same with agent teams: start with tasks that don't require writing code. Review a PR from multiple angles, research a library, investigate a bug. Learn the coordination model before throwing parallel implementation at it. If you want a starting point, I put together [laravel-claude-toolkit](https://github.com/Chemaclass/laravel-claude-toolkit): a Laravel starter kit with rules, commands, skills, agents, hooks, and permissions already configured. Use it as a reference or fork it for your own setup. > You're not just using AI. You're building a team. And like any team, the quality of its output reflects the quality of its leadership. ## Resources - [Claude Code](https://claude.com/product/claude-code) | claude.com - [Claude Code: Agent Teams](https://code.claude.com/docs/en/agent-teams) | claude.com - [Claude Code Tips: Workflow Boosters](https://rfrolov.me/en/blog/claude-code-tips) | rfrolov.me --- ## MCP: Giving Your AI Agent the Right Context Date: 2026-01-11 URL: https://chemaclass.com/blog/mcp-giving-your-ai-agent-the-right-context/ Tags: ai, software-architecture, developer-tools, craftsmanship > MCP connects AI agents to your dev tools, databases, and APIs through a standard protocol. Give your agent the context it actually needs. Modern AI coding assistants are remarkably good at understanding context. Models like Claude Opus with large context windows (~200k tokens) can hold substantial portions of your codebase in mind, reason about architecture, and maintain coherence across long conversations. Not the entire project for large codebases, but enough to work effectively. But understanding isn't the same as access. The AI can reason about your database schema if you paste it. It can suggest changes to files you share. It knows patterns from code you show it. The limitation isn't intelligence. It's reach. That's where MCP comes in. ## What MCP enables Modern AI can understand your codebase when you share it. But understanding and acting are different things. Many IDE-integrated assistants like VS Code Copilot or Cursor already access your project files through their own indexing. So file access itself isn't new. What MCP brings is standardization. Instead of each tool building its own integration, MCP provides a common protocol. You configure a server once, and any MCP-compatible client can use it. It's portable, configurable, and extends beyond just files to databases, APIs, and custom tools. > MCP turns AI from a conversation partner into an active participant in your development environment. With MCP, you give the AI direct access to tools and resources. It can read files, run commands, query databases, fetch documentation. The intelligence was always there. MCP gives it hands. ## What MCP actually is MCP is a protocol, not a product. It's an open standard that defines how AI agents can connect to external data sources and tools. Think of it as a bridge between the AI model and your development environment. The architecture is simple: MCP servers expose capabilities, and AI clients consume them. Claude Desktop and Claude Code officially support MCP, with more tools adopting the protocol as it matures. For example, in Claude Code you can add servers to a `.mcp.json` file at your project root. Claude Code reads this file when you open the project and starts the configured servers automatically: Each server gives the AI different capabilities: - **filesystem**: Read and navigate your project files. The AI can explore your codebase, check existing patterns, and understand your directory structure before suggesting changes. - **github**: Access issues, pull requests, and repository metadata. Ask the AI to summarize open issues, check PR comments, or understand what your team is working on. - **postgres**: Query your database directly. The AI can inspect your schema, run read queries, and understand your data model without you copying table definitions. Different tools, same protocol. You configure once, and any MCP-compatible client can use these servers. ## Where MCP shines ### Working with your codebase The most immediate benefit is filesystem access. The AI can navigate your project, read source files, understand your directory structure. When it suggests code, it can check existing patterns first. Git integration takes this further. The AI can see your commit history, understand what changed recently, and suggest modifications that align with how your codebase evolves. Database schema access means the AI understands your data model. No more explaining table relationships or column types. It sees the structure and generates queries that actually work. ### Documentation and knowledge Connect your internal documentation and the AI becomes aware of your team's decisions. API specifications, architecture documents, coding guidelines. All available as context. This is where MCP starts feeling different. The AI isn't just generating generic code anymore. It's generating code that fits your project. > The best AI assistance comes from understanding not just what you're building, but how your team builds it. ### External integrations GitHub integration means the AI can read issues, understand PR discussions, and see the broader context of what your team is working on. Slack or other communication tools can provide even more context about ongoing decisions. Custom integrations let you connect internal tools specific to your workflow. The protocol is extensible by design. ## Using MCP effectively MCP amplifies whatever it connects to. If your documentation is outdated, the AI will use outdated information. If your codebase is messy, the AI will learn messy patterns. This is the mirror effect I mentioned in [AI gives you speed, not quality](/blog/ai-gives-you-speed-not-quality). The AI reflects the context you give it. Good context produces useful output. Bad context produces confident-sounding garbage. > Giving AI access to your codebase doesn't replace your responsibility to maintain it. It makes good hygiene more valuable. A few practices that help: - **Connect only what the AI needs.** More context isn't always better. Focused context is better. - **Keep your documentation current.** If the AI reads your docs, those docs matter more than before. - **Review your MCP configuration periodically.** As your project evolves, so should your context setup. - **Start small.** One or two servers. See what works. Expand from there. Security matters too. Be intentional about what you expose. MCP servers can access sensitive information. Treat them like any other access control decision. ## What comes next MCP is the foundation. But the ecosystem is building on top of it. **Agentic workflows.** Tools like Claude Code and Cursor now run in "agent mode" where the AI autonomously plans and executes multi-step tasks. It reads files, makes changes, runs tests, fixes errors. MCP servers are the hands. The agent loop is the brain deciding what to do next. **Skills and custom commands.** Claude Code introduced skills. Custom slash commands that chain MCP tools into reusable workflows. `/deploy`, `/test`, `/review`. You define them once, and they become part of your development toolkit. **A2A Protocol.** Google's Agent-to-Agent protocol. While MCP connects AI to tools, A2A connects AI agents to each other. Multiple specialized agents collaborating on complex tasks. One agent writes code, another reviews it, a third runs tests. The pattern is clear: AI is moving from assistant to collaborator. From answering questions to executing workflows. MCP gave AI access to your environment. What's next is AI that knows how to use that access autonomously. > The question is shifting from "what can AI access?" to "what should AI decide on its own?" Human judgment doesn't disappear. It moves upstream. Instead of reviewing every line the AI writes, we design the context and boundaries that shape what it produces. That's still our job. And it's a job worth doing well. --- ## How Bitcoin Works Date: 2025-12-22 URL: https://chemaclass.com/blog/how-bitcoin-works/ Tags: bitcoin, cryptography, tutorial > Transactions, blocks, mining, the UTXO model, and Lightning Network: how Bitcoin actually works under the hood, explained in plain terms. This post explains how Bitcoin works under the hood. If you're looking for why Bitcoin matters, start with [Bitcoin Fundamentals](/blog/bitcoin-fundamentals/). *For the technically curious.* {{ youtube(id="bBC-nXj3Ng4") }} ## The Blockchain ### The Double-Spend Problem Digital money has a fundamental problem: how do you prevent someone from copying their coins and spending them twice? Traditional systems solve this with a central authority (banks, PayPal) that tracks who owns what. Bitcoin's breakthrough was solving this without any central party. The solution: a shared ledger that everyone can verify but no one controls. ### How It Works Bitcoin uses a blockchain: a chain of blocks where each block contains transactions and links to the previous block through cryptographic hashes. A **hash function** takes any input and produces a fixed-size fingerprint. Change one bit of input, and the output changes completely. This makes tampering obvious. Bitcoin uses SHA-256, which produces a 256-bit output. Each block contains: - A list of transactions - A hash of the previous block header - A proof-of-work solution (more below) Before transactions get into a block, they wait in the mempool. Miners pick transactions from this pool, prioritizing those with higher fees. Watch this in real-time at [mempool.space](https://mempool.space/). Every node keeps a complete copy of the blockchain. No single server to hack, no central database to corrupt. To change history, you'd need to rewrite blocks on the majority of nodes worldwide. {% deep_dive(title="Block Structure") %} A block has two parts: the **header** (80 bytes) and the **body** (transactions). The header contains: - **Version**: Protocol version - **Previous block hash**: Links to the chain - **Merkle root**: Hash of all transactions in the block - **Timestamp**: When the block was created - **Difficulty target**: How hard the puzzle was - **Nonce**: The solution miners found **Merkle trees** organize transactions efficiently. Each transaction is hashed, then pairs of hashes are combined and hashed again, building up to a single root hash. This allows proving a transaction exists in a block without downloading all transactions. Useful for lightweight wallets. Block weight is measured in virtual bytes (vB). The limit is 4 million weight units, roughly 1-1.5 MB of data per block. {% end %} ## Transactions & Cryptography ### The UTXO Model Bitcoin doesn't use accounts with balances. Instead, it tracks **Unspent Transaction Outputs (UTXOs)**. Think of them as digital coins of varying sizes. When you receive bitcoin, you get a UTXO. When you spend, you consume entire UTXOs as inputs and create new ones as outputs. If you have a 1 BTC UTXO and want to send 0.3 BTC, you spend the whole UTXO and create two outputs: 0.3 BTC to the recipient and ~0.7 BTC back to yourself (minus fees). Your "balance" is the sum of all UTXOs you can spend. ### Public-Key Cryptography Bitcoin transactions use public-key cryptography: - **Private key**: A secret 256-bit number. This proves ownership. - **Public key**: Derived mathematically from the private key. Shared publicly. When you send bitcoin, you sign the transaction with your private key. This signature proves you own the UTXOs being spent without revealing the private key. Anyone can verify the signature using your public key. ### Programmable Money Bitcoin isn't just digital cash. It has its own programming language called **Script**. Every transaction includes a small program that defines the conditions for spending. Most transactions use simple scripts: "whoever can prove they own this public key can spend these coins." But Script enables much more: multi-signature wallets requiring multiple keys, time-locked transactions that can't be spent until a certain date, and complex conditions combining multiple requirements. This makes Bitcoin programmable money. For a deeper dive into Script and address types, see [Programmable Money](/blog/programmable-money/). {% deep_dive(title="Elliptic Curve Cryptography") %} Bitcoin uses **ECDSA** (Elliptic Curve Digital Signature Algorithm) with the **secp256k1** curve. This curve was chosen for efficiency and because it wasn't designed by any government agency (unlike NIST curves), reducing backdoor concerns. A private key is a random 256-bit integer. The public key is derived by multiplying this number by a generator point on the curve. Easy to compute forward, practically impossible to reverse. **Transaction signing** involves: 1. Hashing the transaction data 2. Creating a signature using the private key 3. Including the signature and public key in the transaction **SIGHASH flags** control what parts of a transaction the signature covers: - `SIGHASH_ALL`: Signs all inputs and outputs (most common) - `SIGHASH_NONE`: Signs inputs only - `SIGHASH_SINGLE`: Signs one specific output - These can be combined with `ANYONECANPAY` for advanced use cases {% end %} ## Mining & Consensus How does a decentralized network agree on which transactions are valid? Through proof-of-work mining. ### The Puzzle Miners race to find a number (the **nonce**) that, when combined with the block header and hashed, produces a result below a target value. It's like rolling dice until you get a number under 100, except with 2^256 possible outcomes. The work is: - **Hard to find**: Requires trillions of guesses - **Easy to verify**: One hash check proves the solution This asymmetry is key. Anyone can verify a block instantly, but creating one requires real computational work. ### Why It Matters Mining serves three purposes: 1. **Secures the network**: Rewriting history means redoing all hash work 2. **Issues new coins**: Following a predictable schedule (halving every 210,000 blocks) 3. **Processes transactions**: Including them in the permanent record Every 2016 blocks (~2 weeks), the network adjusts difficulty to maintain ~10 minute block times. More hashpower joins? Puzzles get harder. Hashpower leaves? Puzzles get easier. Explore mining pools and hashrate at [mempool.space/mining](https://mempool.space/mining). {% deep_dive(title="Difficulty and Game Theory") %} **Difficulty calculation**: The target is a 256-bit number. A valid block hash must be below this target. Lower target = harder puzzle. The network adjusts every 2016 blocks based on how long those blocks actually took vs. the expected 20,160 minutes. {{ youtube(id="S9JGmA5_unY") }} **Hashrate and security**: Bitcoin's security comes from the cost to rewrite history. With ~500 EH/s (exahashes per second) of hashrate, attacking the network would require controlling majority hashpower. That means billions in hardware and electricity, plus the attack would crash the asset's value. **Economic incentives**: Miners spend real resources (electricity, hardware). They only profit if they play by the rules. A miner who creates invalid blocks wastes their work because nodes reject invalid blocks. This aligns individual profit motive with network security. **51% attacks**: If an attacker controlled majority hashrate, they could theoretically double-spend by mining an alternative chain. But the economics make this irrational for large values: the attack destroys the value of what you're stealing. {% end %} ## Addresses & Wallets Bitcoin addresses are derived from public keys. Different formats have evolved: - **P2PKH**: Legacy addresses starting with "1" - **P2SH**: Script addresses starting with "3" - **P2WPKH**: Native SegWit addresses starting with "bc1q" - **P2TR**: Taproot addresses starting with "bc1p" For technical details on each type, see [Programmable Money](/blog/programmable-money/#common-bitcoin-address-types). ### Wallets A wallet manages your keys and constructs transactions. It doesn't hold your coins. Coins exist on the blockchain. The wallet holds keys that prove you can spend them. **Hot wallets** connect to the internet. Convenient for daily use, more vulnerable. Examples: phone apps, browser extensions. **Cold wallets** stay offline. More secure for savings. Examples: hardware wallets (Ledger, Trezor), paper wallets. ### HD Wallets and Seed Phrases Modern wallets are **Hierarchical Deterministic (HD)**. One master seed generates unlimited keys in a tree structure. Back up the seed once, recover everything. **BIP-39** defines the 12 or 24-word seed phrase most wallets use. These words encode entropy that derives all your keys. Lose the phrase, lose access. Anyone with the phrase controls the funds. > Never store seed phrases digitally. Write them down. Store securely offline. How big is the BIP-39 keyspace, really? I built [seed-hunter](https://github.com/Chemaclass/seed-hunter), an open-source educational Go CLI that tries to brute-force a 12-word seed against the real Bitcoin network. It logs every attempt and shows live progress with ETAs spanning 10²⁹ to 10³⁹ years. A burglar checking one trillion seed phrases per second since the Big Bang would have completed 0.000_000_008% of the search by now. The point isn't to break Bitcoin, it's to make the math viscerally obvious: thermodynamics, not just computation, forbids the attack. ## The Network Bitcoin is a peer-to-peer network. No central servers. Nodes connect to each other, share transactions and blocks, and enforce rules independently. ### Node Types **Full nodes** download and validate every block and transaction. They enforce all consensus rules and don't trust anyone. Running a full node means you verify everything yourself. **SPV (light) clients** only download block headers. They trust that miners validated the transactions. Less security, but works on phones and low-power devices. **Mining nodes** are full nodes that also compete to create new blocks. ### How Transactions Propagate When you broadcast a transaction: 1. Your wallet sends it to connected nodes 2. Each node validates and forwards to its peers 3. Within seconds, the transaction reaches most of the network 4. Miners include it in their candidate blocks Blocks propagate similarly. When a miner finds a valid block, it spreads across the network in seconds. {% deep_dive(title="Network Architecture") %} **Peer discovery**: Nodes find each other through DNS seeds (hardcoded addresses that return active node IPs) and by sharing peer addresses with connected nodes. **Gossip protocol**: Information spreads through "inv" (inventory) messages. A node announces it has something new, peers request it if interested. This prevents bandwidth waste from duplicate data. **Compact blocks** (BIP-152) speed up block propagation. Since nodes already have most transactions in their mempool, blocks can be transmitted as just the header plus short transaction IDs. {% end %} ## Security & Confirmations ### Why Confirmations Matter When a transaction is included in a block, it has 1 confirmation. Each subsequent block adds another confirmation. More confirmations = harder to reverse. To undo a confirmed transaction, an attacker would need to mine an alternative chain faster than the honest network. Each block makes this exponentially harder. **General guidelines:** - 0 confirmations: Transaction broadcast but not yet in a block. Can be double-spent. - 1 confirmation: In a block. Reversal requires significant hashpower. - 6 confirmations: Standard for large amounts. Reversal practically impossible. {% deep_dive(title="Confirmation Security") %} Satoshi's whitepaper includes the probability calculation. With an attacker controlling fraction `q` of hashpower: - If `q "Don't trust, verify." Anyone can run a node and verify every transaction, every block, every rule. You don't need to trust banks, governments, or even other Bitcoin users. The math proves itself. ## Scaling: The Lightning Network Bitcoin's base layer processes about 7 transactions per second. That's by design: keeping things decentralized requires blocks small enough for anyone to verify. But this limits how many transactions it can handle. The Lightning Network solves this with a second layer built on top of Bitcoin. It enables: - **Instant payments**: No waiting for block confirmations - **Near-zero fees**: Fractions of a cent - **High capacity**: Millions of transactions per second Lightning works by opening "payment channels" between parties. Transactions within a channel happen off-chain, instantly. Only the opening and closing of channels require on-chain transactions. You can visualize the network topology and statistics at [mempool.space/lightning](https://mempool.space/lightning). > Bitcoin's base layer provides security and final settlement. Lightning provides speed and scale. Different tools for different jobs. If you want to run your own Lightning node and take full control of your payments, I wrote a guide on how to [Run your LN node on a Raspberry Pi](/blog/run-your-ln-node/). {% deep_dive(title="How Lightning Works") %} Payment channels use **2-of-2 multisig** addresses. Both parties must sign to move funds. This creates a shared account that neither can steal from. **HTLCs (Hash Time-Locked Contracts)** enable multi-hop payments. The mechanism: 1. Alice wants to pay Carol through Bob 2. Carol generates a secret and gives Alice the hash 3. Alice creates an HTLC: "Bob gets paid if he reveals the secret within 24 hours" 4. Bob creates a similar HTLC with Carol 5. Carol reveals the secret to Bob, claiming payment 6. Bob uses the same secret to claim from Alice If anyone fails to cooperate, the timelock expires and funds return. The secret travels backward, payments travel forward. **Watchtowers** monitor the blockchain for cheating attempts. If your counterparty tries to broadcast an old channel state, the watchtower can penalize them, even while you're offline. {% end %} ## The Bigger Picture What makes Bitcoin remarkable isn't any single component. It's how they fit together into a self-reinforcing system. Cryptography proves ownership without trusted authorities. Proof-of-work makes history expensive to rewrite. Economic incentives turn individual greed into collective security. Decentralization removes single points of failure. And the fixed supply creates digital scarcity for the first time in history. Every piece supports every other piece. Remove one, and the system weakens. Together, they create something that has never existed before: money that can't be inflated, transactions that can't be censored, and property that can't be confiscated. > No banks. No governments. No trusted third parties. Just math, code, and a global network of nodes all enforcing the same rules. Whether that matters to you depends on where you live and how much you trust your institutions. But the option exists now. And no one can take it away. {% deep_dive(title="Rabbit Holes") %} Bitcoin's technical depth goes far beyond what fits in one post. Here are topics worth exploring if you want to go deeper: **[SegWit](https://bitcoinops.org/en/topics/segregated-witness/)** (Segregated Witness) was Bitcoin's 2017 upgrade that moved signature data outside the main transaction structure. This fixed transaction malleability (a bug that prevented Lightning), introduced block weight for more efficient space usage, and did it all while staying backwards-compatible with old nodes. **[Taproot & Schnorr](https://bitcoinops.org/en/topics/taproot/)** landed in 2021, upgrading Bitcoin's cryptography. Schnorr signatures are smaller and enable aggregation (multiple signatures become one). Taproot makes complex spending conditions look identical to simple payments on-chain, improving both privacy and efficiency. **[Soft forks vs hard forks](https://bitcoin.stackexchange.com/questions/30817/what-is-a-soft-fork)**: How does Bitcoin upgrade without a central authority? Soft forks add new rules that old nodes still accept. Hard forks change rules in ways old nodes reject. Understanding this distinction explains why Bitcoin evolves slowly and why contentious changes are rare. **[Fee mechanics](https://mempool.space/docs/faq#what-is-rbf)**: The fee market is more nuanced than "pay more, confirm faster." Replace-By-Fee (RBF) lets you bump a stuck transaction's fee. Child-Pays-For-Parent (CPFP) lets recipients accelerate incoming payments by spending them with high fees. **[Timelocks](https://bitcoinops.org/en/topics/timelocks/)**: Bitcoin can lock funds until conditions are met. `CLTV` (CheckLockTimeVerify) locks until a specific block height or timestamp. `CSV` (CheckSequenceVerify) locks for a relative time after confirmation. These primitives enable Lightning channels, inheritance schemes, and atomic swaps. **[Coinbase transactions](https://learnmeabitcoin.com/technical/mining/coinbase-transaction/)**: The only way new bitcoin enters circulation. Every block begins with a special transaction that pays the miner the block reward plus all fees. These newly minted coins can't be spent for 100 blocks, a rule that protects against chain reorganizations. The deeper you go, the more you find. {% end %} --- ## Bitcoin Fundamentals Date: 2025-11-21 URL: https://chemaclass.com/blog/bitcoin-fundamentals/ Tags: bitcoin, economics, privacy, philosophy > 21 million cap, no central authority, permissionless and censorship-resistant. Bitcoin is digital money you truly own. No bank required. What would you do if your bank account was frozen tomorrow? No warning, no explanation, no access to your own money. This isn't hypothetical. In 2022, Canada froze bank accounts of people who donated to a protest. In 2015, Greeks could only withdraw €60 per day from ATMs. In Argentina, Turkey, and Lebanon, people watched their savings lose half their value in months. Bitcoin exists because these things happen. Understanding it requires going back to basics: what is money, why does it matter, and how does Bitcoin fit into that picture. *No technical background required. Just curiosity.* ## A Brief History of Money Money is a social agreement. A piece of paper, a gold coin, or a number on a screen has value because we all agree it does. This agreement is what makes trade possible. Throughout history, money has evolved: 1. **Direct trade**: Exchanging goods for goods. "I'll give you my fish for your bread." 2. **Things used as money**: Shells, salt, cattle. Valuable because they were useful or hard to find. 3. **Precious metals**: Gold and silver. Hard to find, long-lasting, easy to divide and carry. 4. **Paper money backed by gold**: Receipts representing gold stored in vaults. 5. **Government money**: Paper backed by nothing but a government's promise. Why does it work? Because governments require you to pay taxes in their currency. This forces everyone to use it. > Money is a way to store and transfer value. The better it performs these functions, the better it serves as money. What makes good money? These properties: - **Hard to create**: Cannot be easily made or faked - **Long-lasting**: Doesn't break down over time - **Divisible**: Can be broken into smaller pieces - **Easy to move**: Simple to carry and send - **Easy to verify**: Simple to check if it's real Gold does well on most of these. Paper money is easy to move and divide but fails on being hard to create. Governments can print as much as they want. Bitcoin, as we'll see, does well on all of them. ## What is Bitcoin? Bitcoin is digital money that works without banks, governments, or any central authority. It was created in 2009 by someone (or some group) using the pseudonym [Satoshi Nakamoto](https://en.wikipedia.org/wiki/Satoshi_Nakamoto). No one knows who this person really is. The first Bitcoin block (the [Genesis Block](https://en.bitcoin.it/wiki/Genesis_block)) contains a hidden message: *"The Times 03/Jan/2009 Chancellor on brink of second bailout for banks."* This headline from The Times newspaper referenced the 2008 financial crisis. It wasn't random. It was a timestamp and a statement of purpose. Bitcoin was created as a response to bank bailouts and monetary manipulation. Bitcoin builds on decades of work by cryptographers and privacy activists. If you're curious about the people and ideas that led to Bitcoin, I wrote about [The Cypherpunks](/blog/the-cypherpunks/) and their vision for digital privacy. At its core, Bitcoin is: - **A protocol**: A set of rules that computers follow to agree on who owns what - **A network**: Thousands of computers worldwide running the Bitcoin software - **A currency**: Units of account called bitcoins (BTC), divisible to 8 decimal places There's no company behind Bitcoin. No CEO, no headquarters, no customer support. It's open-source software that anyone can run, inspect, or contribute to. {{ youtube(id="d7ID3fKAFQM") }} ## Sound Money ### Scarcity There will only ever be 21 million bitcoins. This is enforced by the protocol's code, verified by every node on the network. No government, no committee, no emergency meeting can change this. Compare this to government money. Central banks can (and do) create money whenever they want. The U.S. dollar has lost over 95% of its buying power since 1913. The Euro, the Pound, the Yen: all follow the same pattern of slowly losing value. > In a world of infinite money printing, a mathematically enforced hard cap is revolutionary. Bitcoin is often called "digital gold" because it shares gold's scarcity while being easier to store, divide, and transfer. You can send a billion dollars worth of Bitcoin anywhere in the world in minutes, for a few dollars in fees. Try doing that with gold bars. ### Inflation Protection When governments print money, the value of existing money decreases. This is inflation. Your savings buy less over time, even while sitting untouched in your bank account. Inflation is often called a "hidden tax" because it transfers wealth from savers to those who receive the new money first (usually governments and banks). I wrote more about this in [Understanding Taxes](/blog/understanding-taxes/). Bitcoin's supply schedule is fixed and predictable. New bitcoins are created through mining at a rate that halves roughly every four years. By around 2140, all 21 million will have been created. No surprises, no government decisions to print more. ## Freedom & Sovereignty ### Self-custody With Bitcoin, you can hold your own money. Not a promise from a bank, not a balance on someone else's books. Actual ownership, secured by cryptographic keys that only you control. > "Not your keys, not your coins." This phrase captures a fundamental truth. When you deposit money in a bank, you don't own that money anymore. You own a claim against the bank. If the bank freezes your account, goes bankrupt, or decides you violated their terms of service, your access disappears. With Bitcoin, there's no freeze button. No account to close. No terms of service to violate. You become your own bank. ### Permissionless & Borderless Bitcoin doesn't care about borders, banking hours, or your credit score. You can send money to anyone with an internet connection, anywhere in the world, at any time. Traditional banking: - Hours: Monday-Friday, 9-5 (maybe) - International transfers: 3-5 business days - Fees: Percentage of transfer + fixed fees - Requirements: ID, proof of address, account in good standing Bitcoin: - Hours: 24/7/365 - Global transfers: ~10 minutes to an hour - Fees: Based on data size, not amount sent - Requirements: A Bitcoin address (free, instant, no ID) ### Censorship Resistance No central authority controls Bitcoin. No single entity can stop a transaction or reverse a payment. Once confirmed, it's final. This matters for people living under oppressive governments, facing political pressure, or simply wanting financial privacy. It matters for donations to controversial causes, for journalists protecting sources, for anyone who values financial freedom. > Financial freedom isn't just about being rich. It's about having control over your own money, regardless of who you are or where you live. ### Real Stories These aren't edge cases: WikiLeaks 2010 Payment blocked Cyprus 2013 Bank bail-ins Greece 2015 Capital controls Venezuela 2016 1,000,000% inflation Lebanon 2019 Banking collapse Hong Kong 2019 Protest funding Belarus 2020 Regime resistance Nigeria 2021 Ban failed Turkey 2021 Lira devaluation El Salvador 2021 Legal tender Afghanistan 2021 Women's savings Ukraine 2022 $100M+ in donations Canada 2022 Accounts frozen Russia 2022 Sanctions escape Argentina 2023-25 Inflation slashed Remittances 2023 Cheaper transfers Bitcoin ETFs 2024 Institutional legitimacy Gaza 2024 Humanitarian lifeline US Reserve 2025 National strategy Venezuela 2025 Nobel resistance In December 2010, WikiLeaks published classified U.S. diplomatic cables. Within days, Visa, Mastercard, PayPal, and Bank of America cut off all payment processing. WikiLeaks lost 95% of its revenue overnight. In 2011, they started accepting Bitcoin. It was one of the first major use cases for the cryptocurrency. The financial blockade meant to silence them instead proved Bitcoin's value as censorship-resistant money. Read full article → In March 2013, Cyprus banks took 47.5% of all deposits over €100,000 to bail themselves out. No consent, no warning. Money in the bank was simply confiscated to save the banking system. Bitcoin's price doubled in the weeks following. The Cyprus bail-in was a wake-up call: your bank balance is an IOU, and when banks fail, you're the one who pays. Read full article → In June 2015, Greece closed its banks for three weeks. ATM withdrawals were capped at €60 per day. Citizens couldn't access their own money. The debt crisis showed Europeans that bank deposits aren't as safe as they assumed. Bitcoin interest spiked in Greece during the crisis. It was an early warning: even in "stable" countries, your access to money can be switched off overnight. Read full article → Between 2016 and 2019, inflation reached 53,000,000%. Salaries became worthless within days. People couldn't buy food, medicine, or basic goods. Those who converted savings to Bitcoin before the collapse preserved their wealth. Those who trusted the banking system lost everything. Bitcoin became a lifeline. Not for speculation, but for survival. Read full article → In 2019, Lebanese banks began freezing deposits. By 2020, people couldn't access their own savings. The lira lost 90% of its value. ATM withdrawals were capped at tiny amounts. It wasn't a temporary measure. Banks simply didn't have the money. Those who had converted to Bitcoin before the collapse could still access their wealth. Those who trusted the banks discovered that "your money" wasn't really yours. Read full article → During the 2019-2020 pro-democracy protests, Hong Kong activists faced financial surveillance. Banks could freeze accounts of known protesters. Donations through traditional channels could be traced. Bitcoin offered a way to fund the movement without leaving a trail for authorities. Protesters used crypto to receive international support while protecting their identities. Financial privacy became a tool of resistance. Read full article → After the disputed 2020 election, Belarus erupted in protests. The Lukashenko regime responded with violence and financial repression. Bank accounts of activists, journalists, and NGOs were frozen. The KGB monitored all transfers. A solidarity fund called BYSOL raised over $2 million in Bitcoin and distributed it directly to protesters who lost jobs or faced persecution. The only payment method authorities couldn't control. Read full article → The Central Bank banned crypto exchanges in February 2021 and ordered banks to close accounts of anyone dealing in cryptocurrency. The goal was to stop Bitcoin adoption. It backfired. Peer-to-peer trading surged 27% in the months following the ban. Nigerians simply moved to decentralized platforms. The naira continued losing value while Bitcoin kept working. You can't ban math. Read full article → The Turkish lira has lost over 80% of its value against the dollar since 2018. Every currency crisis triggers a spike in Bitcoin trading. In 2021, Turkey banned crypto payments, but trading volumes only increased. The government can't stop people from protecting their savings. When the lira crashes, Bitcoin search trends surge. Turks aren't speculating. They're surviving. Read full article → In September 2021, El Salvador became the first country to make Bitcoin legal tender. President Bukele's government installed Bitcoin ATMs nationwide, and even started mining BTC using geothermal energy from volcanoes. Critics predicted disaster. Instead, tourism increased, remittance costs dropped, and the country gained global attention. A small nation became a Bitcoin laboratory. Read full article → When the Taliban took control in August 2021, banks froze. International transfers stopped. Women, banned from working, lost access to income. But some Afghan women had learned about Bitcoin before the collapse. They could receive payments from abroad, store value the regime couldn't seize, and maintain financial independence. In a country where women can't open bank accounts, Bitcoin became a tool of quiet resistance. Read full article → When Russia invaded, traditional aid was too slow. Banks were overwhelmed, wire transfers took days. But within hours of posting Bitcoin addresses on Twitter, donations poured in from around the world. By March 2022, Ukraine received over $100 million in crypto. Funds went directly to bulletproof vests, medical supplies, and communication equipment. No bureaucracy, no intermediaries, no delays. Read full article → In February 2022, the government invoked the Emergencies Act to freeze bank accounts of people who donated to trucker protests. No court order needed. Over 200 accounts were frozen overnight. But Bitcoin donations kept flowing. Organizers distributed 14+ BTC directly to protesters. The government couldn't touch those funds. In 2024, a court ruled the freezes unconstitutional. The lesson: custodial money can be weaponized. Read full article → After Russia invaded Ukraine in 2022, Western sanctions cut Russian banks from SWIFT. Suddenly, Russians abroad couldn't access their money. Many turned to crypto, not to evade sanctions, but to survive. Meanwhile, Ukrainians used Bitcoin to receive donations and preserve savings. The same technology served people on both sides of a conflict, based on their individual needs. Bitcoin doesn't pick sides. Read full article → Argentina suffered 211% inflation in 2023 under decades of big-government policies. Then Javier Milei took office. He halved ministries, cut 40,000 government jobs, and ended monetary financing. Result: inflation dropped to 117% in 2024, then 31% by end of 2025, the lowest in seven years. GDP grew 7.6% in Q2 2025, the strongest in two decades. Poverty fell from 57% to 32%. Smaller government, sound money principles. Bitcoin adoption remains high, Argentines learned not to trust any currency they can't verify themselves. Read full article → Migrant workers send $700 billion home every year. Traditional services like Western Union take 6-10% in fees. For a worker sending $200, that's $20 gone. Money their family desperately needs. Bitcoin and Lightning Network transfer value across borders for cents, settling in minutes instead of days. Companies like Bitso processed $8 billion in crypto remittances in 2023. Cheaper transfers mean more food on the table. Read full article → In January 2024, the SEC approved Bitcoin ETFs for the first time. Within months, institutional investment surged 400%. By end of 2024, professional investors held $27.4 billion in Bitcoin ETFs, over 26% of total AUM. BlackRock's IBIT alone reached $50 billion. Bitcoin was no longer just for early adopters. Wall Street called it "year zero of institutional adoption." The asset that banks once dismissed now sits in pension funds. Read full article → When cash imports into Gaza were blocked in 2024, banking infrastructure collapsed. Traditional transfers charged 30%+ fees, if they worked at all. Bitcoin became a lifeline. One volunteer sent $123,000 in BTC that bought food, water, and built shelters for displaced families. A taxi driver named Yusef received $48k in Bitcoin donations and built 100 tents. When banks fail, Bitcoin still works. No permission needed. Read full article → On March 6, 2025, President Trump signed an executive order establishing a Strategic Bitcoin Reserve, a "digital Fort Knox." The reserve holds ~200,000 BTC from seized assets, with a policy never to sell. The U.S. had lost $17 billion selling seized bitcoin too early. Now it's holding. Pakistan announced its own reserve weeks later. Nations that once dismissed Bitcoin now compete to accumulate it. Read full article → María Corina Machado won the 2025 Nobel Peace Prize for fighting Venezuela's dictatorship. Her campaign runs on Bitcoin because "bank wires get blocked, but bitcoin donations cannot be seized." With the bolívar down 98% in a decade and 8,000%+ inflation, Bitcoin became "a vital means of resistance." She promised a democratic Venezuela would embrace Bitcoin in its national reserves. Freedom money for a freedom fighter. Read full article → ## Common Objections - **"It's used for crime."** So is cash. The difference: Bitcoin leaves a permanent, traceable record. The blockchain is a [forensic tool](https://www.chainalysis.com/blog/2025-crypto-crime-report-introduction/). Most criminals prefer dollars. - **"It's too volatile."** True in the short term. Zoom out: Bitcoin has been the [best-performing asset of the last decade](https://www.coingecko.com/research/publications/bitcoin-versus-traditional-assets-price-returns). Volatility decreases as adoption grows. Don't invest money you need next month. - **"It wastes energy."** Bitcoin mining uses electricity to secure a trillion-dollar network. Much of it comes from [stranded energy](https://k33.com/research/archive/articles/bitcoin-mining-using-stranded-natural-gas-is-the-most-cost-effective-way-to) (gas flares, excess hydro) that would otherwise be wasted. The real question: is financial sovereignty worth the energy cost? Air conditioning uses more. - **"It's too late to buy."** People said this at $100, $1,000, $10,000, and $100,000. If Bitcoin achieves even a fraction of [gold's market cap](https://8marketcap.com/), there's still room to grow. ## Honest Caveats Bitcoin isn't perfect. Things to be aware of: - **Self-custody requires responsibility.** Lose your seed phrase, lose your funds. No customer support. - **Irreversibility.** No chargebacks. Send to the wrong address? Gone. - **Learning curve.** Wallets, keys, fees, P2P trading. The more you learn, the more sovereignty you gain. KYC exchanges are easier but come with regulatory strings attached. - **Privacy takes effort.** The blockchain is transparent, not anonymous. True privacy requires learning how to use Bitcoin properly. - **Scaling tradeoffs.** Base layer is slow by design. Lightning adds speed but also complexity. None of these are dealbreakers. They're tradeoffs. The more you learn, the fewer limitations you face. ## Bitcoin Today This isn't just theory anymore. ### Institutional adoption - **US Bitcoin ETFs** approved in 2024, bringing billions in institutional money ([source](https://www.cnbc.com/2024/01/10/sec-approves-rule-changes-that-pave-the-way-for-bitcoin-etfs.html)) - **Strategy** holds 660.000+ BTC as corporate treasury, inspiring others ([source](https://www.strategy.com/purchases)) - **Major banks** now offer Bitcoin custody and trading services to clients - **Pension funds** and asset managers are adding Bitcoin to portfolios ### Global adoption - **Central African Republic** adopted Bitcoin as legal tender in 2022 ([source](https://www.cnbc.com/2022/04/28/central-african-republic-adopts-bitcoin-as-legal-tender.html)) - **Switzerland** allows tax payments in Bitcoin in Canton Zug since 2021 ([source](https://zg.ch/de/steuern-finanzen/steuern/steuerbezug/taxpaymentswithcryptocurrencies)) - **Emerging markets** lead in grassroots adoption: Vietnam, Philippines, Nigeria ### Real-world usage - **Square** accepts Bitcoin payments since Nov. 2025 for 4M+ merchants ([source](https://squareup.com/us/en/press/block-to-roll-out-bitcoin-payments-on-square)) - **Lightning Network** (LN) processes millions of instant payments monthly ([source](https://lightning.network/)) - **Merchants worldwide** accept Bitcoin, from small shops to major retailers ([source](https://btcmap.org/)) You can dismiss it, or you can understand it. --- ## Getting Started Bitcoin is money that no one controls and everyone can verify. It's scarce in a world of infinite money printing. It's permissionless in a world of financial gatekeepers. It's programmable in ways we're only beginning to explore. Understanding Bitcoin doesn't require believing it will change the world. It requires understanding what money is, how it evolved, and why these properties matter. From there, you can form your own conclusions. ### Want to try? The best way to understand Bitcoin is to use it: 1. **Start small**: Buy a small amount on a trusted Bitcoin-only platform like: - [21bitcoin](https://21bitcoin.app/) or [Relai](https://relai.app/): Simple apps for automatic Bitcoin savings - [HodlHodl](https://hodlhodl.com/): Peer-to-peer trading, non-custodial 2. **Move it to your own wallet**: Download a mobile wallet and transfer your Bitcoin there. Feel what self-custody means. Some wallets like [BlueWallet](https://bluewallet.io/), [Nunchuk](https://nunchuk.io/). 3. **Send a transaction**: Send some sats to a friend. Watch it confirm in ~10 minutes. Get curious looking at your transaction in the [mempool](https://mempool.space/). 4. **Try Lightning**: Send an instant, near-free payment. This is the future of everyday transactions. Some LN wallets like [Alby Go](https://getalby.com/alby-go), [Muun](https://muun.com/). You don't have to go all in. Start small and keep learning, one step at a time. {{ youtube(id="Pef22g53zsg") }} **Further reading** - [Bitcoin 101](https://cosmevalera.dev/blog/bitcoin-101/) by Cosme - Another beginner-friendly introduction - [How to Buy Bitcoin Securely](https://cosmevalera.dev/blog/bitcoin-102/) by Cosme - Step-by-step guide --- ## AI Gives You Speed, Not Quality Date: 2025-10-10 URL: https://chemaclass.com/blog/ai-gives-you-speed-not-quality/ Tags: ai, software-architecture, craftsmanship, leadership > AI accelerates your output but doesn't ensure quality. You're responsible for every line you commit. Speed without direction is chaos. I've been using AI coding assistants extensively: ChatGPT, Codex, Claude with Sonnet and Opus. They're incredibly helpful. They give you speed like nothing else. But speed isn't quality. ## The vibe-coding trap AI models are excellent at imitating their surroundings. Give them context, and they'll do whatever it takes to complete the task. This has become known as _"vibe-coding"_: you describe what you want, and the AI produces something that works. Fast. The problem? AI will happily generate messy code if that's what gets the job done. It doesn't care about maintainability. It doesn't think about what happens when requirements change next month. It just produces output. > AI is a mirror that reflects the context you give it. If your codebase is messy, it will generate more mess. If your prompts are vague, it will make assumptions. Without careful guidance, you end up with patches on top of patches. Freshly created legacy code. A codebase where every change feels risky and the team spends more time fighting the code than building features. ## The art of asking Remember Stack Overflow? Google searches that led you to forum threads from 2011 where someone had the exact same problem? Ten years ago, being a developer meant learning how to ask good questions. You'd craft your Stack Overflow post carefully: describe the problem, show what you tried, explain what you expected versus what happened. If your question was vague or lazy, the community would let you know. Sometimes harshly. But that friction taught us something valuable: **the quality of your answer depends on the quality of your question**. The same principle applies to AI. A vague prompt gets a vague response. A well-structured prompt with clear context, constraints, and examples gets something useful. The skill of formulating good questions didn't become obsolete. It became more important. > Learning to prompt AI effectively is the modern equivalent of learning to search Google and ask Stack Overflow. The developers who master this will get better results. Even when AI gives you a fast, impressive-looking answer, **never accept code you don't fully understand**. It's tempting. The response appears in seconds, it looks professional, it might even work. But if you can't explain what it does and why, you're planting a time bomb in your codebase. And when it breaks at 2am, you'll be debugging code you didn't write with no mental model of why it exists. Challenge the output. Ask: _"Can you simplify this?"_ or _"Is there boilerplate here we can remove?"_ AI's default is to add, not to improve. It will generate abstractions, helper functions, and patterns you didn't ask for. It won't refactor unless you tell it to. Push back. This is especially critical with tests. Ask AI to generate tests and you'll often get tests that mirror implementation details rather than behavior. They'll break the moment you refactor, even if the logic stays the same. If you want tests that verify behavior, you need to explicitly say so. AI won't make that choice for you. > Don't be seduced by speed. Sometimes, a fast answer you don't understand is worse than a slow answer you do. ## The human factor AI can write code fast, but it can't understand overall architecture. It doesn't know why certain decisions were made months ago. It can't see the bigger picture of where the product is heading. It only sees what you show it, making local decisions without understanding global implications. That's our job. As I explored in [different beliefs about software quality](/blog/different-beliefs-about-software-quality), teams often have varying standards for what _"good enough"_ means. When you add AI to the mix, maintaining that shared understanding becomes even more critical. The AI doesn't share your team's values. It just generates code. > The discipline to maintain clean architecture, to say _"no"_ to quick hacks, to refactor before things get worse. That's uniquely human. Books like [Clean Code](/readings/clean-code/) and [Clean Architecture](/readings/clean-architecture/) aren't less relevant in the AI age. They're more relevant. They help you spot when AI is heading in the wrong direction. ## Collaboration over automation There's something else AI can't replace: the team. A conversation with a colleague about _"should we extract this into a service?"_ often leads to insights that no AI prompt would surface. That back-and-forth, the pushback, the _"what if we tried this instead"_. That's where real understanding happens. [Extreme Programming Explained](/readings/extreme-programming-explained/) emphasizes practices like pair programming and collective code ownership for good reason. These aren't inefficiencies to be automated away. They're how teams build quality into their process. When you skip the human discussion and just let AI generate solutions, you lose the opportunity to learn, to challenge assumptions, and to grow as a team. ## You own the code When AI writes code and you commit it, review it, approve it, merge it, and deploy it, **it's your code**. You can't blame the AI when something breaks in production. You can't point at Claude or Copilot when the architecture becomes unmaintainable. As I wrote about [the art of testing](/blog/the-art-of-testing/), quality is a choice we make at every step. Every commit is a decision. Every review is an opportunity to catch problems. Every merge is an endorsement of the code's quality. > We are the ultimate responsible party for the code AI writes. The commit, the review, the approval, the merge, the deploy. That's all us. Moving fast in the wrong direction just gets you lost faster. Lines of code appearing on screen isn't progress. The value we bring as developers isn't typing speed. Our value is in understanding where we're going, maintaining discipline over chaos, and ensuring that the code we ship today doesn't become tomorrow's nightmare. Use AI. Embrace the speed. But never forget: **you're the one steering**. If you let go of the wheel, you'll end up in a pile of unmaintainable code faster than you expected. And when that happens, there's no one else to blame. --- ## What Success Means to Me Date: 2025-09-15 URL: https://chemaclass.com/blog/what-success-means-to-me/ Tags: philosophy, career, productivity, leadership > Success is waking up knowing that what you do makes the people around you, and yourself, happier. No complex formula. Just consistency over perfection, and building habits that align with what matters. For the longest time, I thought success was about hitting certain milestones. Getting that promotion. Earning a specific salary. Building something that people would recognize. But I've realized that's not what gets me out of bed in the morning. ## The real measure Success, for me, is straightforward now: **waking up knowing that what I do makes the people around me, and myself, happier**. It took me a while to get here. This definition might not feel simple to everyone, and that's okay. But for me, it clarified everything. No complex formula. No checklist of achievements. > Success is about those small moments when you help a colleague solve a tricky problem, when you share something that makes someone smile, or when you finish the day feeling like you actually added some good to the world. This applies whether you're leading a team or just showing up as yourself. As I wrote about [great leadership](/blog/great-leadership), real leadership starts with your own life and behavior. It's fundamentally about making the people around you better, not just achieving targets. ## Why happiness matters I used to think that focusing on happiness was somehow trivial. Like it wasn't "serious" enough as a goal. But I've learned that making people happy, genuinely happy, is one of the hardest and most rewarding things you can do. ### What does this mean in practice? - Being present when someone needs you - Creating things that solve real problems - Choosing kindness over being right - Finding joy in what you do, even on tough days > When you focus on making others happier, you usually end up happier yourself. It's not zero-sum. It compounds. This connects deeply with [understanding people](/blog/understanding-people) and how they think. When you truly understand that everyone processes the world differently, you become better at creating genuine happiness, not just what you think should make them happy. ## The daily practice ### How does this look in daily life? For me, it's about checking in with myself regularly: "Did what I do today make things better?" Not perfect. Not revolutionary. Just better. Sometimes that's writing code that helps a team work more smoothly. Sometimes it's taking time to really listen to someone. Sometimes it's just being patient when everything feels chaotic. It's not always easy. Some days you miss the mark. But having this simple definition of success makes decisions clearer. When you're wondering whether to take on a project, accept an opportunity, or say no to something, you can ask yourself: "Will this make me and the people around me happier?" ### Consistency over perfectionism Here's something I've learned the hard way: **success is built through consistency, not perfection**. Perfectionism will paralyze you. It whispers that nothing is good enough, that you should wait until conditions are ideal, that one mistake invalidates everything. It's a trap. What actually works? Showing up. Day after day. Building small habits that compound over time. As James Clear explains in [Atomic Habits](/readings/atomic-habits/), real change comes from the compound effect of hundreds of small decisions. You don't need to be perfect. You need to be consistent. > Don't try to make a habit perfect, just repeat it. This means: - Writing a few lines of code every day beats waiting for the perfect architecture - Having a short, genuine conversation beats waiting for the perfect moment - Making small improvements consistently beats waiting for the big breakthrough The goal isn't to never fail. It's to build habits that align with making yourself and others happier, and to keep showing up even when you stumble. > This is where [the process itself becomes the goal](/blog/the-process-itself-is-the-goal). It's not about reaching some final destination of "being successful", it's about building daily habits and practices that align with what actually matters to you. ## Success is personal Your definition of success will probably be different from mine, and that's not just okay, it's necessary. "[Have I always been like this?](/blog/have-you-always-been-like-this)" The answer is no. I certainly wasn't. Our understanding of what matters evolves as we grow. That's part of the journey. If you're feeling stuck or unsure about what you're working toward, try this: **figure out what truly makes you and the people you care about happier**. Not what you think should make you happy. Not what looks impressive from the outside. Just what actually works for you. And be ready to [embrace the change](/blog/embrace-the-change) when your definition shifts, **because it will**. What success means to you today might look different tomorrow. That's not failure. That's growth. --- > At the end of the day, if you wake up knowing that what you do brings more happiness into the world, including your own, you're probably doing something right. That feels like success to me. --- **Thanks** to my friend Toni, for [bringing up](https://x.com/Chemaclass/status/1989652323925377462) this question and inspiring this reflection. --- ## Ship, Show, Ask Date: 2025-04-12 URL: https://chemaclass.com/blog/ship-show-ask/ Tags: agile, code-review, team-management, productivity > Not every change needs the same review. Ship, Show, Ask matches the review process to the risk of the change, so teams keep shipping without losing quality or collaboration. In fast-moving teams, one of the biggest tensions we face is this: How do we keep shipping without compromising quality or collaboration? The traditional approach to pull requests often slows things down. We wait hours, or days, for approvals, even for trivial changes. But the alternative, merging directly, can feel reckless or invisible to the rest of the team. That's where the Ship-Show-Ask strategy comes in. Originally described by [Rouan Wilsenach](https://martinfowler.com/articles/ship-show-ask.html), this model offers a more flexible and thoughtful way to handle code changes. It's not just a branching strategy, it's a shift in how teams collaborate, trust, and take ownership. ## What is Ship, Show, Ask? It's a model that classifies changes based on how much review they require: - **Ship**: Merge directly to main (without a PR) - **Show**: Open a pull request, but merge it immediately - **Ask**: Open a pull request and wait for review The key idea is to use Ask as the default for most work, fall back to Show when the context makes it safe, and avoid Ship (or reserve it for extremely trivial cases, if used at all). ## Why I prefer to Ask and Show Treat every change, even the small ones, as something worth sharing. I always create a branch and open a PR. It provides visibility, builds a shared history, and creates a space for optional or asynchronous feedback. It's [working with the garage door open](/blog/working-with-the-garage-door-open/), applied to code. But not all PRs need to follow the same review process. ### I default to Ask I prefer to wait for a peer review when: - The change involves risky or complex logic - It could impact other developers or teams - It introduces architectural or structural decisions that haven't been agreed on yet - It benefits from shared input or a second pair of eyes That said, **Ask doesn't mean over-engineering the process**. Often, one thoughtful reviewer is enough, especially if they're familiar with the domain. If the change touches a specific area, I'll ask for feedback from the person who owns (or best understands) that part of the code. It doesn't need to involve everyone. > In small teams, requiring two approvals on every PR can quickly become a bottleneck and slow down the delivery of value. The goal is alignment and quality, not ceremony for its own sake. ### I use Show for safe, low-impact changes I might merge immediately when: - Practicing [pair programming](/blog/effective-pair-programming/) (the review already happened live) - Fixing typos or broken links - Updating documentation or changelogs - Refactoring within a module I own - Adding tests for existing behavior - Making non-functional tweaks (formatting, logs, comments) - Applying UI or style adjustments with no logic change The key principle: **Show is optional, never mandatory**. I choose Show only if the change is low-risk and fits within team expectations. When I use Show, I own the outcome. The responsibility is mine. ## Why this approach works for me This model helps me: - Ship faster without compromising quality - Work with greater autonomy and ownership - Avoid bottlenecks, especially in small or async teams - Foster a mindset of trust, accountability, and thoughtful decision-making > It shifts the goal from getting approval to sharing intent and owning the outcome. ## What makes a good "Show"? A Show PR might be the right choice when: - The change is trivial and within my area of responsibility - No one is available to review, and waiting would block progress - The PR includes clear context and reasoning - I'm open to post-merge feedback - I'm ready to follow up with adjustments if needed ## Tips for making it work Some practical advice from experience: - Clarify team expectations for when to use Show vs Ask - Always provide context in your PR, even if merging immediately - Write tests for any new logic or behavior - Welcome post-merge feedback, review doesn't stop at merge - Reflect regularly as a team and adjust the approach as needed --- Ship, Show, Ask is more than branching hygiene. It builds a culture of clarity, accountability, and trust, where developers move fast while staying thoughtful. If you're tired of slow PR queues and over-engineered approvals, try it on your next change. Want to dive deeper? Read [Rouan Wilsenach's original post](https://martinfowler.com/articles/ship-show-ask.html). > Match the review to the risk. Own what you merge. --- ## Run Your LN Node on a Raspberry Pi Date: 2025-02-17 URL: https://chemaclass.com/blog/run-your-ln-node/ Tags: bitcoin, open-source, privacy, tutorial > In this guide, I'll show you how to set up a fully custodial Lightning Network (LN) node using Alby Hub on a Raspberry Pi, giving you complete control over your node. Alby Hub offers a DIY free version for a self-custodial Lightning wallet, ensuring full ownership of your funds while being 100% open-source. In this guide, I'll show you how to set up a fully custodial Lightning Network (LN) node using Alby Hub on a Raspberry Pi, giving you complete control over your node. Alby Hub offers a DIY free version for a self-custodial Lightning wallet, ensuring full ownership of your funds while being 100% open-source. It supports both Lightning and Nostr addresses, enabling seamless connectivity across ecosystems, and integrates effortlessly with dozens of Bitcoin applications. With built-in Lightning Service Provider (LSP) services and the Alby Go mobile app, managing your node on the go has never been easier. --- > Important: This is NOT a Bitcoin miner or a full node. It's simply a Raspberry Pi running on an SD card power-efficient and low-cost. ⚠️ **Disclaimer** ⚠️ - I assume you **understand [Bitcoin](https://bitcoin.org/)**'s fundamental concepts. - I assume you know **how the [Lightning Network](https://lightning.network/) (LN) works**. Anyway, I've included a brief recap of the Lightning Network basics below. ## What is the Lightning Network? The LN is a second-layer solution built on top of Bitcoin to enable fast, cheap, and scalable transactions. - **Why?** Bitcoin's base layer is secure but slow and expensive for small payments due to block size limits and fees. - **How?** LN uses off-chain payment channels that allow users to transact instantly without waiting for blockchain confirmations. ### Key Concepts - **Payment Channels**: Users open a channel by making an on-chain transaction, then send unlimited instant payments within that channel. - **Routing**: You don't need a direct channel with everyone, payments can be routed through multiple connected nodes. - **Low Fees**: Only opening/closing channels require on-chain fees; most transactions cost fractions of a cent. ### Goal LN makes Bitcoin usable for everyday transactions, like buying coffee, without waiting 10+ minutes for confirmations. > In short: Lightning Network = Instant + Cheap Bitcoin payments, secured by Bitcoin's blockchain. --- ## Setting up Alby Hub [Alby Hub](https://albyhub.com/) is a free, open-source ([ideally private](https://guides.getalby.com/user-guide/alby-account-and-browser-extension/alby-hub/faq-alby-hub/should-i-open-a-private-or-public-channel)) Lightning Network node. ### Requirements Before we begin, you are going to need the following things: - A windows or mac or linux computer - **Raspberry Pi 4** or **5** (For [**Zero 2W** see this tutorial!](https://guides.getalby.com/user-guide/alby-account-and-browser-extension/hidden-archives/raspberry-pi-zero)) - _In this tutorial, I am using a raspi-4b (~60€)_ - The charger for your raspi _(~10€)_ - SD memory card (32/64gb) _(~10€)_ - Adapter SD card to USB (to flash the OS into the raspi) _(~10€)_ ### Installation Steps #### 1. Flash a Linux kernel into the SD card > Suggestion: You can use [RPI imager](https://www.raspberrypi.com/software/) on your computer. Use it to flash the recommended raspi OS for you On the Storage you will see your SD card after inserting it into your laptop. Once you click "Next", you will see different settings. Click to **Edit Settings** On `Settings > General`: set your hostname, the username and password for your admin user. Make sure you enable your WIFI, otherwise you will have to plug it to the router with an RJ-45. > For this tutorial, I am using `testhub` as hostname, you can use `albyhub` or whatever you prefer. On `Settings > Services`: make sure the access via SSH is enabled. We are going to need it to install Alby Hub. Click "Save" and click "Yes" to start the installation. You will see a confirmation. Click "Yes". It will take ~10 mins... Now we got the SD with a fresh linux kernel ready to use! #### 2. Insert the SD into the raspi Extract the SD from the laptop and insert it in the raspi first. Once the SD is inserted, then plug in the power cable. It will turn on automatically as soon as you plug it in. #### 3. Alby Hub installation It will take ~5mins since you turned it on to be able to access to it. How can you make sure it's alive? Open the terminal and ping the hostname you defined while flashing the SD on [Settings > General](/blog/run-your-ln-node/#hostname-setup), remember it ended up with `.local`: It's normal if you don't get any answer at the beginning... until you do get this. Now you can **install Alby Hub** in your raspi **using the SSH connection** that you [enabled earlier](/blog/run-your-ln-node/#pi-enable-ssh): You will be asked to type the word "yes"; type it. Then, you will be asked to enter your password. Enter the password you chose in [Settings > General](/blog/run-your-ln-node/#hostname-setup) for the username. #### 4. Alby Hub Setup Wait another 2-3 mins and visit your host: [http://testhub.local/](http://testhub.local/) Your Alby hub is now running. Let's connect it to your GetAlby account! --- ## Creating a GetAlby Account 🔗 [getalby.com](https://getalby.com/) --- ## Connecting GetAlby with Alby Hub I created an account named testhub. **Left**: the GetAlby account. **Right**: the node in the raspi. Click "**Connect Now**". Click "**Request Authorization Code**". You get the auth code (**left**) that you need to insert it into your setup (**right**). Create a **Password** for your Alby Hub installed in your raspi. It can be different from the password that you set up for your root user in the rapi itself. Now it's time to **Link your Alby Account** Unless you specify otherwise, set the default "Budget renewal: _Monthly 1M sats_". --- ## Opening Lightning Channels I recommend following the **Initial Steps** to set up your Alby Hub. Let's open the first channel. You need to pay ~$20 in sats to open a 1M sats _**incoming liquidity channel**_. After the payment, then you will see the channel open. It might take a couple of mins until the **_funding transaction_** is mined in the next block. --- ## Receiving Sats You can receive sats using your LN Address. **Left**: Public page linked to your [node](https://getalby.com/p/chemaclass). **Right**: Private page from your Alby Hub. > Optional: You can add ln funds to your wallet using GetAlby's third-party services: [getalby.com/topup](https://getalby.com/topup) - mind the KYC... --- ## Using Your Sats After that, you will be able to use it via the [Alby Extension](https://getalby.com/) or the [AlbyGo](https://albygo.com/). Your node is the ultimate source of truth. Connecting these apps to it will allow you to use your sats seamlessly across different platforms. > **Disclaimer**: the testhub LN address was created only for testing and tutorial purposes. My real address is [chemaclass](https://getalby.com/p/chemaclass) ;) ## Maintenance and Troubleshooting ### Updating Your Node Similar to the installation process, there's a script available to update your node. You can find it in the source repository: [GitHub - Alby Hub Update Script](https://github.com/getAlby/hub/tree/master/scripts/pi-aarch64) ### Handling Power Outages If the power goes out, the Raspberry Pi will turn off. Once power is restored, it will automatically restart, but Alby Hub will prompt you to enter the password you set earlier. --- **Related links** - [GetAlby - User Guide](https://guides.getalby.com/) - [Installing Alby Hub in a Raspberry Zero](https://guides.getalby.com/user-guide/alby-account-and-browser-extension/hidden-archives/raspberry-pi-zero) --- ## Understanding Taxes Date: 2025-01-02 URL: https://chemaclass.com/blog/understanding-taxes/ Tags: bitcoin, philosophy, economics, privacy > Taxes are unavoidable. Whether it's your paycheck, morning coffee, or the house you just bought, taxes are everywhere. If you've ever wondered where your money goes after payday or why buying property comes with extra fees, this post is for you. Taxes are unavoidable. Whether it's your paycheck, morning coffee, or the house you just bought, taxes are everywhere. If you've ever wondered where your money goes after payday or why buying property comes with extra fees, this post is for you. I'll keep it simple without diving into complicated legal stuff. 1. Tax journey 101 1. Types of Taxes 1. How do they work? 1. Why do we pay taxes? 1. A new perspective --- ## Tax journey 101 1. When you earn: - Personal Income Tax: Deducted from your salary. - Social Security Contributions: For healthcare, pensions, and unemployment. - Self-Employment Tax: Covers taxes and social security for freelancers. 2. When you spend: - Value-Added Tax (VAT): Adds 10%-25% to most goods and services. - Excise Tax: Extra charges on fuel, alcohol, tobacco, and luxury items. 3. When you own: - Property Tax: Paid annually on owned real estate. - Wealth Tax: Charged on substantial assets in some countries. - Road Tax: Annual fee for owning or operating a vehicle. 4. When you transfer or inherit: - Transfer Tax: Applied to purchases like second-hand properties. - Inheritance/Gift Tax: Payable on inherited assets or large gifts. 5. When you sell: - Capital Gains Tax: On the profit when selling property, stocks, or investments. - Land Value Increase Tax: On the increase in land value during ownership. 6. When you use services: - Local Fees: For waste collection, car registration, or building permits. - Tourism/Travel Tax: For lodging or certain tourist-related services. 7. When you win the lottery: - Lottery Tax: A substantial portion of your winnings goes to the government. --- ## Types of taxes Consider taxes as a three-course meal: **direct**, **indirect**, and **special**. ### Direct taxes: What you earn and own These taxes are based on your income, assets, or gains: - **Income Tax:** This is the big one. It's progressive, meaning the more you earn, the higher your pay rate. Income Tax applies to salaries, freelancing income, rental earnings, and investment gains. - **Corporate tax:** This tax is paid on businesses' profits. Rates vary by country, but a general rate of 20-30% is common. - **Wealth Tax:** Some countries tax high-net-worth individuals on their total assets, like properties or savings. Rates and exemptions depend on where you live. - **Inheritance and Gift Tax:** When you inherit assets or receive a significant gift, you must pay taxes. The rate often depends on your relationship with the giver. ### Indirect taxes: What you spend These taxes are baked into the price of goods and services: - **Value-Added Tax (VAT):** A tax on almost everything you buy. Standard rates range from 10-25% in most countries, though essential goods like food and medicine often have reduced rates. - **Excise taxes:** Special taxes on products like alcohol, tobacco, and fuel. They're designed to raise revenue while discouraging consumption. ### Property and local taxes: Owning stuff costs money If you own, rent, or sell property, these taxes come into play: - **Property Tax:** Paid annually based on the value of your home or land. - **Transfer Tax:** When buying a 2nd-hand property, you might pay a % of its price. - **Capital Gains Tax:** When selling a property or other assets for a profit. ### Other Taxes and fees: The little extras These include fees for registering vehicles, paying for waste collection, and obtaining permits. They might seem minor, but they add up over time. --- ## How do they work? Taxes are usually a mix of **national**, **regional**, and **local** responsibilities: - National taxes have **standardized rates**, like income tax or VAT. - Regional taxes vary **depending on where you live**, like wealth or inheritance taxes. - Local taxes are **specific to your city** or town, like property or waste fees. Taxes are often deducted directly from employees' paychecks. Freelancers and business owners, on the other hand, need to calculate and pay their taxes regularly. ## Why do we pay taxes? Taxes are **meant to pay for public services** like roads, healthcare, schools, and pensions to make life better for everyone. But the system's complexity and how the money is spent often make it feel unfair. ### Are Taxes fair? This depends on two big questions: **Who should pay? How much is fair?** #### The case for taxes - Taxes **fund essential services** we all use, like hospitals and schools. - **Progressive taxes**, where higher earners pay more, help reduce inequality and create stronger communities. #### The case against taxes - Some taxes, like **wealth or inheritance taxes, feel unfair**. They take money that's already been earned. - Worse, when governments **waste tax money on corruption or bad decisions**, people feel like they're paying for nothing. It feels **unfair when governments waste the money**. If services don't improve or funds are mismanaged, it's **frustrating to see your money disappear without benefit**. Taxes would seem much fairer if people trusted their money was being spent wisely. Without trust, paying **taxes feels like throwing money into a black hole**. --- ## A new perspective Taxes are supposed to fund critical public services, but the biggest problem with taxes (and big governments) is that they often lead to **inefficiency and corruption**. The more power a government has, the more likely it is to misuse it. That's why governments should be (for me) **small, focused, and efficient**, providing essential services without overcomplicating things or overreaching into people's lives. Here is where **Bitcoin offers an interesting alternative**. Bitcoin is decentralized, which means no one controls it: not governments, banks, or anyone. This removes the risk of corruption or mismanagement by powerful institutions. Every Bitcoin transaction is recorded on a public ledger that anyone can verify, so it's **transparent and resistant to manipulation**. While most countries want to tax Bitcoin transactions, using **Bitcoin gives people more control over their money**. Unlike traditional currencies that governments can print endlessly (causing inflation and lowering the value of savings), Bitcoin has a **limited supply**, so its value can't be diluted similarly. It's also borderless, meaning you can send and receive money without relying on banks or other intermediaries that might take a cut or add delays. ### Why government money works Have you ever wondered why paper money has value when it's not backed by gold or anything physical? The answer is taxes. **Governments require you to pay taxes in their currency**. This creates forced demand: everyone needs euros, dollars, or yen to pay the government. It's a circular system. The government creates the money, then requires you to earn it, then takes a portion back through taxes. This is why government money is sometimes called "fiat" (from Latin, meaning "let it be done"). It works because the government says so, and backs that up with the tax system. ### Inflation: The hidden tax **Inflation** is often called a "**hidden tax**," and for good reason. When governments print money endlessly to fund their spending, the value of the existing money drops. This means **your hard-earned savings can buy less over time**. While politicians benefit in the short term by having more money to spend without directly raising taxes, ordinary people pay the price through higher living costs. **Inflation is theft**, as it quietly takes value away from everyone's money to cover the government's poor financial decisions. With its **fixed supply of 21 million** coins, Bitcoin cannot be inflated in this way. **Its scarcity ensures that no one**, including politicians, **manipulates its value**. For people frustrated by rising prices and shrinking savings, Bitcoin offers a way to protect their wealth from the damaging effects of inflation. It's **a system designed to reward savers**, not punish them. ### Final thoughts **Bitcoin** doesn't eliminate taxes or public services but **challenges how we think about money and power**. It gives people more **control over their wealth** and shows how financial systems work without needing large, often corrupt institutions. It's **a step toward a world where individuals have more freedom** and governments focus on being small, efficient, and fair. --- ## The Cypherpunks Date: 2024-12-11 URL: https://chemaclass.com/blog/the-cypherpunks/ Tags: privacy, bitcoin, cryptography, security, philosophy > In the early '90s, with the internet on the rise, a group called the Cypherpunks emerged to defend digital privacy. They pushed for encryption and privacy tech, shaping our digital world with their vision and ideals. In the early '90s, with the internet on the rise, a group called the Cypherpunks emerged to defend digital privacy. They pushed for encryption and privacy, shaping our digital world with their vision. ## Who were the Cypherpunks? The term "Cypherpunk" combines "cipher" (a reference to encryption) with "punk", reflecting the group's rebellious and anti-establishment spirit. Far from being a formal organization, the Cypherpunks were a diverse assembly of visionaries, technologists, and activists bonded by shared principles. The movement started in 1992 when Eric Hughes, Timothy May, and John Gilmore founded the cypherpunks mailing list. Some key figures: - **Eric Hughes** who wrote "A Cypherpunk's Manifesto," laying out the philosophical foundation for the movement. - **Timothy C. May** authored "The Crypto Anarchist Manifesto," which imagined a society where cryptography could foster a new anarchistic order. - **John Gilmore**, a co-founder of the Electronic Frontier Foundation (EFF), was pivotal in early internet privacy advocacy. - **Julian Assange**, later known for WikiLeaks, participated in these discussions. - **Phil Zimmermann** revolutionized email privacy with his creation of PGP. - **Jude Milhon** (St. Jude), a hacker and writer, coined the term "cypherpunk" together with Eric Hughes. - **Nick Szabo** contributed significantly to digital contracts and currencies, conceptualizing "bit gold" before Bitcoin. - **Hal Finney**, an early Bitcoin developer, worked on cryptographic software including PGP, influencing the privacy tech landscape. - **Adam Back** introduced Hashcash, which later inspired Bitcoin's proof-of-work, while actively engaging in cypherpunk dialogues on privacy. - **Wei Dai** proposed "b-money," an early idea for anonymous digital cash systems, which influenced Bitcoin's development. - **Zooko Wilcox-O'Hearn**, with his work on Zcash, brought advanced privacy to cryptocurrencies, having roots in cypherpunk discussions. - **David Chaum**, often called the "godfather of cypherpunks", pioneered digital cash with DigiCash (1989). His work on electronic privacy predates and inspired the movement. - **Bram Cohen** developed BitTorrent, showcasing the cypherpunk ethos of decentralization in file sharing. Their work built on foundational cryptographic research by **Whitfield Diffie** and **Martin Hellman**, who invented public-key cryptography in 1976, making secure communication between strangers possible. They gathered online on the cypherpunks mailing list, which at its peak had around 2000 subscribers exchanging 30+ messages per day. Their motto: **"Cypherpunks write code."** They didn't just talk about privacy. They built it. ## Philosophy and goals The core philosophy of the Cypherpunks was centered around privacy, freedom of speech, and the potential of cryptography to protect these rights. Their main tenets included: - **Privacy as a fundamental right**: They believed that privacy was essential for personal freedom and that digital communication should be private. - **Decentralization**: Suspicious of centralized control over information, they pushed for decentralized systems where individuals could control their own data. - **Cryptography as a tool**: They saw encryption not just as a means of securing data but as a political tool against surveillance and oppressive regimes. ### Their goals were 1. To create and promote tools for encryption, anonymity, and digital cash. 1. To educate the public on the importance of cryptography. 1. To resist governmental and corporate efforts to control or monitor digital communications. ## Impact nowadays ### Development of key technologies Cypherpunks built tools, not just theories: - **PGP** (1991): Email encryption for everyone - **Tor** (2002): Anonymous browsing through onion routing - **BitTorrent** (2001): Decentralized file sharing - **Bitcoin** (2009): Digital money without banks - **Signal Protocol**: The encryption behind Signal, WhatsApp, and other messengers When you send an encrypted message today, you're using cypherpunk technology. ### Cultural shift They changed how society views privacy. Before them, encryption was mostly for governments or experts. Today, it's a standard part of tools like messaging apps and web browsers. By promoting encryption and anonymity, they made privacy a priority and encouraged people to take control of their data. ### Legal and policy influence: The Crypto Wars The 1990s saw a real battle between cypherpunks and governments, known as the "Crypto Wars." The US classified strong encryption as a weapon and banned its export. When Phil Zimmermann released PGP, he was investigated for "exporting munitions" because the software spread globally via the internet. The cypherpunks fought back creatively. They printed PGP source code in books, since books were protected speech. They wore t-shirts with encryption code. Eventually, they won. Export restrictions were relaxed in 2000. Today's encrypted messaging exists because of that fight. ## Challenges and Criticisms The Cypherpunks face these main criticisms: - **Accessibility**: Their tools are too complex for many people, so only tech-savvy individuals can use them, leaving others behind. - **Misuse Risk**: There's concern that their encryption tech could be used by bad actors. While Cypherpunks believe privacy is a right for all, this view conflicts with security concerns from authorities who fear these tools could hide illegal acts. This shows the ongoing struggle between promoting privacy and maintaining safety in the digital world. ## Precursors to Bitcoin Bitcoin is the most well-known outcome of the cypherpunk philosophy, embodying their values of decentralization, privacy, and independence from government control over money. Created by the mysterious Satoshi Nakamoto, Bitcoin was first shared with the world through the cypherpunks' mailing list in 2008. However, it is the result of many trials of other technologies also created within this group of people. It uses ideas like proof-of-work from Hashcash, and concepts from b-money and bit gold, all reflecting the cypherpunks' dream of a currency not controlled by any single entity. ### DigiCash (eCash) Developed by David Chaum in the late 1980s and implemented in 1990, DigiCash was one of the earliest attempts at an electronic payment system. It used cryptography to ensure privacy in transactions but struggled with adoption and eventually failed due to issues like centralization and the double-spending problem. ### B-Money Proposed by Wei Dai in 1998, B-Money was a conceptual framework for anonymous, distributed electronic cash. It aimed to solve issues like double-spending without a central authority but was never implemented. Its ideas influenced Bitcoin's design. ### Bit Gold Also conceptualized in 1998 by Nick Szabo, Bit Gold proposed a currency with properties similar to gold, using cryptographic proof-of-work. Like B-Money, it was never fully realized but contributed to Bitcoin's development, particularly its proof-of-work system. ### Hashcash Introduced by Adam Back in 1997, Hashcash was not a currency but a system to counter email spam using proof-of-work. This concept was later adopted by Bitcoin for mining. > These earlier projects and ideas, while not successful in creating a functional digital currency, were critical in laying the theoretical groundwork for Bitcoin. They tackled issues like double-spending, privacy, and decentralization, which were key problems Bitcoin aimed to solve. ## Cypherpunk legacy Bitcoin has revolutionized our understanding of money, privacy, and security: - **Decentralized Control**: Bitcoin isn't run by any bank or government, which fits perfectly with the cypherpunk's skepticism of centralized power. - **Privacy**: While not completely anonymous, Bitcoin transactions use pseudonyms, offering some protection from financial oversight. - **Immutable Transactions**: Once a transaction is on the blockchain, it's nearly unchangeable, fostering trust in digital dealings. Bitcoin has brought cypherpunk ideals to life, sparking global discussions on financial privacy, money's nature, and cryptography's transformative power. With developments like the [Lightning Network](https://en.wikipedia.org/wiki/Lightning_Network) for faster, private transactions and [Taproot](/blog/programmable-money/#p2tr-pay-to-taproot-taproot-up) for enhanced transaction privacy, Bitcoin continues to evolve. ## What the cypherpunks left behind The cypherpunks proved that a small group of people who write code can change the world. Every encrypted message you send, every Bitcoin transaction, every anonymous browse: their legacy. Privacy isn't dead. They made sure of that. --- {{ youtube(id="9vM0oIEhMag") }} --- **Related links** - Learn more: [What is PGP encryption?](/pgp) A 3-minute tutorial for beginners - Wikipedia Article: [wikipedia.org/Cypherpunk](https://en.wikipedia.org/wiki/Cypherpunk) --- ## Verified Git Commits Date: 2024-11-17 URL: https://chemaclass.com/blog/verified-git-commits/ Tags: git, security, cryptography, open-source > Sign your Git commits with GPG to prove they're really from you. Without signatures, anyone can fake commits using your email. It takes 5 minutes to set up and adds real trust to your codebase. When it comes to software development, trust and security are very important. One easy way to level up both is by using verified commits. Whether you're working on an open-source project or in a private company, verified commits can make sure your contributions are legit. Let's break down what they are, why they're important, and how to start using them. ## What are verified commits? A verified commit is basically a Git commit that is signed by the author using a digital signature. This signature proves that the commit actually came from the person who says they made it. Tools like [GPG (GNU Privacy Guard)](https://gnupg.org/) let you attach this signature to your commits. If you're using platforms like GitHub, you'll notice a little "Verified" badge next to commits that are signed properly. It's a quick way to show that the commit is authentic. ## Why Are They Important? Signed commits help keep your contributions authentic and trustworthy. By adding a cryptographic signature to your commits, you prove that the changes came from you. This is especially important in collaborative environments, where maintaining trust and accountability is key. Without signed commits, anyone could fake a commit using someone else's email. For example, they could use your email, and platforms like GitHub would link it to your profile, making it look like you made the changes, even if you didn't... not good! By signing your commits, you show that the work is genuinely yours. It stops impersonation, builds trust in what you've done, and keeps everything transparent and accountable. > Note: For this demo, I used a public email address belonging to Linus Torvalds. After pushing the commit to this repository, GitHub recognized the email and linked it to his profile. This impersonation is purely for demo purposes to highlight potential risks. Always use your own email for commits. --- ## How to get started with verified commits ### Set up a GPG key First, you'll need a GPG key to start signing commits. Here's how: Generate a GPG key: Find your key ID: Tell Git to use your key: Make signing commits the default: ### Add your key to [GitHub](https://github.com/settings/keys)/[GitLab](https://docs.gitlab.com/user/project/repository/signed_commits/gpg/) Export your public key: Navigate to "Settings > SSH and GPG keys," and paste your key. ### Start signing commits From now on, Git will automatically sign your commits. If you want to sign a commit manually, just use the `-S` flag: You can **verify** the commit signature with: And also when clicking on the "Verified" badge on GitHub directly. Verified commits might seem like a small step, but they make your code more trustworthy. It's an easy way to add an extra layer of protection to your work, and it's worth it. Give it a try! --- ### Extra: Full setup in Spanish 🇪🇸 {{ youtube(id="0DzQBu7U2f4") }} --- **Related links** - Learn more: [What is PGP encryption?](/pgp) A 3-minute tutorial for beginners --- ## bashunit Date: 2024-10-30 URL: https://chemaclass.com/blog/bashunit/ Tags: bashunit, bash, testing, open-source, tdd > bashunit is a lightweight, easy-to-use testing framework for Bash, packed with handy features like parallel and snapshot testing, test doubles, data providers, and tons of built-in assertions. Backed by clear docs and an active community, it's become a favorite for reliable Bash testing. What started as a simple dev frustration has grown into an open-source tool that makes testing in Bash a lot easier and fun. bashunit is a lightweight, easy-to-use testing framework for Bash. Features like parallel and snapshot testing, test doubles, data providers, and tons of built-in assertions. Backed by clear docs and an active community, it’s become a favorite for reliable Bash testing. What started as a simple dev frustration has grown into an open-source tool that makes testing in Bash a lot easier and fun. 1. The story behind bashunit 2. Why create another testing library? 3. How is it nowadays? 4. Core features 5. Lightning tech talk ## The story behind bashunit The journey to create bashunit started from a simple frustration: I worked with a team where each commit had to start with the ticket name. Since I like working in small steps with quick, iterative commits, adding the ticket key and number to every single commit became a major hurdle, slowing down my development flow with unnecessary friction. After a few days of this, I decided to automate it. Git has a helpful hook, `prepare-commit-msg`, which allows you to alter commit messages before they're finalized. I created a Bash ([script](https://github.com/Chemaclass/conventional-commits/blob/main/git-hooks/prepare-commit-msg.sh)) that automatically fetches the ticket key and number from the branch name and inserts it into the commit message, making my process smoother and more efficient. As someone who values continuous improvement, I began adding more features to this script. However, it became clear that maintaining and testing these changes manually was taking too long and was prone to error. To make development safer and more efficient, I created an `assert`([link](https://github.com/Chemaclass/conventional-commits/blob/705489a3487a4607183090d5574827bf6fedabda/git-hooks/prepare-commit-msg_test.sh)) function, enabling automated tests that verified the expected behavior based on script output. The `assert` function allowed me to define multiple assertions in a separate file, making it easy to validate that any refactoring of the original hook maintained the expected behavior. If a change inadvertently broke existing functionality, it would instantly flag the issue, letting me know right away that something needed fixing. This setup provided immediate feedback and helped ensure that any updates to the script didn't disrupt its intended logic. For example: In the example above, you'll notice that I execute the actual “`SCRIPT`” as the second argument in the assert function, comparing its output to the expected value provided as the first argument. Here, we have two test cases, each exporting `TEST_BRANCH` to simulate how the commit message would vary based on the branch name. This setup emulates real behavior, allowing us to test how different branch names affect the commit message formatting. More examples [here](https://github.com/Chemaclass/conventional-commits/blob/27aeebe4e76afe0a2e91cba85537399eab112eb4/test/prepare-commit-msg_test.sh). I decided to separate the `assert` function from the test cases, as shown [here](https://github.com/Chemaclass/conventional-commits/commit/5458e5728296bb94b1e8e6b25eeccde6cc700589), to keep things modular and reusable. Then, I created a `runner` to execute each test case independently, reducing test interference and improving reliability. You can see that setup [here](https://github.com/Chemaclass/conventional-commits/commit/92a5880d7f26b3422de6b91b51c04f9ff7b961fd). This structure made automated testing easier and refactoring safer. This was a great improvement because it made it easier to separate [test cases](https://github.com/Chemaclass/conventional-commits/blob/4c7dae8d44d425ff06fbb48654388f90c2beb3c4/tests/prepare-commit-msg_test.sh) from the logic of the test runner itself. This clear structure has simplified both creating and managing tests. Now the tests were organized and I got an [idea](https://github.com/Chemaclass/conventional-commits/commit/f459f43cecc271becb1e5eb6ca95d24c97e87830): And so it [began](https://github.com/TypedDevs/bashunit/commit/27269c21c8d0b03bcb3f2000767f4a27b8bf08a1). At the time, I didn't know much about Bash or the best ways to use a Bash project as a dependency. But I knew I could start by using a Git submodule, even though I'm not a huge fan of them. On September 4, 2023, I launched version [0.1](https://github.com/TypedDevs/bashunit/commit/fc9aac40eb8e5ad4483f08d79eb678a3650dcf78), which featured a working runner and a single assertion function: `assertEquals`. Later, version [0.2](https://github.com/TypedDevs/bashunit/releases/tag/0.2.0) was released, allowing `./bashunit` to be a standalone executable, runnable from any folder. Here's how it looked back then: I shared the project with a few friends who quickly jumped in to help with documentation, the website, additional assertions, snapshot testing, and key decisions. To emphasize its open-source spirit and community ownership, I moved it to an organization we created specifically for sharing OSS projects, making it a truly collaborative project rather than an individual one. ## Why create another testing library? I know now that other Bash testing libraries exist. But when I started with bashunit, I wasn't aware of them, and frankly, I'm still no Bash expert. By the time I learned about these alternatives, it was already too late, bashunit had gained enough momentum and excitement to keep going strong. While those other libraries may serve specific use cases, use modern Bash, or be developed by more seasoned Bash developers, bashunit aims to set itself apart by offering a great developer experience, shaped by years of working with various testing frameworks. I was asked about the differences on September 7, 2023, and here's my response: [Question: Difference to pgrange/bash_unit](https://github.com/TypedDevs/bashunit/issues/8). ## How is it nowadays? Today, you can [install](https://bashunit.typeddevs.com/installation) bashunit via curl, Homebrew, MacPorts, by downloading the latest GitHub [release from GitHub](https://github.com/TypedDevs/bashunit/releases), or even by [building it yourself](https://github.com/TypedDevs/bashunit/blob/main/build.sh) from source. Completely open-source. The project is written in Bash 3.2 (from 2007) since that's the default version on macOS, even now, in 2024. This compatibility means bashunit runs smoothly on that version, and I plan to maintain support for it. To ensure quality, we test each feature with unit, functional, and acceptance tests, making bashunit its own “first user” of every new feature. We also have several CI workflows using [GitHub actions](https://github.com/TypedDevs/bashunit/actions/workflows/tests.yml) that run tests on different platforms to check compatibility and confirm everything works as promised. In June 2024, bashunit was [integrated in PHPStan](https://bashunit.typeddevs.com/blog/2024-06-21-phpstan-integration) for their end-to-end tests, enabling the use of bashunit's assertions independently of its runner. This flexibility turned out to be very useful. Last summer, I was invited to speak about bashunit at the [International PHP Conference](/talks/#may) in Berlin, alongside [Manu](https://emmanuelvalverde.dev/), another contributor. This project has opened doors and led to a lot of gratitude from users who appreciate the work we've put into it. ## Core features bashunit includes classic lifecycle functions like `set_up`, `tear_down`, `set_up_before_script`, and `tear_down_after_script`. It also supports a wide range of [command-line parameters](https://bashunit.typeddevs.com/command-line) and [configuration values](https://bashunit.typeddevs.com/configuration). Some of my favorites include: * `--parallel` * `--filter` * `--stop-on-failure` * `--verbose` We also provide [data providers](https://bashunit.typeddevs.com/data-providers) for running the same test cases with different inputs. For [test doubles](https://bashunit.typeddevs.com/test-doubles), bashunit offers mocks and spies. These work within the same process as the test, but currently, they don't work across processes, an area for improvement. Powerful [snapshot testing](https://bashunit.typeddevs.com/snapshots) is included, making it easy to verify command or script outputs over time. bashunit offers a large set of native [assertions](https://bashunit.typeddevs.com/assertions) for test cases, including: * `assert_same` * `assert_equals` * `assert_contains` * `assert_matches` * `assert_string_starts_with` * `assert_array_contains` * `assert_successful_code` * `assert_general_error` * `assert_file_exists` * `assert_file_contains` * `assert_match_snapshot` You can even create your own [custom asserts](https://bashunit.typeddevs.com/custom-asserts) to extend bashunit's capabilities. With over **25** contributors and more than **325** stars on GitHub within just a year of spare-time development, I’m genuinely proud of what this project has become. ## Lightning tech talk Recently, I presented a lightning tech talk at a hackers’ meetup, demoing bashunit to an audience of over 100 people. It was an incredible experience to share this tool with such an engaged crowd! {{ youtube(id="SX7iNHaSsF0") }} --- bashunit original logo designed by [Antonio](https://antonio.gg/). --- ## People Skills Date: 2024-09-02 URL: https://chemaclass.com/blog/people-skills/ Tags: communication, team-management, career, leadership > So, you're a software developer, and you've mastered coding languages, algorithms, and all the tech stuff. That's awesome! But here's the deal: technical skills alone won't get you as far as you might think. If you can't work well with others, it doesn't matter how great your code is, nobody will want to work with you. So, you're a software developer, and you've mastered coding languages, algorithms, and all the tech stuff. That's awesome! But here's the deal: technical skills alone won't get you as far as you might think. If you can't work well with others, it doesn't matter how great your code is, nobody will want to work with you. ## Why People Skills Matter in Software In software development, collaboration is everything. Projects aren't just solo endeavors. You will be part of a team, with other developers, designers, or even non-tech folks like managers and clients. How you communicate, collaborate, and handle feedback can make or break your success. ### The Brilliant but Difficult Teammate Think about it. Have you ever had that one teammate who's brilliant but hard or nearly impossible to work with? Maybe they don't listen, get all the credit, or make everything more complicated than it needs to be. No one likes working with that person, right? It's the same for you. If you can't get along with your team, it doesn't matter how good your code is. ### What Being a Good Team Player Means Being a good team player means listening to others, being open to feedback, sharing ideas, and, most importantly, being respectful and considerate. You want people to enjoy working with you, not avoid it. Good people skills help you build strong working relationships, solve problems faster, and create a better work environment for everyone. Don't just aim to be a coding expert, ensure you're also great to work with. ### The Long-Term Impact In the long run, your people skills can boost your success as much, if not more, than your technical abilities. They play a vital role in a team's success and make the work experience enjoyable for everyone involved. > People skills are as necessary as technical skills. No one will want to work with you if you are not a good team player. ## What are people skills? The competencies that enable you to interact effectively and smoothly with others. ### Core Communication Skills - **Communication**: The ability to clearly convey ideas, listen actively, and engage in meaningful conversations. This includes both verbal and non-verbal communication. - **Empathy**: Understanding and being sensitive to the feelings, thoughts, and experiences of others. It involves seeing things from someone else's perspective. - **Emotional intelligence**: Recognizing and managing your own emotions and understanding and influencing the emotions of others. ### Collaboration Skills - **Teamwork**: Working well with others to achieve common goals. This includes collaboration, sharing responsibilities, and supporting colleagues. - **Conflict resolution**: The ability to handle disagreements and disputes constructively, finding solutions that satisfy all parties involved. - **Negotiation**: Finding mutually acceptable solutions or compromises during discussions or disagreements. ### Growth and Influence - **Adaptability**: Being flexible and open to change, adjusting your approach as needed to meet different situations or personalities. - **Leadership**: Inspiring and guiding others, providing direction, and fostering a positive environment. - **Networking**: Building and maintaining professional relationships that can provide support, opportunities, and resources. > These skills are essential in almost every job and help build strong relationships, enhance teamwork, and create a positive work environment. ### Why They're Harder Than You Think These are often called interpersonal or soft skills, but mastering them can be surprisingly challenging, perhaps even more so than many technical skills. Unlike "hard skills," which are tangible and can often be learned through a few hours or days of study, people skills involve navigating the intricate web of human emotions, experiences, and expectations. While technical skills might require you to dive into documentation, run experiments, and refine your approach, understanding and relating to people is far more complex. Humans bring their feelings, backgrounds, and routines into interactions, adding layers of complexity beyond machines' straightforward logic. These personal details shape the reality we perceive, making interpersonal skills an essential yet complex part of effective communication and collaboration. --- ## What Is Waterfall? Date: 2024-08-01 URL: https://chemaclass.com/blog/what-is-waterfall/ Tags: agile, software-design, team-management, productivity > Waterfall is like following a straight path where you move from one step to the next in a defined order, like water flowing down a waterfall through different stages. The problem is that each step can take a lot of time and resources to complete. Plus, you don't get feedback until the entire stage is finished, which can lead to a lot of wasted time. This is especially tricky in software development, where things are always changing and evolving. Waterfall is like following a straight path where you move from one step to the next in a defined order, like water flowing down a waterfall through different stages. The problem is that each step can take a lot of time and resources to complete. Plus, you don't get feedback until the entire stage is finished, which can lead to a lot of wasted time. This is especially tricky in software development, where things are always changing and evolving. It usually follows a straightforward sequence like this: ## The reality of Waterfall Waterfall can be like communism in theory, it seems perfect on paper but doesn't work in the real world. - Clients often don't know exactly what they want. - Requirements are constantly changing. - Businesses need to quickly adapt to market shifts and client needs. - Software needs to be flexible to keep up with these changes. So, in a constantly changing world, Waterfall can really hurt a business. It tends to frustrate developers and teams, and it can also annoy clients and the businesses paying for the software. This usually leads to delays and extra costs. ## Why companies still use Waterfall Even with its problems, a lot of companies still use Waterfall because it seems straightforward and logical. This makes them reluctant to take the time to learn Agile. Plus, getting management to agree to switch to Agile can be a tough sell, especially since it requires an investment in time and learning. The big issue is when higher-ups dictate exactly how teams should work, leading to micromanagement. This messes up the flexibility that Agile brings. From what I've seen, this is a common problem. > Looking back, switching to Agile could have fixed a lot of issues. --- ## Why Agile was created Agile was created to overcome the limits of the Waterfall method. It focuses on constant interaction with clients and teams. Agile builds autonomous and responsible teams that handle tasks from start to finish, reducing wasted time and resources. It emphasizes flexibility, collaboration, and customer feedback. Unlike Waterfall, Agile uses iterative development, breaking projects into small, manageable sprints or iterations that last 1-4 weeks. Each cycle includes planning, development, testing, and review, aiming to deliver value quickly and gather feedback to improve. ### Key aspects of Agile - **Iterative Development**: Work in small chunks and adjust as you go. - **Customer Collaboration**: Keep talking with clients to make sure they're happy. - **Cross-Functional Teams**: Teams with different skills working together. - **Adaptive Planning**: Stay flexible and tweak plans based on feedback. - **Continuous Improvement**: Always look for ways to get better. > Read the original [Agile Manifesto](https://agilemanifesto.org/). ### Where can you start? As a developer, you can boost your agility by diving into [pair programming](/blog/effective-pair-programming/) and [TDD](/blog/test-driven-development/). - With pair programming, two developers work side by side, which means you get instant feedback and shared problem-solving, leading to better code. - TDD, on the other hand, involves writing tests before the code, which help specifying what you want to do, focusing on baby steps. Together, these practices make your development process more flexible, collaborative, and high-quality, fitting right in with Agile’s focus on quick adjustments and continuous improvement. See more practices [here](/readings/extreme-programming-explained/#practices). > The key is collaboration, baby steps, and quick feedback on everything you work on. ## My experience with Agile I’ve [talked](/talks/) about Agile at various tech events and explored it in depth because I’m passionate about how it can supercharge software teams. When done right, Agile can completely change how teams work, making them faster, more efficient, and better at delivering what clients and businesses really need. - 2022-06-26 | [International PHP Conference](https://phpconference.com/mixed/update-your-team-to-be-more-extreme/) [Berlin, Germany] (EN) - 2022-09-16 | [Code Talks](https://codetalks.de/) [Hamburg, Germany] (EN) - 2022-10-26 | [International PHP Conference](https://phpconference.com/mixed/update-your-team-to-be-more-extreme/) [Munich, Germany] (EN) - 2022-12-21 | IES Ginés Pérez Chirinos [Murcia, Spain] (ES) - 2023-01-19 | [devm.io](https://devm.io/update-your-team-to-be-more-extreme/) [Remote] (EN) - 2023-07-28 | [WeAreDeveloper World Congress](https://www.wearedevelopers.com/world-congress) [Berlin, Germany] (EN) ### WeAreDevelopers World Congress in Berlin {{ youtube(id="dqtAyl-SvaY") }} --- ## Pretty Good Privacy Date: 2024-07-13 URL: https://chemaclass.com/blog/pretty-good-privacy/ Tags: security, privacy, cryptography > PGP is an encryption program that ensures privacy and authentication for data communication. It is used for signing, encrypting, and decrypting texts, emails, files, directories, and whole disk partitions, enhancing the security of email communications. PGP (_Pretty Good Privacy_) is an encryption program that ensures privacy and authentication for data communication. It is used for signing, encrypting, and decrypting texts, emails, files, directories, and whole disk partitions. ## History PGP was developed by [Phil Zimmermann](https://en.wikipedia.org/wiki/Phil_Zimmermann) out of concern for the lack of privacy in digital communications. He aimed to provide individuals with strong encryption tools. In 1991, PGP was released to the public for free, marking the beginning of a new era in digital security. ### Legal Challenges In the early 1990s, strong encryption was classified as a weapon under U.S. export law. When PGP spread globally via the internet, Zimmermann faced a criminal investigation for "exporting munitions." His defense was clever: he published the PGP source code in a book. Books are protected speech. The case was dropped in 1996, and encryption export restrictions were eventually relaxed in 2000. --- {{ youtube(id="1-MPcUHhXoc") }} ## Key Features - Encrypts and decrypts data to ensure secure communication - Provides authentication to verify the identity of senders and receivers - Generates public and private keys for secure key exchange - Supports various encryption algorithms and hash functions Today, PGP lives on as **OpenPGP** (the standard) and **GPG** (GNU Privacy Guard, the free implementation). When you verify a software download or sign a git commit, you're often using GPG. ## How it works PGP uses a combination of [public-key](https://en.wikipedia.org/wiki/Public-key_cryptography) and [symmetric-key](https://en.wikipedia.org/wiki/Symmetric-key_algorithm) to ensure secure data transmission. It generates a keypair consisting of a public key and a private key. The public key is shared with others, while the private key is kept secret. When data is encrypted, it is encrypted with the public key, and only the corresponding private key can decrypt it. - **Symmetric Key Encryption**: PGP generates a unique, one-time-use session key to encrypt the message. This method is fast and efficient but requires the sender and recipient to share the same key securely. - **Asymmetric Key Encryption**: PGP solves the key exchange problem with asymmetric encryption. Each user has a public key and a private key. The session key is encrypted with the recipient’s public key and can only be decrypted by the recipient’s private key. - **Digital Signatures**: PGP provides authentication through digital signatures. The sender signs the message with their private key, allowing the recipient to verify the sender’s identity using the sender’s public key, ensuring the message has not been tampered with. {{ youtube(id="Lq-yKJFHJpk") }} --- ## My public key ### Fingerprint ### Import directly ### Download the .asc file Download public PGP key --- ## Programmable Money Date: 2024-07-06 URL: https://chemaclass.com/blog/programmable-money/ Tags: bitcoin, software, cryptography, security > Bitcoin is often referred to as programmable money because it allows for the execution of programmable transactions through its scripting language, leveraging each bit for precision and functionality. Bitcoin is often referred to as "programmable money" because it allows for the execution of programmable transactions through its scripting language. ## Understanding Programmable Money Programmable money is the ability to embed logic and conditions into financial transactions. This programmability allows transactions to be executed automatically based on predefined rules without intermediaries or manual intervention. It transforms money from a static medium of exchange into a dynamic tool capable of executing complex agreements and automating financial operations. ## The Script Language Bitcoin’s programmability is powered by its built-in scripting language, [**Script**](https://en.bitcoin.it/wiki/Script). Unlike traditional programming languages, Script is a stack-based, Forth-like language explicitly designed for Bitcoin transactions. It supports multi-signature, time-locked, and other conditional transfers that can be programmed into Bitcoin transactions. It is intentionally not Turing-complete, without loops. This video includes examples of the most commonly used locking/unlocking scripts. {{ youtube(id="6Fa04MnURhw") }} ## Key Features of Bitcoin's Script ### Stack-Based Execution Script operates on a stack-based execution model where commands and data are pushed onto a stack and processed in a Last-In-First-Out ([LIFO](https://en.wikipedia.org/wiki/Stack_(abstract_data_type))) manner. ### Conditional Spending A transaction that can only be spent if certain data is provided or specific criteria are met. This can be used for: - escrow services - atomic swaps - and other complex financial arrangements ### Multisignature Transactions can be set up to require multiple signatures from different private keys before they can be spent. Useful for: - joint accounts - corporate funds - and enhancing security, as no single party can unilaterally spend the funds ### Timelocking Transactions can include time-based conditions that prevent them from being spent until a certain time or block height is reached. This feature is useful for various purposes: - delayed payments - smart contracts - and ensuring that funds are not spent prematurely (eg: with [Lightning Network](https://en.bitcoin.it/wiki/Lightning_Network)) ### Operation Codes Bitcoin's Script performs specific operations within transactions with its [OP_Codes](https://en.bitcoin.it/wiki/Script#Opcodes). Here are some of them: - `OP_DUP`: Duplicates the top stack item. - `OP_HASH160`: Hashes the top stack item twice (SHA-256 followed by RIPEMD-160). - `OP_EQUALVERIFY`: Verifies that the top two items are equal and removes them. - `OP_CHECKSIG`: Verifies a signature against a public key. - [`OP_RETURN`](https://en.bitcoin.it/wiki/OP_RETURN): Marks the transaction output as invalid, often used to store data. --- ## Common Bitcoin address types In Bitcoin, different address types correspond to various ways to script transactions. Here, we'll explore examples of Bitcoin Script for each major address type. Each address type has its own specific script format. - [**P2PK**](#p2pk-pay-to-pubkey-earliest-legacy-address-up): Earliest legacy transactions using full public keys directly. - [**P2PKH**](#p2pkh-pay-to-pubkey-hash-legacy-address-up): Begins with `1`. **Legacy** transactions using public key hashes. - [**P2SH**](#p2sh-pay-to-script-hash-up): Begins with `3`. **Legacy**, encapsulates complex scripts like multisig. - [**P2MS**](#p2ms-pay-to-multisig-up): It is typically a type of P2SH or P2WSH address. - [**P2WPKH**](#p2wpkh-pay-to-witness-public-key-hash-segwit-up): Begins with `bc1`. Native **SegWit**, more efficient transactions. - [**P2WSH**](#p2wsh-pay-to-witness-script-hash-segwit-up): Begins with `bc1`. **SegWit** for complex scripts. - [**P2TR**](#p2tr-pay-to-taproot-taproot-up): Begins with `bc1p`. SegWit **Taproot** addresses, improving privacy and efficiency for complex transactions. > Using native SegWit (P2WPKH and P2WSH) is preferable when possible, as it maximizes the benefits of the SegWit upgrade, but P2SH-SegWit can be useful for compatibility with older systems. ### P2PK (Pay-to-PubKey) - Earliest Legacy Address [up](#common-bitcoin-address-types) Begins with "1" (e.g., 1A1zP1eP5QGefi2DMPTf...v7DivfNa) Before P2PKH and P2SH became standard, Bitcoin addresses were not as flexible or feature-rich. Here are some considerations: - Addresses starting with 1 but without hashing the public key. - Not common in modern practice due to lack of privacy and efficiency. - The P2PK format is largely **obsolete** in favor of (at very least) P2PKH. --- ### P2PKH (Pay-to-PubKey-Hash) - Legacy Address [up](#common-bitcoin-address-types) Begins with "1" (e.g., 1A1zP1eP5QGefi2DMPTf...v7DivfNa) A typical P2PKH script consists of two main parts: 1. **ScriptPubKey**: The locking script (also known as the output script) that specifies how funds can be spent. 1. **ScriptSig**: The unlocking script (also known as the input script) that provides the necessary data to unlock the funds. ### ScriptPubKey (Locking Script) - `OP_DUP`: Duplicates the top stack item (the public key). - `OP_HASH160`: Hashes the public key with SHA-256 followed by RIPEMD-160. - ``: The hashed public key (a 20-byte value). - `OP_EQUALVERIFY`: Checks if the hashed public key matches the hash in the script. - `OP_CHECKSIG`: Verifies the provided signature against the public key. ### ScriptSig (Unlocking Script) - ``: The digital signature generated by the private key. - ``: The public key corresponding to the address. ### Execution Flow 1. The `ScriptSig` (unlocking script) is pushed onto the stack. 2. The `ScriptPubKey` (locking script) is executed. --- ### P2SH (Pay-to-Script-Hash) [up](#common-bitcoin-address-types) Begins with "3" (e.g., 3J2BtwzN2GEr6FCP.....81T2eiX8PVHh) P2SH scripts are used for more complex scripts. The primary feature is that the address itself encodes a hash of a script, which will be used in the transaction. ### ScriptPubKey (Locking Script) - `OP_HASH160`: Hashes the script with SHA-256 followed by RIPEMD-160. - ``: The hashed script (a 20-byte value). - `OP_EQUAL`: Checks if the hash matches the provided script hash. ### ScriptSig (Unlocking Script) - ``: The digital signature. - ``: The public key. - ``: The actual script that matches the script hash, which itself will be executed by the Bitcoin network. --- ### P2MS (Pay-to-Multisig) [up](#common-bitcoin-address-types) ### Script Format - `OP_M`: The minimum number of signatures required. - `, , ..., `: The public keys involved in the multisignature scheme. - `OP_N`: The total number of public keys provided. - `OP_CHECKMULTISIG`: The opcode that verifies the signatures against the provided public keys. ### ScriptPubKey (Locking Script) This script means that any 2 out of 3 provided public keys are required to sign the transaction for it to be valid. ### ScriptSig (Unlocking Script) - `, , ..., `: The public keys. - ``: The serialized script (the same as the locking script but without the `OP_M` and `OP_N`). NOTE: There is an oddity in CHECKMULTISIG execution. See note at the bottom. --- ### P2WPKH (Pay-to-Witness-Public-Key-Hash) - Segwit [up](#common-bitcoin-address-types) Begins with "bc1q" (e.g., bc1qf0r2m0ck4psv6yrk9w.....kw8v5rj7ph3) P2WPKH is a Segregated Witness (SegWit) address type that uses a different scripting format compared to legacy and P2SH addresses. Simplifies transactions by reducing data size and fees compared to legacy formats. ### ScriptPubKey (Locking Script) - `OP_0`: A single byte (0x00) indicating the version of the script. - `OP_PUSHBYTES_20`: Pushes 20 bytes (the public key hash) onto the stack. - ``: The 20-byte hash of the public key. ### Witness Data For P2WPKH, the unlocking script is not required in the traditional sense (i.e., inside the unlocking script explicitly included in the transaction input). Instead, the unlocking information is provided as part of the witness data in the SegWit transaction format. - ``: Digital signature for the transaction. - ``: Public key used to generate the public key hash. --- ### P2WSH (Pay-to-Witness-Script-Hash) - Segwit [up](#common-bitcoin-address-types) Begins with bc1q (e.g.: bc1q4a3h5sdg4cfkhftgd24tj9g2sg...yj57jmfckhkrw5gslr9g59) ### ScriptPubKey (Locking Script) - `OP_0`: Indicates a witness version 0 (SegWit). - `OP_PUSHBYTES_32`: Pushes the next 32 bytes (the script hash) onto the stack. - ``: 32-byte hash of the redeem script. ### Witness Data - `, `: Signatures required to unlock the transaction. - ``: The actual script that matches the script hash. This script will be executed as part of the witness data. --- ### P2TR (Pay-to-Taproot) - Taproot [up](#common-bitcoin-address-types) Begins with bc1p (e.g.: bc1pl9dfv7kvj4hj9s3a8l.....gjstmrpjl09g8ks3ukds70q4r2j5h) Taproot combines [Schnorr](https://en.bitcoin.it/wiki/Schnorr) signatures with [MAST](https://en.bitcoin.it/wiki/BIP_0114#Merkelized_Abstract_Syntax_Tree), enabling private, efficient spending conditions and making complex transactions **_appear standard_** unless conditions are revealed. It allows the efficient execution of complex transactions while hiding their details. ### ScriptPubKey (Locking Script) - `OP_1`: Indicates a witness version 1 (Taproot). - ``: A 32-byte Schnorr public key (without the y-coordinate). ### Witness Data - ``: A Schnorr signature proving possession of the private key corresponding to the x-only pubkey. --- {{ youtube(id="yU3Sr07Qnxg") }} --- ### *There is an oddity in CHECKMULTISIG execution [up](#scriptsig-unlocking-script-2) The implementation of `OP_CHECKMULTISIG` pops one more item than it should. The extra item is disregarded when checking the signatures, so it has no direct effect on the OP itself. It must be present because if `OP_CHECKMULTISIG` attempts to pop on an empty stack, it will cause a stack error and script failure. The input script in this multisig is not ` ` but `OP_0 `. It became the custom early on to use `OP_0`, which later became a relay policy rule and eventually a consensus rule ([BIP147](https://github.com/bitcoin/bips/blob/master/bip-0147.mediawiki)). It is possible that the original developer added the extra element in the original version of Bitcoin, so they could add a feature for allowing a map to be passed in a later soft fork (for performance reasons). However, that feature was never implemented, and the BIP147 update to the consensus rules in 2017 makes it impossible to add that feature in the future. Only Bitcoin's original developer could tell whether the dummy stack element was the result of a bug or a plan for a future upgrade. From now on, if you see a multisig script, you should expect to see an extra `OP_O` in the beginning, whose only purpose is as a workaround to an oddity in the consensus rules. --- ## Follow-ups - Official docs of [Script](https://en.bitcoin.it/wiki/Script) in the Bitcoin Wiki. - [Bitcoin IDE](https://siminchen.github.io/bitcoinIDE/build/editor.html) is an online Bitcoin Script visual emulator. Great for learning purposes. - [Script Editor](https://coins.github.io/bitcoin-scripts/script-editor/) is product-driven research on Bitcoin scalability and usability. - [Miniscript](https://bitcoin.sipa.be/miniscript/) is a language for writing (a subset of) Bitcoin Scripts in a structured way, enabling analysis, composition, generic signing, and more. --- ## Prisoner's Dilemma Date: 2024-06-27 URL: https://chemaclass.com/blog/prisoners-dilemma/ Tags: psychology, philosophy, communication > The Prisoner's Dilemma illustrates the complexities of strategic decision-making, where individuals must choose between cooperation and betrayal, often revealing insights into human behavior and the consequences of self-interest versus collective benefit. The Prisoner's Dilemma is a hypothetical game set up showing a situation where people won't want to work together even when it's beneficial to do so. It's just a long way of saying people don't like to be taken advantage of. It's often game theory 101. {{ youtube(id="t9Lo2fgxWHw") }} The Prisoner's Dilemma illustrates the complexities of strategic decision-making, where individuals must choose between cooperation and betrayal, often revealing insights into human behavior and the consequences of self-interest versus collective benefit. ## Premise Source: [Wikipedia](https://en.wikipedia.org//wiki/Prisoner's_dilemma) > Two members of a criminal gang are arrested and imprisoned. > Each prisoner is in solitary confinement with no means of speaking to or exchanging messages with the other. > The police admit they don't have enough evidence to convict the pair on the principal charge. > > They plan to sentence both to a year in prison on a lesser charge. > Simultaneously, the police offer each prisoner a bargain. > If he testifies against his partner, > he will go free while the partner will get three years in prison on the main charge. > Oh, yes, there is a catch ... > > If both prisoners testify against each other, both will be sentenced to two years in jail. > The prisoners are given a little time to think this over, > but in no case may either learn what the other has decided until he has irrevocably made his decision. > > Each is informed that the other prisoner is being offered the very same deal. > Each prisoner is concerned only with his own welfare, with minimizing his own prison sentence. This leads to four different possible outcomes for prisoners A and B: - If A and B both remain silent, - they will each serve **one year** in prison. - If A testifies against B but B remains silent, - **A** will be set **free** while **B** serves **three years** in prison. - If A remains silent but B testifies against A, - **A** will serve **three years** in prison and **B** will be set **free**. - If A and B testify against each other, - they will **each serve two years**. ### The Iterated Prisoner's Dilemma It is just like the regular game except you play it multiple times with an opponent and add up the scores. But it can change the strategy and has more real world applications as it resembles a relationship. {{ youtube(id="BOvAbjfJ0x0") }} --- This is closely related to trust, human behavior, and social constructs in relationships that impact us both individually and collectively. In the Prisoner's Dilemma, the best strategy is to start with cooperation, but then mimic the other player's previous action in the following rounds, rewarding cooperation and punishing betrayal. {{ youtube(id="S0SQLQMLi8Q") }} > Don't trust, verify. --- ## What Kills Agility? Date: 2024-05-30 URL: https://chemaclass.com/blog/what-kills-agility/ Tags: agile, xp, leadership, team-management, communication > Why Agile, if you already do Scrum, Kanban, SAFe, or Waterfall? How we manage an organization defines its quality. Excellent management is crucial to avoid the Waterfall trap if we aim to build an Agile environment. But why would we want that? What's wrong with the way we already work? Dozens of documents and spreadsheets, meetings over meetings, and yet without much impact, result in team misalignments, realized too late. How we manage an organization defines its quality. Excellent management is crucial to avoid the Waterfall trap if we aim to build an Agile environment. But why would we want that? What's wrong with the way we already work? If you are already happy with how you and your team work together, that's okay. However, what about reevaluating how you work to look for potential improvements? I am referring to evaluating your system and how you and the people around you act within it. What worked months or years ago might differ from what we could discover today, as part of continuous improvement. I dislike politics in the workplace, where each team looks out for themselves instead of having a bigger shared direction. This results in daily work filled with fear from above, passed down to the people below, maintaining an [unhealthy working environment](/blog/unhealthy-working-environment). Game of Thrones is great as a fictional series, but not something to deal with in daily business. Agile was born precisely as a response to the excessive waste generated by politics and organizational micromanagement. Controlling and “slow performance” needed a more flexible approach. When people adopt a fixed mindset, they resist change, fear failure, and prioritize rigid processes and hierarchies. This conflicts with Agile's core ideas of embracing change, continuous delivery with iterative development, flexible planning, and fostering collaboration and innovation. A fixed mindset leads to fear of experimentation and a reluctance to challenge the status quo, reducing progress and the potential for learning and growth. --- ## What kills agility? - **Fixed mindset**: Resistance to change, fear of failure, and prioritizing rigid processes over learning and adaptation strangle innovation and flexibility. - **Excessive bureaucracy**: Complex processes and excessive documentation slow down decision-making and responsiveness. - **Micromanagement**: Over-controlling leadership undermines team autonomy. - **Lack of collaboration**: Poor communication and teamwork hinder progress. - **Ineffective feedback loops**: Prevent adjustments and continuous improvement. - **Fear of experimentation**: A culture that punishes failure discourages experimentation and learning from mistakes. - **Inflexible processes**: Strict adherence without adapting to project needs. - **Misaligned goals**: Conflicting priorities reduce efficiency. - **Lack of leadership's support**: Without backing from upper management, Agile initiatives can struggle to gain the necessary resources and commitment. - **Poor technical practices**: Neglecting technical excellence and good design can lead to a fragile codebase that is difficult to adapt and extend. ### What can you do about it? Learn the basics of Extreme Programming (XP) and Lean Software Development. - **XP**: Focused on software development practices and technical excellence, with specific practices like pair programming and Test-Driven Development (TDD). - **Lean**: Takes a broader approach, focusing on removing waste, optimizing flow, and improving processes across the organization. --- ## Learning Concurrency in Golang Date: 2024-04-02 URL: https://chemaclass.com/blog/learning-concurrency-in-golang/ Tags: golang, software-design, clean-code > I wanted to learn a new programming language, so after trying some, I ended up with Golang as one of my favorites for its simplicity and capabilities. It has features I haven’t used in years, like multithreading and concurrency. I wanted to learn a new language, so after trying some, I ended up with Golang as one of my favorites for its simplicity and capabilities. It has features I haven’t used in years, like multithreading and concurrency. [Golang](https://go.dev/) (or `Go`) supports concurrency through lightweight threads called goroutines. These are different from traditional multithreading, like in Java, where you have to handle sync and coordination to manage shared resources safely. In contrast, Go's goroutines are lightweight, managed by the Go runtime, and cheaper to create and manage. While parallelism is **doing** several things simultaneously, concurrency is about **dealing** with several things at the same time. When we talk about concurrency and parallelism, we don’t know the order of things. We don’t know what’s going to happen first or what’s going to end first. There is an undefined order of execution. > Imagine you cooking: preparing a soup, a salad and an omelet. You would be one single unit, but you are preparing different dishes. You might finish the salad first or the soup or the omelet… We cannot guarantee that! This would be concurrency, as you are alone dealing with several things. As soon as your partner comes and helps you cook, then we will be talking about parallelism. I remember building a similar game in `Java` when I was learning multithreading ten years ago… let’s use this opportunity to do it again with modern `Go`. I built a terminal game emulator that mimics one horse racing. Each horse is a goroutine that runs in a shared bidimensional matrix. Once a horse reaches the end, it notifies the shared channel between all other horses (running in different processes) and they all stop, showing in the terminal the winner of the race. I separated the code into four areas to help visualize it: - Entry point - Generating the board - Rendering the game - Moving the horses ### Entry point The struct `Horse` represents each Horse in the race. The game consists of a list of lines, in which each Horse is running. You can spawn a new process using the keyword `go` when invoking any function. In this game, this is used 1) to render the game `RenderGame()` and 2) for each horse's movement `startRuningHorseInLine()`. The goal is to keep the "rendering" and "movement logic" working in parallel. go func RenderGame(board [][]*Horse) { for { time.Sleep(renderDelay * time.Millisecond) RenderRaceBoard(board, nil) } } func RenderRaceBoard(board [][]*Horse, winner *Horse) { // use a "string buffer" to save the whole board state // so we can later use one IO call to render it var buffer bytes.Buffer buffer.WriteString("\n") for line := range board { renderRaceLine(board, line, &buffer, winner) } clearScreen() fmt.Println(buffer.String()) } func clearScreen() { cmd := exec.Command("clear") cmd.Stdout = os.Stdout cmd.Run() } func renderRaceLine( board [][]*Horse, line int, buffer *bytes.Buffer, winner *Horse, ) { buffer.WriteString(fmt.Sprintf(" %.2d | ", line)) var current Horse for col := range board[line] { h := renderRacePosition(board, line, col, buffer, winner) if h != nil { current = *h } } buffer.WriteString(fmt.Sprintf("| %s", current.Name)) if current.Equals(winner) { buffer.WriteString(" [Won!]") } buffer.WriteString("\n") } func renderRacePosition( board [][]*Horse, line, col int, buffer *bytes.Buffer, winner *Horse, ) *Horse { if board[line][col] == nil { buffer.WriteString(" ") return nil } current := board[line][col] if current.Equals(winner) { removeChars(buffer, col+1) for range board[line] { buffer.WriteString("-") } } buffer.WriteString(current.Letter()) return current } go func main() { //... winnerChan := make(chan Horse) for line := range board { // each horse will be moved in different processes go startHorseRunning(board, line, winnerChan) } // wait until one horse reaches the end winner := 0; col-- { if board[line][col-1] == nil { continue } // here we identify that there is a horse in // the following column, so we move it to the // current column, and we set `nil` the other one board[line][col] = board[line][col-1] board[line][col-1] = nil if col+1 == cols { winnerChan <- *board[line][col] } break } } ``` ### Source code The code displayed in this post is a simplified version, so if you would like to check the working source, you can do it here: [Chemaclass/go-horse-racing](https://github.com/Chemaclass/go-horse-racing). {% kudos() %} Thanks to my former Team Lead, Andrei Boar, who helped me review my first original solution and provided an [alternative solution](https://gist.github.com/zuzuleinen/79413aa7933d7d6c6d84ec6ba8c3910a) (simpler and better!), which I applied to my original code. The main learning was using a `chan Horse` to pass the winner Horse from `main()`, instead of using a `chan bool` and a `sync.WaitGroup` between all threads. {% end %} --- ## Effective Pair Programming Date: 2024-03-28 URL: https://chemaclass.com/blog/effective-pair-programming/ Tags: pair-programming, xp, tdd, communication, clean-code > A practical guide to pair programming that works: roles, rotation, when to pair, common pitfalls, and how to make sessions productive. What is pair programming? Two people working together on the same problem, at the same time. It is not about one person showing off their skills in front of another, nor one person afraid of making mistakes due to an impostor syndrome. Each person will have a role: - Navigator: he will pay attention to the bigger picture; eg: architecture, relation between collaborators, object design, etc. - Driver: she will pay attention to the small details; eg: naming, code conventions, writing syntax, object design, etc. > The pair could, and should, switch roles occasionally; eg: every X commits pushed, every 10 mins, … up to them. Pair programming should not be considered a practice only for "seniors" to juniors, but regardless of the team members' experience level. It is about the **collaboration flow**, the quality communication, the absence of feeling judged, and the idea of welcoming vulnerability with your peers, knowing they will support and help you. It is about constantly challenging each other, seeking the most pragmatic solution while keeping it simple. Always looking for **quick feedback** when speaking to each other, but also on the solution you agreed to implement and its direction. It is about the short, quick, and immediate feedback loop while talking to your partner, who **reviews your code on the fly**. You can guide as a navigator or help the driver validate their ideas in a broader picture. It is about the constant **sharing** of **knowledge** atmosphere by default, reducing bus-factors and silo-knowledge areas to the maximum. Increasing the focus by having two minds working on the same task simultaneously. It is about **team cohesion** and sharpening the feeling that we belong. When we understand each other's strengths and weaknesses, we will realize how much we can help each other grow. ## How can you practice pair programming? Pair programming can be done in different ways: - You can start and finish a task with pairing. You can time-box it to 30, 60, 90 minutes. Either way, it is recommended to have pauses in the middle - Pomodoro. - You can start the task together and stop when one of your peers feels confident enough to continue alone. > It is up to the team, and the task in context, to decide when and how to apply pairing to get the best out of it. This does not mean you must constantly work "no matter what" in pair. This is not about creating rules; on the contrary, it is about embracing this practice to the point you feel confident to choose when and how to use it to get the best out of it. Pair programming might become one of the best tools in your team toolbox for daily interactions. Not because you read it somewhere but because of the benefits you and your team will find. ### Common Patterns #### Different strategies for effective pairing - **Driver-Navigator**: One person is driving the code (with the keyboard), focusing on the detail aspect of the task itself. The other is a navigator (no keyboard), having a more abstract picture of the task in mind. - **Ping-Pong**: Frequent switching driver-navigator roles in small interactions, e.g., every N minutes, every N commits, etc. - **Backseat driver**: The navigator engages actively with the driver. - **Tourist guide**: The navigator passively learns with the driver. #### Anti-patterns while pairing - **The silent partner**: The navigator is not participating, and they are being silent. - **The solo act**: The driver ignores all inputs from the navigator. - **Distracted pair**: The pair does not focus on the problem to solve. - **The Dictator**: One person is telling what to do, ignoring the input from the other. - **Philosophical pair**: The pair is [bikeshedding](/blog/bikeshedding/) into irrelevant topics. - **The code war**: The pair does not reach an agreement and starts an unnecessary war, which wastes time and effort. **Want more?** Check this out: [Learning Through KATAS](https://www.figma.com/file/FCmGwRPIO8cLowDRraJhgr/Learning-TDD) ## The takeaway Pairing is not a rule to enforce, it is a tool to reach for. Use it when the task is complex, the knowledge is siloed, or the stakes are high. Skip it when the work is trivial. The goal is never "always pair", it is **better software and a stronger team**. Pick one real task this week, pair on it, and switch roles often. The benefits show up faster than you expect. {% kudos() %} Thanks to my friend [Manu](https://x.com/evrtrabajo), who helped me with this post. We even share a [workshop](https://phpconference.com/agile-culture/practical-tdd-workshop/) on this topic. {% end %} --- ## Deployments on Fridays Date: 2024-02-25 URL: https://chemaclass.com/blog/deployments-on-fridays/ Tags: agile, xp, leadership, productivity > I have heard multiple times, from various people, the idea of panic towards deploying on Fridays. How good is that idea of banning the day before weekend from delivering new value to our clients or customers? I have heard multiple times, from various people, the idea of panic towards deploying on Fridays. How good is that idea of banning the day before weekend from delivering new value to our clients or customers? The main argument in favor of NOT deploying on Friday is based on the idea that we "should be paranoid" with our software and that it could fail when we touch it. So, we "should assume" the worst whenever we deploy a new release version of our system. However, the critical factor here is Why? Why should we not deploy on Fridays? Is it OK to be afraid of our own software system, that we live in a constant panic of breaking it the day after we have done a deployment? How much impact should our releases have? How can we make sure the deployment won't break the live system? Your Continuous Integration/Delivery pipelines, end-to-end and other types of tests in place, automated scaling policies, a previous staging sandbox to perform even manual tests if necessary, etc., will determine the security and confidence for any of your releases. However, the quality of these topics is a deal-breaker to have enough confidence on how, when and why would it make sense to release to production. The goal is build a system where deployments to production should be as often, smooth and easy as possible; any time, any day. Being afraid of your system should not be the aim. On the contrary, it should be something to work towards to fix it. The team dynamics are also an essential factor here. If we establish fear of deployments on Fridays, and fear of our system, that will end up in lack of accountability by default. This reminds me of [The Five Dysfunctions of a Team](/readings/the-five-dysfunctions-of-a-team/). If you deploy small and frequent changes as soon as they can guarantee 100% quality value success, why delay such an incremental improvement to your system? Coming back to “Why should we not deploy on Fridays?” The only reason I can think of is being afraid that we have to work on Saturday on the broken thing we delivered on Friday. However, I wonder if any option was available, so we could have identified such a broken thing during the working Friday itself. Monitoring your live system is crucial to guarantee the health after each deployment. This is essential to ensure everything is working fine and smoothly. To build a resilience system, this should trigger alarms to notify someone responsible for addressing the issue, disable or revert the latest “broken” feature… there are many techniques to create awareness and act on them. In case of doubt, you could use feature flags to disable the feature you will deploy. Still, you prefer not to enable it during the weekend while keeping the option of adding value and deploying anytime always open. I believe **frequent** and **small releases** to production **are key**; any time, any date, as far as it makes sense, and there is a clear path to bringing value soon to the customer to get feedback ASAP. > Deliver quality value in small increments, as frequently as possible. Being able to deploy on Fridays (if needed or wanted) impacts the team's confidence. Similarly, forbidding deployments on Fridays impacts the team's self-esteem as well. --- ## Great Engineering Date: 2023-12-30 URL: https://chemaclass.com/blog/great-engineering/ Tags: software-design, career, communication, clean-code > Coding is not just another job. In the right environment, writing software can be really fun and, even more, it can be your personal hobby as well! So... you might be focused on coding, coding and more coding to level up your own career skills. Coding is not just another job. Writing software can be really fun and, even more, it can be your personal hobby as well! You might be focused on coding, coding and more coding to level up your own career skills. That itself is not bad at all! Practice makes the master, so a lot of coding will inevitably help you improve your coding skills… but there are [other aspects](/blog/the-path-to-seniority-in-software/) that you need to keep in mind in order to help you grow into a great engineer. As a software engineer, your job is not "just to write software" for its own sake, but to **use software to solve actual business problems**. To make that happen there are plenty of different methodologies out there, for sure. However, we must agree that you need to identify and understand your customer’s needs in order to know what to actually build. You need to know your product, at least until certain level, so you can design your software using a similar language closer to the business, which will help its evolution and overall quality. This will be beneficial for the future (and present) maintenance of the product. IT, Software, Product and People topics are highly interconnected, and having at least a common ground of understanding the relation between these can help the overall goal of every single individual. The result of a great team work is not equal as the sum of the individual parts, as it's multiplying the created value among their peers. To that, great communication skills are a key part of it in order to create as much clarity as possible from any different abstraction level. That's why a great engineer is a knowledgeable person about business, customer, product, and coding. Understanding these points have a strong impact on your daily work as it creates a difference between the average and the great engineer. --- Image original by [Nicola Ballotta](https://hybridhacker.email). --- ## Forming, Storming, Norming and Performing Date: 2023-11-25 URL: https://chemaclass.com/blog/forming-storming-norming-performing/ Tags: leadership, team-management, psychology, communication > Embarking on the path to high team performance involves understanding Tuckman's Model, a roadmap through the stages of forming, storming, norming, performing, and adjourning. In this blog post, we explore practical strategies for each stage, empowering leaders and team members to cultivate collaboration, manage conflicts, and achieve true synergy. In 1965, psychologist Bruce Tuckman developed a model (Tuckman's Model) that describes the stages of group development, forming and maturing into a cohesive and effective team. The model initially consisted of four stages: "_**forming**, **storming**, **norming**,_ and _**performing**_," adding one additional "_**adjourning**_" in 1977. It's important to note that teams may not always progress through these stages linearly, and they might revert to a previous stage under certain circumstances. ## Forming In this initial stage, team members are polite, tentative, and unsure about their roles. There is a reliance on the leader for guidance. > **Goal**: Members are getting to know each other, and there is a focus on defining the team's purpose, goals, and roles. ### Leadership approach - Provide clear direction and guidance - Clearly define team goals, roles, and expectations - Act as a facilitator, encouraging open communication and helping team members get to know each other. ## Storming Conflict and disagreement emerge as team members start to express their individuality. There may be power struggles and challenges to the leader's authority. > **Goal**: The team clarifies its goals, members learn to resolve conflicts and address differences constructively. ### Leadership approach - Facilitate conflict resolution - Acknowledge and address conflicts constructively - Encourage open and honest communication while guiding the team through the process of understanding and appreciating diverse perspectives ## Norming Cohesion begins to develop, and team members establish norms and values. Roles become clearer, and there is a sense of unity. > **Goal**: The team strives to establish norms, values, and a shared understanding. Members learn to appreciate each other's strengths and weaknesses. ### Leadership approach - Foster collaboration and inclusivity - Encourage team members to establish norms and values collectively - Recognize and celebrate individual strengths, fostering a sense of unity and mutual respect ## Performing The team is highly functional, with a focus on achieving its goals. Members work collaboratively, trust each other, and are mutually supportive. > **Goal**: The team is committed to its common purpose and operates at a high level of efficiency and effectiveness. ### Leadership approach - Empower autonomy and trust - Provide opportunities for team members to take ownership of tasks and projects - Foster an environment where individuals feel confident in their abilities and can collaborate seamlessly ## Adjourning (or Mourning) This stage involves the completion of the task or project. Team members may experience a sense of loss as the group disbands. > **Goal**: Acknowledge and celebrate the team's achievements, provide closure, and reflect on the overall experience. ### Leadership approach - Acknowledge achievements and provide closure - Recognize the team's accomplishments and express gratitude for individual contributions - Facilitate a reflective session to capture lessons learned and create a positive closure experience To develop a team to a high-performance level using [Tuckman's Model](https://en.wikipedia.org/wiki/Tuckman's_stages_of_group_development), **leaders** should be aware of the stages and **adapt** their leadership style accordingly. This involves providing **guidance and structure** during the _forming_ stage, **facilitating conflict resolution** during _storming_, **fostering collaboration and communication** during _norming_, **empowering autonomy** during _performing_, and **recognizing achievements** during _adjourning_. > Regular communication, team-building activities, and constructively addressing conflicts are crucial throughout the process. --- ### Video summary {{ youtube(id="-RwkZxGPQb8") }} --- ## How to Test Private Methods? Date: 2023-10-20 URL: https://chemaclass.com/blog/how-to-test-private-methods/ Tags: testing, tdd, software-design, clean-code > From time to time I have had to face this question: how to test private methods? I have put together in an article the techniques that I usually use. This is a question that I have encountered with some frequency for a long time. So I thought I would put together my thoughts on the subject here. ## Short answer Never. ## Long answer Never ever. --- ## What if...? If you really want to test a private method, consider extracting that private method logic into a separate class, and write a unit test for that class' behavior. > For this one, I was inspired by Fran Iglesias' [original post](https://franiglesias.github.io/test-private-methods/). --- ## Unhealthy Working Environment Date: 2023-10-11 URL: https://chemaclass.com/blog/unhealthy-working-environment/ Tags: leadership, team-management, communication, psychology > An unhealthy working environment can have various symptoms that negatively impact both the physical and mental well-being of employees. An unhealthy working environment can have various symptoms that negatively impact employees' physical and mental well-being. While writing about [The Peter Principle](/blog/the-peter-principle), I mentioned: _"Talk to each other. If you feel you can’t, that’s a **symptom of a non-healthy working environment**, and that’s something more significant to deal with."_ But what are those symptoms? ## Symptoms From all possible symptoms, these are the ones that I would highlight: High stress, poor communication, lack of recognition, micromanagement, lack of work-life balance, unfair treatment, lack of growth opportunities, unhealthy conflicts among colleagues, lack of clear goals and expectations, high turnover rates, low morale and motivation, and constant physical or emotional tiredness. Let's go one by one. ### High stress Excessive stress and pressure. This can be due to heavy workloads, unrealistic expectations, or a lack of support. ### Poor communication Ineffective communication, whether it's between colleagues, teams, or between management and employees, can lead to misunderstandings, frustration, and unhealthy conflicts. ### Lack of recognition When employees feel that their efforts are not acknowledged or rewarded, it can lead to feelings of demotivation and reduced job satisfaction. ### Micromanagement Overly controlling management styles can stifle creativity and autonomy, leading to frustration and decreased job satisfaction. ### Lack of work-life balance A healthy work-life balance is essential for employee well-being. Long working hours, excessive overtime, or unrealistic expectations can lead to burnout and reduced productivity. ### Unfair treatment Discrimination, favoritism, or unequal opportunities can create a toxic and divisive atmosphere among employees. ### Lack of growth opportunities When employees feel that there is no room for advancement or professional growth, they may become disengaged and unfulfilled in their roles. ### Unhealthy conflicts among colleagues Constant disagreements, conflicts, or a hostile atmosphere among colleagues can create a toxic working environment. ### Lack of clear goals and expectations Employees need clear guidance on their roles, responsibilities, and performance expectations. Unclear or constantly changing goals can lead to confusion and frustration. ### High turnover rates If there is a constant stream of employees leaving the company, it may be a sign that the working environment is not conducive to long-term employment. ### Low morale and motivation When employees are consistently demotivated or have low morale, it can lead to decreased productivity and a negative atmosphere. ### Constant physical or emotional tiredness Prolonged exposure to a non-healthy work environment can lead to physical and emotional exhaustion or even mental health issues. > It's important to note that these symptoms can vary from one workplace to another. Addressing these issues promptly and effectively is crucial to create a healthy and productive environment. ## What can you do about it? ### Yourself - [Embrace the change](/blog/embrace-the-change/) Who moved my cheese? - [The process itself is the goal](/blog/the-process-itself-is-the-goal/) How to focus and have self-discipline - [Have you always been like this?](/blog/have-you-always-been-like-this/) How to find a balance of growth and happiness ### Your managers and leaders - [Great leadership](/blog/great-leadership) Leadership starts within your own life and behaviour - [Understanding people](/blog/understanding-people) Misunderstandings, effective communication, and self-reflection --- ## The Peter Principle Date: 2023-09-30 URL: https://chemaclass.com/blog/the-peter-principle/ Tags: leadership, career, team-management, psychology > The Peter principle states that a person who is competent at their job will earn a promotion to a position that requires different skills. If the promoted person lacks the skills required for the new role, they will be incompetent at the new level, and will not be promoted again. A person who is competent at their job will get promoted to a position that requires other skills. If they lack the skills for the new role, they will be incompetent at the new level, and will not be promoted again. If the person is competent in the new role, they will be promoted again and will continue to be promoted until reaching a level at which they are incompetent. Being incompetent, the individual will not qualify for promotion again, and so will remain stuck at this final placement or Peter's plateau. --- > There are incentives at play. People work hard to reach a particular position or salary. Once they achieve that, some get lazy. Once people lose passion, they stop learning. They might fail to keep up with new developments, which might lead to poor work quality. To protect their comfort zone, they challenge any new idea or person that could make their life unconformable. Incompetent employees are often unhappy. {{ youtube(id="IbFr5DAyZBM") }} --- ## Have you experienced the Peter Principle? I've seen this several times during my 10-year career, working in different companies with people in various departments at different levels. It's indeed more dangerous than it seems because it can kill the spirit of a healthy environment and company. Creating awareness about this can help you to be cautious to avoid this from happening to yourself, or at least trigger warnings when you feel this might be happening to you. ### What can you do about it? If you can recognize this situation within your company, I recommend helping to create awareness about it. Talk to each other. If you feel you can't, that’s a symptom of an [unhealthy working environment](/blog/unhealthy-working-environment/), and that’s something more significant to deal with. If you are the one experiencing this in "first person," I would recommend you: - Talk to your manager; ask for training, mentoring, or whatever you need to get the skills you lack, from confidence, communication, or anything that could help your new role. Maybe you didn’t get enough or proper training for the new job, which requires different skills. - Consider pivoting back where you were good and keep mastering that, helping and inspiring those next to you. Not everybody has to be promoted all the time. --- ## How Do You Get Everyone on Board? Date: 2023-08-02 URL: https://chemaclass.com/blog/how-do-you-get-everyone-on-board/ Tags: leadership, communication, team-management, mentoring, xp > I was invited to the WeAreDevelopers World Congress to give a tech talk about my experience with Extreme Programming and the profound benefits of embracing change in your work and life. I was invited to the WeAreDevelopers World Congress to give a tech talk about my experience with XP and the profound benefits of embracing change in your work and life. With more than 12k attendees, 300 speakers, and ~10 tracks in parallel, I was invited to give not one but two talks. One is about my experience with Extreme Programming and the profound benefits of embracing change in your work and life. I especially enjoyed the audience engagement and feedback they gave me after each talk. In particular, a question I had faced many times during my career: "**How do you deal with people reluctant to change?**" --- This is one of the most complex topics affecting any team, regardless of their profession. But, especially in our constantly changing software industry, if you are reluctant to embrace change, you will do more harm than good to your team, career, and yourself. As stated in [Peopleware](/readings/peopleware/), "*our software profession is less about computers and more about humans and their interactions*". This is usually the root problem for people; it's a human problem first. To become truly agile, you must have a good foundation of **trust** among your peers. Without trust, there is [no team](/readings/the-five-dysfunctions-of-a-team/), and the primary responsibility of a [good leader](/blog/great-leadership/) is to help create a trusted environment without fear of healthy conflicts. Everyone feels they can speak and express freely in a safe environment. A **safe environment** means you don’t need to carry on armor the whole day to protect yourself from others, so you will have more energy to drive excellence in your workplace. But still, despite your effort to create a trustable and safe environment, you might encounter people reluctant to change. For those, you might need to try different approaches. How can you help create trust among everyone? > Don't be afraid of failure; instead, think that everything you do is an experiment from which you will learn something. And anything that brings you closer to a better state is better than nothing. The key here is to find a way to connect with people by understanding how they understand their potential so you can empower them and help them grow. ### Grant time for reading 1:1 meetings are ideal for establishing personal connections with your peers. However, you might feel that the situation requires an additional push, especially if you have someone who doesn't like to speak about themselves, and it is hard to know what they think about what’s happening. Here is an idea you could try: - Give them a book containing ideas or knowledge that could benefit the whole. - Allow reading this book during work time, eg: on Fridays after lunch. This is a company investment for the development of your team. - The book should be read in 3-4 hours, or a couple of Fridays, depending on the number of pages. - Don’t wait until the book is finished to talk about it. Follow the progress. - You will have great topics to discuss during your next 1:1. ### You could use any book for this exercise Any book would be fine. Still, if you are looking for great examples, these are my favourite three to start thriving a conversation: - **[Who moved my cheese?](/readings/who-moved-my-cheese/)** is a metaphor of the different attitudes that people adopt as part of their identity in life when they have to confront any change. - **[Extreme Programming Explained](/readings/extreme-programming-explained/)** contains a compilation of values, principles, and practices highly related to the human touch in our software industry. Focusing on the team aspect, collaboration with your peers, and creating a sense of mastery and purpose in our craft. - **[Start with Why](/readings/start-with-why/)** addresses the importance of starting with "Why?" in order to define a purpose for anything we do. Experiment with any book, timeframe, person, or group to create a shared understanding of the team’s foundational values and motivations. The goal is to engage in active knowledge-sharing while cultivating a team that feels they belong, fostering passion at work. This will help create trust, and you can start building on top of it. > If you are looking for books to help scale up your leadership skills, there you go: "[Great Leadership](/blog/great-leadership)". --- You cannot force people to change. On the contrary, the more you try to force it, the harder they will make it for you. Instead, focus on understanding them by acknowledging what they feel and thinking about what they do to create a common ground of [understanding each other](/blog/understanding-people). > Photos from me at WeAreDevelopers World Congress, Berlin 2023. --- ## Never Ending Loop Date: 2023-07-05 URL: https://chemaclass.com/blog/never-ending-loop/ Tags: career, philosophy, productivity > It is hard sometimes to get to bed with the mind blank because, more often than not, I think about my next reading, learning, talk, or what I will write this or next month. It is hard sometimes to get to bed with the mind blank because, more often than not, I think about my next reading, learning, talk, or what I will write this or next month. It is funny to remind that eight years ago, I stayed up for hours until all kinds of thoughts got out on paper, so I used to write one or more of them every week. Sometimes innocent thoughts came to my brain and didn't let me sleep properly. Sometimes deep and full of worry that reflected how I struggled with certain situations that I was living in or remembering from my past youth. I kept writing for three years; I wrote a lot, another format than I usually do today; a deep and personal [book](https://chemaclass.com/books/) about my thoughts and feelings with the primary motivation of reading them later and doing some retrospectives to help me understand myself better. Nowadays, I like to mix my passion around software quality and people puzzles to achieve true excellence in my profession, always aiming for an honest and healthy egoism of helping others that could help me later. The better the people around me are, the better they will help others and me. Back then, I used to write about my current and past feelings, always with a touch of illusion wanting to express myself differently for my future self. I remember clearly, in the beginning, I wanted the main readers to be my siblings, my family, to know how I was doing so far away from all of them, after migrating to another country, far away from my family. However, as the months passed by, the main reader changed to be no one but myself. I spent hours on each thought, page, chapter… Drafting the initial idea and then reading it out loud once, twice, again, and again the day afterward. Helping this way to discover that part of myself that tried to reflect what was going on inside. I can see some similarities nowadays. However, I no longer see the need to write about those deep old past thoughts because they healed. Instead, I can reflect and see how they did and how. Writing is one of my favorite ways to express myself, especially when I cannot sleep. It reminds me of those years, and I think greatly about the incredible evolution since then. > Original photos from my trip to Tuscany, Italy, last month. --- ## Learned Helplessness Date: 2023-06-08 URL: https://chemaclass.com/blog/learned-helplessness/ Tags: psychology, productivity, career, philosophy > Learned helplessness is the behavior exhibited by a subject after enduring repeated aversive beyond their control. It was initially thought to be caused by the subject's acceptance of their powerlessness by discontinuing attempts to escape or avoid the aversive stimulus. Learned helplessness is the behavior exhibited by a subject after enduring repeated aversive stimuli beyond their control. It was initially thought to be caused by the subject's acceptance of their powerlessness by discontinuing attempts to escape or avoid the aversive stimulus. ## Experiments ### A classroom with different assessments {{ youtube(id="gFmFOmprTt0") }} > Charisse Nixon, Ph.D Developmental Psychologist at Penn State Erie, The Behrend College and Director of Research and Evaluation for The Ophelia Project discusses the phenomenon of learned helplessness. ### Original: Docking shocks and harnesses In 1967, the American psychologist Martin Seligman at the University of Pennsylvania researched docking shocks and harnesses. In **Part 1** of this study, three groups of dogs were placed in harnesses. Group 1 dogs were put in a harness for some time and released later. Groups 2 and 3 consisted of "yoked pairs." Dogs in Group 2 were given electric shocks randomly, which the dog could end by pressing a lever. Each dog in Group 3 was paired with a Group 2 dog; whenever a Group 2 dog got a shock, its paired dog in Group 3 got a shock of the same intensity and duration, but its lever did not stop the shock. To a dog in Group 3, it seemed that the shock ended randomly because their paired dog in Group 2 was causing it to stop. Thus, for Group 3 dogs, the shock was "inescapable." In **Part 2** of the experiment, the same three groups of dogs were tested in a shuttle-box apparatus (a chamber containing two rectangular compartments divided by a barrier a few inches high). The dogs could escape shocks on one side of the box by jumping over a low partition to the other. The dogs in Groups 1 and 2 quickly learned this task and escaped the shock. Most of the Group 3 dogs, which had previously "learned" that nothing they did affected the shocks, lay down passively and whined when shocked. --- Even though this experiment was demonstrated with different types of animals, it also applies to people. This is visible in children when they integrate early failure to ask for help, frustration, giving up, poor motivation, and procrastination. And these points carry on as people age. > Because, if you "cannot do anything", why would you even try it? All this leads to anxiety and depression, and people think nothing can be done about their current situations and feelings. ## Learned optimism The antidote to learned helplessness is **learned optimism**. These people are higher achievers, have better overall health, and have lower levels of depression. ### How do you practice it? - **Permanence**: bad events or failures are not permanent. So, you can recover faster than people stuck in these situations. However, good things or events happen for a good reason that you've worked on. - **Pervasiveness**: do not generalize failure. Failing in one area in your life should not affect other areas. - **Personalization**: bad events are external to blame, outside yourself, as you did all you could have done. Isolate the problem and don't extrapolate it to other areas. Stop generalizing failure. --- ### English {{ youtube(id="Z8n1oUhp-EM") }} ### Español {{ youtube(id="E99XmEIPmf8") }} --- ## Dedicated QA Teams in Software? Date: 2023-05-17 URL: https://chemaclass.com/blog/dedicated-qa-teams/ Tags: testing, tdd, agile, clean-code > This will be controversial, but let's talk about the QA position. The hidden truth behind the lack of software quality and why this should concern you if you write software. This will be controversial, but let's talk about the QA position. The hidden truth behind the lack of software quality and why this should concern you if you write software. ## QA is a role, not a position As a software developer, when you write software, you are responsible for the quality of whatever you're writing. A third person acting like QA could find that your solution doesn't work like expected, but how come? You might argue they might catch edge cases, but how could that be possible if the software was already tested previously? A software team's final goal is to make the QA position useless because they should find nothing but well-working software. But how do you get to that point? How can we ensure that the software we write is working as expected and there is no need for a QA person in our team? ## The hidden truth behind the lack of software quality Unfortunately, in our software industry, the demand for "fast, quick and dirty" projects ended up in poorly developed MVPs by simply applying patches and code over code with just manual testing checking happy paths, sometimes even ignoring edge cases. > "The deadline is in one week, so you better finish it on time!" We don't learn the importance of what automated testing can bring to our daily job, so we don't take it seriously, and therefore, we don't practice it enough. And, for that exact reason, because we don't practice it, we don't know how to perform it properly. Yes, I am talking about writing automated tests that prove the behavior of your software! Our inability to write testable code results in software that is hard to test, and thus we delegate testing to other third parties shifting the responsibility for the overall end quality of the product or service we write. ## Practice makes the master You must learn and apply proper testing techniques when they make sense. How and when effectively use test doubles, prepare solitary or sociable tests, which compromises and reasons backup your mind when choosing one or other paths toward your testing strategies? You are the latest and main responsible person in charge of your knowledge, so you better invest in yourself because no one else will do it for you. Look at everything you do as an opportunity for learning. Practice and get better by default at everything you do. If you don't know how to start, here is my favourite tip: you can always practice and improve your testing skills using code-katas. Read more about this topic [here](/blog/test-driven-development/). ## Nice theory, but… why bother? Manual testing is, of course, necessary. It is another testing strategy that I am not blaming or attacking. We might still need a dedicated person in charge of discovering what new features we want to build to satisfy our clients. But this blog-post is not about that position. It is all about shortening the feedback loop. If you can write software to work in specific ways, can't you write automated tests to prove that the software you wrote behaves the way you expect? If you have covered with automated tests the behavior of your software at any level that makes sense, what's left for a dedicated QA person? Next time you think about "We need a QA person to test this," try the exercise of thinking instead, "How can I write an automated test that verifies what I would expect if a QA person were checking this?" And that's how you change the "full-time QA position" into a "role mentality for everyone that writes software." Code never lies and never forgets; once it's written and automated in your pipeline, you can run it anytime at zero cost. --- ## Introducing a New Tech Stack Date: 2023-04-14 URL: https://chemaclass.com/blog/introducing-a-new-tech-stack/ Tags: software-design, architecture, team-management, communication > To introduce a new tech stack for the entire team, it's important to bring \ To introduce a new tech stack for the entire team, it's important to bring "why?" and a strategy to make it happen among the team because it will affect everyone. ## Why that new tech stack? To decide whether to use a new tech stack or not, remember that it is a team decision, according to the standardization and maintainability of the project when introducing such a new tech stack. But, most importantly, what problem do you want to solve by introducing it? Is it because it is "cool"? Or is there an actual "necessity" that this tech helps you with? ### The direction of the technology When proposing adopting a new library, framework, or entire new technology, an important aspect to consider is to be aware of its background and the direction where they are moving forward. What is the motivation for that tech, and why are you considering introducing it in your current stack? ### Coupling and dependencies When adopting new technologies in our daily business, it's not rare that we tend to couple ourselves with them. This makes it harder later to roll back if, after a while, we regret that decision. Don't get me wrong, learning and experimenting with new technologies is great, but introducing it in your daily work is another story because it will affect the whole team. So we need to be more careful with this. ## The focus of the conversation - What does this new tech contribute to the project? - What problem do we want to solve by introducing it? - Can we solve that problem with our current tech? - If we already have a similar tech, do we want to have a mix of both? - What are the tradeoffs when using it vs. not using it? - Is it worth the incremental complexity over time? - What is the team strategy to onboard everyone if we aim to use it? ### Architectural Decision Records (ADRs) Whatever the outcome, you should write it down as an [ADR](https://adr.github.io/) to revisit it as time passes. An ADR will record your team's decisions regarding the pros and cons, among any other arguments you have found together, to decide what to do and why. ADRs are useful to understand old decisions and keep them in the version control, in the same project if possible. They are helpful for the current team, but also for new joiners. {% kudos() %} Thanks to my friends [Manu](https://x.com/evrtrabajo), [Antonio](https://x.com/Tito_Kati), and [Jesus](https://x.com/JesusValera96), who helped me come up with this summary of ideas after brainstorming together. {% end %} --- ## Have You Always Been Like This? Date: 2023-03-16 URL: https://chemaclass.com/blog/have-you-always-been-like-this/ Tags: career, productivity, philosophy > Have you always been like this? Constantly reading books, writing blog posts, public speaker in conferences and meet-ups, learning in your private time, etc...? The short answer is: no, and let me tell you how I ended up in this situation. I've got this question recently, a couple of times, and this is a great topic to share. > "Have you always been like this? Constantly reading books, writing blog posts, public speaker in conferences and meet-ups, learning in your private time, etc...?" The short answer is: no, and let me tell you how I ended up in this situation. --- ## I used to be introvert I used to be an introvert, but with work and effort, I managed to master some public speaking skills. > Sharing knowledge is hard because first, you need to have it. I used to dislike reading; I always preferred other sources of getting information and learning new things. Of all of them, reading was the most boring one. > Reading is hard, because it needs your entire attention. However, I have always enjoyed writing since I was a kid. For personal circumstances, writing was a way to express and reflect on me, doing regular retrospectives about the ideas in my head. ### Writing to the rescue > Combining "sharing knowledge" and "reading" from and to myself. Writing was (and still is) a way to sort out my thoughts, especially during hard times; writing was a way to escape from the world. It helped me to understand myself better the day after. And it worked. Knowing your limitations can help you understand your reality and fight against it. Life is hard enough to accept whatever "is there," even if you are dissatisfied with it, especially if you have a reason for that. I learned that I don't want to waste my time in a life I will regret when I die. For that reason, I started seeking opportunities to grow at everything I do all the time. ### Will I always be like this? > "Are you all the time 100% learning and being productive?" You cannot be 100% productive all the time. That’s impossible because of our human nature. Life is about constant "ups and downs," which is also part of its beauty. It’s your responsibility to understand yourself; I mean, truly understand your emotions and your persona. These are questions that can help you keep the focus while building yourself. When asking these types of questions, try looking from a rational and external point of view. Leave out emotions and personal feelings. - Who are "you"? - What differentiate "you" from other people? - What differentiate "today's you" from "you a year ago"? - What about your "you" in 1 year? --- Within your context and possibilities, you are what you choose to be. And that’s what differentiates you from your past and your future. The actions you do, the way you communicate and interact with others, the decisions you choose, etc..., differentiate you. That’s what differentiates you from yourself at another point in time. This is why I enjoy reading (or listening to a book) per month. This is why I enjoy learning anytime, all the time. This is why I like to share what I know with others. This is who I choose to be. A few years ago, I wrote about [the process itself as the goal](/blog/the-process-itself-is-the-goal/), which says basically: "_Repetition is the key. Make it easier to do what you want to do. Make it harder to do what you want to stop doing. Enjoy the process: that's the goal._" ## How much time do I have? I like to prove myself wrong and challenge the status quo. I even decided to investigate, for example, how I could be one [speaker](https://chemaclass.com/talks/) in an international conference last year. The hardest step is always the first; once you're there, it's more fun than you initially thought. I might write a dedicated post about this "public speaking" topic. For now, you can check some tips I wrote about [improving your public speaking talks](/blog/improve-your-tech-talk/). Regarding reading, I need around 4 to 6 hours (on average) to finish a book. A typical working day can be divided into 3 slots of 8h; 8 sleep, 8 work, 8 leisure (or other obligations). I don't work on the weekend, so those days are 16h each of leisure/obligations. So, assuming I work 5 days per week, this means _5 days x 8 hours (working days) + 2 days x 16 hours (weekend) = 72 hours_ of leisure/obligations time within a week! ### Time is not the problem Within a month, I have **72 hours x 4 weeks = 288 hours** of leisure/obligations time to spare with my girlfriend, talking to my family, playing music, partying or chilling with friends, going to the gym, walking in a park, traveling to other cities..., but also going to the supermarket, doing the dishes, preparing the evening meals, clean the apartment, commuting to work..., all of this requires time as well. The problem isn't time but the priorities I define. Within a month, I can really do a lot of things. The issue I usually encounter is not having a clear goal about what I want to reach in the middle-long goal for myself. There might be others, but [The power of habits](/readings/the-power-of-habits/) and [Atomic habits](/readings/atomic-habits/) were the books I read so far about habits that impacted me the most, and I think they might help you if you are struggling with habits that you would like to change anyhow. It all starts by understanding yourself within your context. I don't expect things to change from one day to another. I enjoy experimenting, combining habits, and trying different approaches to improve and get the best out of them over time. Losing fear of failure and seeking constant and continuous improvement is a life-changing mentality. What keeps me moving is the time I have left and the idea of thinking, "**what would I like to have changed?**" And in such a case, "**Why didn't I?**" --- ## Great Leadership Date: 2023-02-27 URL: https://chemaclass.com/blog/great-leadership/ Tags: leadership, communication, team-management, mentoring > As organizations grow, leaders must shift focus from customers to employees. Key principles for scaling leadership effectively. As business scales, the leaders' primary focus must shift from customers to employees. Therefore, I would like to share what I consider critical points that any leader should address and focus on regularly. For each key point, you will have book recommendations that go deeper into the matter, giving you references from real experts behind them. --- I already wrote about the [beauty of leadership](/blog/the-beauty-of-leadership/), and as a quick recap, to become a leader, you need specific skills: - Excellent **communication**, giving support, and enabling your people - Leading by **example**, especially to become a better self - **Passion** for sharing your leadership skills, so you build other leaders To extend the previous post providing resources and examples, in this one, you will find books about the following topics: - Motivation - Leading through change - Empowering your people - Effective communication - Persuasion - Team dysfunctions - Management principles - CEO Mindset - Engineering leadership --- ## For "starting" leaders ### Motivation First of all, you need to define a **purpose** for your leadership. I would recommend "[Start with Why](/readings/start-with-why/)", as this can help you clarify the difference between great leaders and those who are not. > "The ability to inspire those around you and to achieve remarkable things starts with WHY." - Start with Why You need to be aware that leadership is not about being the boss of anyone but **serving** others. It would help if you were a role example that your people would copy and follow, especially in hard times. This is a leadership philosophy in which the leader aims to serve. "[Leaders Eat Last](/readings/leaders-eat-last/)" goes deeper into this topic. After reading the previous two books, if you are looking for more, the cherry on top is "[The infinite game](/readings/the-infinite-game/)", which is the third and last book (so far) by Simon Sinek. This book questions our daily mindset when confronting (business) problems. It's about the need of a _just cause, courageous leadership, trusting teams,_ and a _worthy rival._ > "There is no such thing as the one "right" organization. There are only organizations, each of which has distinct strengths, distinct limitations, and specific applications. An organization is not absolute. It is a tool for making people productive in working together." - The infinite game ### Leading through change Leading through change is something you have to face in many moments in your life, whether you like it or not. "[Who moved my cheese?](/readings/who-moved-my-cheese/)" is a tale about the different attitudes people adopt as part of their identity when confronting change. How do you eliminate bad habits and start creating good ones? "[The Power of Habit](/readings/the-power-of-habits/)" and "[Atomic Habits](/readings/atomic-habits/)" are great books that help you understand that habits are like a muscle. You can train them. > "Change how you identify yourself. The environment is more important than being motivated. Reduce friction for good habits and increase friction for bad habits." - Atomic Habits ### Empowering your people It would be best if you empowered your people to become leaders themselves. A great book I recommend is "[Turn the ship around!](/readings/turn-the-ship-around/)", in which the author challenges the commonly accepted **leaders vs. followers** model into a **leaders-to-leaders** relationship. > "Leadership is communicating to people their worth so clearly that they are inspired to see it in themselves." - Turn the ship around! ### Effective communication Communication is one of the most challenging skills you need because you constantly communicate with other people; with different backgrounds, experiences, expectations, and even understanding of life. And the important key aspect is not just what you say but how you say it to ensure your desired message is correctly delivered to the receiver. "[Leadership is Language](/readings/leadership-is-language/)" challenges the industrial-age playbook (where leaders give commands and employees follow them), giving you strategies that can help you such as: _control the clock, collaborate, commit, complete, and improve_. > "Your words matter more than you think." - Leadership is Language It is important to recognize our emotions and not let them control our actions. Creating an open, honest, and **safe environment** is crucial to create trust among your peers. "[Dare to lead](/readings/dare-to-lead/)" addresses that leaders need to be more vulnerable. It shows that solid values guide you to do what is correct rather than easy. The importance of trust and difficult conversations even when they make you uncomfortable. > "Great leaders must be brave and always dare to provide constructive feedback, speak the truth, and be clear about their expectations." - Dare to lead ### Persuasion Regarding communication, you might need some good persuasion skills to convince others about your ideas. "[Never split the difference](/readings/never-split-the-difference/)" is a book about negotiation (from one FBI's lead international kidnapping negotiator) that gives you great insides into how to negotiate effectively: negotiation begins with listening, using mirrors to encourage the other side to empathise, tactical empathy to getting an agreement, labelling emotions, among others. > "Negotiation begins with listening, making it about the other people, validating their emotions, and creating enough trust and safety for a real conversation to begin." - Never split the difference --- ## For "experienced" leaders Assuming you have read the books above (for "starting leaders") I can give you more recommendations. ### Team dysfunctions One of the most difficult areas from the communication layer is dealing effectively with conflicts; so "[The Five Dysfunctions of a Team](/readings/the-five-dysfunctions-of-a-team/)" is a great book which addresses the "absence of trust, fear of conflict, lack of commitment, avoidance of accountability and inattention to results" as a pyramid of dysfunctions that you need to pay attention. ### Management principles Although leadership is not the same as management, I find it quite useful knowing some theory behind management, and for this "[High Output Management](/readings/high-output-management/)" is a great starting point. After that one, if you want more, I can recommend something more advance with "[The Essential Drucker](/readings/the-essential-drucker/)", which addresses the essential principles of management. > "Management is about humans." - The Essential Drucker ### CEO Mindset Although not every leader might want to be a CEO, I find "[The Great CEO Within](/readings/the-great-ceo-within/)" a great book because this can help you understand the responsibilities from any organization's most abstract point of view. Similarly, "[Adapt or Die](/readings/adapt-or-die/)" is a great book that covers the fundamental aspects of overall responsibilities and capabilities to thrive in any business, addressing aspects such as Product, Strategy, Growth Engine, Financial Model, People, Operations, Process, and Leadership. > "Leadership is about helping people adapt and leading through change so the business and its people can thrive." - Adapt or die ### Engineering leadership Related to engineering and growing, I also recommend "[The Manager Path](/readings/manager-path/)", and "[The Art of Leadership](/readings/the-art-of-leadership/)", both great books; easy to read and full of wisdom. > "Managers tell you where you are; leaders tell you where you are going." - The Art of Leadership --- I hope I got enough attention to create awareness about the key areas you must work on. I am aware that many other books could be included in this list. You might have others on your shelf. These are just a reference, not necessarily better or worse than others. I still have many other books I want/will read over time. Still, I thought it would be interesting to compile these already, aiming to create value, sharing especially for those who don’t know where to start or how to become better leaders themselves. However, these are the essential points to remember: - You need to have **passion for your work** and share this passion with the people around you. You cannot expect passion from your peers if you don’t have passion for what you do. - You need to **empower your people**, creating leaders instead of folks who follow orders from their superiors. - You need to learn how to create a **safe environment**, which is crucial for trust and honest relationships. - You need to help **create agreements** when dealing with conflict resolutions. Avoiding healthy conflicts doesn't help long-term relationships. - You have to look for **opportunities to grow** everywhere and help our team grow with you. Your primary responsibility is to help others improve, and this is only possible if you **embrace the change** and **start with yourself**. ### All mentioned authors - Simon Sinek: [Start with Why](/readings/start-with-why/), [Leaders Eat Last](/readings/leaders-eat-last/), [The infinite game](/readings/the-infinite-game/) - Spencer Johnson: [Who moved my cheese?](/readings/who-moved-my-cheese/) - Charles Duhigg: [The Power of Habit](/readings/the-power-of-habits/) - James Clear: [Atomic Habits](/readings/atomic-habits/) - L. David Marquet: [Turn the ship around!](/readings/turn-the-ship-around/), [Leadership is Language](/readings/leadership-is-language/) - Brené Brown: [Dare to lead](/readings/dare-to-lead/) - Chris Voss: [Never split the difference](/readings/never-split-the-difference/) - Patrick M. Lencioni: [The Five Dysfunctions of a Team](/readings/the-five-dysfunctions-of-a-team/) - Andrew S. Grove: [High Output Management](/readings/high-output-management/) - Peter F. Drucker: [The Essential Drucker](/readings/the-essential-drucker/) - Matt Mochary: [The Great CEO Within](/readings/the-great-ceo-within/) - Thomas H. Douglas: [Adapt or Die](/readings/adapt-or-die/) - Camille Fournier: [The Manager Path](/readings/manager-path/) - Michael Lopp: [The Art of Leadership](/readings/the-art-of-leadership/) ## Extra: Leadership Guide for the Reluctant Leader Especially if you are a software developer, this video is for you. > "Leadership is for everybody. It is for all y'all." {{ youtube(id="3PcL8UkorEg") }} --- ## Interview About XP and Agile Date: 2023-01-09 URL: https://chemaclass.com/blog/interview-about-xp-and-agile/ Tags: agile, xp, tdd, communication > My interview with devm.io regarding Agile and Extreme Programming. Agile is more about HOW you do certain things, rather than WHAT things you do. My interview with **devm.io** regarding Agile and Extreme Programming. --- **devm.io: We talked to Chema, a software developer and an Extreme Programming expert, about his favourite topic and his upcoming live event [Update Your Team To Be More Extreme](https://devm.io/update-your-team-to-be-more-extreme/).** ## Could you tell us a little about yourself, who you are, and what you do? Chema: My name is Jose Maria Valera Reales, but everyone calls me Chema. I’m originally from Spain but have lived in Berlin since 2015. I’ve been working as a software developer since 2013. In recent years, I have focused on achieving excellence and figuring out how to help my peers and, with them, the entire software community to improve in our profession. I am currently a Tech Lead at [Lautsprecher Teufel GmbH](https://teufel.de/), where I work with the e-commerce webshop team. I also enjoy [open-source software](https://github.com/Chemaclass), so I enjoy creating pull requests for other repositories, and I also love when I receive pull requests from others. ## How would you describe Extreme Programming? What makes it so "extreme?" Extreme Programming is the most straightforward and pragmatic approach to embracing Agile in your software team. It incorporates solutions based on values, principles, and practices. You don't have to use or do everything, but rather whatever fits you and your team in your context. However, these are helpful general solutions that work better when combined. From my experience, the word "extreme" can be misleading, but I see it as an opportunity to emphasise the difficulty of the fundamentals behind it. The critical point is realising that our "common sense" is not as "common" as we tend to think, nor the best practices for practical teamwork. Therefore, this is about pushing ourselves to extreme effectiveness, collaboration, and satisfaction while working with others. ## You will host a live event on devm.io on the topic on January 19th. Could you give us a sneak peek of what your audience can expect? We will explore how a software team works nowadays, the common issues we encounter, and what solutions we could apply to improve our team routines. We will look for the real meaning of Agile, focusing on Extreme Programming ideas. In addition, I will share some ideas to help your team create learning opportunities with concrete examples that any team can incorporate into their current work. ## During the event, you will also tell us something about Katas. What exactly are Katas? The term "kata" comes from the repetitive movements done in karate that help you improve your fighting skills. Why "code katas?" Because as a group, we need to practice more. Most of our learning takes place on the job, so most of our mistakes are also made there. And because we want to keep PROD, we're reluctant to try new things. Katas exist to help developers get the same benefits you would get from practice in any other profession. These simple, simulation exercises let you experiment and learn without the pressure of PROD. There are no right or wrong answers in any software kata: the benefit comes from the process, not the result. There are katas to help you improve your refactoring skills (such as Gilded Rose Refactoring Kata by Emily Bache) or your testing skills (easy ones like Fizz Buzz or Roman Numerals, or more advanced ones like the Bank Kata by Sandro Mancuso). They're also great for building confidence when programming with others, watching and practising different roles collaboratively, fostering team cohesion, etc. ## What role do Agile methods play in software development for you? The very first question here is to define what Agile methods are. In the end, everyone communicates somehow, provides feedback to others, and simplifies to some level. Sometimes people have the courage to speak their minds and sometimes they do not, and usually, they try to respect their peers. So, for me, Agile is more about "how" you do certain things rather than "what" things you do. Agile is a highly collaborative working process at any level, which might have a challenging learning curve at the beginning, but it pays off sooner than you might expect. ## Which topic in the area of agile should receive more attention? Team building and embracing agility, starting with asking "why?" We need to challenge the status quo more often and ask ourselves why we work the way we do and how and what we could do differently to keep improving and never stop learning. > You can also read the interview from the original link: [https://devm.io/agile/extreme-programming-agile](https://devm.io/agile/extreme-programming-agile). --- ## Ignoring Scrum to Get More Agile? Date: 2022-12-06 URL: https://chemaclass.com/blog/ignoring-scrum-to-get-more-agile/ Tags: agile, scrum, communication, productivity > People become slaves to systems that are supposed to help. Boring meetings are killing agile. Meetings require active participation from everyone. Otherwise, you might not be essential to that meeting, and rather use your time with something else. Talking to a friend about agile, he asked me a fascinating question remarking how badly sometimes Agile and Scrum fit together, especially regarding meetings. These are my thoughts about this topic. > "Do you think it would make sense to just use agile and ignore scrum (sprints) completely in a product based > development company. I feel it's hard to be agile when you have 10 hours of meetings per week." Filip G. That is related to the essence core of [Extreme Programming](/readings/xp-embrace-change/), which is the first value: Effective Communication. > "Probably some companies just don't know how to properly use meetings and just have them out of habit." Filip G. I wouldn't say completely ignore Scrum. Scrum (when done well) is a great "Product Management" Framework. To improve your understanding of Scrum I recommend reading: [Scrum: The Art of Doing Twice the Work in Half the Time](/readings/scrum-the-art-of-doing-twice). The main issue with scrum nowadays is that management took control over the whole thing, and developers are not really educated about how to practice Scrum properly (in a real Agile way), and that's where the problem starts. For this, I recommend a book that addresses pretty well the common issues that most Scrum teams face in a fun and easy-reading book [Zombie Scrum Survival Guide: A Journey to Recovery](/readings/zombie-scrum-survival-guide/). It's not about Agile yes, and Scrum no. They are totally compatible. The issue is to create awareness about how to focus the team processes from an agile point of view. ## Agile in a nutshell I recently wrote a blog post about agile fundamentals, which I recommend you to read to get into the details: [Working agile with non-agile teams](/blog/working-agile-with-non-agile-teams/). But, the **tl;dr**: Agile is about quick feedback. It's about effective communication and reducing waste while aiming for simplicity. [Agile](https://agilemanifesto.org/) is about keeping these values always present: - Individuals and interactions over processes and tools - Working software over comprehensive documentation - Customer collaboration over contract negotiation - Responding to change over following a plan > While there is value in the items on the right, we value the items on the left more. ## Scrum in a nutshell Scrum is a framework for project management emphasizing software development, although it is used in other fields like sales, marketing, and more. It's designed for teams of 5 to 9 people (see [Dunbar number](/blog/dunbar-number/)) who are totally autonomous and responsible for breaking down their work into small chunks that can be completed in a time-boxed iteration, called sprints, usually 1, 2, or 4 weeks. It's common to find certain ceremonies/meetings like: - **Stand-up**: 15 min (or less) to keep everyone in the team sync and updated about the work and call out for action when anyone is blocked or needs special attention or help. - **Refinement**: 2h? meeting to make sure the tickets are in a good shape before planning them to be worked on in the next sprint. - **Planning**: 2h? meeting to plan the work to be done in the next sprint. - **Demo/Review**: 2h? meeting to show the work done for the whole team, stakeholders and other interested people. - **Retrospective**: 2h? meeting intended to enable the team to reflect and improve. The critical question is how your team organizes these meetings and, most important of all, how effective these are. These above are just some of the important meetings you have in any “Scrum Team” nowadays. Still, apart from those, you might encounter a lot of additional meetings that pile up, and suddenly your entire working day is gone, and you feel you didn't produce the value you expected. Unless your job is being in meetings every time, like coordinating projects and talking to people all the time, it seems something is wrong. ### Boring meetings Have you ever been in any of those meetings and thought, "_This is boring, what a waste of time..._". Well, I've experienced that more than once. Who's to blame? That would be the very first question that could come to your mind. Followed by, "_My boss, obviously, because he/she organized that meeting, to which I got invited, therefore I am forced to attend, and this wasting time is their fault._" This is a tricky question, and I don't think it is an honest answer. However, there is an easy explanation for this answer: pushing away responsibilities and blaming others rather than yourself is way easier. "_I am forced to attend, and this wasting time is their fault_" it could be that that's actually the actual fact. You were really forced, and you're wasting your time, and there is no other way… but is there no way to act on it, really? When something doesn't work the way I expect (e.g., I don't like the outcome, or I think something is off), before blaming and pushing away responsibilities to others, I want to reflect on it and identify the root of the issue. What could I do to make the situation better? --- ## What can you do about it? Coming back to this context of "many meetings", if you see yourself in a meeting again that feels off or boring, try asking yourself: > Am I feeling bored? Why so? Is it possible that I am not participating in the desired outcome of the meeting? And if > so, is my presence here in this meeting really necessary? Could I simply ask for a summary afterward and jump outside > the meeting to do something more productive? > > Contrarily, is it OK to feel bored in this meeting? Or should I participate and engage with my peers to > contribute to the outcome of the meeting? In these situations, I encounter a pattern such as: - If the meeting is not boring, it is productive and will produce a rich outcome for you and, hopefully, all participants. - If the meeting is boring, then either A) it is OK to be boring, politely ask to leave, and you will get the summary afterward, or B) it is not OK to be boring. Your participation is necessary for the outcome of the meeting. Try being more engaging with your peers, and the meeting won't be boring. In the end, there are a lot of strategies, and it's up to you to act on them whenever you see something that could be improved. It's OK to point out the "_elephant in the room_" and ask for help to improve any situation you think (or feel) is not working as it should. --- ## Working Agile with Non-Agile Teams Date: 2022-11-11 URL: https://chemaclass.com/blog/working-agile-with-non-agile-teams/ Tags: agile, xp, communication, team-management > Let's assume you already know what the agile manifesto is. Let's consider that you apply most of the extreme programming values, principles, and practices. How can you work with other teams that aren't agile? Let's assume you already know what the agile manifesto is. Let's consider that you apply most of the "extreme programming" values, principles, and practices. How can you work with other teams that aren't agile? > - Individuals and interactions over processes and tools > - Working software over comprehensive documentation > - Customer collaboration over contract negotiation > - Responding to change over following a plan You're using short feedback loops, where things are constantly changing. You can feel that the team is alive and every one is essential. You **embrace the change** to the point that you **enjoy** going out of your comfort zone whenever needed. Seeking to create **value** for your team and its dynamics, and always considering personal growth. But sure, let's assume all that, and everything else I might have missed regarding "**agility**," how could you work with an external team that is not agile? How could your "perfectly agile team" work with another group of people with nothing to do with software? For example, a doctor. A doctor has no time to learn about your "agile values and principles for software development." A doctor has no time to learn about "extreme programming." Similarly, they don't have time to learn about testing, design, architecture, and **good practices** related to software in general. How could you create a **bridge** between that doctor and your software team? ## How could you work agile with that doctor? If you need to work with that doctor is because he/she should be a domain expert. I suggest getting one or two of your team members to meet with that expert for 30/60 min, so they can talk and share their impressions. And then repeat this as much as possible to shorten the feedback loop. For example, once a week. Collecting those requirements and impressions from the experts and then driving the design of your software according to that is [Domain-Driven Design](https://en.wikipedia.org/wiki/Domain-driven_design). You can find a lot of documentation about *DDD* in books (like *[Domain-Driven Design Distilled](/readings/domain-driven-design-distilled)*) or in many blogs on the Internet. However, the critical aspect here is not what requirements or impressions are *being resolved* but **how**. How could you work agile with that doctor? > Agile is about quick feedback. It's about effective communication and reducing waste while aiming for simplicity. ### By truly applying these five values, you're already acting agile - Communication - Feedback - Simplicity - Courage - Respect These **abstract goals** apply to any profession, and even life, not just software. > Continuous communication helps shorten the feedback loop, which simplifies the tasks. Always with the courage to > address the truth and respect for each other. ### Practices are the things that you do - Sit Together - Pair Programming - Test First - Incremental Design - and many more And despite having a technical name, they might apply to any profession: > - Sit Together & Pair Programming: **think and do** with other peers > - Test First: **verify your assumptions** first, then solve the problem > - Incremental Design: whatever you do, **make it better** incrementally ### Principles guide and motivate the practices to the values - Mutual Benefit - Diversity - Failure - Opportunity - Baby Steps - Quality - and many more Mutual benefit is the most important because it's about finding practices that benefit us now, us later, and the customer too. > Other principles include the diversity of ideas. Don't be afraid of failure. Look at everything you do as > an opportunity for learning. Avoid giant steps because they have a higher risk of failing. Aim for a high-quality system > because they are more predictable and easier to change. ## The question remains: are you agile? I truly believe an agile team is the one who can cope with change at team level. Therefore, you must first master agile within your team, and then you can collaborate with other teams in an "agile way". Once you have internalized these points above, you can apply them while working with anyone from any team. While these isolated ideas are good, they are even more powerful when combined. They create an atmosphere of curiosity and active learning. It might even wake up some **passion** for your profession that builds an aura of team cohesion, and just like that, the team breathes on its own. Everyone cares and takes full responsibility for keeping the team healthy by building **trust**. There is no fear of healthy **conflicts**. They feel empowered and **accountable** to their commitments. The team **celebrates** their results and learns from their **mistakes**; there is no need for masks anymore. That's when the magic starts to happen, and suddenly you can work agile with any team, especially yours. --- ## Different Beliefs About Software Quality Date: 2022-10-08 URL: https://chemaclass.com/blog/different-beliefs-about-software-quality/ Tags: clean-code, agile, xp, communication, career > What to do when working on \ I recently got a great question on Twitter which got me thinking for a while and I decided to share my thoughts about it. --- ## The tweet that started this But first, some context: I am feeling great because the codebase where I work is getting better and better, so I am tweeting this: > "As software improves with time, you can feel you're doing right." And then I got a question asking for suggestions: So there we go... --- ## My answer ### Create agreements The first thing is to create agreements about what quality software means for your team and yourself. This helps clarify what software culture you want to establish and work towards that direction. Leaving your company should be the *last resort* once you have no other option. Before thinking about leaving your company, I would ask you: - **Why do you think** you cannot improve the working codebase of your company? - **What can you do** to reduce the friction between your different beliefs regarding what quality means for software? There is no perfect codebase to work on because software is a living entity and constantly changes. So, at least for me, quality software is the one that can cope with change smoothly. Once you have agreed on that goal, and while there are multiple ways to achieve that result, my favorite way of working is keeping an **agile mindset** with doses of **extreme programming** values, principles, and practices in mind. ### Software is about people Software is not just about writing _clean and solid code_. This is indeed desired, and we should aim for that, but we must first understand why we want that. The "_why_" is based on the **values** that you have as a team. If you don't share the same purpose, the same "why," then you won't _enjoy_ working together, and in such a case, I would advise looking for another company that shares your values. But, before that, I would strongly suggest fixing the deeper issue and helping your team improve. ### Understanding your why You first need to deeply understand your "_why_" so you can transmit this to your peers and the people around you. Have you tried all you can to create awareness about your "_why_"? Some ideas include encouraging collaborative programming (pair/mob), presenting some internal tech talks, creating a culture of sharing knowledge on a regular daily basis, creating awareness about the current status quo, and looking for opportunities to improve everywhere. ### Your career path If, after several months of (really) trying these ideas, none of them work, look for a new company that shares your beliefs. After all, you're the first and primary responsible person for taking care of your career path. > Original [twitter thread](https://x.com/Chemaclass/status/1578425454562021376). --- ## Extra thoughts If **you want something to be different**, don't wait till it's changed automatically. Try to **change it**; if it's not working, leave it. Maybe you don't belong in that place. On the other hand, it’s crucial to reflect if you see that pattern often repeating (changing companies too quickly). In such a case, maybe the problem isn’t the companies but yourself. Software development is not just about code but **business**. It's essential to be aware of finding a fair _trade-off_ between speed, costs, and quality, depending on the situation. You might want to use some _tech debt_ to conquer the market as soon as possible. It doesn't make sense to have "low quality" as part of the identity of any team. Every team has certain quality expectations. Therefore, the **key** here is to **agree on what good quality is**. {% kudos() %} Thanks to my former Engineer Manager, Evgenii Sokolov, who inspired me to write these extra lines after sharing the original post. {% end %} --- ## The Beauty of Leadership Date: 2022-09-25 URL: https://chemaclass.com/blog/the-beauty-of-leadership/ Tags: leadership, team-management, communication, mentoring > Leadership is action, not a title. It has nothing to do with management or hierarchy. What it really means and how anyone can lead. Leadership is not a synonym for management, it has nothing to do with titles or personal attributes. So, what is it? How can we become leaders? And most importantly, why? While researching this topic, I found ["What is leadership" by Kevin Kruse](https://www.forbes.com/sites/kevinkruse/2013/04/09/what-is-leadership/), which I liked particularly. I thought about sharing the key takeaways from that blog post as it expresses very well the general points about what *is* and what *is not* leadership. --- ## What is not leadership? Leadership has nothing to do with titles. Just because you have a C-level title, doesn't automatically make you a "leader". You don't need a leading title to become a leader. Leadership has nothing to do with your personal attributes. Leadership is not an adjective. You don't have to be an extroverted charismatic person to practice leadership. Leadership and management are not synonymous. Management needs to plan, measure, monitor, coordinate, solve, hire, fire, etc. Managers manage *things*. Leaders lead **people**. ## What is leadership? > "A leader is someone who has followers." Peter Drucker. This definition is too simplistic and can be dangerous. Just because you have "under you" some people that do what you say simply "following orders" doesn't mean that you are a leader. You might be a commander, but not necessarily a leader. > "The capacity to translate vision into reality." Warren Bennis. Every sprint, you envision fruits in your garden. And you work towards it and make that happen. This makes you a gardener, not a leader. > "Leaders will be those who empower others." Bill Gates. Empowering others is essential, but it's missing the vision or common goal. > "Leadership is influence." John Maxwell. A manager has the power to fire team members, which provides a lot of influence. Same as a robber with a gun who has "influence" over their victims. We are missing the source of influence. ### So, what about combining them all? > "Leadership is a process of social influence, which maximizes the efforts of others toward the achievement of a goal." Kevin Kruse Key elements of this definition: - Leadership starts from social influence, not authority or power - Leadership requires others, not necessarily direct reports - It includes a goal - No mention of a title or attributes of any kind *End from the key takeaways by ["What is leadership" by Kevin Kruse](https://www.forbes.com/sites/kevinkruse/2013/04/09/what-is-leadership/).* --- ## Why would anyone want to become a leader? We need to make clear that there are two different conceptions when asking that question, and we need to separate them from the beginning. There is the "leader title" aspect, which is usually attached to the management position. I am **not** talking about that one. You can be a great manager and an appalling leader. A leader is a person with the **multiplier** factor attitude that wants to develop specific skills (related to their social influence) to boost even more the value they produce. So, can anyone become a leader? What are those *skills* that you need to be a leader? ## Can everyone become a leader? Now that we found a definition of leadership, we can agree that this definition could have different degrees applied depending on the type of person and responsibilities they want. However, to become a leader, you need specific skills. These are the ones I find the most important: - Excellent **communication**, giving support, and enabling the people around you - Leading by **example**, especially to become a better self - **Passion** for sharing your leadership skills, so you build other leaders > Leadership starts within your own life and behaviour. I am aware that not everyone might want to accept the necessary changes to become a leader, but I truly believe everyone can grow certain leadership skills to some extent, which also means **inspiring** the people around you. ## How to become a better leader? You can get inspiration from a lot of different sources. While it's true that you can learn a lot from your own mistakes and successes, and even from the people around you, I think it's very optimal to listen to the wisdom from other people's experiences outside your circle. For example listening to podcasts, ted-talks, books, or even audiobooks. > The beauty of leadership is that it asks for no permission. No title, no promotion, no org chart. It begins the > moment you decide to lift the people around you. --- ## Understanding People Date: 2022-08-22 URL: https://chemaclass.com/blog/understanding-people/ Tags: communication, psychology, team-management > One of the most complicated challenges for everyone is avoiding misunderstandings and being aware that other people don't think the same way as you do. One of the most complicated challenges for everyone is avoiding misunderstandings and being aware that other people don't think the same way as you do. ## Different perceptions People have different experiences and backgrounds, and we all have different perceptions of reality. This is the first thing we need to be aware of if we want to create self-awareness of our role in communication with others or empathy. Very often, the real issue behind friction in a team is due to miscommunication. Sometimes no one knows how or why two or more team members don't like each other anymore, but the conflict is obvious. This can be a problem because it prevents the team from working as effectively as possible. Often, the reason for that friction is because of their **inability to understand each other's motivation and problems**. And this misfunction often leads to misunderstandings. ## Misunderstandings Our understanding of a conversation might differ from what the other person perceives, which could (and often will) cause a problem. This can become a serious problem related to the relationship's direction between both parties. ## How to solve this? Avoiding misunderstandings is not always easy, but by improving your communication skills, you can get better at this step by step. ### Empathy Empathy is the ability to understand what other people feel, see things from their point of view, and imagine yourself in their place. Essentially, it is putting yourself in someone else's position. ### Effective communication In most cases, the solution does not start by fixing the other person. Instead, it helps to work on **making yourself more explicit**. For example: - Work on clarifying the expectations around the common goal - Create an open and honest conversation about your expectations - Assumptions are dangerous - Provide as much context as needed - Even if it seems evident to you at first instance - Every little detail counts - More information is always better than less While aiming for effective communication, we need to **reduce the risk of misunderstandings to the minimum**. ### Self-reflection Healthy conflicts are expected and acceptable. We shouldn't be afraid of disagreements. It's ok to change our minds when discovering new possibilities; the sooner, the better. In my experience, understanding people is complicated for multiple reasons, but most especially because of misunderstandings we generate due to missing context, more than disagreements. If something doesn't work as expected, start looking at yourself, not blaming others when dealing with people. What could you have said to create more clarity? What would you do differently? Self-reflection is essential to improve and correct your attitude, adapting to the evolution of the constant change we are surrounded by, **especially when dealing with people**. > Look over your reach area, share your thoughts, and don't be ashamed of your mistakes as far as you take them as > learning opportunities. --- ## The Project Management Triangle Date: 2022-07-25 URL: https://chemaclass.com/blog/the-project-management-triangle/ Tags: agile, team-management, productivity > A triangle of time, quality and cost. it's an indicator that these three parameters are interconnected. You can fix one or two of them, but not three. A triangle of time, quality and cost. It's an indicator that these three parameters are interconnected. You can fix one or two of them, but not three. ### The triple constraint - Cheap and fast: the quality will suffer. - Cheap and good: it will take more time. - Fast and good: it will push the price up. ## Waterfall vs Agile In software methodologies, you can adapt this idea by changing **quality** to **scope**: ### Waterfall In waterfall projects, the scope is fixed, while the time and money will be more variable. Depending if it's more important finishing on time or on budget. ### Agile On the other hand, in an agile environment we usually work on a few weeks' iterations, so this is the fix part: the time, in order to deliver value as soon as possible, and so get feedback and recalibrate again and again. The costs in a software team are also fixed by the people that belong to it. > Time is fixed, cost is fixed, so by the rule of the iron triangle, the scope must be variable. An agile team cannot predict the scope of their work in one-year project, however, they don't need to. Their **focus should be on deliver constantly value as much as possible**, or at least at the end of every iteration, reflecting their learnings and recalibrating their priorities again and again. As you can see, one funny fact is that the waterfall and agile share an inverted triangle with their fixed and variables parameters. Really interesting indeed. ## Reference {{ youtube(id="MKEyF2dmGaM") }} --- ## The Path to Seniority in Software Date: 2022-06-08 URL: https://chemaclass.com/blog/the-path-to-seniority-in-software/ Tags: career, mentoring, clean-code, tdd, communication > Real seniority goes beyond job titles. It's about impact, mentoring others, owning outcomes, and raising the bar for your entire team. We all have been junior developers at some point. This is easy to know because it sits at the very beginning of your career. Your responsibilities were narrowed down by other peers who were looking after you. At some point, after months or years, you got your promotion or another job, where you weren't a junior anymore, but an intermediate. An intermediate (also known as middle) is something between junior and senior. You know now that you are not a junior anymore, you know how to deliver value but yet you also have mixed feelings about seniority. You want to be a senior, but you don't know how. There is no clear path to achieving this goal. Wait for a second… there are actually two easy ways to get the senior title! You can get promoted as such in your company, or you can start a new position as a "senior" in another company, easy right? ## Marketing and politics Unfortunately, the "seniority" level is very much polluted by marketing and politics. First, what does it mean "senior" in this context? In all the companies where I have been working (if not all) I have always been surrounded by people who claimed to be "seniors" when in reality only a few I would consider such. Our senior label is inflated by companies needing experts on paper more than in reality, and this is a problem we need to deal with and speak about. Seniority generally means more experience, but how do you calculate this? It is easy from a company's point of view: more years in the industry. But, is the number of years you have been working really relevant in an industry that is constantly changing and evolving? Actually, this wouldn't be a big issue if you have the software fundamentals well interiorized, but funny enough, I have seen these fundamentals in only ~10% of the seniors I have met across many years and several companies. The fact that you have been working for 10 or more years doesn't necessarily mean you are a "senior" with software. What else can we measure in order to identify if you deserve indeed this title? ### It is not all about the money Let us be honest, senior titles are better paid than junior or middle positions. If you have the chance to get a higher salary because you got the "senior" in your job title, well, it wouldn't be clever to reject it. But, independently of politics and marketing, we must address some seniority fundamentals to understand better what the word "senior" means in this context. > It is not all about the money, but also about the responsibilities that come with seniority. ## Seniority fundamentals Being senior in our software industry is not about "the number of years of experience" but: - How well do you **transmit your knowledge** to others? Sharing what you know is a core task for a senior person. - How well do you **collaborate** with other people, including the PM/PO and other teams? Collaboration is crucial to creating a constant feedback loop. - How well do you **work together** with your peers? Pair-programming builds team cohesion and helps everyone become better. - How strong are your **testing** skills? Testing is tied to the quality of your work, and a senior should aim for an incremental design. - How well do you understand **delivering value constantly** in small chunks? The sooner you deliver value, the sooner you get feedback about it. - How deep is your **technical knowledge** of quality software and the trade-offs to get there? SOLID principles, clean code, TDD, refactoring as part of your daily job, low coupling, high cohesion, appropriate data structures, and choosing the right solution (KISS, YAGNI...). - How well do you adapt and **cope with change**? Change is inevitable, so we must learn to deal with it, especially the parts we cannot control. - How developed is your **entrepreneurial thinking**? Always keeping the organization's goals in mind. As you can see, there is no mention of concrete technology or years of experience. Why? Because technology is just an "implementation detail", and experience comes by practicing and attitude, not by letting the time pass by. ### Attitude is important We've got two persons: A) a person who is working for 15 years, doing relatively the same every day, and without caring about his own skills. He just does what others tell him to do. B) a person who is working for 5 years, challenging herself every week, trying different approaches when dealing with problems, and sharpening her own skills constantly. Can you see the main difference? No, it's not the 10 years difference of "experience" between them, but their **attitude**. We wrongly understand that _a year of experience must come with learning and knowledge_, so we tend to use time as a measurement of seniority. But I argue that the "attitude factor" is equal or even more important. I have been surrounded by many people who call themselves seniors with 3, 6, 10, and more years of "experience" but lacking attitude, and you could clearly see this problem on a daily basis. > You need this combination to build yourself as a truly senior developer; time, experience, and most importantly: > attitude towards **improving your own skills and the ones that surround you**. ## Where to start Seniority is not granted, it is practiced. You don't wait for the title, you build the behavior until the title catches up. Start small, and start now: - **Teach what you know.** Pick one thing you understand and explain it to someone this week. If you can't explain it, you don't own it yet. - **Seek the uncomfortable.** Volunteer for the task slightly beyond you. Growth lives at the edge of what you can already do. - **Reflect on purpose.** After each project, ask what you would do differently. Experience without reflection is just repetition. The path is not a promotion. It is the daily decision to improve yourself and the people around you. Do that long enough, and the title becomes a formality. --- ## Bikeshedding Date: 2022-05-27 URL: https://chemaclass.com/blog/bikeshedding/ Tags: psychology, team-management, productivity, communication > Bikeshedding explains why teams waste time on trivial decisions while ignoring complex, important ones. Learn to recognize and avoid it. The term was coined as a metaphor to illuminate Parkinson's Law of triviality. People within an organization typically give disproportionate weight to trivial issues. ## Bikeshed +-ing The concept was first presented as a corollary of his broader "[Parkinson's law](https://en.wikipedia.org/wiki/Parkinson%27s_law)" spoof of management. "Bikeshedding" is a dramatized form of the "[Law of triviality](https://en.wikipedia.org/wiki/Law_of_triviality)". [C. Northcote Parkinson](https://en.wikipedia.org/wiki/C._Northcote_Parkinson) observed that a committee whose job is to **approve plans for a nuclear power plant** may spend the majority of its time on relatively unimportant but easy-to-grasp issues, such as what materials to use for the staff bikeshed while neglecting the design of the power plant itself, which is **far more important** but also far more difficult to criticize constructively. As he put it: > "The time spent on any item of the agenda will be in inverse proportion to the sum of money involved." ### People within an organization typically give **disproportionate weight to trivial issues** This has been true in all companies where I've been working. From time to time, when you have important mixed with not-so-important topics together (or even not important at all!), it's pretty common to see yourself "bikeshedding" with your peers about the trivial topics instead of confronting the important things that will bring real value soon to the end customer/consumer. This is more common than we think, and it can happen to everyone. ### What can we do about it? Create awareness about this problem with your team. Honest communication and trust are crucial for the solution. Break down steps: - You need to be aware of this problem. - You see value in changing this team behavior. - You are able to point to the problem when you see it occurring. - You expect the same from your team members. ### References {{ youtube(id="D4hUq_aNXaA") }} --- ## Dunbar Number Date: 2022-04-02 URL: https://chemaclass.com/blog/dunbar-number/ Tags: psychology, team-management, communication > Dunbar's number is a suggested cognitive limit to the number of people with whom one can maintain stable social relationships. A cognitive limit to the number of people with whom one can maintain stable social relationships, in which an individual knows who each person is and how each person relates to every other person. The study shows that: - Close relationship: 5 people. - Share deep trust: 15 people. - Meaningful relations: 50 people. - Active contacts: 150 people. ## Why is this limit 150? This is due to the limit of our cognitive ability. This is our ability to reason, solve problems, and comprehend complex ideas. As the team size increases, the cognitive load of the team does it as well and communication suffers, thereby breaking down the benefit of a large team. ### Origin In the 1990s, the British anthropologist Robin Dunbar found a correlation between primate brain size and average social group size. By using the average human brain size and extrapolating from the results of primates, he proposed that humans can comfortably maintain 150 stable relationships. Dunbar theorised that: > "this limit is a direct function of relative neocortex size, and that this, in turn, limits group size [...] > the limit imposed by neocortical processing capacity is simply on the number of individuals with whom a stable > inter-personal relationship can be maintained". The number also includes past colleagues, such as high school friends, with whom a person would want to reacquaint themselves if they met again. ## How is this related to Teams? - Single teams: 5-9 people. - There is a shared trust among the team members. - The trust is built over time. - Therefore, they must be a long term team. - Group: 50 people. - They can have meaningful relationships. - They share a domain or subdomain. - They understand the challenges and help each other out. - Division: 150 people ### References - [Robin Dunbar](https://en.wikipedia.org/wiki/Robin_Dunbar) - [Dunbar's number](https://en.wikipedia.org/wiki/Dunbar%27s_number) --- ## Update Your Team to Be More Extreme Date: 2022-02-26 URL: https://chemaclass.com/blog/update-your-team-to-be-more-extreme/ Tags: xp, agile, team-management, mentoring, tdd > Our profession is constantly evolving; therefore, it demands a non-stop learning process. Embracing the change is not optional in our software industry. We need to create spaces to get out of our comfort zone. Our software profession is constantly evolving; it demands a non-stop learning process. We must embrace the change in our industry. We need to create spaces to get out of our comfort zone, so our cognitive brain can train and improve how to adapt to our surroundings, which are constantly transforming. ## Why code katas, tech talks or research Fridays? The goal is to help create an environment that aims for continuous improvement towards looking for learning everywhere, all the time, as the core attitude for the individuals and the group. ### Create learnings opportunities > Schedule some time every X weeks for practicing together. At the end of each iteration, or even 2 or 4 weeks, we celebrate and work on katas in pairs/mob for 2 hours. That space is also an opportunity to create an internal tech-talk presentation to share exciting knowledge with the team non-directly-related to our "regular daily business". The goal is to get out of our comfort zone, improving our recognition for change in general while learning other subjects regularly. ## What is a code kata? As a group, software developers don't practice enough. Most of our learning takes place on the job, so most of our mistakes get made there as well. The term "kata" comes from the repetitive movements done in karate that help you improve your fighting skills. Code Katas exists to help developers get the same benefits as practicing in any other profession. There are simple, artificial exercises that let you experiment and learn without the pressure in a production environment. > There are no right or wrong answers in any software kata: the benefit comes from the process, not the result. ### Motivation - Work on refactoring techniques. - Work on TDD examples. - Work on SOLID principles. - Work on live coding sessions. - Work on driver-navigator concepts. - Work on team cohesion. - Have fun while learning and practicing together. If you're interested in my thoughts about TDD and katas, I wrote a post about it not long ago: [Test-Driven Development](/blog/test-driven-development/). ## What is a tech-talk? Tech talks allow us to share some knowledge related to our tech industry with our team members. It can be any FrontEnd, BackEnd, DevOps related. But I encourage also: - a new programming language that you are learning, - a summary of one book that you finished, - a new technology that you are studying or feeling curious about, - a piece of software that you would like to share and present thoughts about it, - a new tool that helps you to improve your productivity, - really: anything related to creating value or knowledge. ### How can I present a tech talk? I wrote this article with some tips about [how to improve your tech-talk](/blog/improve-your-tech-talk/). Some key questions that might help you to find something on your own: - What have you learned recently (in the last X months)? - What knowledge might be interesting to be shared with your peers? - Which aspect of yourself you'd like to improve professionally and/or personally? > Just one rule: Be curious and "[embrace the change](/blog/embrace-the-change/)." ## Research and learning Fridays Block the last Friday of the month for research and learning purposes. The whole team will have a dedicated space for growth and experiment. It's crucial to build trust with your team, so you all know everyone will use this time as good as possible. Don't micromanage this time forcing keeping a record in a wikipage with what everyone does in detail. Although, it would be nice that the team shares what they do during this time, mostly to create transparency among themselves. A verbal announcement to the peers the day before, with their intentions. Even the day after with the learnings key-takeaways. ### Summary You can help your team to be more extreme by helping with a dedicated team space for growth and experimentation. - Provide flexibility to experiment with these ideas as they see fit. - It is an opportunity for self-growth and learning at the same time. - It is, ultimately, up to the person and the team. > Do not micromanage this dedicated time. Focus on the outcome. Help your team to grow, and they will enjoy growing with you. ## Tech Talk After writing this blog post (originally in Feb, 2022), I was invited to do a [tech talk](/talks/update-your-team-to-be-more-extreme) in different conferences about this topic. --- ## The Power of Authority and Obedience Date: 2022-01-24 URL: https://chemaclass.com/blog/the-power-of-authority-and-obedience/ Tags: psychology, leadership, communication > Milgram was interested in researching how far people would go in obeying an instruction if it involved harming another person, and how easily people could be influenced into committing atrocities. For example, Germans in WWII. Milgram was interested in researching how far people would go in obeying an instruction if it involved harming another person, and how easily people could be influenced into committing atrocities. Eg: Germans in WWII. ## The experiment During the 1960s, the psychologist Stanley Milgram conducted a series of obedience experiments directly related to the power of authority and obedience, even when they might end-up in fatal ending. Milgram examined justifications for acts of genocide offered by those accused at the World War II, Nuremberg War Criminal trials. Their defence often was based on "obedience", that they were just following orders from their superiors. Milgram came up with the experiment to answer this question: > Could it be that Eichmann and his million accomplices in the Holocaust were just following orders? > Could we call them all accomplices? ### The procedure The selected participants for his experiment were by newspaper advertising to take part in a study of learning at Yale University; 40 men were recruited, and in exchange for their participation, each person was paid $4.50. The participant was paired with another person and they drew lots to find out who would be the "learner" and who would be the "teacher". The draw was fixed, so that the participant was always the teacher, and the learner was one of Milgram's confederate (pretending to be a real participant). The learner was taken into a room and had electrodes attached to his arms, and the teacher and researcher went into a room next door that contained an electric shock generator and a row of switches marked from 15 volts (slight shock) to 300 volts (severe shock) to 450 volts (XXX). The learner gave mainly wrong answers (on purpose), and for each of these, the teacher had to give him an electric shock. When the teacher refused to administer a shock, the researcher gave a series of orders to ensure they continued: 1. "Please continue." 2. "The experiment requires that you continue." 3. "It is absolutely essential that you continue." 4. "You have no other choice; you must go on." ### Results 65% of participants (teachers) continued to the highest level of 450 volts. All participants continued to 300 volts. Milgram did more than just one experiment. He carried out 18 variations of this study. All he did was alter the situation to see how this affected obedience. ### Conclusion The simple explanation would be that it was something about them as people that caused them to obey, but a more realistic explanation is that the situation they were in caused them to behave in the way that they did. Some of the aspects of the situation that may have influenced their behaviour included the location, the behaviour of the researcher and the fact that it was an experiment for which they had volunteered and been paid. People tend to obey orders from other people if they recognise their authority. This response to legitimate authority is learned in a variety of situations, for example in the family, school, and work. {{ youtube(id="rdrKCilEhC0") }} --- ## Milgrams' agency theory Milgram explained the behaviour of the participants by suggesting that people have two states of behaviour when they are in a social situation: - The autonomous state: people direct their own actions, and they take responsibility for the results of those actions. - The agentic state: people allow others to direct their actions and then pass off the responsibility for the consequences to the person giving the orders. They act as agents for another person's will. Two things must be in place for a person to enter the agentic state: 1. The person giving the orders is perceived as legitimate for that. 2. The person being ordered believe that the authority will accept responsibility for what happens. For example, when participants were reminded that they had responsibility for their own actions, almost none of them were prepared to obey. In contrast, many participants who refused to go on did so if the researcher said that he would take responsibility. ## Milgram experiment variations Among many others, these are some of the variations: ### Uniform When the role of the researcher was taken over by an "ordinary person without a uniform" (always a confederate), the obedience dropped to 20%. ### Change of location Obedience dropped to 47.5% when the experiment was moved to a set of offices instead of the impressive Yale University. ### Social support condition Two other participants (confederates) were also teachers but refused to obey. One at 150 volts, and the other at 210 volts. The presence of others who are seen to disobey the authority figure reduces the level of obedience to 10%. ### Absent experimenter condition When the researcher instructed and prompted the teacher by telephone from another room, obedience fell to 20.5%. Many participants cheated and missed out shocks or gave less voltage than ordered. The proximity of authority figure affects obedience. ### The moral questions Milgram raised Why did so many of the participants in this experiment perform a seemingly sadistic act when instructed by an authority figure? According to Milgram, there are some situational factors that can explain such high levels of obedience: - The physical presence of an authority figure increased compliance. - The fact that Yale (a trusted academic institution) sponsored the study led many participants to believe that the experiment must be safe. - The selection of teacher and learner status seemed random. - Participants assumed that the researcher was a competent expert. - The shocks were said to be painful, not dangerous. Milgram's experiment has become a classic in psychology, demonstrating the dangers of obedience. The research suggested that situational variables have a stronger sway than personality factors in determining obedience. > Often it is not so much the kind of person a man is as the kind of situation in which he finds himself that determines how he will act. > > Stanley Milgram, 1974. ### Resources - [Wikipedia](https://en.wikipedia.org/wiki/Milgram_experiment) - [Simply psychology](https://www.simplypsychology.org/milgram.html) - [Very well mind](https://www.verywellmind.com/the-milgram-obedience-experiment-2795243) --- ## London vs Chicago Date: 2021-11-20 URL: https://chemaclass.com/blog/london-vs-chicago/ Tags: tdd, testing, software-design, refactoring > There are two known schools in TDD: the mockist school (aka Outside-in) and the classicist school (aka Inside-out). There are two known schools in TDD: the mockist school (aka Outside-in) and the classicist school (aka Inside-out). ### Why London and Chicago? Two companies, one from London and another from Chicago, claimed to do TDD, but they were focused on different aspects. The London company was building software from outside-in, while the Chicago company from inside-out. Let's see them in more detail. ## Outside-in: London School It provides a behavior-driven approach to TDD. Starting from the outside of the application and working inwards to lower layers. For example, starting from the API/Controllers down to the application or domain layers. ### PROS - **Behavioral Focused**: this requires a lot of test doubles because you will test a lot of abstractions that don't exist yet as you are creating a high level of logic first. You aren't going to write dead-code but it will be easy to create tests highly coupled to the logic and therefore making refactoring a difficult task. - **Command-Query separation**: is a discipline for managing side effects. Either you perform an action (command) or you ask for a value (query). ### CONS - **Fragile Tests**: it tends to create tests that break easily because they are usually too coupled to the production code. - **Difficult Refactoring**: for the same reason as "Fragile Tests", having tests coupled to production code make continuous refactoring very difficult and time-consuming. ## Inside-out: Chicago School It's an informal, exploratory, state-based approach of TDD. Starting from the inside of the application (usually the domain) and working out towards the APIs. ### PROS - **Strong Safety Net**: it tends to produce tests that are decoupled from the implementation. Enabling you to adopt a more experimental style of changing software without fear of breaking it. This is desired for continuous refactoring. - **High Cohesion**: as tests become more general, the production code becomes more specific. This promotes high cohesion, and with high cohesion comes loose coupling. Something that promotes high code quality: extensibility, maintainability, and testability. - **Minimizes Test Doubles**: building from the inside out requires fewer test doubles since you are building on top of the previously written tests. This helps to develop less fragile tests. ### CONS - **YAGNI**: it's often over-engineering solutions, with code that is not really needed (or even used!) in the end. ## London and Chicago work better together It's not about choosing one over the other. It's about understanding your context and driving optimization towards those qualities that need to be optimized. London and Chicago each have their pros and cons. The best approach to TDD is an integrated adoption of these two schools. {{ youtube(id="rbSDGr-_UwY") }} --- ### References - [Test-Driven (Development)](/blog/test-driven-development/) - [TDD vs BDD](/blog/tdd-vs-bdd/) - [Notes about "London vs Chicago TDD styles"](https://gist.github.com/xpepper/2e3519d2cb8568a0b13739d9ae497f21) --- ## Red Work vs Blue Work Date: 2021-10-21 URL: https://chemaclass.com/blog/red-work-blue-work/ Tags: leadership, team-management, productivity, agile > Blue Work and Red Work are concepts that David Marquet describes in his book 'Leadership is Language. Both require different mindsets and both have different languages. "Blue Work" and "Red Work" are concepts that [David Marquet](https://x.com/ldavidmarquet) describes in his book [Leadership is Language](/readings/leadership-is-language/). Both require different mindsets and have different languages. > "Doing" in our traditional leadership style will not take us to where we need to be in the future. ## What is "Red Work"? Red Work is about **doing and reducing variability**. Red Work focuses on a proving mindset and a performance mindset. In Red Work, you seek to complete a task without a lot of need for deciding what or how. Red Work is being in control and taking control. Such as: - Process work and avoid errors. - Having predictability and controllability. We need a mechanism to stop Red Work and ask: **are we doing the right thing?** ## What is "Blue Work"? Blue Work is about **deciding, thinking, planning**. Blue Work focuses on improving with an embarrassing mindset. > The correct place to do Blue Work is at the beginning and at the end of a decision point. Blue Work is crucial for a good starting point, allowing us to decide the best way to do something with the information that we have right now. It's also important to establish short iterations between the different actions or activities that we want to complete, so we can have some "Blue Work time" and reflect again. Blue Work is perfect to do retrospectives and see what could be improved. It's the time to stop and "control the clock", collaborate and make a commitment for the next iteration. Blue Work is also about: - Thinking work. - Decision-making. - Looking to achieve excellence. - Getting more people to do independent thinking answers. - Embracing variability and looking for different inputs. Blue Work in isolation is useless. The job of Blue Work is to make Red Work better. Endless Blue Work, planning without outcome doesn't bring any real benefits. --- > Nowadays, especially in our modern software industry, there is no room for the old school of "Red-Workers" and "Blue-Workers", but "Red Work" and "Blue Work", and everyone should be involved in both. It is, therefore, everyone's responsibility to be aware of these different types of work and find a good balance between them. Leaders involve everyone in both Red Work and Blue Work. {{ youtube(id="OEX1EVc-zjk") }} --- ### References - [Leadership is Language](/readings/leadership-is-language/) Book - [https://www.infoq.com/podcasts/david-marquet/](https://www.infoq.com/podcasts/david-marquet/) --- ## TDD vs BDD Date: 2021-09-25 URL: https://chemaclass.com/blog/tdd-vs-bdd/ Tags: tdd, testing, software-design > These are two different techniques. The key to each of them is about the mindset and context of what you want to achieve. These are two different techniques. The key to each of them is about the mindset and context of what you want to achieve. ## BDD is a "test-driven feature" Basically, it's a test-first driven development, where the main focus is ensuring the expected final behavior, and therefore the result of the software logic that you want to have at the end. In BDD the main focus is the behavior of your domain logic that doesn't exist yet. It is, from an abstract point of view, about the whole functionality and domain requirements. ## TDD is about the rhythm 1. Specify what you want. 2. Make it work. 3. Make it better. TDD is not just about the already known "red-green-refactor" mentality, but mostly about the workflow that helps you understand the constant design decisions you are doing every time for every logic you are designing. > TDD is about constant feedback about your decisions. In the context of OOP (to make the examples clearer), there are always tons of different ways to design your class: - What's the name of this method's class? - What are the dependencies or collaborators for this class? - How will this class behave when I use this other class inside it? - What's the expected outcome of this method when I give these arguments? - etc, etc... We ask these questions (and many more) every time, and we do give them an answer as well, but usually without any rational thinking or feedback about it. We just do what we think is "the best" at that particular time focusing on making something work, but is it enough to make it work? ## The constant feedback loop Testing is not just a great tool because it gives you some safety-net so you can refactor with confidence, but also because it helps design a better system. **How is that?** Because before going for any solution, it makes you think about the decisions that you need to do. You are challenging yourself to understand the arguments of your decisions, and why A and not B is a better solution in a particular context. BDD and TDD aren't mutually exclusive, in fact, they can and should coexist. It depends mostly on the context of what you want to build and test. BDD is about Test-First feature development. The goal is not how but what. The feedback loop is long because you will get "green" feedback once the feature is implemented and working as expected. TDD is also another Test-First driven but, unlike BDD, it is about a shorter and quicker feedback loop. 1. First, you **specify what you want**. You think about the design of your class or method. Its name or signature. Its dependencies. But all of this by baby steps, one at a time. 2. Second, you **make that little thing work** in the simplest possible way. 3. Finally, you **make it better**. Because software is hard and complicated enough to make it right on the first try, so refactoring is a must to keep a system healthy. At this point, with a "green running test", you can refactor and improve your logic safely. The above is basically TDD, right, but… what's so special about it? The constant **feedback loop** and **design decisions** that you need to make before you are actually writing the solution. This is the power of TDD. ### Why so small steps in TDD? Theoretically you "must" write little steps for every iteration, but why? **It's all about the feedback loop**. This is up to you, your expectations, and your experience with testing. --- ### Resources - [https://chemaclass.com/blog/test-driven-development/](https://chemaclass.com/blog/test-driven-development/) - [https://blog.testlodge.com/tdd-vs-bdd/](https://blog.testlodge.com/tdd-vs-bdd/) --- ## Test-Driven (Development) Date: 2021-08-01 URL: https://chemaclass.com/blog/test-driven-development/ Tags: tdd, testing, software-design, refactoring > TDD is a design practice, not just a testing technique. Writing tests first changes how you think about code and shape its structure. The complexity here is not about writing tests itself, but the habits that we have to change to create software that is easy to be tested. ## The root of the problem Without (a solid) experience in testing, developers can have a hard time while trying to apply testing in general as part of their daily job. It's not simply because of the topic's complexity, but **because they are used to writing code that is hard to test.** Writing tests for already working software (mainly when it was done without considering testing at all) translates as something boring, next to useless, usually accompanied by a lack of motivation, blaming the wrong subject in this context: "the tests itself are reducing my speed". > In a domain context, if a piece of software logic is hard to be tested, the problem is not the test, but the code which wasn't well written. There are already hundreds of tutorials, books, and documentation about testing, but I can share my experience and how I do apply this great (and mandatory) philosophy in my daily work. ### Test-Driven is based on this simple rule - Instead of: design code -> develop code -> write tests. - It's about: write failing automated test -> run failing test -> develop code to make test pass -> run test -> repeat. The idea of driving your code by testing can be understood depending on the abstraction level of what you're writing at the moment. You don't want to create a wrong coupling between the tests and the code being tested. You want to test the behavior of your logic. TDD is based on a loop of baby steps that helps you find **patterns** and guide your software design every little iteration with **constant refactorings**. It's the best choice if you want to ensure the expected behavior of all possible paths of your logic. The beauty of this is that you don't need to know the full algorithm from the very beginning. Instead, you are **discovering** how your logic should be by expressing the desired implementation, step by step, on automated tests. Considering writing tests for your software at the same time you're writing it, will **irremediably force you to write better software**. Because you want to write software which has to be easy to be tested, and therefore it will end up with higher quality. > I already wrote another post about the relation between software **quality and testing**: [The Art of Testing: where design meets quality](/blog/the-art-of-testing/). ## Improve your Test-Driven skills The best way to learn Test-Driven is doing software katas. Try them alone and with others. Both are equally important. - Alone: to challenge your inner self without any distraction but yourself. - With others: pair-programming is essential in our job. Katas are the best tools to train our communication skills and learn together from each other. ### What's a Code Kata? Software developers don't practice enough. Most of our learning takes place on the job, which means that most of our mistakes get made there as well. Other creative professions practice: musicians play technical pieces, poets constantly rewrite works. In karate, most of a student's time is spent learning and refining basic moves. These are katas. ### What is the goal of a kata? What should we have at the end? Katas exist to help developers get the same benefits as practicing in any other profession. There are simple, artificial exercises that let you experiment and learn without the pressure of a production environment. > There are no right or wrong answers in any software kata: the benefit comes from the process, not from the result. ### Tips - Once you have resolved a kata, try it again in a few weeks or months. - Try to explore new solutions. Be creative in the process and do not rush. - When doing them in groups, they are not a competition to see who will accomplish more of the exercise. - The focus should be on the process, never on the result. - The true valuable outcome of any kata is the learnings that you (and your team) will get after talking about it and sharing your experiences. You can find a lot of katas on the Internet. For example: - [http://codekata.com](http://codekata.com) - [https://codingdojo.org/kata](https://codingdojo.org/kata) - [https://github.com/gamontal/awesome-katas](https://github.com/gamontal/awesome-katas) --- ### TDD is more as a workflow than a design > "TDD is a design tool." That’s what Sandro has said for years. But not anymore. After working with different teams and in different organisations, and also carefully inspecting how he works, Sandro changed his mind about the role of TDD in software design. {{ youtube(id="KyFVA4Spcgg") }} TDD in a nutshell; it's about the rhythm. 1) Specify what you want. 2) Make it work. 3) Make it better. --- ## Kent Beck 1. Change the code as usual2. Write a test that only passes after the change3. Revert to before 14. Type the test again (copy/paste is cheating & invalidates the warranty of the exercise)5. Make it compile by changing the code6. See it fail7. Change the code to make it pass— Kent Beck 🌻 (@KentBeck) July 30, 2021 --- Images original by [Emmanuel Valverde Ramos](https://x.com/evrtrabajo). --- ## Responsibilities of a Tech Lead Date: 2021-07-01 URL: https://chemaclass.com/blog/tech-lead/ Tags: leadership, mentoring, team-management, communication > The Trident Career Model by Patrick Kua has three tracks. Each track represents where people spend most of their time or energy. The Trident Career Model by Patrick Kua has three tracks. Each track represents where people spend most of their time or energy. ## Archetypal Story ### Individual Contributor - 70-80% time spent on "Executing, doing". - Designing. Testing. Coding. ### Management - 70-80% time spent on "Managing the system". - Planning. Organizing. Supporting. Budgeting. ### Technical Leader - 70-80% time spent on "Leading Technical Topics & Teams". - Aligning Team. Technical Vision. Growing Tech Knowledge. Tech Risk & Tech Debt Management. What is a Tech Lead? > "A Tech Lead is a software engineer, responsible for leading a development team, and responsible for the quality of its technical deliverables." ([source](https://www.patkua.com/blog/the-definition-of-a-tech-lead/)) ## A Tech Lead is a Developer who is a Leader A good leader is making sure that the team is moving in the same direction. The team moves further altogether, rather than simply people who are working "together". ## Leadership skills to invest in - Empathy - Self-Awareness - Motivation - Conflict Resolution - Communication - Coaching - Feedback - Influencing - Delegation The Tech Lead role is a leadership position, not necessarily a management position. ## Surprises & Struggle - Feeling Alone: "Outsider". Different role. Shield/Filter. - Uncertainty: No right answer. Binary habit. Imperfect information. - People are puzzling: Unique. Different Strengths. Archetypes. ## A Great Tech Lead A great Tech Leader is really focusing on developing others, so the team will get better capabilities. ### Tell or Delegate? The goal is to reach a complete delegation, step by step. It's about starting to shift responsibilities to other people, so they grow as well. It can also depend on the skills, motivations, and urgency of the task. > "Nobody is perfect, but a team can be." - Meredith Belbin ## Key points - Tech Lead is a role change. - It requires leadership skills. - Others have been on this journey. - There are many resources available. - Move from maker mode to multiplier. {{ youtube(id="F81W-JcRgXM") }} --- ## Recommended books on this field - [Extreme Programming](/readings/xp-embrace-change/) - [The Manager's Path](/readings/manager-path/) - [The art of Leadership](/readings/the-art-of-leadership/) - [Peopleware](/readings/peopleware) - [High Output Management](/readings/high-output-management/) - [Become an Effective Software Engineering Manager](/readings/become-an-effective-software-engineering-manager) --- ## References - [The Trident Model of Career Development](https://www.thekua.com/atwork/2019/02/the-trident-model-of-career-development/) - [Tech Lead: Circles of Responsibility](https://www.thekua.com/atwork/2015/06/tech-lead-circles-of-responsibility/) --- ## Conformity Experiments Date: 2021-06-01 URL: https://chemaclass.com/blog/conformity-experiments/ Tags: psychology, leadership, communication > To what extent do social forces alter people's opinions? Which aspect of the group influence is most important: the size of the majority, or the unanimity of opinion? To what extent do social forces alter people's opinions? Which aspect of the group influence is most important: the size of the majority, or the unanimity of opinion? ## The psychologist Solomon Asch During the early years of World War II, when Hitler was at the height of power, Solomon Asch began studying the impact of propaganda and indoctrination while he was a professor at Brooklyn College's psychology department. He also was a professor for 19 years at Swarthmore College. During the 1950s, Asch became famous for his series of experiments that demonstrated the effects of social pressure on conformity. How far would people go to conform to others in a group? Asch's research demonstrated that participants were surprisingly likely to conform to a group, even when they personally believed that the group was incorrect. ## Asch asked To what extent do social forces alter people's opinions? Which aspect of the group influence is most important: the size of the majority, or the unanimity of opinion? > Asch believed that people behave according to how they perceive the world, not to how it actually is. ## The Asch experiment Asch used an experiment to study conformity based on a "simple vision test". Using a line judgment task, Asch put a naive participant in a room with other confederates/stooges. The confederates had agreed in advance what their responses were going to be when presented with the line task. Giving intentionally the same wrong answer most of the time. The real participant didn't know this and was led to believe that the other people were also real participants like himself. Each person in the room had to state aloud which comparison line (A, B, or C) was most like the target line. The answer was always obvious. The real participant sat at the end of the row and gave his answer last. Asch was interested to see if the real participant would conform to the majority view. The confederates gave the wrong answer most of the time (known as critical trials). ## Findings Nearly 75% of the participants in the conformity experiments went along with the rest of the group at least one time. Asch also found that having one of the confederates give the correct answer while the rest of the confederates gave the incorrect answer dramatically lowered conformity, which means that having social support is an important tool in combating conformity. > After combining the trials, the results indicated that participants conformed to the incorrect group answer approximately one-third of the time. ## Why people conform to a group they disagree with Why did the participants conform so easily? When they were interviewed after the experiment, most of them said that they did not really believe their conforming answers, but had gone along with the group for fear of being ridiculed. A few of them said that they really did believe the group's answers were correct. Apparently, people conform for two main reasons: because they want to fit in with the group (normative influence) and because they believe the group is better informed than they are (informational influence). > Conformity can be influenced both by a need to fit in and a belief that other people are smarter or better informed. {{ youtube(id="TYIh4MkcfJA") }} ## Factors that influence conformity Asch went on to conduct further experiments in order to determine which factors influenced, and how and when people conform. He found that: - Conformity tends to increase when more people are present. - Conformity also increases when the task becomes more difficult. - Conformity increases when other members of the group are of a higher social status. - Conformity tends to decrease, however, when people are able to respond privately (i.e., when the group can't know the naive participants' answers). --- ### Resources - [Solomon Asch | Wikipedia](https://en.wikipedia.org/wiki/Solomon_Asch) --- ## Open-Source Software Date: 2021-05-03 URL: https://chemaclass.com/blog/open-source-software/ Tags: open-source, git, career, productivity > A practical guide to open-source software: its benefits, how to start contributing, and why sharing code accelerates your career growth. Every project you ship stands on open-source software. Your framework, your test runner, your compiler, the small library you never think about. You use it every day. The real question is whether you ever give back. Giving back is not charity. It is one of the fastest ways to grow as a developer. ## What is OSS? Open-source is not the same as free software. Free software is one kind of open-source, but open-source does not have to be free to use. Two examples draw the line. [PHPUnit](https://github.com/sebastianbergmann/phpunit/blob/master/LICENSE) is open-source and free. [Spryker](https://github.com/spryker/spryker-core/blob/master/LICENSE) is open-source and paid. Both publish their code for anyone to read. > OSS is software that is public, open to the world. ## Benefits Two groups win from open-source: the companies that publish it, and the people who contribute. ### For companies Open access drives adoption. The easier the code is to get, the faster people build on it. Training and tutorials pull in newcomers and grow the ecosystem. The code tends to sit on the cutting edge, because software that stands still goes obsolete. A public project gathers a community around it, and public channels make that community easy to join. And because anyone can read the source, anyone can check its quality. That is trust you cannot fake. ### For individual contributors You pick what you work on. You practice real skills without the pressure of a production outage. You get to play with the newest features of your language, or try a language you have never touched. You also sharpen the soft skills that carry a career: writing clearly, explaining a change, holding your ground when people disagree. > The code teaches the hard skills. The disagreements teach the rest. ## Contributing to OSS ### Getting started with GitHub Starting is easy, and you have two doors. Open your own project, or contribute to one that already exists. A pet project fits the first door perfectly. ### Pet projects A pet project is a playground to build real software and train real skills. Put it on your public GitHub profile and you get every benefit of contributing to OSS, plus one more: you answer to nobody. You set the roadmap. You decide what to build and how. You are your own boss. > The project is there for you. You are responsible to play, explore, and push past your limits. ### My pet projects **Active:** - [agnostic-ai](https://github.com/Chemaclass/agnostic-ai): write AI agents, skills, rules, and hooks once, use them in every AI CLI. - [bashdep](https://github.com/Chemaclass/bashdep): a simple dependency manager for Bash. - [phel-snake](https://github.com/Chemaclass/phel-snake): the snake game in your terminal, written in Phel. - [edifact-parser](https://github.com/Chemaclass/EdifactParser): a parser for a UN/EDIFACT file format in PHP. - [unspent](https://github.com/Chemaclass/unspent): a PHP library for UTXO-like bookkeeping with unspent entries. **Inactive:** - [create-pr](https://github.com/Chemaclass/create-pr): a Bash script to open a pull request from your branch and context. **Abandoned:** - [stock-ticker](https://github.com/Chemaclass/stock-ticker): get a notification with the news from your favorite Tickers. - [jira-status-notifier](https://github.com/Chemaclass/JiraStatusNotifier): Notify when the JIRA tickets don't move along. - [php-best-practices](https://github.com/Chemaclass/php-best-practices): what I considered best practices for web-dev (archived). - [php-scaffolding](https://github.com/Chemaclass/php-scaffolding): a basic PHP scaffolding with Docker (archived). - [knob-mvc](https://github.com/Chemaclass/knob-mvc): a framework to create WordPress templates (2015/2017). > ... and many more on [github.com/Chemaclass](https://github.com/Chemaclass) ### My OSS organization contributions **Active:** - [phel-lang](https://github.com/phel-lang/phel-lang): Phel is a functional programming language that compiles to PHP. It is a dialect of Lisp inspired by Clojure and Janet. I already wrote a post about this: [Phel: A Lisp that compiles to PHP](/blog/phel-first-release/) - [gacela-project](https://github.com/gacela-project/gacela): Gacela is a PHP framework that helps you to improve the design of your application by splitting the logic into different modules. **Abandoned:** - [nm_template](https://github.com/NuevaMetal/nm_template): The base template for NuevaMetal (2013-2016). ## Knowledge Sharing and Impact Code is only half of it. The other half is what you write down and hand to the next person. ### Blog posts - [Pull Requests vs Pair Programming](/blog/pull-request-vs-pair-prog/) - [The Process Itself Is the Goal](/blog/the-process-itself-is-the-goal/) - [The Art of Refactoring: When, How, and Why](/blog/the-art-of-refactoring/) - [The Art of Testing: Where Design Meets Quality](/blog/the-art-of-testing/) > ... and many more on [https://chemaclass.com/blog/](https://chemaclass.com/blog/) ### The beauty of OSS Contribute in public long enough and you start to see your own growth. The corrections you keep making. The code you wrote last year, already aged. The mistakes, all of them, in the open. And underneath, the slow proof that you are getting better. You build a sixth sense for patterns you have hit before, the good ones and the painful ones. **Show your skills. Help the people around you.** That is [working with the garage door open](/blog/working-with-the-garage-door-open/). > Open-source software offers you one of the best opportunities to start building a career of continuous improvement. --- This is a (Spanish) talk that I did remotely on April 2021, for [PHPMad Madrid Community](https://www.meetup.com/phpmad/events/277733306/). I present all these ideas together with a live demo of how to contribute to a real OSS. {{ youtube(id="GE5wR_SC_P4") }} --- --- ## Pull Requests vs Pair Programming Date: 2021-04-01 URL: https://chemaclass.com/blog/pull-request-vs-pair-prog/ Tags: pair-programming, code-review, agile, communication > Let's talk about the benefits of Pull Requests and Pair Programming, and my thoughts on these after some years of experience with them. Let's talk about the benefits of Pull Requests and Pair Programming, and my thoughts on these after some years of experience with them. ## Pull Requests A Pull Request (PR) is basically a way of showing your suggested code changes such that they are easily comparable with the existing source code. This is part of a workflow that helps developers to share knowledge about the changes that are being done within the system. > A Pull Request is the moment where you ask your peers to review and check out your code changes. Usually, it's also used: 1. For discussions about code style. 2. To spot potential bugs. 3. For architectural or design discussions once the solution is done. ### Pull Requests aren't the best tool for everything The main problem with these topics above is that PR's are usually ready when the feature/bug is already being worked on and in the last stage of its development process. It [a PR] is an "already changed proposal [I have already worked on this change, here's the code] to be merged into the current system [someone please look it over]". The concept of "Draft PR" exists to make explicit that a PR is not ready to be merged, so it's still a "work in progress thing", but that's another topic. Pull Requests are, indeed, one of the best tools that we have in our industry to share knowledge about the changes that we are doing in the system, but sometimes they might be misused, as for example: 1. **Discussions about code style**. Code style shouldn't be discussed in a PR. There should be already a CI running a code style checker, that's all. If you want to talk about code style, request a change in your code style checker, but not in a random PR. 2. **Spot bugs**. Bugs and desired behavior should be covered by automated tests. The developer is the first responsible person for this topic. 3. **Architectural or design discussions**. Once a particular solution is developed and ready for review, it is usually really hard to "rollback" that idea and rewrite it again. Because "why would you do that? For some subjective opinion? It's done already. And it seems to work just fine." Having an extra person looking at the changes that we have done for "designing decisions" might be beneficial, but we could have addressed "potential disagreements" in a sooner stage. ### What should the purpose of a Pull Request be? 1. Sharing knowledge about the proposed changes with the team. 2. Ensuring the team aligns and agrees across the multiples changes that are getting submitted every day in order to keep a healthy direction for the project. Yes, this might include double-checking the outcome design, but… What if that is now too late? How could we solve all those issues? ## Pair Programming The concept of "Pair Programming" can be understood from different points of view. Pair thinking and pair programming, driver-navigator roles concepts, or pure live coding from one side. Actually, this is way easier than it looks like at first instance: - Either you watch and help the other person to write code, - Or you type while getting another pair of eyes watching and helping you. > Pair Programming helps the team to work together. Pair programming is the joy of working with an extra brain and another pair of eyes, where the key is to **build a context** where you two **share the same goal** in order to find the **best possible solution**. All of this while learning from each other every single second. Pair Programming is not about developing the best solution at the very beginning. It's about making it work, sharing ideas, and finding a better solution together. After that, you can refactor and clean the code. ### Pair Programming is a continuous code review Pull Requests are an asynchronous way to share code changes, while Pair Programming is totally **synchronous** because it happens at the same time. That said, Pull Requests and Pair Programming aren't mutually exclusive, they can coexist. They are tools, and we should wisely choose them in order to achieve our objectives. The most common fear that I saw while encouraging to do Pair Programming is that some people are shy and they don't like to have other eyes around them while they are coding because of: - Fear that they don't know what to code or where to start. - Fear that others will laugh at their solutions. - Fear to not succeed in public. - Fear to not be able to develop the expected solution for multiple reasons: misunderstanding the task or lack of knowledge. - Fear to change your mind in front of others. - Fear to discuss and make decisions loud. - Fear of disagreeing with others. ## After several years of experience on this topic The pattern which rejects Pair Programing is basically "fear", and being out of your comfort zone. And this is due to the misunderstanding of the roots of the actual Pair Programming concept. Pair Programming is not "to show off in front of your colleagues" or "to be screwed by your peers", but to be transparent (showing your skills as they really are) and improve as a team lifting up each other. Programming is an iterative process that needs a continuous refactoring of our way of thinking in order to achieve better solutions, day by day. Therefore, programming with another person next to you (with a different way of thinking) will help the team to get the best from each other while discarding the waste or bad habits if necessary. Pair Programming doesn't need to be always set for everything. As a tool, it's flexible, and we can choose how, when and for what reason. A personal rule of thumb, before starting tasks that might involve touching multiple modules or complex business rules, think about a quick Pair Thinking/Programming with another more experienced colleague in that field. > Everything depends on a particular context and people: the developers, the pairs, the tasks, the mood. ### Still uncomfortable with Pair Programming? If you still feel uncomfortable having another person next to you while you write code, it might be because you aren't particularly happy with your own code, or the process that you follow in order to achieve some result. My favorite way to work on this is by exercising on your own and working on improving your skills as a software developer. - Create and play around with your own pet projects. - Work on code katas on your own and with others. > Practice makes the master. ## Keep pull requests, add pair programming - Don't get me wrong, Pull Requests are great. Keep doing them. - Team collaboration is essential. Pair Programming aims for this. - Pair Programming encourages the team to proactively work together. - Don't be afraid of coding while having eyes around you. Ask questions when something is unclear. Ask for help when you don't know how to solve something. > It's totally ok not knowing everything. The most important thing is to know how to work together. --- ## Embrace the Change Date: 2021-03-01 URL: https://chemaclass.com/blog/embrace-the-change/ Tags: leadership, psychology, career, philosophy > The tale is a beautiful metaphor of the different attitudes that people adopt as part of their identity in life when they have to confront any change. The book *Who moved my cheese?* presents a tale inside the main story that consists of 4 characters: two mice, **Sniff** and **Scurry**, and two little persons, **Hem** and **Haw**. Published in 1998, and I just read it at the beginning of 2021. Better late than never. Actually, thanks to my brother Jesús, who recommended it to me. > They live in a Maze (that represents one's environment) and in order to survive they need to go out of their comfort zone and look for cheese (which represents happiness and success). > > The tale starts when both groups end up at "Cheese Station C", full of cheese. The humans established routines while the mice kept their instincts active. > > One day the mice arrive at the "Cheese Station C" and find no cheese left. So they go out to find more cheese somewhere else. On the contrary, when Hem and Haw see that there is no cheese left, they start complaining. Hem, angry and annoyed, demands "Who moved my cheese?!". Both humans counted on the cheese supply being endless and constant, so they weren't prepared for the unexpected. The main difference here is how Haw and Hem react to this situation. > > Hem denies moving away from the "Cheese Station C", so he keeps going there every day expecting to find cheese without success, being weaker, and with continuous fear of doing something different. Haw, on the other hand, decides to laugh at the situation, turns down his fear, and goes out looking for more cheese. > > ... I will leave the rest of the tale to you. The tale is a beautiful metaphor of the different attitudes that people adopt as part of their identity in life when they have to confront any change. > Noticing small changes early helps you adapt to the bigger changes that are to come. This book is full of lessons that apply to everyone no matter who they are or when they read it. I fully recommend it. ### My favorite lessons of the book 1. Change happens. They keep moving the cheese. 2. Anticipate change. Get ready for the cheese to move. 3. Monitor change. Smell the cheese often so you know when it's getting old. 4. Adapt to change quickly. The quicker you let go of old cheese, the sooner you can enjoy new cheese. 5. Change. Move with the cheese. 6. Enjoy change. Enjoy the taste of new cheese 7. Be ready to change quickly and enjoy it again. They keep moving the cheese. > "Everyone knows that not all change is good or even necessary. But in a world that is constantly changing, it is to our advantage to learn how to adapt and enjoy something better. It is not what is in the story of "Who moved my cheese?" but how you interpret it and apply it to your own situation that gives it the value." - Ken Blanchard. {{ youtube(id="OvYCLxqkfvY") }} > "Life moves on and so should we" - Spencer Johnson --- ## Phel: The Lisp That Compiles to PHP Date: 2021-02-01 URL: https://chemaclass.com/blog/phel-first-release/ Tags: phel, php, open-source, software-design > The new Functional Programming language build-in for PHP. A new Functional Programming language built-in on the PHP ecosystem. ## The Phel Language Phel is a Functional Programming ([FP](https://en.wikipedia.org/wiki/Functional_programming)) language that compiles to PHP. It is a dialect of [Lisp](https://en.wikipedia.org/wiki/Lisp_(programming_language)) inspired by Clojure and Janet. ## Features - Built on PHP's ecosystem - Good error reporting - Different Datastructures (Arrays, Tables, and Tuples) - Macros - Recursive functions - Powerful but simple Syntax - REPL ## Why Phel? Phel is a creation of Jens Haase, and as he mentions on the website, "it is the result of many [failed attempts to do functional programming in PHP](https://phel-lang.org/blog/functional-programming-in-php)". He was looking for something with these characteristics: - A LISP-inspired - Functional Programming language - That runs on cheap hosting providers - It is easy to write and debug From my point, it was ending May 2020 when I finished the book [Seven Languages in Seven Weeks](/readings/7-languages-in-7-weeks/), in which I learned the basics of Prolog, Erlang, Clojure, Haskell… I even created a [repository in GitHub](https://github.com/Chemaclass/7LangIn7Weeks) to store my progress over the weeks with these learnings. Suddenly, one day beginning of June 2020, I saw a post in Reddit's PHP official channel, with a message of someone mentioning this "**Phel**" project, claiming to be a **"functional programming language" written in PHP**! I've worked with PHP for around 8 years so far, and I always try to combine OOP with FP as much as possible (because I believe both paradigms are better combined; they are not necessarily exclusive), and a new dialect of Lisp fully written in native **PHP 7.4** sounded really exciting. I decided to take a look at it. I wanted to see the code. The fresh readings from [Mathias NoBack](https://x.com/matthiasnoback) books such as [Object Design Style Guide](/readings/object-design-style-guide), and [Advanced Web Application Architecture](/readings/advance-web-application-architecture/), gave me the courage to try out what I learned and put it for real in a project. This was (and still is) a beautiful challenge, which helps me to test myself and grow professionally at the same time. My first commit was done on 6 June 2020, and since then I've been dedicating a little time each day during my free hours to its development. It helps me to learn more about FP, languages' internal design, and best practices on testing and software design architecture in general. I started applying minor changes until I ended refactoring the whole compiler structure (among other things) in order to make the modules easier to read and understand. Psalm, strict types, good test coverage, unifying code style… These were some of my favorite topics. ## Example of Phel code The following example gives a short impression of how Phel looks like: ## Current status of Phel - We prepared an easy [Getting Started Guide](https://phel-lang.org/documentation/getting-started/) - We prepared an easy GitHub Repository with a [Phel Scaffolding Template](https://github.com/phel-lang/phel-scaffolding) - We just released the first official version: [0.1.0](https://github.com/phel-lang/phel-lang/tags) Check out the official website with all documentation: [https://phel-lang.org/](https://phel-lang.org/) --- ### Also recommended - [Functional Programming with Phel - JesusValera](https://jesusvalera.dev/functional-programming-with-phel/) --- ## To Mock or Not to Mock Date: 2021-01-11 URL: https://chemaclass.com/blog/to-mock-or-not-to-mock/ Tags: testing, tdd, software-design, clean-code, php > Mocking is useful, but 'what to mock' usually turns out to be a more complicated than expected if you don't treat this carefully. Mocking is useful, but "what to mock" usually turns out to be more complicated than expected if you don't treat this carefully. #### How to escape the mocking hell What is actually happening when we create a mock? Which types of mocks are there? Is mocking good or bad? Well, as always, everything depends on the context. And here we will consider some of the main situations about when to mock and when not to mock, but especially why. ## What happens when you mock something? First, we should define what is a mock: > In a unit test, mock objects can simulate the behavior of complex, real objects and are therefore useful when it is impractical or impossible to incorporate a real object into a unit test. Mocking makes sense in a *unit testing* context. An integration test should go through the real implementation checking the integration between multiple units, which are even allowed to talk to the DB or File IO: infrastructure code. Therefore we should agree that *a unit test is a fast and deterministic test that doesn't rely on external dependencies and doesn't require any special context to run*. Mock objects meet the *interface* requirements. In consequence, they allow us to write and unit-test functionality without calling complex underlying or collaborating classes. A mock is a test double that stands in for real implementation code during the unit testing process. It is also capable of producing assertions about how it was manipulated by the test subject during the test run. > I strongly recommend you to read this post if you want to get into the details of why [Mocking is a code smell](https://medium.com/javascript-scene/mocking-is-a-code-smell-944a70c90a6a) (Topics like these: What is a mock? What is a unit test? What is test coverage? What is tight coupling? What causes tight coupling? What does composition have to do with mocking? How do we remove coupling? and more!) ## The problem with mocking When you mock you are overriding the logic of the mocked class. The real logic is getting hidden behind the scenes and there is actually where bugs love to live. Consider that: * The mock may have attributes, methods, or arguments that the real object doesn't. * The mock's *return values may differ from the real objects' return values*. For example, it may return a different type of object that has different attributes. * The mock's *side effects and behavior may differ from the real objects' ones*. For example, maybe the mock fails to raise an exception when the real object would raise it. ## Alternatives to mocking "Are you saying that mocking is bad and we shouldn't mock?!" No. It depends on what you are "overriding". * Is your business domain logic what you are mocking? Then it's wrong. * Is the connection to the DB what you are mocking? Then it's right. > It depends on the context of the logic and where that logic belongs. Is it part of your business domain logic? Then you shouldn't mock it but instantiate it. Is it part of any infrastructure dependency like DB connection, IO file system, Network, or any external service that has nothing to do directly with your business domain? Then *mock it using abstractions/interfaces*. The interface should be the *contract between your business domain logic and its external infrastructure dependencies*. Imagine how easy it would be to unit test your domain logic by instantiating it and calling their methods with different arguments expecting different inputs under your entire control. ## Some tricks When you are writing a unit test: * Try to instantiate your classes first. * Avoid mocking concrete classes. I wrote an article exclusively about this: encouraging [final classes](https://medium.com/swlh/final-classes-in-php-9174e3e2747e) and interfaces. > Mock interfaces. Instantiate concrete classes. {{ youtube(id="RbSqXFUfRMU") }} "Excessive use of mocks leads to legacy code." - Philippe Boargau ### How can we avoid excessive mocking? * Favor immutable state over a mutable state. * Make dependencies explicit. * Program to an interface, not to an implementation. --- #### References - [Mocking is a code smell](https://medium.com/javascript-scene/mocking-is-a-code-smell-944a70c90a6a) - Eric Elliott - [When to mock](https://blog.cleancoder.com/uncle-bob/2014/05/10/WhenToMock.html) & [Test Definitions](https://blog.cleancoder.com/uncle-bob/2017/05/05/TestDefinitions.html) - Uncle Bob - [Final classes by default](https://matthiasnoback.nl/2018/09/final-classes-by-default-why/) - Matthias Noback - [The problem with mocks](https://www.seanh.cc/2017/03/17/the-problem-with-mocks/) - Sean Hammond - [A Set of Unit Testing Rules](https://www.artima.com/weblogs/viewpost.jsp?thread=126923) - Michael Feathers --- ## Sharing Your Git Patches Date: 2020-12-01 URL: https://chemaclass.com/blog/sharing-git-patches/ Tags: git, code-review, communication, pair-programming > Discover another way of sharing suggestions with your development team. Discover another way of sharing suggestions with your development team. ### Imagine this situation You are reviewing a Pull Request (PR), and you see some minor improvements or suggestions that you would like to share with the author. You might write some comments, and usually, that would be sufficient. Imagine that in order to transmit your "whole idea" you would need to change some files because just communicating the full picture will end up in a huge comment which might be not as clear as it could be. ## What possibilities are there apart from just comments in a PR? Well, there are multiple options. The key is to be aware of them and use them wisely depending on the priority of the task and the changes themselves: - As already mentioned, writing a comment as feedback is a good idea by default, but not the only one. - We can always do some pair-thinking, talk at any time. Communication is always good in order to clarify the possible uncertainty. - Sharing your git patches is another good option. ## Git diff to the rescue! What if you (as a reviewer) could share your idea without any single commit or comment in the PR, but sharing your changes directly with the author? Well, that's actually possible and really easy. As you already know, the git diff command gives you the differences between any two branches. What we are doing here is redirecting the output of the diff command into a file (aka: patch), so we can share that output with any other peer-team. ## What now? Well, having that patch file, it's pretty easy to apply those changes in your local machine without doing any commit: Applying this patch will simply change your local system in the same way the patch was created. ## "How to" by steps Let's divide the responsibilities into two: the creator of the patch and its user: ### The patch creator: the person who will create the patch ### The patch user: the person who will see the patch --- #### References - [Official documentation for "git apply"](https://git-scm.com/docs/git-apply) --- ## Never Use array_merge in a Loop Date: 2020-11-10 URL: https://chemaclass.com/blog/array-merge-in-loop/ Tags: php, clean-code, refactoring > Using array_merge inside a loop is a performance killer. The spread operator will help you to improve this by flatting the array. Using array_merge inside a loop is a performance killer. The spread operator will help you to improve this by flatting the array. ## Flattening a one-level array I have seen people using the array_merge function in a loop like: In that case, you will need to unpack its values: In these cases, you might want to use the internal standard library: ## Which flattening approach to reach for Usually, being aware of how to flat a "2 level" array might be sufficient: Otherwise, the internal standard library will help you deal with it. --- ### References - [Spread_operator_for_array - Wikipedia](https://wiki.php.net/rfc/spread_operator_for_array) - [Flatten_a_list - Rosettacode](https://rosettacode.org/wiki/Flatten_a_list) --- ## Typed Arrays in PHP Date: 2020-10-13 URL: https://chemaclass.com/blog/typed-arrays-php/ Tags: php, software-design, clean-code > Argument unpacking, function variable argument list, and variadics function. Argument unpacking, function variable argument list, and variadics function. ### The perfect combination - Argument unpacking: Instead of passing the argument itself to the function, the elements it contains will be passed (as individual arguments). - Function variable argument list: The arguments will be passed into the given variable as an array. - Variadics function: Types can be checked with a type-hint. We will use this snippet for our examples. Having a class, `Customer`: Whenever we want to manipulate a list of Customers, we can pass as an argument: `…$customers`. ## How we used to do it We define the array type using the PHPDoc param comment block above. But we cannot define the real type of the item. The code will still run without any problem passing any type on that argument `array $customers`: The code below would work at "compile-time". But it might fail at "runtime". An alternative (recommended!) might be to extract that logic and ask for the particular type in order to "check it" at runtime in that particular moment, failing if one of the items wasn't really a Customer: Everything here below would work at "compile-time". It will for sure break during "runtime" if the `createInvoice(Customer $customer)` receives something different than a Customer. By doing that `createInvoice(Customer $customer)` we are ensuring the type of the argument, which is good! But, what about going one step further. Could we check the types of the elements when calling the function `createInvoiceForCustomers(array $customers)`, even making the IDE complain when the types are not right? Well, that's actually what Generics are for, but sadly, they are not yet in PHP. Not even in the upcoming PHP 8. Hopefully in a near future, but we cannot predict that for now. Luckily, we have currently an alternative nowadays, but it's not that popular. It has its own "pros" and "cons", so let's take a look at an example first: Everything here below would work at "compile-time". It will for sure break during "runtime" if the `createInvoice()` receives something different than a Customer. ### PROS - We can easily type a list of any concrete type. ### CONS - We better define our functions with one or two arguments max. Otherwise, it would be too complicated to read. ### Important remarks - It needs to be the last taken argument of a function. - It helps to minimize the number of arguments that we use in a function. ## Variadics simulate typed arrays, use them wisely Argument unpacking is a great feature that, in combination with variadic functions, can help us to simulate typed arrays. With great power comes great responsibility, and this is no exception. We need to learn about our toolbox in order to use it wisely. --- ### References - [Argument unpacking](https://wiki.php.net/rfc/argument_unpacking) - [Function variable argument list](https://www.php.net/manual/en/functions.arguments.php#functions.variable-arg-list) - [Variadics function](https://wiki.php.net/rfc/variadics) --- ## The Process Itself Is the Goal Date: 2020-09-08 URL: https://chemaclass.com/blog/the-process-itself-is-the-goal/ Tags: productivity, psychology, career, philosophy > No goal should be an achievement on its own, but the process itself that helps us to go in the direction of these goals. No goal should be an achievement on its own, but the process itself that helps us to go in the direction of these goals. Goals, in business and in life in general, should be conceived as directions, where their real intention is to help us accomplish more in the way we planned or want. > If we get rewarded only for results and not for processes, we will become pretty miserable. Society doesn't reward the journey, but the results, and that's exactly part of the problem when you are too focused on how society acts on you. Of course, it's important to listen to society, but it's more important to listen to ourselves in order to improve constantly. Continuous improvement doesn't apply to software only but to everything in life. ## How do I keep myself focused? This is a totally subjective topic that might be different from person to person. That said, I think it might be useful to share my thoughts with you, so I'll do it. ### Self-reflection I used to write my thoughts in a "diary" for some years. Back then, in 2015, when I moved to Germany, I didn't know many people here, and the environment was completely new. I decided to write my thoughts to myself in order to read them the day after and do some retrospection about it. Finally, after around 3 years, in December 2017, I published a book named ["Ojos en un recuerdo"](http://ojosenunrecuerdo.es/). That book is the compilation of those thoughts. No story behind it. They are as they came. You can see the evolution of the topics and about what and how they were written. The exercise of self-reflection itself was more important than the book! The goal here wasn't writing a book at all. The goal was the self-projection to understand what was going on inside myself. Publishing those thoughts in a book was an accident. A beautiful accident, though. This habit of thinking about my actions and decisions (what do I do and why) helped me to develop who I am nowadays. ### Sports Exercise helps my mind to disconnect from the tech area. It keeps my body active using some energy in a different environment. But most importantly, it helps to get fully tired before going to bed. I feel myself resting much better if I've done some sport during the day: contact sports, fitness studio, or simply running. > The specific sport itself is an irrelevant detail as far as you feel comfortable. The act of doing sport is the key here. ### Books I try to read tech throughout the day and non-tech during the night. For example, some days before going to work or after working time I might read a tech book. And some days before going to sleep I like to read a non-tech one. This way, I feed my brain with knowledge and I also provide it with non-tech space, so it can rest from code and enjoy other "universes" as well. Some suggestions that helped me to understand how we behave, why we do what we do, and therefore build some habits that I didn't know how to: - The Power of Habit, by Charles Duhigg. - Atomic Habits, by James Clear. - Scrum: Doing Twice the Work in Half the Time, by Jeff Sutherland. ## Personal tricks I wish I would have read much more. Nowadays, with the number of distractions that we have, keeping yourself focused is pretty hard. Some tricks that help me a lot when I want to focus: - I keep my personal phone always in silence and vibration mode. - I used to spend hours on social media; a lot of time wasted. Not anymore. I reduced the social media noise to the minimum by removing the apps that prevent me from being as productive as I want. Some of them from my phone, others the account itself. - I used to play video games. Not anymore. Instead, I go to GitHub to work on my pet projects, contribute to an open-source project, or simply read a book. - When I go for a run, I enjoy it twice by listening to a 45-min podcast that I want to listen to since the very morning. The reward of listening to the podcast is linked with the act of going out and running. I conscientiously created that habit. > It's not about removing your old habits but replacing them with new ones. ### How to improve your habits Habits emerge without our consent. To save energy, the brain creates a habit loop that looks for a trigger to cue a behavior. - Willpower can be learned. It needs exercise, like a muscle. - Small successes are the building blocks of bigger wins. - Focus less on goals and more on systems and processes. - To change habits, change how you identify yourself. - To build good habits, the environment is more important than being motivated. - To break a bad habit, reduce exposure to the cues that cause it. - Bundle an action you want to do with an action you need to do. - Don't try to make a habit perfect, just repeat it. - Reduce friction for good habits and increase friction for bad habits. - Like in Scrum, removing waste is fundamental to get better. > Repetition is the key. Make it easier to do what you want to do. Make it harder to do what you want to stop doing. Enjoy the process: that's the goal. ## Interesting links - [13 key insights from The Power of Habit](https://heleo.com/charles-duhigg-13-key-insights-charles-duhiggs-power-habit/2026/) - [The most interesting takeaways from Atomic Habits](https://medium.com/@saurinparikh/the-most-interesting-useful-takeaways-from-atomic-habits-9acc20bdc858) - [Atomic Habits in my readings](/readings/atomic-habits/) --- ## Testing Effectively Legacy Code Date: 2020-08-17 URL: https://chemaclass.com/blog/testing-effectively-legacy-code/ Tags: testing, refactoring, clean-code, tdd > How to write characterization tests for legacy code to safely refactor without breaking existing behavior. These tests are also known as Characterization tests. > A characterization test describes the actual behavior of an existing piece of software, and therefore protects existing > behavior of legacy code against unintended changes via automated testing. This term was coined by [Michael Feathers](/readings/working-effectively-with-legacy-code/). They enable and provide a safety net for extending and refactoring code that does not have adequate tests. A test can be written that asserts that the output of the legacy code matches the observed result for the given inputs. ## How to start? These are my learnings one year after reading [Working Effectively with Legacy Code](/readings/working-effectively-with-legacy-code/) and applying it to the different projects I've been working on since then. ### 1. What do you want to test? Find out the assertions. Create a test file for your class, and a testing method for the function that you want to test. Hint: - If you have the following method `applySomeLogic(): ReturnType`, - the test you could write is `test_apply_some_logic(): void`. ### 2. Instantiate the concrete/final class that you want to test. Do not mock your concrete classes. Especially your business domain. Mock only interfaces. Otherwise, you can be hiding bugs unintentionally (with green/passing tests!). Treat your [business domain classes as final](/blog/final-classes). Either mock the interface or instantiate an anonymous class if you want to create a Stub: > Stubs provide answers to calls made during the test, usually not responding to anything outside what's programmed in for the test. > Where `FakeDependency` is a concrete implementation of `DependencyInterface` with already "fake data/implementation" that it's useful only for testing purposes. ### 3. Call the method from that class providing the desired input. The output will be determined by the initial state of the business logic class that we want to test PLUS the input arguments that we are using. ### 4. Assert the output with the expected value. From step-1 you need to know what you want. Apply the assertion(s) now. ### 5. You might want to assert different expected values. You can easily provide different arguments to your business logic either via the logic construction or different given arguments. To do so, use the @dataProvider annotation. The “dataProvider” method must be public and return any iterable. ### Lastly: clean what you did. Yes, clean the tests. They deserve to be as clean as your production code. Otherwise, they will rot as time passes by and remain dirty for your colleagues and your future self! For example, you can apply extract method refactoring to move out the implementation details (of the creation of the different objects) and keep the same abstraction level while reading the test code. Of course, everything depends on the context. Does it really make sense to extract into a private method the createBusinessLogic() or even createInput()? Well, that's up to you. It depends on the number of lines and, most importantly, the abstraction level that belongs to that context. > Just remember: keep your methods small. Now you can refactor the production code that you covered with tests without that fear of breaking it. --- ### All together {{ gist(url="Chemaclass/07704606fcb337dbb0881c94197c329e") }} {{ gist(url="Chemaclass/9f7f96242153b696b3f8da5c7fa80461") }} --- ## Legacy Code is code without tests Of course, there is way more to learn about [testing and working with legacy code](/readings/working-effectively-with-legacy-code/). In fact, especially when dealing with legacy code, you will encounter situations where the code is coupled somehow that you might want to mock your concrete classes because there is no interface (yet) for it. This book presents to you a lot of techniques about when, why, where, and how you can apply these changes. > When working with code you need **feedback**. Automated feedback is the best. Thus, this is the first thing you need to do: write the tests. ### First, add tests, then do your changes. #### Change as little code as possible to get tests in place with the recipe: 1. Identify “change points” to break your code dependencies. 1. Break dependencies. 1. Write the tests. 1. Make your changes. 1. Refactor. --- {{ youtube(id="wRtJRkRIa2s") }} --- ## Strict Types in PHP Date: 2020-08-09 URL: https://chemaclass.com/blog/strict-types/ Tags: php, clean-code, software-design > Why declaring strict_types in PHP improves code readability and prevents silent type coercion bugs. In December 2015, PHP 7 introduced scalar type declarations and with it the strict types flag. What is this new feature? The good thing about declaring a PHP file as strict is that it actually applies to **ONLY the current file**. It ensures that this file has strict types, but it doesn't apply to any other file in the whole project. It allows you to do, step by step, this migration from non-strict code to strict code, especially for new files or projects. > To enable the strict mode, a single declare directive must be placed at the top of the file. This means that the strictness of typing for scalars is configured on a per-file basis. This directive not only affects the type declarations of parameters, but also a function's return type. ## Strict types affect coercion types Using a type hint without `strict_types` may lead to subtle bugs. Without this, `int $x` meant `$x must have a value coercible to an int`. Any value that could be coerced to an int would pass the hint type, including: - a proper `int` (example: 42 -> 42) - a `float` (example: 13.1459 -> 13) - a `bool` (example: true -> 1) - a `null` (example: null -> 0) - a `string` with leading digits (example: "15 Trees" -> 15) By setting `strict_types=1`, you tell the engine that int $x means $x must only be an int proper, no type coercion allowed. You have the great assurance you're getting exactly and only what was given, without any conversion or potential loss. ## Who should care about this "strict type" line? Actually, declare(strict_types=1); is more for the reader than for the writer. Why? Because it will explicitly tell the reader: - The types in this current scope (file/class) are treated strictly. > 'strict_types=1' is more for the reader than for the writer The writer just needs to maintain such strictness while writing the expected behavior. That said, as a writer, you should care about your readers, which also includes your future self. Because you are going to be one of them. ------ ## References - [Scalar type declarations](https://www.php.net/manual/en/migration70.new-features.php#migration70.new-features.scalar-type-declarations) - [What do strict types do in PHP](https://stackoverflow.com/questions/48723637/what-do-strict-types-do-in-php/48723830#48723830) --- ## The Art of Refactoring Date: 2020-06-28 URL: https://chemaclass.com/blog/the-art-of-refactoring/ Tags: refactoring, clean-code, testing, software-design > If you see something, in the scope of your current task, that can be easily improved, improve it. And if you have any questions about it, ask. If you see something, in the scope of your current task, that can be easily improved, improve it. And if you have any questions about it, ask. ## What is refactoring? Refactoring means improving your code. It can go from making a variable name more readable, extract some lines of code into a private method, or separate the responsibilities of a class into subclasses, for example. Refactoring is the action of showing that you care about what you do as a professional. It can be a controversial topic; it is indeed one of the major controversial topics since a long time ago. But we shouldn't stop trying our best in order to improve the quality of the system just because of that controversiality. ## When and how should we refactor? Always. In the scope of your current task unless it is an already planned task, something like "architecture refactoring" or similar, where the scope of the task is actually to do refactoring. > Refactoring should be part of our daily job, not a separate task by default. We do not need to ask permission to refactor. Or do we ask our managers for permission to do our best job? In order to do proper refactoring, the intention of such refactoring needs to be clear. What is intended to achieve and how? Pair programming (or even pair thinking!) certainly helps in this topic because it syncs two brains on the same topic and that encourages team building and a better understanding of them. Applying refactoring in a collaborative way, in a "bidirectional channel", is fundamental when working within a team. Refactoring shouldn't be a taboo topic, on the contrary: it will be helpful in order to unify the goals and the direction of the team code quality. ### Some personal advice about the "how" Continuous improvement is what we're looking for within this topic, but… * If you realize your changes are generating more noise than help, stop immediately and think again if your changes are worth it in the current system status. Maybe it's not the right moment for that refactoring. Maybe you are polluting your current diff with out-scoped changes. Or, maybe, your refactoring idea is too big to be applied in your current task. In such a case, a follow-up task (in order to apply the refactoring) would be a better idea. * If you see that refactoring is perhaps needed even before starting your current task, do the refactoring first. We usually refactor in order to increase our productivity, making the code more readable and therefore easier to understand. ### Testing Be aware that you should have a pretty good suite of tests covering the logic that you might have changed. Without tests, refactoring can be really risky. Usually, the easier something is to be tested, the easier it is to be replaced or removed. You can read more about how testing is related to quality here. ## Why should we do it? Wouldn't you want to have a better system as time goes by? Software isn't like wine: it doesn't get better as time passes by. Therefore, if you want to have a better system you must work for it. --- ## Final Classes in PHP | Java | Any Date: 2020-06-06 URL: https://chemaclass.com/blog/final-classes/ Tags: php, software-design, clean-code, testing > Clear contracts, isolated side effects, testability, low complexity and cognitive load, code fluidity, and confidence in yourself. Clear contracts, isolated side effects, testability, low complexity and cognitive load, code fluidity, and confidence in yourself. ## Motivation ### Reduce the scope visibility to the minimum When you see a class prefixed with final you will prevent a particular class to be extended by any other, which not only makes it more readable but also makes you be sure that the scope of the logic where you are is limited to that particular class. ### Encourage "composition over inheritance" mentality The Open-Close Principle states: open for extension but closed for modification. If for any reason, a good one you should be completely aware of, you decide to create an inheritance there, well, then just drop the final keyword and you are good to go. When you "by default" can't extend from a class (because it's final), you will help yourself by thinking about using composition instead of inheritance. ## Why isn't this class final? If we aim for composition over inheritance, then we should try to avoid inheritance as much as possible, and use it only when it's really necessary. Inheritance is often misused in OOP. ### Misconception When we first taught OOP, we usually introduced the classic inheritance example. Nonetheless, when Alan Kay created Smalltalk, the inheritance was never the main concept of it. The main concept was messaging, which is that you can send messages to objects and they encapsulate the data and logic in it, and you can change their behavior by using different objects, which is actually composition. But the concept of inheritance is so popular that it eventually overshadows composition. ### Benefits * Clear contracts. Using interfaces will force you to think in terms of communication between objects. * Isolated, side effect free code units. Injecting interfaces only as dependencies will remove every nasty side effect around the code you are working on. * Testability. Mocking dependencies is extremely easy when they are interfaces. * Low, manageable complexity. Since everything is isolated, you won't need to worry about rippling changes. This dramatically decreases the complexity of your code. * Low cognitive load. With decreased complexity, your brain will be free to focus on what matters. * Code fluidity. By removing any unnecessary coupling, you will be able to move things around way more easily than before. * Confidence in yourself. Being able to test your code in isolation so well will give you a wonderful sense of confidence in changing it. ## Composition over inheritance If you feel the need to reconfigure an object, to change parts of an algorithm, or to rewrite part of the implementation, consider creating a new class instead of overriding an existing class. If you need to represent a hierarchy of classes, where subclasses are proper substitutes for their parent classes. This would be the classic situation where you may still consider inheritance. However, the result may even be better if you don't inherit from concrete parent classes but from abstract interfaces. ### What you should start doing instead * Use interfaces to define the contracts between your classes. * Use final classes to implement behavior for those interfaces. * Use composition (using dependency injection through constructor) to put things together and prevent complexity. > Interfaces -> Final classes -> Composition --- ## The Art of Testing: Where Design Meets Quality Date: 2020-04-07 URL: https://chemaclass.com/blog/the-art-of-testing/ Tags: testing, software-design, clean-code, tdd > Why you should consider testing as part of your daily development habit and how it's directly linked to the software quality. Why you should consider testing as part of your daily development habit and how it's directly linked to the software quality. This post intends not to explain the different testing techniques that we can use. I'm not going to tell you the differences between unit, integration, feature, or end-to-end testing. I'm still amazed by the lack of experience with testing in software in general. Common ignorance in this world about best testing practices for us as developers. Inexperience that you can easily see if you have already worked on different projects and teams. ### Software testing Some horrible patterns I've seen (and done): * Testing for the sake of testing: testing every single file, sometimes wrongly considered a unit. * Mocking every class we intend to test, overriding the actual implementation, and creating a fake behavior, providing a false coverage perception. * Coupling production code with tests everywhere, so it's impossible to change anything without breaking some tests, even if the feature itself it's working as intended. * Not testing at all because "why should we even test anything if the feature is done, and it works? Why should we spend more time on this if it's done?." One of the main reasons for software testing is actually verifying a suite of proofs for the expected behavior of the final software piece. However, testing can (and should) be more than that. ### Software design Software design goes from algorithm to architecture design. Even when I believe these two levels of components have different needs and requirements, they still share some common patterns. For example, testing, and this is what we are going to talk about right now: > If it's easy to test, it will likely be because of good design. ### Software quality Is quality hard to measure out? Indeed. There are different measurement keys that we should take while considering quality for any piece of software. Still, I'm sure we could agree on this: > If you aim for quality in your software, you better seek a good design. Testing by itself means "proving," as we all know. That said... how difficult it sometimes turns to prove some logic that we finally give up because of its complexity itself? The art of testing is about using testing itself to help and contribute to the final result. To encourage good design, suppose we're able to use testing (of any kind) in our favor, depending on the context of what we want to prove. In that case, it will undoubtedly help us increase the product's end quality. Therefore, testing should be used not only to prove the behavior of our software but also to guide our software to a better design. Should we test everything? Well, that's the million-dollar question. In my opinion, everything depends on the context. We might encounter situations where tests might not be beneficial. Even in those situations, we should write our code as if it could be tested anyway. > Testable code tends to better design and, therefore, better quality. --- ## How to Improve Your Tech-Talk (or Any Other Presentation) Date: 2019-11-18 URL: https://chemaclass.com/blog/improve-your-tech-talk/ Tags: communication, leadership, productivity, career > We have found ourselves attending a meeting that felt like we were wasting our time with a monologue that is either hard to follow or doesn't seem so interesting as it could. Let's fix this. We have found ourselves attending a meeting that felt like we were wasting our time with a "monologue" that is either hard to follow or doesn't seem so interesting as it could. Let's fix this. Therefore, I was thinking about it, and I tried to get some keys to improving their general quality. It applies to all presentations but also tech-talks and other tech presentations in which engineers are usually involved. ## Structure of the talk To explain how I think a good presentation should look like I will address three main topics that are relevant to structure and design your presentation. 1. Content of the presentation: what message do you want to convey to whom and how? 2. Design and Layout: how you can design an easy-to-follow presentation that supports your talk instead of taking away the attention from what you are actually trying to say. 3. Lastly, I think also the audience is responsible for making a tech talk successful, so I will also add a reminder about the role and responsibilities of the listeners. ### Consider your audience When you prepare your presentation, ask yourself: * Who is attending the talk? * Which backgrounds do they have? * Which position do they have? * Which information is relevant to them? * Do they have to know all the keywords that you would like to use? ### Introduce the topic Create some atmosphere. Try to answer these questions: * Why should they listen to you? * Why should they spend their time in another meeting? * What will they have learned by the end of the talk? * What is your main message? Every meeting should have an output and an outcome. Keep it in mind. ### Create a Storyline * When preparing the main content of your talk, think about a storyline that connects your arguments. This makes it easier for the audience to follow. * Stick to the messages that are necessary to explain your idea or concept. * Leave out any unnecessary information that is not relevant to the core of your message. ### Build a conclusion Summarize the main conclusion(s) in a concise way: * What is the conclusion of this meeting? * What are the learnings from this meeting? * What are the open questions or next steps? ## Design and Layout ### Write less, talk more * A tech-talk is about learning new ideas and concepts. * A presentation should support your talk, not replace or replicate what you have said. * The more words on the slide, the fewer they will be remembered. * Use visuals/graphics that support your talk instead of additional text. ### Large fonts If you have some code to present, consider: * If it is a picture: use large fonts inside. I recommend using https://carbon.now.sh/ for simple snippets. Or just screenshots from your favorite IDE. * If you code in live: prepare your editor in advance. Use the Presentation Mode of your IDE. ## Role of the Audience ### Responsibilities of the attendee * No unnecessary phone usage, like Twitter, Instagram, Facebook, WhatsApp, Telegram, etc. * Keep your questions for the questions time, unless the presenter mentions at the very beginning that you can ask at any moment. Usually, it's better not to interrupt the topic, so we can ask the questions at the end. * Show interest in the topic. The presenter should have spent some time preparing the slides for you. * Pair with the presenter the interest of the topic. This is also the responsibility of the presenter. You both should be eager to learn more about the topic. ### Inner questions * Was it worth the time that we all spent in this room? * Do we regret the attendance of this meeting? At the end of the meeting, we should ask these questions in order to improve. Ask other people for their feedback, so we can grow further and together. # Readings - Full Articles --- ## Meditations Date: 2026-06-21 URL: https://chemaclass.com/readings/meditations/ Tags: philosophy, self-improvement > The private notebook of a Roman emperor who never meant for you to read it. Marcus Aurelius wrote these notes to remind himself how to stay sane while running an empire. Stoicism with the theory stripped out and only the practice left. Marcus Aurelius ruled the most powerful empire on earth. Emperor of Rome. And every night he sat down and wrote notes to himself about how to be a better person. He never meant for anyone to read them. That's exactly what makes the book so good. It's not advice for you. It's a man arguing with himself. There's no system here. No chapters, no plan. Just fragments, written across years in army camps and palaces. You can open it anywhere and find something useful. Less like a philosophy book. More like a notebook that survived 1,800 years by accident. I came to this one as an audiobook, in Spanish, a few sections at a time. It's the rare book that works better in fragments than in one sitting. A few minutes a day, one idea to sit with, then back to it tomorrow. ## Control What You Can, Ignore the Rest This is the core of the whole book. Some things are up to you: your judgments, your effort, your reactions. Most things are not: other people, your reputation, the past, the outcome. Confuse the two and you suffer. > "External things are not the problem. It's your assessment of them. Which you can erase right now." Marcus ran wars, plagues, and people who turned on him. He couldn't control any of it. What he could control was how he met it. That's not a comforting idea. It's a demanding one. It puts the work back on you. ## The Obstacle Is the Way Most people treat problems as interruptions to the good life. Marcus treats them as the material of it. The thing blocking your path becomes the path. > "The impediment to action advances action. What stands in the way becomes the way." A difficult colleague teaches patience. A setback teaches you to keep going. You don't need easier circumstances. You need to use the ones you have. Every obstacle is practice for the virtue it demands. ## Remember You Will Die Marcus comes back to death constantly. Not out of fear. As a tool. Knowing you'll die soon makes it obvious which things matter and which don't. > "You could leave life right now. Let that determine what you do and say and think." Old anger, status games, needing to be right: all of it shrinks when you remember the clock. Death isn't the enemy of a good life here. It's the editor. It cuts the noise. ## Other People Are the Test Marcus dealt with liars, fakes, and fools every single day. His response wasn't to withdraw. It was to expect it, and to keep doing his work anyway. > "When you wake up in the morning, tell yourself: The people I deal with today will be meddling, ungrateful, arrogant, dishonest, jealous, and surly." They act badly out of ignorance, not malice. You were made to work with them, like two hands or two rows of teeth. Getting angry at people for being people is wasted energy. ## The Present Is the Only Thing You Own The past is gone. The future hasn't arrived. The only moment you can act in is this one. Marcus keeps pulling himself back to it. > "Give yourself a gift: the present moment." You can't lose what you don't have, and you only ever have now. Worrying about the future and regretting the past both steal from the single thing that's actually yours. Do the next right thing, here, today. ## Key Takeaways - **Separate what you control from what you don't.** Your judgments are yours. The outcome isn't. - **Problems are the material, not the interruption.** What blocks the way becomes the way. - **Death clarifies.** Remembering it cuts the noise and shows what matters. - **People will be difficult. Do your work anyway.** Don't become what annoys you. - **Only the present is yours.** The past and future are borrowed worry. Two thousand years later, none of it feels dated. The empire is gone. The problems are identical. That's the strange comfort of this book: a man with absolute power discovered the same thing the rest of us do. The only thing you ever really run is yourself. --- {{ youtube(id="_6cSYKeafmk") }} --- ## The Art of Being Happy Date: 2026-03-15 URL: https://chemaclass.com/readings/the-art-of-being-happy/ Tags: philosophy, self-improvement > Schopenhauer's posthumous collection of 50 rules for practical happiness, built on the idea that avoiding suffering matters more than chasing pleasure. Surprisingly useful advice from philosophy's most famous pessimist. Schopenhauer is probably the most famous pessimist in philosophy. He believed suffering is the default state of existence and that desire only leads to more desire. So a book about happiness from this guy? Sounds like a contradiction. It's not. It's actually one of the most practical things he ever wrote. These 50 rules were never published during his lifetime. They were put together from his manuscripts and notes after he died. Less like a lecture. More like honest advice. ## Avoid Envy, Cultivate Gratitude Schopenhauer's point is blunt: **happiness depends more on what you avoid than on what you chase.** Envy, comparison, and excessive ambition cause more pain than anything they promise to deliver. > "We seldom think of what we have, but always of what we lack." His advice? Focus on what you already have instead of obsessing over what others have. Sounds obvious, right? But Schopenhauer says most people do the exact opposite. Instinctively. And it makes them miserable. ## Your Inner World Matters Most For Schopenhauer, what's inside you matters way more than what's around you. Money, status, reputation: all fragile. Your temperament? That stays with you. He breaks the sources of happiness into three buckets: - **What you are**: health, character, intellect. - **What you have**: property, possessions. - **What you represent**: reputation, status. The first bucket dominates the other two. A rich person with a bad temperament will still be miserable. A healthy person with a clear mind can be happy with very little. ## Want Less, Suffer Less Here Schopenhauer sounds a lot like the Stoics and the Buddhists. The engine of dissatisfaction? Desire. The trick isn't getting everything you want. It's wanting less. > "Wealth is like sea-water: the more we drink, the thirstier we become." This isn't asceticism for its own sake. It's a practical strategy: **reduce the surface area for disappointment.** The less you need, the less that can go wrong. ## Stop Living in the Future A recurring theme: the danger of living entirely for tomorrow. Planning and hoping pull you out of the present, which is the only place where happiness can actually be experienced. Many people reach old age and realize they spent their whole lives preparing to live rather than actually living. Schopenhauer saw this happening all around him in the 19th century. It's only gotten worse. ## Key Takeaways - **Happiness is about subtraction, not addition.** Reduce envy, excessive ambition, and dependency on others. - **Your inner life wins.** Health, character, and temperament determine happiness far more than money or status. - **Desire multiplies itself.** Wanting less is a more reliable path to contentment than getting more. - **The present is all you have.** Living for the future is a form of self-deception. - **Solitude is a strength.** Not everyone deserves your time and energy. A short, sharp book. Schopenhauer's pessimism doesn't make him joyless. It makes him realistic. And from that realism comes advice you can actually use. --- {{ youtube(id="q0zmfNx7OM4") }} --- ## Notes from Underground Date: 2026-02-04 URL: https://chemaclass.com/readings/notes-from-underground/ Tags: fiction, philosophy, psychology > A bitter, hyper-conscious man retreats from society to wrestle with free will, spite, and the stubborn irrationality of human nature. The Underground Man is not someone you'd want to have a beer with. He's bitter, contradictory, and painfully self-aware. He knows his flaws and still refuses to change. That's the whole point. The book is split into two parts. The first is a philosophical rant against reason, progress, and the idea that humans will always act in their own best interest. The second tells a story from the narrator's past that shows just how far his self-sabotage goes. ## On Free Will and Spite The narrator argues that people don't just want what's good for them. Sometimes they want chaos. Sometimes they want to suffer. Not because it makes sense, but because it proves they're free. > "What man wants is simply independent choice, whatever that independence may cost and wherever it may lead." He rejects the utopian idea that a perfect society could be built on rational self-interest. Humans aren't machines. They'll destroy their own happiness just to prove they can. ## The Wall and Inaction The Underground Man is paralyzed by over-thinking. He sees every angle, every consequence, every possible interpretation. So he does nothing. He calls himself more conscious than the "men of action" who simply act without questioning everything. > "I swear, gentlemen, that to be too conscious is an illness: a real thorough-going illness." There's something uncomfortably relatable here. The trap of analysis paralysis. Knowing too much can become an excuse to do nothing at all. ## The Liza Episode The second part shows the narrator meeting a young prostitute named Liza. He delivers a passionate speech about her future, about dignity and redemption. For a moment, he seems almost noble. Then she shows up at his door, and he crumbles. His cruelty returns. He can't accept genuine human connection because it threatens his carefully constructed self-image. This is Dostoevsky at his most uncomfortable. The gap between what we say and what we do. The way wounded pride can poison everything. ## Key Takeaways - Rationality doesn't fully explain human behavior. People act against their own interests out of spite, boredom, or the need to feel free. - Excessive self-awareness can become a prison. At some point, you have to act despite uncertainty. - The desire for control and the fear of vulnerability can destroy meaningful relationships. - Suffering isn't always something to be eliminated. Sometimes people cling to it as proof of their existence. This book is not easy or pleasant. But it gets under your skin. It anticipates exstentialism by decades and challenges the comfortable belief that progress and reason will save us. --- {{ youtube(id="yo1MBH6j4bs") }} {{ youtube(id="CoyN710gRv4") }} --- ## Broken Money Date: 2026-01-17 URL: https://chemaclass.com/readings/broken-money/ Tags: bitcoin, economics, philosophy > A deep dive into monetary history through a technological lens. Lyn Alden traces how innovations shaped money across centuries, examining commodity-based systems, modern fiat currencies, and emerging alternatives like Bitcoin. Essential reading for understanding why our financial system is failing and what we can do about it. A deep dive into monetary history through a technological lens. Lyn Alden traces how innovations shaped money across centuries, examining commodity-based systems, modern fiat currencies, and emerging alternatives like Bitcoin. ## What Makes Money Work? Alden starts with the fundamentals: what actually makes something money? She breaks it down into key properties (durability, divisibility, portability, scarcity) and shows how different forms of money throughout history have excelled or failed at these. The key insight? Money is a technology, and like all technologies, it evolves. What worked for ancient civilizations doesn't necessarily work in a globally connected digital world. ## The Fiat Experiment One of the most eye-opening sections covers how we ended up with our current fiat system. Alden documents the shift from gold-backed currencies to pure government-issued money, explaining why this experiment (only about 50 years old) has led to persistent inflation and monetary instability. > "Many currencies are rapidly diluted, which continually devalues the savings and wages of the billions of people who live and work within those jurisdictions." She backs this up with real-world examples from Nigeria, Egypt, Brazil, and other nations experiencing currency crises. For people in developed economies, these stories serve as a warning of what unchecked monetary expansion can lead to. ## The Network Effects of Money Alden brings a unique perspective as an engineer turned financial analyst. She applies network theory to explain why certain forms of money win out over others. Money, like the internet, benefits from network effects: the more people use it, the more useful it becomes. This framework helps explain both why the dollar dominates global trade and why Bitcoin has grown so quickly despite starting from zero. ## Bitcoin as a Solution The book builds logically toward Bitcoin as a potential fix for broken monetary systems. But unlike many Bitcoin books, Alden doesn't just cheerlead. She evaluates Bitcoin against gold and other cryptocurrencies, acknowledging trade-offs and limitations. Her analysis is grounded in engineering principles: What are Bitcoin's actual properties? How does it compare to historical forms of sound money? What problems does it solve, and what problems remain? ## Final Thoughts "Broken Money" stands out because it doesn't assume you already agree with the premise. Alden methodically builds the case that something is wrong with how money works today, traces the historical roots of these problems, and then evaluates potential solutions. Whether you end up convinced by her conclusions or not, you'll come away with a much deeper understanding of monetary systems and why they matter. You use money every day. Learn how it actually works. --- ## Principles of Economics Date: 2025-06-22 URL: https://chemaclass.com/readings/principles-of-economics/ Tags: economics, bitcoin, philosophy, career > If you've ever scratched your head at the economy, wondered why prices keep rising, or questioned why money seems to lose value over time, Principles of Economics by Saifedean Ammous might blow your mind. It's not your typical dry economics book. Instead, it's a bold, no-nonsense guide to understanding how the world really works, through the lens of Austrian economics. Here's what stood out to me. If you've ever scratched your head at the economy, wondered why prices keep rising, or questioned why money seems to lose value over time, Principles of Economics by Saifedean Ammous might blow your mind. It's not your typical dry economics book. Instead, it's a bold, no-nonsense guide to understanding how the world really works, through the lens of Austrian economics. Here's what stood out to me. ## 1. Economics = Human Action Ammous starts with something super simple but powerful: economics is just people making choices. Every time we choose to do one thing over another, that's economics in action. Forget all the charts and equations you might've seen in school. Real economics begins with you trying to make life better, one decision at a time. ## 2. Time Preference = How Much You Value the Future This idea was a game-changer: your time preference is how much you value stuff now vs. later. - If you spend everything today, you've got a high time preference. - If you save and plan for tomorrow, you've got a low time preference. Low time preference leads to building cool things. Like businesses, families, skyscrapers, or even civilizations. High time preference? That's fast food, impulse buying, and short-term thinking. ## 3. Good Money = Strong Society The quality of a society's money affects everything. If your money constantly loses value (_hello, inflation_), people stop saving and start living for today. He argues that government-controlled "fiat" money is the problem, and we need a return to "hard money" (like gold or [Bitcoin](/tags/bitcoin/)) that holds its value over time. Good money helps people plan, save, and grow wealth across generations. ## 4. Producing Stuff Takes Time, and That Matters Making things isn't instant. It takes time, tools, and planning. Ammous explains how advanced economies only exist because people invest in long-term production: factories, machines, supply chains. That's only possible when people trust their money and their future. So again, low time preference is key. ## 5. Entrepreneurs, Not Governments, Drive Progress If there's a hero in this book, it's **the entrepreneur**: the person who **takes risks**, builds businesses, and **creates value**. Ammous has zero love for central planners, regulations, or government bailouts. He's all about free markets and letting smart people solve problems without interference. When prices are honest and money is sound, people figure things out on their own. ## 6. Inflation and Central Planning? Big Red Flags Ammous doesn't pull punches. He's very critical of how governments manage money and the economy. He sees inflation as a sneaky form of theft and believes that constant meddling (like printing money or setting interest rates) only makes things worse. He even calls out entire fields like climate economics and ESG as being more about politics than real economics. ## 7. Bitcoin: The Grand Finale While this book isn't just about Bitcoin, it clearly leads there. After explaining why our current money system is broken, Ammous points to Bitcoin as the best solution we've seen in over a century. It's digital, limited, and no one can mess with it. Bitcoin is the return of sound money, and a chance to fix a lot of what's wrong today. ## Final Thoughts: A Crash Course in Real Economics "Principles of Economics" is like an economics red pill. It's straightforward, bold, and sometimes brutal. But if you're tired of the usual financial nonsense, this book will hit you like a breath of fresh air. You'll walk away with a new lens to see the world: why prices rise, why saving matters, and why the kind of money we use shapes everything. ## Austrian Economics vs Keynesian Economics {{ youtube(id="GUvTJ0xy74c") }} --- ## The Road to Serfdom Date: 2025-03-31 URL: https://chemaclass.com/readings/the-road-to-serfdom/ Tags: economics, philosophy, privacy, bitcoin > A quick and plain-English summary of Hayek's classic take on freedom, planning, and why good intentions can still go very wrong. First published in 1944, The Road to Serfdom is still making waves today. Friedrich Hayek, an Austrian economist, wrote it during World War II to warn against something he saw as really dangerous: central economic planning. His message? Even well-meaning government control over the economy can quietly take away our freedom, and possibly lead us toward dictatorship. --- ## 1. The danger of central planning Hayek's main point is simple: **when the government tries to control the economy, it ends up controlling people's lives too**. Once the state decides who gets what, it also ends up deciding who can do what. Even if it starts out with good intentions, it eventually leads to force, because people have different goals, and planners can't make everyone happy. > "Controlling the economy means controlling everything people want to do. (Chapter 7)" ## 2. The illusion of "good" socialism Some folks believe in democratic socialism, mixing freedom with shared planning. Hayek wasn't buying it. He says **you can't really separate socialism from authoritarianism**, because planning on behalf of "the group" means ignoring individual choices. Over time, the people running the system need to silence anyone who disagrees. That opens the door to the worst kinds of leaders. > "The worst get on top. (Chapter 10)" ## 3. Rule of law vs. Rule by discretion In a free society, rules should apply to everyone, be known ahead of time, and stay consistent, like traffic laws. But **planning needs flexible rules**. Bureaucrats need to make calls on the fly, and that gives them a ton of power. Hayek thinks that's a problem. The more discretion officials have, the less protection individuals have. > "Nothing distinguishes more clearly conditions in a free country from those in a country under arbitrary government than the observance in the former of the great principles known as the Rule of Law. (Chapter 6)" ## 4. Markets work because no one's actually in charge Hayek believed that no planner, no matter how smart, can replace what the market does on its own. Why? Because markets use **price signals** to share info. Millions of people making choices send signals (through prices) about what's needed and what's not. Trying to manage all that from the top? Super inefficient, and it usually fails. > "The more the state 'plans' the more difficult planning becomes for the individual. (Chapter 5)" ## 5. Incremental loss of freedom Hayek wasn't warning about overnight dictatorships. He was more concerned about **the slow loss of freedom** that comes from small steps: price controls here, nationalized industries there. Each step might feel harmless, but it adds up. And once people depend too much on the state, it's hard to say no to the next "solution" from above. > "The danger of tyranny inevitably arises from the methods of collectivism. (Chapter 10)" --- ## Final thoughts: Is Hayek still relevant? Totally. While the world has changed, the tension between freedom and control is still very real. Hayek's ideas remind us that freedom doesn't usually vanish overnight: it fades when we're not paying attention. Sure, some government help is needed. But Hayek's warning? Too much control, even with good intentions, can lead us somewhere we don't want to go. {{ youtube(id="2oG2SLzNo-E") }} --- ## Digital Minimalism Date: 2025-02-16 URL: https://chemaclass.com/readings/digital-minimalism/ Tags: productivity, psychology, career, philosophy > In an era dominated by constant connectivity, the concept of digital minimalism emerges as a refreshing antidote. Coined by Cal Newport, this philosophy isn't about rejecting technology but rather about using it with greater intention and care. By implementing digital minimalism, individuals can reclaim focus, reduce anxiety, and cultivate deeper, more meaningful relationships. In an era dominated by constant connectivity, the concept of digital minimalism emerges as a refreshing antidote. Coined by Cal Newport, this philosophy isn't about rejecting technology but rather about using it with greater intention and care. By implementing digital minimalism, individuals can reclaim focus, reduce anxiety, and cultivate deeper, more meaningful relationships. ## The Core Principles of Digital Minimalism Newport's approach to digital minimalism is built on three fundamental ideas: - **Clutter is Costly**: Unnecessary digital distractions fragment our attention and drain our mental energy. By decluttering our digital lives, we regain control over our focus and time. - **Optimization is Essential**: Rather than mindlessly accepting every new app or platform, digital minimalists carefully curate their technology use to align with their values and goals. - **Intentionality is Key**: Digital minimalists don't just cut back on screen time; they deliberately choose how and when to engage with technology to maximize its benefits while minimizing its drawbacks. ## The 30-Day Digital Declutter One of Newport's most actionable strategies is the 30-day digital declutter. The idea is simple: - Take a **30-day break** from all non-essential digital tools. - During this period, **explore alternative offline activities** that bring fulfillment. - After 30 days, **reintroduce only** the digital tools that **add value to your life**. This method serves as a reset, allowing individuals to assess which technologies truly enhance their lives rather than simply consuming their time. ## The Benefits of Digital Minimalism Those who embrace digital minimalism often report: - **Improved Focus**: With fewer distractions, deep work and meaningful projects become easier to accomplish. - **Reduced Anxiety**: Less exposure to social media and endless notifications results in a calmer, more present mindset. - **Richer Relationships**: By prioritizing face-to-face interactions, digital minimalists cultivate stronger and more meaningful personal connections. - **Increased Productivity**: Fewer digital distractions translate into higher efficiency and greater creative output. ## Practical Steps to Get Started If you're ready to experiment with digital minimalism, here are some simple steps to begin: - **Audit Your Digital Life**: Identify which apps, platforms, and devices are consuming the most time without offering meaningful benefits. - **Set Screen Time Limits**: Use built-in tools on your phone or computer to cap the amount of time spent on certain apps. - **Establish Tech-Free Zones**: Designate areas like the bedroom or dining table as screen-free spaces. - **Prioritize Analog Activities**: Replace digital distractions with books, hobbies, and in-person interactions. - **Schedule "Offline" Hours**: Set intentional times during the day when you completely disconnect from digital devices. ## Final Thoughts Digital minimalism **is not about rejecting technology** altogether. **It's about using it in a way that enhances** rather than diminishes **our quality of life**. By taking a more mindful approach to our digital [habits](/tags/habits/), we can reclaim our time, improve our well-being, and refocus on what truly matters. --- ## Video Summary {{ youtube(id="sJdZ7kmA2QQ") }} ### Cal Newport interviewed by Lex Fridman {{ youtube(id="y3Umo_jd5AA") }} --- ## Criptoria Date: 2025-02-09 URL: https://chemaclass.com/readings/criptoria/ Tags: bitcoin, privacy, philosophy, economics > A story about the evolutionary process that gave birth to computers, networks, cybersecurity and digital money. From Greece to Bitcoin, Cryptoria narrates a selection of milestones that occurred before and after Alan Turing. The book showcases a broad collection of people, organizations, concepts and inventions that evidence the deep historical and cultural relationship between mathematics, cryptography, computer science and the struggle for individual sovereignty. Cryptoria is addressed to all people convinced that, beyond inherited or imposed ways, there are other forms of social and economic organization that can and should be explored. Cryptoria is a story about the evolutionary process that gave birth to computers, networks, cybersecurity and digital money. From Greece to Bitcoin, Cryptoria narrates a selection of milestones that occurred before and after Alan Turing. The book showcases a broad collection of people, organizations, concepts and inventions that evidence the deep historical and cultural relationship between mathematics, cryptography, computer science and the struggle for individual sovereignty. Cryptoria is addressed to all people convinced that, beyond inherited or imposed ways, there are other forms of social and economic organization that can and should be explored. --- ## Content ## Part I: Before Turing ### 1. The Beginning of the End - The Boys Who Loved Puzzles - Alan Turing - Irving John Good - The Men Who Loved Their Genes - Galton's Chimera - The Lugenesis Mutation - The Power of Science Fiction - Hugo Gernsback - Amaizing Stories - The Descent of Saint Jude ### 2. In Search of Truth - As We Know It - Organon - The Mosaic Effect of Science ### 3. Numbers Shall Set You Free - Sovereign Mathematics - Formal Language - Set Theory - Modular Arithmetic - Congruence - Gauss - Gauss, Fermat and Euler - Boolean Algebra - Truth Tables - Axiomatize or Die - Unsolved Problems - Principia Mathematica - Bologna 1928 - The Revelation of Gödel - The Turing Machine - Computable Numbers - Computing Machine - Conclusions 1936 ### 4. The Mathematics of Secrecy - A Brief History of Numbers - Tool of War - Linked by Signals - The Persuasion Factory - Bletchley Park - Ratio Club - Metallic Intelligence - Eternal Alan ## Part II: After Turing ### 5. Modern Computing - Bell Labs - Claude Shannon - Glad You Came - Information Theory - The UNIX Era - New Languages - New Clock - The First Microprocessor - Horst Feistel - Lucifer - DES - ARPANET - First Companies - Computational Complexity ### 6. The Dawn of Strong Cryptography - Forbidden Cryptography - One Law to Ban Them All - Key Cryptography public - Diffie-Hellman-Merkle - Martin Hellman - Whitfield Diffie - Whit meets Martin - Diffie investigates with Hellman - Multi-user cryptographic techniques - Ralph Merkle - Merkle 1974 - Merkle puzzles - Ralph meets Whit and Martin - New directions in cryptography - The RSA team - Ron, Adi and Len - The RSA system - Key distribution centers (KDC) - Distributed networks - Merkle tree ### 7. Making legion - Internet universe - USENET - CPSR - David Chaum - Crypto Conferences - CRYPTO '82 - Zero knowledge proof - Free software - GNU Project - Free Software Foundation ### 8. Road to libertarian - Digital signatures - Taher Elgamal - Claus Schnorr - Curves elliptical - David vs. Big Brother - Cryptoanarchy - Extropians ### 9. Soldiers of Privacy - EFF - John Perry Barlow - Joohn Gilmore - Mitch Kapor - Electronic Frontier - Cyberspace Independence - EPIC - PGP - Phil Zimmermann - Hal Finney - Dances with Wolves - OpenPGP - Cypherpunks - Cyphernomicon - Cypherpunk Manifesto - Clipper Chip ### 10. Digital Money - Tatsuakki Okamoto - Proof of Dwork - Digicash - Hal 1993 - Magic Money Digicash - Smart Contracts - The Palace Mint - Hashcash - B-money - Bit Gold - RPOW ### 11. The Age of Satoshi - Satoshi Nakamoto - Whitepaper - Binaries - First TX - Bitcoin --- ## 🇪🇸 Related videos {{ youtube(id="7CvsAVaOjlQ") }} {{ youtube(id="DN3UKsf_Wmk") }} --- **Related links** - Book website: [www.prometeabtc.com/criptoria](https://www.prometeabtc.com/criptoria) --- ## Bitcoin with Rigor Date: 2025-01-18 URL: https://chemaclass.com/readings/bitcoin-with-rigor/ Tags: bitcoin, privacy, software-design > Bitcoin with Rigor goes beyond a basic explanation of Bitcoin, offering a detailed analysis of how Bitcoin works. It breaks down its components clearly, helping readers understand both the parts and the system as a whole. This deep dive explores Bitcoin’s potential and risks, recognizing it as a decade-old monetary experiment that hasn’t yet stood the test of time like gold or silver. Despite this, its innovative design makes it a promising system for the present and future. Bitcoin with Rigor goes beyond a basic explanation of Bitcoin, offering a detailed analysis of how Bitcoin works. It breaks down its components clearly, helping readers understand both the parts and the system as a whole. This deep dive explores Bitcoin’s potential and risks, recognizing it as a decade-old monetary experiment that hasn’t yet stood the test of time like gold or silver. Despite this, its innovative design makes it a promising system for the present and future. Bitcoin’s novelty makes it challenging to grasp fully. It requires knowledge of computing, economics, and finance while also being a digital asset with no historical precedent to guide understanding. Yet, much like the Internet (also relatively young but undeniably transformative), Bitcoin has the potential to redefine systems and leave a lasting impact. This book aims to equip readers with the tools to understand how Bitcoin works, empowering them to form their own well-informed opinions about its role in society or, if they choose, to begin a professional journey in this evolving sector. Written with rigor but without excessive technicality, the content is designed to be concise, accessible, and engaging, providing the foundation needed to truly comprehend Bitcoin. --- ## Content ### 1. Basic Computer Concepts - Information and Communication - How Computers Work - Languages and Protocols - The OSI Model: The Onion of Computing - Logic Gates: Fundamental Computing Functions - Client-Server and P2P Networks ### 2. Basic Cryptographic Concepts - Asymmetric Complexity - Ciphers, Keys, and Symmetric Cryptography - Asymmetric Cryptography - The Cypherpunk Movement - Cryptographic Hash Functions ### 3. The Basics of Bitcoin and Cryptocurrencies - Key Generators and Randomness - Cryptographic Signatures - The Discrete Logarithm Problem - Elliptic Curve Cryptography - Merkle Tree - Traditional Digital Money - Distributed Consensus Algorithms - Proof of Work (PoW) ### 4. Bitcoin Piece by Piece - Blockchain or Hashchain? - Block Synchronization - The Headerchain - Keys and Signatures in Bitcoin - Transactions and the UTXO Model - Bitcoin Script and Opcodes - P2PKH (Pay to Public Key Hash) and P2PK - Multi signatures and P2SH (Pay to Script Hash) ### 5. Nodes and Blockchain in Detail - Transaction Size and Frequency - Initializing a Full Network Node - Databases and Pruning - How a Wallet Works - Wallets, SPV Nodes, and Others - From Mempool to Blockchain - Forks and Consensus Criticality - Hard Fork vs. Soft Fork ### 6. Bitcoin Updates and Applications - Much Work Ahead - Transaction Malleability - Segregated Witness (SegWit) - P2WPKH and P2WSH - Unilateral Payment Channels - Lightning Channels - Multi-channel Payments and HTLCs - Lightning Network - Discreet Log Contracts (DLCs) - MAST, P2SMR, and P2CH - Taproot and Grafroot --- ## Book presentation {{ youtube(id="55ZRM7j1Jzc") }} --- **Related links** - Book website: [www.bitcoinconrigor.com](https://www.bitcoinconrigor.com) --- ## Man's Search for Meaning Date: 2024-11-29 URL: https://chemaclass.com/readings/mans-search-for-meaning/ Tags: psychology, philosophy, leadership, career > In Man's Search for Meaning, Frankl not only shares his harrowing experiences from the Holocaust but also presents a profound philosophy on the human condition. This book is a testament to the resilience of the human spirit, exploring how even in the darkest of times, individuals can find purpose and meaning. In "Man's Search for Meaning," Frankl not only shares his harrowing experiences from the Holocaust but also presents a profound philosophy on the human condition. This book is a testament to the resilience of the human spirit, exploring how even in the darkest of times, individuals can find purpose and meaning. Frankl's insights into the psychology of survival and his development of [logotherapy](https://en.wikipedia.org/wiki/Logotherapy) offer a unique lens through which we can view our own lives. As we delve into the depths of his narrative, we are invited to reflect on our personal search for meaning, challenging us to consider how we find purpose amidst life's trials and tribulations. ## Part 1: Experiences in a Concentration Camp Frankl, an Austrian psychiatrist, recounts his experiences in Nazi concentration camps, including Auschwitz and Dachau, during World War II. He describes the psychological stages prisoners went through: shock upon arrival, apathy where they became emotionally numb to survive, and finally, the phase of disillusionment or bitterness if they were liberated. Frankl emphasizes that even in the most horrific conditions, finding a purpose or meaning can provide the strength to survive. He notes that those who had something to live for, like a loved one or a personal project, were more likely to endure. ## Part 2: Logotherapy in a Nutshell This section introduces Frankl's psychotherapeutic method, which he developed based on his experiences. Logotherapy focuses on the meaning of human existence as well as on man's search for such a meaning. Unlike Freud's "will to pleasure" or Adler's "will to power," Frankl proposes the "will to meaning" as the primary motivational force in humans. Three Paths to Meaning: - Achievement: Doing a deed or creating work. - Experience: Experiencing something or encountering someone (love). - Attitude: The attitude we take toward unavoidable suffering. Even in extreme situations, Frankl asserts that one can choose one's attitude towards the situation, which can be a significant source of meaning. He discusses this concept as the feeling of meaninglessness in modern society, leading to various psychological issues. Logotherapy aims to guide individuals to find personal meaning. ## Key Takeaways ### Meaning of Life Frankl argues there is no one universal meaning to life; rather, meaning is unique to each individual and can shift over time. ### Suffering and Meaning Not all suffering must be devoid of meaning; it can be a path to finding or reaffirming meaning. ### Responsibility Each person has the responsibility to find their own meaning, which also entails the freedom to choose one's path. Frankl's book is not just a memoir but a testament to human resilience and the power of the human spirit to transcend even the worst circumstances through the discovery of meaning. --- ## Quotes > "Ultimately, man should not ask what the meaning of his life is, but rather he must recognize that it is he who is asked." > “We needed to stop asking about the meaning of life, and instead to think of ourselves as those who were being questioned by life, daily and hourly.” > “Everything can be taken from a man but one thing: the last of the human freedoms, to choose one’s attitude in any given set of circumstances, to choose one’s own way.” > "Freedom, however, is not the last word. Freedom is only part of the story and half of the truth. Freedom is but the negative aspect of the whole phenomenon whose positive aspect is responsibleness." --- ## Personal notes My favorite aspect of the book is its portrayal of life as an ongoing shift in perspectives, both from within oneself and in relation to the external world. It's like adjusting a camera lens, zooming in or out based on context, recognizing that we are simultaneously individual entities and part of a larger collective. This approach helps you gain a broader perspective, allowing awareness of both your limitations and your significance within any given scenario. Consequently, life doesn't inherently possess meaning; rather, it's the meaning we choose to attribute to it that shapes our existence. --- ## Animated book summary {{ youtube(id="-srD1Deh9Xg?t=64") }} --- ## Bitcoin: A Work in Progress Date: 2024-08-02 URL: https://chemaclass.com/readings/bitcoin-wip/ Tags: bitcoin, privacy, software-design > With thousands of 'crypto' projects out there, they say Bitcoin is old and boring, but nothing could be further from the truth. This book will guide you through the latest developments in Bitcoin, as seen through the eyes of one of its many developers. With thousands of "crypto" projects out there, they say Bitcoin is old and boring, but nothing could be further from the truth. This book will guide you through the latest developments in Bitcoin, as seen through the eyes of one of its many developers. You'll learn about the latest soft fork known as Taproot, the challenges of keeping open source software free of money-stealing bugs and malware, new ways to protect nodes against evildoers on the internet, how to deal with the ever-growing blockchain, and more! The book links to more than two hundred articles, videos, podcasts, and even the source code. And thanks to a tiny QR code next to every link, you'll never have to type long URLs. --- ## Contents ### The basics 1. Bitcoin Addresses 2. DNS Bootstrap and Tor V3 3. SegWit 4. libsecp256k1 ### Resource usage 5. Sync Time and AssumeUTXO 6. Utreexo ### Attacking Bitcoin 7. Eclipse Attacks 8. Fake Nodes 9. Guix ### Better Wallets 10. Script, P2SH, and Miniscript ### Taproot 11. Taproot and Schnorr 12. Activation Options ### Appendix A. More Episodes B. A crime on Testnet C. Bitcoin White Paper --- {{ youtube(id="pQb24UWWSl8") }} --- **Related links** - Book source code: [GitHub/Sjors](https://github.com/Sjors/nado-book/) - Book website: [www.btcwip.com](https://www.btcwip.com/) --- ## Mastering Bitcoin Date: 2024-07-05 URL: https://chemaclass.com/readings/mastering-bitcoin/ Tags: bitcoin, software-design, privacy > This book covers everything from the basics to the most profound technical aspects of how Bitcoin works. It is an excellent guide through the complex world of Bitcoin, providing the knowledge you need to participate in the Internet of Money. This book covers everything from the basics to the most profound technical aspects of Bitcoin. It is an excellent guide through this complex world, providing the knowledge you need to participate in the Internet of money. The first edition of this book was published in December 2014. Ten years later, a third edition with up-to-date knowledge just came out. It is highly recommended to all people interested in this outstanding topic and the tech behind it. - A broad introduction to Bitcoin and its underlying blockchain, ideal for nontechnical users, investors, and business executives. - An explanation of Bitcoin's technical foundation and cryptographic currency for developers, engineers, and software and systems architects. - Details of the Bitcoin decentralized network, peer-to-peer architecture, transaction lifecycle, and security principles. - New developments such as Taproot, Tapscript, Schnorr signatures, and the Lightning Network. - A deep dive into Bitcoin applications, including how to combine the building blocks this platform offers into powerful new tools. - User stories, analogies, examples, and code snippets illustrating key technical concepts. --- ## Contents 1. Introduction 2. How Bitcoin Works 3. Bitcoin Core: The Reference Implementation 4. Keys and Addresses 5. Wallet recovery 6. Transactions 7. Authorization and Authentication 8. Digital Signatures 9. Transaction Fees 10. The Bitcoin Network 11. The Blockchain 12. Mining and Consensus 13. Bitcoin Security 14. Second-Layer Applications > Full book also on [GitHub](https://github.com/bitcoinbook/bitcoinbook). ### Key takeaways 1. Your wallet doesn't store any bitcoins, only the keys to access them. The coins are stored in the blockchain. 1. Understanding **UTXOs** is crucial to understanding how transactions work. - These are outputs from previous transactions that have not yet been spent 1. A transaction needs: - **inputs**: UTXOs and an unlocking script (scriptSig) which proves ownership. - **outputs**: the recipient's address and the amount to send. 1. The unlocking script is written in a custom language called [**Script**](https://en.bitcoin.it/wiki/Script). - Transaction validation is achieved through the execution of a script. - This allows for a nearly infinite variety of conditions to be expressed. - Script is a stack-based lang, processed from left to right. 1. Bitcoin is often referred to as "**programmable money**" because it allows: Multisignature, timelocking and conditional spending. - Extends Bitcoin's functionality beyond simple value transfers. 1. Common Bitcoin [**address types**](/blog/programmable-money#common-bitcoin-address-types): - P2PKH: Begins with `1`. Standard transactions using public key hashes. - P2SH: Begins with `3`. Encapsulates complex scripts like multisig. - P2WPKH: Begins with `bc1`. Native SegWit, more efficient transactions. - P2WSH: Begins with `bc1`. SegWit for complex scripts. - P2TR: Begins with `bc1p`. Taproot, enhanced privacy and efficiency. - Bech32: Starts with `bc1`. Human-readable, designed for SegWit and Taproot. 1. Digital signatures serve three purposes in Bitcoin transactions: - First, it proves that the controller of a private key has **authorized** the spending of those funds. - Secondly, the proof of authorization is **undeniable**. - Thirdly, the authorized transaction **cannot be changed** by unauthenticated third parties. 1. [Schnorr's signatures](https://en.wikipedia.org/wiki/Schnorr_signature) aren't specific to the [elliptic curve cryptography](https://en.wikipedia.org/wiki/Elliptic-curve_cryptography) (ECC) that Bitcoin uses, although it is most associated with ECC today. They have a number of nice properties: - **Provable security**: strong security guarantees based on the hardness of the discrete logarithm problem, with formal proofs ensuring their robustness against attacks. - **Linearity**: allows for efficient aggregation of multiple signatures into a single compact signature, simplifying verification processes. - **Batch verification**: enabling multiple signatures to be verified simultaneously in a more computationally efficient manner. 1. The best known secure secret sharing algorithm is [Shamir's Secret Sharing](https://en.wikipedia.org/wiki/Shamir's_secret_sharing). 1. Running a **full node** gives you the pure Bitcoin experience: independent verification of all transactions without trusting any other system. 1. **Merkle tres** are used to summarize all transactions in a block, producing an overall commitment to the entire set of transactions and permitting a very efficient process to verify whether a transaction is included in a block. 1. Mining is one of the inventions that make Bitcoin special, a **decentralized consensus** mechanism that is the basis for P2P digital cash. - It secures the Bitcoin system and enables the emergence of network-wide consensus without a central authority. 1. A **soft-fork** is a forward-compatible change to the consensus rules that allows unupgraded clients to continue to operate in consensus with the new rules. --- ## The Genesis Book Date: 2024-06-21 URL: https://chemaclass.com/readings/the-genesis-book/ Tags: bitcoin, privacy, economics, philosophy > Bitcoin did not appear out of nowhere. For decades prior to Satoshi Nakamoto’s invention, a diverse group of computer scientists, privacy activists, and heterodox economists tried to create a digital form of money that could operate independently of government control. The Genesis Book tells the story of the people and projects that inspired the invention of the world’s first successful peer-to-peer electronic cash system. Bitcoin did not appear out of nowhere. For decades prior to Satoshi Nakamoto’s invention, a diverse group of computer scientists, privacy activists, and heterodox economists tried to create a digital form of money that could operate independently of government control. The Genesis Book tells the story of the people and projects that inspired the invention of the world’s first successful peer-to-peer electronic cash system. --- ## Contents ### Part I: Foundations 1. Spontaneous Order 2. Free and Open Source 3. Neutral Money 4. Cryptography 5. Denationalization of Money 6. eCash (and Trustless Time-stamps) 7. The Extropians ### Part II: Cypherpunks 8. The Cypherpunk Movement 9. Cypherpunk Currency 10. Hashcash 11. Bit Gold 12. B-money (and BitTorrent) 13. RPOW ### Part III: Bitcoin 14. Twenty-First Century Fiat 15. The White Paper 16. The Release --- > The central bank declared the insurer "too big to fail," and, along with the US Treasury, bailed it out with an injection of $68 billion (plus another $112 billion in guarantees). > If Friedrich Hayek's analysis of monetary economics early in this career was correct, Bitcoin could help fix the economy. As an unbacked currency that operated without a central bank, bitcoin was an entirely homogeneous form of money. Anyone could control their own coins, and there were no reserve ratios to worry about. And, since bitcoin existed on the internet, it was borderless as well. Anyone with an internet connection, anywhere in the world, could download the software and start sending and receiving transactions to anyone else. This combination (a homogeneous, borderless type of money with a fixed supply) is what Hayek once described as neutral money. > Bitcoin would also facilitate international trade in a much more straightforward manner, where only the buyer and seller and (the prices of) their respective products are affected, not the price levels across their entire countries. > In Bitcoin, no one is in charge... and everyone is in charge. --- {{ youtube(id="TXs3maguye4") }} --- ## The Phoenix Project Date: 2024-05-31 URL: https://chemaclass.com/readings/the-phoenix-project/ Tags: devops, leadership, agile, team-management > This is a story about an impossible project in which the people around are constantly playing politics, busy fixing critical bugs and wasting constant efforts on quick patches instead of helping the business thrive. This is a story about an impossible project in which the people around are constantly playing politics, busy fixing critical bugs and wasting constant efforts on quick patches instead of helping the business thrive. > If IT fails, the business fails. **DevOps Principles**: Flow, Feedback, and Continual Learning and Experimentation. These guiding concepts promote advancements in responsiveness, dependability, and teamwork. #### Summary The book starts with the promotion of Bill as VP of IT, and with that the responsibility of delivering an imposible (Phoenix) project. The CEO warns him that if the project does not deliver in time, then the entire IT department will be outsourced and the current IT employees will be fired. Bill tries to understand the status quo, and finds out that the people are too busy firefighting constantly and dealing with too many responsibilities (in addition, they are understaffed). Everything is urgent and needs to be done asap. The deadline was already setup from above, and there is no planning or discussions with other departments. TL;DR: Corporate chaos, politics and bloodbath meetings. However, Bill gets to know one person in the company that helps him improve the status quo, not by telling him what to do but by asking him questions to help find the solution. For example, the first question: "What are the four types of work that IT does?" which is not answered immediately but during the story: 1. **Business projects**: these are the projects that directly affect business goals. They generate revenue and deliver value to customers. 2. **Internal projects**: these are regular tasks that keep the system working. Like system upgrades, security patches, etc. It tends to be invisible and can become a bottleneck for IT departments. 3. **Changes**: the result of the previous business and internal projects, to know what to change with and within them. 4. **Unplanned work**: this is the real productivity killer. This is related to all operational issues resulted from the previous three types of work. --- {{ youtube(id="6QNdL1I7OTM") }} --- ## Radical Candor Date: 2024-04-17 URL: https://chemaclass.com/readings/radical-candor/ Tags: leadership, communication, team-management, mentoring > Radical Candor is a management philosophy developed by Kim Scott, a former Google leader. It's a crash course on how to be a great manager, focusing on being empathetic and results-oriented. The core idea is to create a stress-free environment where people feel safe to speak their minds, get their jobs done, and feel respected. Radical Candor is a management philosophy developed by Kim Scott, a former Google leader. It's a crash course on how to be a great manager, focusing on being empathetic and results-oriented. The core idea is to create a stress-free environment where people feel safe to speak their minds, get their jobs done, and feel respected. ### Key Insights - Command and control can hinder innovation and harm a team's efficiency. Collaboration and innovation flourish when human relationships replace bullying and bureaucracy. - The goal of Radical Candor is to help managers and leaders achieve collaboratively what they cannot achieve individually, by caring about the people they work with. - Radical Candor is about being radically honest and open, while still being kind and respectful. ### The Two Dimensions of Radical Candor - **Care Personally**: This dimension involves showing genuine interest in people's lives, well-being, and goals. It's about being human and empathetic. - **Challenge Directly**: This dimension involves giving specific, timely, and actionable feedback that is both kind and clear. It's about being straightforward and results-oriented. ### Avoiding the Three Behaviors 1. **Obnoxious Aggression**: Being overly critical or aggressive. 2. **Ruinous Empathy**: Being overly sympathetic or enabling. 3. **Manipulative Insincerity**: Being insincere or manipulative in your feedback. ### Radical Candor in Action - Give specific and sincere praise and kind and clear criticism. - Create a stress-free environment where people feel safe to speak their minds. - Focus on collaboration and innovation, rather than command and control. - Care about the people you work with and challenge them to do their best work. By applying Radical Candor, managers and leaders can build strong relationships, motivate their teams, and achieve better results. --- {{ youtube(id="O9hDTLo5rLA") }} --- ## The Lean Startup Date: 2024-01-26 URL: https://chemaclass.com/readings/the-lean-startup/ Tags: leadership, team-management, productivity, agile > Most startups fail. But many of those failures are preventable. The Lean Startup is a new approach being adopted across the globe, changing the way companies are built and new products are launched. Most startups fail. But many of those failures are preventable. The Lean Startup is a new approach being adopted across the globe, changing the way companies are built and new products are launched. Eric Ries defines a startup as an organization dedicated to creating something new under conditions of extreme uncertainty. This is just as true for one person in a garage or a group of seasoned professionals in a Fortune 500 boardroom. What they have in common is a mission to penetrate that fog of uncertainty to discover a successful path to a sustainable business. ## Key Takeaways - Test frequently and learn quickly - Observe and measure real customer behaviour - Focus exclusively on capturing actionable Metrics - Be comfortable pivoting based on key learnings - Embrace new accounting methods - Learn what is not working and apply changes immediately: stay lean ### Summary {{ youtube(id="RSaIOCHbuYw") }} --- {{ youtube(id="fEvKo90qBns") }} --- ## Invincible Date: 2023-12-09 URL: https://chemaclass.com/readings/invincible/ Tags: philosophy, psychology, productivity > Marcos Vazquez combines stoic philosophy with modern psychology to train your mind for clarity, determination, and discipline in the face of adversity. The quality of your life depends on the quality of your mind. Unfortunately, we spend little time improving our thoughts, and it is rarely taught at school. As a result, we go through life without really understanding how to use our mind. We have in our head the most sophisticated object in the world, but we barely know how it works. Most people are unable to direct their mental strength toward the goals they truly desire. They get distracted and frustrated. They can’t resist temptation or persevere in the face of adversity. In the end, they quit. Luckily, our mind can be trained, and this book will show you how. It combines **stoic philosophy** with **modern psychology**, and provides the tools to help you visualize with clarity, act with determination and resist with discipline. > "We suffer not from the events in our lives, but from our judgement about them." Epictetus. Any external change requires an internal change first. If you want to transform your body, you must start from within. A weak mind will never create a strong body. This book will help you use your mind to improve your body, but it actually goes much further. It is not a simple guide to optimize your daily habits, but rather it aims to guide your own philosophy of life. The tools you will develop will help you with anything you want to achieve. Life is always simpler with clarity, determination and discipline. #### The philosophy of Stoicism {{ youtube(id="R9OCA6UFE-0") }} --- ## The Alchemist Date: 2023-11-07 URL: https://chemaclass.com/readings/the-alchemist/ Tags: fiction, philosophy, career > A classic novel about Santiago, a boy who embarks on a journey seeking treasure in Egypt, learning the true importance of self-improvement and what really matters in life. The Alchemist is a classic novel in which a boy named Santiago embarks on a journey seeking treasure in the Egyptian pyramids after having a recurring dream about it. On the way meets mentors, falls in love, and most importantly, learns the true importance of who he is and how to improve himself and focus on what really matters in life. #### Video Summary {{ youtube(id="b41MXNaFJj0") }} --- ## Crucial Conversations Date: 2023-10-31 URL: https://chemaclass.com/readings/crucial-conversations/ Tags: communication, leadership, psychology, team-management > Crucial Conversations gives you the tools you need to step up to life's most difficult and important conversations, say what's on your mind, and achieve the positive resolutions you want. When stakes are high, opinions vary, and emotions run strong, you have three choices: Avoid a crucial conversation and suffer the consequences; handle the conversation badly and suffer the consequences; or read Crucial Conversations and discover how to communicate best when it matters most. > If you don't talk it out, then you'll act it out. --- ### Chapters 1. Know your heart 2. Ensure safety 3. Beware of reverting to your style under stress 4. Make the content safe 5. Control your emotions 6. Share your stories 7. Move from conversation to results ## Key takeaways A crucial conversation is a confrontation you need to handle with care, which usually is characterized by three factors: 1. Stakes are high 2. Opinions vary 3. The parties involved have strong emotions Examples: - Calling a client who didn't pay their invoices - Talk to your boss about a promised promotion that is being delayed - Confronting a teammate who is not doing their share of the project - Talking to your siblings about your parent's inheritance Navigating through a crucial conversation is like defusing a bomb. Touch the wrong button or hit the wrong wire, and you create an explosion of emotions. The key is to have an honest and productive dialog to work out the situation. These are unplanned conversations, and we tend to avoid them because we believe that we are going to make it worse. We tend to react negatively because we are humans, and human beings "behave their worst at the most critical moments." ### The "Story" Everybody walks into a crucial conversation with a story. Examples: - My mate doesn't care about the project because they don't come to the meetings - My boss doesn't care about my career because they haven't given me a promotion If you approach a crucial conversation with a story in mind, there is no room for dialog, because your mind already made it up. #### When... I... framework To create the space for a dialog, you need to start assuming you don't know the whole story, and that **you need the help of the person** you are talking to. You can use: ` When... I...` Example: > **When** [you don't show up to team meetings], > **I** [fear you don't care about this project]. Invite them to share their own `When...I...`, so you can discover together what might be the issue, misunderstanding, or misalignment between you two. The key is to avoid being passive/aggressive, but rather assertive, and honest with facts. This will help reduce the chance of being defensive and willing to help clarify the situation. ### Common goal To avoid a confronting hit and get back to a productive dialog, you need to convince the person you're talking to that you're not their opponent or enemy, you are on the same side. To do this, you must communicate a common goal, value, or purpose. > I don't want to fight. I just want to find a way for both of us to get [common goal/purpose]. > I know we both care about [common value], let's see if we can both get what we want. Make a good-faith guess. The more you engage in productive dialog, the more chance you have to find **agreements**, and the more luckily you will **work together** to resolve the problem at the heart of a crucial conversation. --- ### Keynote: Mastering The Art of Crucial Conversations {{ youtube(id="uc3ARpccRwQ") }} #### Video Summary {{ youtube(id="Q2yG142cyNg") }} --- ## It's Your Ship Date: 2023-09-20 URL: https://chemaclass.com/readings/its-your-ship/ Tags: leadership, team-management, communication, mentoring > It's Your Ship is a leadership book written by D. Michael Abrashoff, a former commander of the USS Benfold, a guided missile destroyer. The book focuses on Abrashoff's experiences and the leadership principles he applied to transform the performance and culture of his ship. "It's Your Ship" is a leadership book written by D. Michael Abrashoff, a former commander of the USS Benfold, a guided missile destroyer. The book focuses on Abrashoff's experiences and the leadership principles he applied to transform the performance and culture of his ship. ## Key takeaways - **Empowerment**: Abrashoff emphasizes the importance of empowering team members. He believes that when people feel trusted and empowered, they take ownership of their work and perform at a higher level. - **Listen and Communicate**: He highlights the significance of active listening and open communication. He made an effort to listen to his crew members, seek their input, and address their concerns. This helped build trust and fostered a culture of open dialogue. - **Lead by Example**: Leaders should set the standard through their own actions. He worked hard to be a positive role model for his crew, demonstrating the behavior and work ethic he expected from them. - **Delegate Responsibility**: Abrashoff encourages leaders to delegate authority and responsibility. By giving his crew members more control over their areas of expertise, he allowed them to take ownership of their roles. - **Foster a Culture of Innovation**: Abrashoff promoted a culture of continuous improvement and innovation. He encouraged his crew to suggest and implement changes that would enhance efficiency and effectiveness. - **Celebrate Achievements**: It is important to recognize and celebrate the achievements and contributions of team members. This recognition serves as positive reinforcement and motivates individuals to continue performing at a high level. - **Take Calculated Risks**: Abrashoff was not afraid to take calculated risks in order to achieve better results. He was willing to challenge established procedures and norms when he believed it would lead to improvements. - **Build Trust and Respect**: Trust and respect are foundational elements of effective leadership. Abrashoff worked to build strong relationships with his crew members, which created a sense of camaraderie and mutual trust. - **Adaptability and Flexibility**: In a rapidly changing environment, leaders need to be adaptable and flexible. Being able to adjust to new circumstances and make quick decisions is crucial for success. - **Continuous Learning and Improvement**: A mindset of continuous learning and improvement is crucial. He encouraged his crew to seek out opportunities for professional development and to always strive for excellence. Overall, "It's Your Ship" provides valuable insights into leadership principles that can be applied in various organizational settings. Abrashoff's approach emphasizes the importance of empowering and valuing team members, fostering open communication, and constantly seeking ways to improve performance. {{ youtube(id="A-mZW2VZZgY") }} --- ## The Day of the Triffids Date: 2023-08-13 URL: https://chemaclass.com/readings/the-day-of-the-triffids/ Tags: fiction, psychology > This book is fantastic and frightening, but entirely plausible. It doesn't just seem scientifically possible, but its characters are living people shaken out of the civilization they know into the horror of a world dominated by triffids. This book is fantastic and frightening but entirely plausible. It doesn't seem scientifically possible, but its characters are living people shaken out of the civilization they know into the horror of a world dominated by "triffids". The triffids are grotesque and dangerous plants, over seven feet tall, originally cultivated for their yield of high-grade oil. So long as conditions give mastery to their human directors, they are a valuable asset to mankind. But when a sudden universal disaster turns those conditions upside down, the triffids, seizing their opportunity, become an active and dreadful menace. ### Summary {{ youtube(id="OQfdjhDOuCo") }} > Summary based on the movie "[The Day of the Triffids](https://www.imdb.com/title/tt1332653/) (2009)" --- ## The Book Of Satoshi Date: 2023-07-10 URL: https://chemaclass.com/readings/the-book-of-satoshi/ Tags: bitcoin, economics, philosophy > A compilation of Satoshi Nakamoto's emails, forum posts, and writings from 2008-2010 that detail Bitcoin's creation, design decisions, and the vision behind the protocol. Have you, like the rest of the world, speculated as to the identity of Satoshi Nakamoto, anonymous creator of Bitcoin? The world's first cryptocurrency, Bitcoin went online in 2009 and has since revolutionized our concepts of currency and money. Not supported by any government or central bank, completely electronic, Bitcoin is a virtual currency based on advanced cryptographic systems. Like the currency he created, the identity of Bitcoin's creator Satoshi Nakamoto is virtual, existing only online. The Nakamoto persona, which may represent an individual or a group, exists only in the online publications that introduced and explained Bitcoin during its earliest days. Here, collected and professionally published for the first time are the essential writings that detail Bitcoin's creation. The Book of Satoshi provides a convenient way to parse through what Bitcoin's creator wrote over the span of the two years that constituted his "public life" before he disappeared from the Internet . . . at least under the name Satoshi Nakamoto. Beginning on November 1st 2009 with the publication of the seminal paper describing Bitcoin, this public life ends at about the time PC World speculated as to a possible link between Bitcoin and WikiLeaks, the infamous website that publishes leaked classified materials. Was there a connection? You be the judge. Nakamoto's true identity may never be known. Therefore the writings reproduced here are probably all the world will ever hear from him concerning Bitcoin's creation, workings, and theoretical basis. Want to learn more about Bitcoin? Go directly to the source-the writings of the creator himself, Satoshi Nakamoto. {{ youtube(id="kaBmAV5DaXI") }} --- ## Fahrenheit 451 Date: 2023-06-28 URL: https://chemaclass.com/readings/fahrenheit-451/ Tags: fiction, philosophy, psychology > Ray Bradbury's dystopian masterpiece about a fireman whose job is to burn books, until a chance encounter makes him question everything about his society's war on knowledge. Guy Montag is a fireman. His job is to **destroy** the most illegal of commodities, the **books**, along with the houses in which they are hidden. Montag never questions the destruction his actions produce, returning each day to his bland life and wife, Mildred, who spends all day with her "television family." But when he meets an eccentric young neighbor, Clarisse, who introduces him to a past where people didn't live in fear and to a present where one sees the world through the ideas in books instead of the mindless chatter of television, Montag begins to question everything he has ever known. ### Summary {{ youtube(id="YMZcp0EQO2s") }} > Another great summary: [https://youtu.be/_agaWPlVG8Q](https://youtu.be/_agaWPlVG8Q) --- ## The Blocksize War Date: 2023-06-20 URL: https://chemaclass.com/readings/the-blocksize-war/ Tags: bitcoin, economics, leadership > Jonathan Bier chronicles the Bitcoin blocksize war (2015-2017), exploring the key players, strategies, and ideological battles that shaped who controls Bitcoin's protocol. This book covers Bitcoin's blocksize war, which was waged from August 2015 to November 2017. On the surface the battle was about the amount of data allowed in each Bitcoin block, however it exposed much deeper issues, such as who controls Bitcoin's protocol rules. This book explores some of the major characters in the conflict and includes coverage, from both the front lines and behind the scenes, during some of the most acute phases of the struggle. The account in this book includes discussions with the key players from both sides during the war, exploring their motivations, strategy and thought processes as the exhausting campaign progressed and developed. ## Chapters 1. First strike 2. March to war 3. Scaling I - Montreal 4. Scaling II - Hong Kong 5. SegWit 6. Lightning network 7. Bitcoin Classic 8. Hong Kong Round table 9. Faketoshi 10. The DAO 11. Scaling III - Milan 12. Bitcoin unlimited 13. Exchanges 14. ASICBoost 15. Dragons's Den 16. Litecoin 17. User - Activated softfork 18. New York agreement 19. Bitcoin Cash 20. SegWit2x 21. Victory ### Summary {{ youtube(id="6YtS5ZNuuTw") }} --- ## Agile Project Management Date: 2023-05-31 URL: https://chemaclass.com/readings/agile-project-management/ Tags: agile, team-management, scrum, communication > Projects that followed a Waterfall methodology tended to exceed their expenses in the first initiative over time, while the product delivered was below standard and difficult to use. That situation originated that a group of developers signed a brief, 68-word manifesto in 2001. A basic and straightforward overview of what Agile is, presenting some framework examples that are well known today, such as Scrum or Kanban, everything condensed in a 100's pages book that you can read in a couple of hours. ## Chapters 1. The fluid manifesto 2. Being agile 3. Agile process 4. Planning for success 5. Agile communication 6. Scrum basics 7. Introduction to Kanban 8. Building an adaptive team 9. Leadership and collaborative management 10. Common errors behind agile failure 11. Final words: agile is adaptation --- > "The benefits of Agile projects extend no only to the team using it, but also to the customer receiving the final product." > "There is an underlying critical metric that consistently leads to the success of an Agile project: communication. Miscommunication, under-communication, or poor communication of any type leads to the collapse and failure of said project." --- ### Key takeaways Projects that followed a **Waterfall** methodology tended to exceed their expenses over time, while the product delivered was below standard and difficult to use. That situation originated that a group of developers signed a brief, 68-word manifesto in 2001. #### A brief background During the 1960s, software got into a big crisis; creating software was complex but changing it later became pure chaos. **Waterfall** to the rescue. **Waterfall** outlined a simple, logical set of processes that a company would need to follow for a project to be successful. Its name comes from the metaphor of water gently cascading down a predictable, steady, incremental stream. Its life cycle of software development would be in six simple steps. 1. Requirements 2. Analysis 3. Design 4. Code 5. Testing 6. Operations For 10 years, **Waterfall** was the standard methodology in the software universe. And for 10 more years, chaos persisted. Although the intention was good, the reality is that the ever-changing set of constraints does not cope very well with this methodology because each step is dependent on the previous one. 86% of the time a company uses the **Waterfall** method for project management, the customer receives inadequate or useless software. A lot of software projects were unused or never finished. During the 70' and 80', **Iterations and Incremental Development (IID)** proved to be a viable option. In the 90' surges an **Evolutionary Delivery (ED)**, which changes the situation. The developer is responsible for listening to the user's reactions early and often. The user starts playing a direct role in the development process. A few years later, a new method surged **Rapid Iterative Production Prototyping (RIPP)**, later called **Rapid Application Development (RAD)**, which they claimed *"Working software in 90 days... or your money back."* Lastly, during the 90' **Extreme Programming (XP)**, **Scrum**, and **Crystal** were defined in detail. These distinct yet similar solutions were decentralized, working independently of one another. This realization led to that night in Utag the unification of these ideas under one banner, in one document. **Agile** became the definitive standard for software development. ### The Agile Manifesto - Individuals and interactions over processes and tools - Working software over comprehensive documentation - Customer collaboration over contract negotiation - Responding to change over following a plan > That is, while there is value in the items on the rights, we value the items on the left more. --- ## Effective Remote Work Date: 2023-04-17 URL: https://chemaclass.com/readings/effective-remote-work/ Tags: team-management, communication, productivity, leadership > An effective remote work environment is about treating everyone as remote, with everyone in mind having the same level, equality, and information. An effective remote work environment is about treating everyone as remote, with everyone in mind having the same level, equality, and information. --- ## Part 1 - Getting oriented for remote work It covers the foundation for a possible remote work environment. It seems a bit common sense nowadays, especially after the covid hit, where we had no choice but to work remotely for more than a year. But I think it's still good to see this foundational knowledge written to polish assumptions in the following chapters of the book. ### Chapters - **A remote future**: A brief history of the future. Lockdown. Remote is here to stay. Time to get set up. - **Getting set up**: The office: what we want and what we don't. The basics, briefly. In the real world. Installing mental scaffolding. The golden rule. ## Part 2 - Building effective remote teams Most likely, we all had the experience of casual remote work (before remote work was even a trend) when we felt that we were apart from the team dynamics when we were doing remote work for some reason. This is precisely why "treat everyone as remote" is so important - when at least one person works remotely. There are different ways to communicate depending on the urgency, intention, and how long and easy that message should be accessible. It's about sync/async communication with our peers. Highly related to the previous paragraph, the quality of our messages should be considered when aiming for effective communication. We need to consider the right tools. A phone call is different from a chat message or an email. Use the right tools for the right messages within the proper context. ### Chapters - **Treat everyone as remote**: Out of sight, out of mind. A principle for cultural change. Taking practical action. Let's build a model! - **The spectrum of synchronousness**: Synchronousness. Permanence. Restoring your humanity. Onward to Hyrule. - **The same but different**: A normal day in the office. Through the magic mirror. Conquering the dark world. Let's discover some artifacts. - **Artifacts for a better future**: Comparing artifacts. Written artifacts. Codebase and recorded artifacts. Getting on board with onboarding. - **Onboarding and orientation**: The contribution curve. The onboarding equation. And here's the trick. Considering communication. - **Effective communication techniques**: Why humans communicate. Principles for better remote communication. Techniques to improve interactions. The right tools and when to use them. Turning inwards. - **Managing yourself**: An organizational bedrock. On being unobserved. Riding peaks and troughs. From yourself to teams. - **Managing teams**: The output equation revisited. Shrinking the scale factor. Supercharging the scale factor. Time to take it up a level. ## Part 3 - Creating a world-class remote culture Even though a fully remote company might not be possible for some reasons out of our control, if the company claims to be remote-friendly, there are some aspects that we can consider: 1. Do you treat everyone as remote? 2. Do you provide a remote work-space setup? 3. Do you spend money equally on in-office and remote staff? 4. Do you optimize for asynchronous communication? 5. Do you create artifacts from synchronous interactions? 6. Do you measure staff by their impact? 7. Do you allow staff to choose flexible hours? 8. Are the members of the executive team remote workers? 9. Do you use the best collaborative tools that money can buy? 10. Do you hire staff anywhere in the world? 11. Do you support families as well as employees? 12. Do you give back to an employee's local community? > This is a "Joel Test version for a remote working environment". The Joel Test originated in the year 2000, during the dot-com bubble; a test to rate the quality of teams with "yes/no" questions. If a team can answer each question wit a yes, they're likely a productive team. [Read more about the original Joel Test](https://www.joelonsoftware.com/2000/08/09/the-joel-test-12-steps-to-better-code/). ### Chapters - **The remote working test**: The joel test. Twelve questions about remote working. Making changes in your company. Something to guide us. - **Creating a handbook**: The GitLab handbook. Creating a handbook for your team. A handbook for the company. Fully making the shift. - **Becoming fully remote**: The spectrum of remoteness. The challenge of retrofitting fully remote culture. The triangle of transition. Learning from trailblazers. Now the difficult stuff. - **The hard parts**: Walking the curves. The physical and mental impact of working remotely. Supporting other remotely. - **The path to equality is remote**: Diversity and inclusion. Remote: The great leveler. This is just the beginning. --- ## Book summary {{ youtube(id="6BFIg6Opd1c") }} --- ## Accelerate Date: 2023-03-19 URL: https://chemaclass.com/readings/accelerate/ Tags: devops, software-design, agile, productivity > The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations Accelerate explores how software development teams using **Lean Software** and **DevOps** can measure their performance and the performance of software engineering teams impacts the overall performance of an organization. > Note: DevOps is about integrating and automating software development (Dev) and IT operations (Ops), focusing on improving (and shortening) the systems development life cycle. ## Key Capabilities ### Continuous Delivery - Use Version Control for all Production Artifacts - Automate Your Deployment Process - Implement Continuous Integration - Use Trunk-Based Development Methods - Implement Test Automation - Continuous Delivery (CD) ### Architecture - Use a Loosely Coupled Architecture ### Product and Process - Gather and Implement Customer Feedback - Make the Flow of Work Visible through the Value Stream - Work in Small Batches - Foster and Enable Team Experimentation ### Lean Management and Monitoring - Have a Lightweight Change Approval Processes - Monitor across Application and Infrastructure to Inform Business Decisions - Check System Health Proactively - Improve Processes and Manage Work with WIP (Work-In-Process) Limits - Visualize Work to Monitor Quality and Communicate throughout the Team ### Cultural - Support a Generative Culture - Encourage and Support Learning - Support and Facilitate Collaboration among Teams - Provide Resources and Tools that Make Work Meaningful - Support or Embody Transformational Leadership ## Four Key Metrics - **Change Lead Time** - Time to implement, test, and deliver code for a feature - **Deployment Frequency** - Number of deployments in a given duration of time - **Change Failure Rate** - Percentage of failed changes over all changes (regardless of success) - **Mean Time to Recovery** - Time it takes to restore service after production failure {{ youtube(id="_d9cws_T9qk") }} --- ## 21 Lessons Date: 2023-03-11 URL: https://chemaclass.com/readings/21-lessons/ Tags: bitcoin, economics, philosophy > Bitcoin as more than just money: a deep dive into economics, philosophy, and culture. Like Alice in Wonderland, exploring Bitcoin is full of surprises. Gigi portrays Bitcoin as more than just money; it's a deep dive into economics, philosophy, and culture. Like Alice in Wonderland, exploring Bitcoin is full of surprises, teaching about money, inflation, and the idea of decentralization. It redefines what 'good money' is, shows its cultural impact, and stresses that learning about Bitcoin is a personal journey that keeps evolving. ## Key takeaways ### Philosophical and Conceptual Insights Bitcoin teaches more than traditional education, offering insights into economics and philosophy. Engaging with Bitcoin feels like falling down a rabbit hole, full of learning and surprises. ### Economic and Monetary Lessons Bitcoin brings back the idea of 'sound money', teaching about inflation and banking systems. Issuing new money reduces the value of existing money, unlike Bitcoin which has a fixed supply. ### Technical and Cultural Aspects Bitcoin's core ideas include scarcity, security, and consensus, but the book isn't a technical manual. Bitcoin reflects a shift towards decentralization, influenced by movements like cypherpunk. ### Personal and Educational Journey Each person might learn different lessons from Bitcoin, encouraging personal exploration. Bitcoin's lessons evolve, requiring ongoing study. --- "21 Lessons" focuses on why Bitcoin matters philosophically, economically, and culturally, rather than how to use it. > You can buy the book or read it for free on their own website: [https://21lessons.com/preface](https://21lessons.com/preface) {{ youtube(id="-5lU92SEplU") }} --- ## Adapt or die Date: 2023-02-26 URL: https://chemaclass.com/readings/adapt-or-die/ Tags: leadership, team-management, communication, productivity, philosophy > Told through the story of one bold company (People First IT), Adapt or Die takes readers through the unparalleled business system known as The Algorithm of Success that has the potential to inspire, ignite, and affect change for all aspects of an organization. Told through the story of one bold company (People First IT), Adapt or Die takes readers through the unparalleled business system known as The Algorithm of Success that has the potential to inspire, ignite, and affect change for all aspects of an organization. Each chapter reveals more of the winning formula that all small and midsize businesses absolutely must have to succeed. Through real examples, research, and practical tools, Adapt or Die unpacks exactly how to create innovation, solve people puzzles, and win in business. > "Leadership is about helping people adapt and leading through change so the business and its people can thrive." ## Why businesses fail? Businesses fail because they... - are unable or unwilling to have courageous conversations - focus on money too much or too soon instead of on people - can provide the value themselves but can't make it scale - fail to focus on people as their primary responsibility - focus on people, but don't have the necessary skills to make a difference - listen to respond instead of listening to hear - think that because their idea is unique and specific, so are their issues - live in the business and fail to spend time on the business - expect thing to happen without truly leading through change - fail to fall in love with the truth and fight the truth instead ## How to help growing your teamwork > "As a business scales, the primary focus of the owner and the leadership must shift from focusing on customers to focusing on employees." By having courageous conversions about the full spectrum of skills required to go to the next level, focusing on improving the personal and professional career experience for that person and the people around them. These are the main points that everyone could develop: - Good communications - Focus & achieve goals & results - Everyone contributes - Offer each other support - Good leadership - Clear and good organization - Constructive conflict drives innovation > "People is not usually the root problem. The taxonomy is 3Ps: product, process, or people. And "people" is the final step because leaders need to look at product and process first. In other words, "people first" when it comes to values, but "people last" when it comes to blame." ## The Algorithm of Success As you can see in the diagram, all of this comes under leadership. If leadership is about helping others adapt to change, then it must be core to our organizations. ### Product - Promises - Solve a problem or need - Cash release triggers - The way we create value - Pain or Pleasure - Innovation - Connections: Logical, emotional and competitive ### Strategy - Target customer profile (Who) - Value Creation Strategy (VCS) - Core Values - Shared vision - Value loop - Key processes ### The Growth Engine - Unique selling proposition - Targeted marketing - Sales channels - Sales steps - Measuring the Growth Engine - Funnel & opportunity management - Return on Sales ### The Financial Model - Revenue management - Cost of goods sold (COGS) - Sales and marketing costs - General administration - EBITDA, ITDA, NOI - Categorization - Reporting ### People - Alignment - People elevators - Problem solving - People banks - Leadership code of conduct - Career plans - One-on-one's - Income managements ### Operations - Identify the core operations - Responsibilities - Cadence management - Meetings - GSD (Get Shit Done) ### Process - Promises Kept - Downstream / Upstream - Accountability - Repeatable - Efficiencies --- You can find the book in [https://www.adaptordie.com/the-book/](https://www.adaptordie.com/the-book/). --- ## The infinite game Date: 2023-01-29 URL: https://chemaclass.com/readings/the-infinite-game/ Tags: leadership, team-management, philosophy, communication > From the bestselling author of Start With Why and Leaders Eat Last, a bold framework for leadership in today's ever-changing world. How do we win a game that has no end? Finite games, like football or chess, have known players, fixed rules and a clear endpoint. The winners and losers are easily identified. Infinite games, games with no finish line, like business or politics, or life itself, have players who come and go. The rules of an infinite game are changeable while infinite games have no defined endpoint. There are no winners or losers: only ahead and behind. > Infinite-minded leaders understand that "best" is not a permanent state. Instead, they strive to be "better". "Better" suggests a journey of constant improvement and makes us feel like we are being invited to contribute our talents and energies to make progress in that journey. The question is, how do we play to succeed in the game we're in? In this book, Simon Sinek offers a framework for leading with an infinite mindset: 1. Just Cause 2. Courageous leadership 3. Trusting teams 4. Worthy rival --- ## #1 You have to have a Just Cause A Just Cause is the answer of _Why your organization exists?_ A cause so just that people will be willing to sacrifice themselves to see the advancement of that cause. Eg: working more hours, giving your best ideas, or rejecting another job offer and staying here because you believe in what you are doing. In order to be happy, we need a sense of purpose or meaning; businesses are no different. When we look at developing a Just Cause, there are a few things that we need to articulate. Firstly, we must stand for something that's inclusive, and exists primarily for the benefit of others. In short, a Just Cause is a vision of a compelling future, making people want to be part of building this future, although they may never see it completed. ## #2 You have to have courageous leadership Courageous leaders are the ones that are willing to sacrifice the sort term in order to advance the long term. Leadership is the acceptance of the responsibility to create an environment in which people can work on their natural best. The senior most people in an organisation are not responsible for the result. They are responsible for the people that are responsible for the result. ## #3 You have to have trusting teams A trusting team is an environment in which people feel safe to raise their hand and say "I made a mistake. I don't feel qualify to do the job you asked me to do, and I need more training. I need help. I am scared." Without any fear of humiliation or punishment, whatsoever. If you don't have trusting teams, you have a group of people that work together lying and faking, and you're forcing them to. It's not their fault. You're creating an environment in which people will not share mistakes because they think it will make them in trouble. Which means eventually things will compound and break. It's the responsibility of the leader to get the environment right. Get the environment right, you'll get trusted teams. Get the environment wrong, you are forcing people to protect themselves from you. ## #4 You have to have a worthy rival Although the only true competitor in an infinite game is yourself, what competition does is help to reveal your weaknesses. The goal is not to be number one in the infinite game, because there is no such thing. It's about building a strong foundation. It's about looking long term. Money is a result, not a purpose. > There is no such thing as the one "right" organization. There are only organizations, each of which has distinct strengths, distinct limitations, and specific applications. An organization is not absolute. It is a tool for making people productive in working together. --- Leaders who embrace an infinite mindset build stronger, more innovative, more inspiring organizations. Ultimately, they are the ones who lead us into the future. {{ youtube(id="tye525dkfi8") }} --- ## Momo Date: 2022-12-17 URL: https://chemaclass.com/readings/momo/ Tags: fiction, philosophy, psychology > Momo is a modern fairytale that shows the fight between good and evil in our contemporary society, focusing on the lack of time to care for other people. Momo is a fairytale that shows the fight between good and evil in our contemporary society, focusing on the lack of time to care for other people. This book is about the concept of time and how it is used in modern societies. --- ## Recipes for Decoupling Date: 2022-11-28 URL: https://chemaclass.com/readings/recipes-for-decoupling/ Tags: php, software-design, architecture, clean-code > What is coupling, and why is it bad? What is decoupling, and how to do it efficiently? This book is a compilation of strategies to decouple your domain code from those infrastructure details, so you can enjoy a healthier system in the long run. What is coupling, and why is it bad? What is decoupling, and how to do it efficiently? This book is a compilation of strategies to decouple your domain code from those infrastructure details, so you can enjoy a healthier system in the long run. This book will teach you how to create [**PHPStan**](https://phpstan.org/) rules from no knowledge, and then it will guide you across many decoupling opportunities like, for example: - web framework - cli frameworks - form validation - orm and database - test framework Read more about the book: [matthiasnoback.nl/book/recipes-for-decoupling/](https://matthiasnoback.nl/book/recipes-for-decoupling/) > Buy it here: [leanpub.com/recipes-for-decoupling](https://leanpub.com/recipes-for-decoupling) --- ## The Essential Drucker Date: 2022-10-29 URL: https://chemaclass.com/readings/the-essential-drucker/ Tags: leadership, team-management, philosophy > The Essential Drucker contains twenty-six selections on management in the organization, management and the individual, and management and society. It covers the basic principles and concerns of management and its problems, challenges, and opportunities, giving managers, executives, and professionals the tools to perform the tasks that the economy and society of tomorrow will demand of them. A twenty-six selections on management in the organization, management and the individual, and management and society. It covers the basic principles of management and its problems, challenges, and opportunities, giving managers, executives, and professionals the tools to perform the tasks that the economy and society of tomorrow will demand of them. --- ## 4 Essential Principles Of Management 1. Management is about humans 2. Management should define an organization's values, objective, goals & mission 3. Management must enable the organization and members to grow and develop 4. Results only exist outside the organization {{ youtube(id="1il9VfJoaDo") }} --- ## Dare to lead Date: 2022-09-30 URL: https://chemaclass.com/readings/dare-to-lead/ Tags: leadership, communication, psychology, mentoring > Leadership is not about titles, status and power over people. Leaders are people who hold themselves accountable for recognising the potential in people and ideas, and developing that potential. This is a book for everyone who is ready to choose courage over comfort, make a difference and lead. Leadership is not about titles, status, and power over people. Leaders are people who hold themselves accountable for recognising the potential in people and ideas and developing that potential. This book is for everyone ready to choose courage over comfort, make a difference, and lead. ## Courage and vulnerability ### Leaders need to be more vulnerable The problem is that most people associate that vulnerability as a synonym for weakness, but that’s not true. > "Vulnerability is the universal human emotion we feel when we expose ourselves to others during times of risk or > uncertainty." And this is what the core of leadership is about: the courage **to act how we should** despite fear, uncertainty, or danger in our way. ## Values The modern workplace might feel like a “gladiator arena.” While it might not be a matter of a life-dead situation, it still requires bravery, and plenty of sweetness and tears, to the point that we can feel so overwhelmed that we are tempted to leave. So, according to Brené: > "One of the most significant sources of motivation for sticking it out is to be crystal clear about our core values." Values are the **ideals** that we have that bring purpose to what we do in our life. They guide us and give us something to hold on to during dark and difficult times. Strong values guide us **to do what is correct** rather than easy. ## Honesty A great leader encourages potential in people and possesses the courage to guide this potential as it develops. One of the critical skills for doing this is courage and the ability to deliver **honest and open feedback**. Unfortunately, many leaders are afraid to give tuff feedback and leave their employees in the dark. Yes, sometimes the truth hurts, but we often avoid difficult conversations because they make **us** uncomfortable. > "Great leaders must be brave and always dare to provide constructive feedback, speak the truth, and be clear about > their expectations." In the long run, this is kinder and more productive. ## Trust > "Trust is an essential aspect of our working relationships." ### 7 behaviours that encourage trust Expressed together with the acronym: *BRAVING* 1. Setting **B**oundaries - respect one another's boundaries 2. **R**eliability - which means to follow-up words with actions 3. **A**ccountability - being responsible and acknowledging mistakes 4. **V**ault - the ability to keep confidential information private 5. **I**ntegrity - choosing courage over comfort 6. **N**on-judgment - talk to one another without judgment 7. **G**enerosity - assuming that people meet you with the best intentions ## Failure The ability to fail and recover from it is an **essential skill** for any great leader. Fear of failure holds us back and stops us from achieving true greatness. It is crucial to **take off the armor of perfectionism** and jump into the uncertainty of life. Only this way do we indeed gain the courage to succeed and lead. --- ### Summary {{ youtube(id="bsT5Tbt2mjU") }} --- ## Continuous Discovery Habits Date: 2022-08-21 URL: https://chemaclass.com/readings/continuous-discovery-habits/ Tags: team-management, agile, productivity > Continuous Discovery Habits (2021) explores how product managers and designers can keep making a positive impact on their customers’ lives. It explores an optimal decision-making process for product teams, so that they can continue to improve their offerings. This book explores how product managers and designers can keep making a positive impact on their customers' lives. It explores an optimal decision-making process for product teams, so that they can continue to improve their offerings. #### Part 1: What is continuous discovery? 1. The What and Why of Continuous Discovery 2. A Common Framework for Continuous Discovery #### Part 2: The continuous discovery habits 3. Focusing on Outcomes Over Outputs 4. Visualizing What You Know 5. Continuous Interviewing 6. Mapping the Opportunity Space 7. Prioritizing Opportunities, Not Solutions 8. Supercharged Ideation 9. Identifying Hidden Assumptions 10. Testing Assumptions, Not Ideas 11. Measuring Impact 12. Managing the Cycles 13. Show Your Work #### Part 3: Developing your continuous discovery habits 14. Start Small, and Iterate 15. What's Next? > Focusing on outcomes over outputs will help you create the right products for your customers. --- ### The What & Why of Continuous Discovery {{ youtube(id="yNCcQODWYh0") }} --- ## The Great CEO Within Date: 2022-08-01 URL: https://chemaclass.com/readings/the-great-ceo-within/ Tags: leadership, team-management, communication, productivity, mentoring > Learn how to efficiently scale your business from startup to corporation by implementing a system of accountability, effective problem-solving, and transparent feedback. Matt Mochary coaches the CEOs of many of the fastest-scaling technology companies in Silicon Valley. He shares his highly effective leadership and business-operating tools with any CEO or manager in the world. Learn how to efficiently scale your business from startup to corporation by implementing a system of accountability, effective problem-solving, and transparent feedback. > Reading, talking to other experts in a particular area, practicing, and teaching are the best ways to learn and > improve yourself. ## 3 Key takeaways - You need to learn how to manage yourself before you can manage your business. - Don't ignore conflict. Be transparent, give and take feedback often, and be an active listener. - Be obsessed with learning about your customer. Do so by asking better questions. --- ## Summary ### The team - Do not create a 50/50 partnership, because despite it sounds ideal, it actually leads to real pain if there is no easy way to break a deadlock. - Find a partner who has complementary skills to yours. Give a large percentage of the company; it worth it. - Founding teams should never grow beyong six until there is a true product-market fit (PMF). - Metrics that PMF are important. For example revenue, renewal rates, ... ### Getting things done - Read "Getting Things Done: The art of stress-free productivity", by David Allen. ### Inbox zero - Keep your inbox clean as a single triage room at a hospital. - It is important to distinguish the urgent cases from the ones that aren't. ### Top goal - Schedule two hours each day to work on your top goal only. - The earlier in the day you schedule this top goal, the better. ### On-time and present - Don't waste other people's time. - If you know you're going to be late, let the other people know as soon as possible. - Be present and focus on what's being discussed. ### When you say it twice write it down - Write down all processes. In doubt, write everything. ### Gratitude - Focus on the positives. - We perform our best when we are having fun and feeling good. - Be appreciative. Tell people when they've done something good. ### Energy audit - Audit your time and figure out how much of it is spend on activities that energize you and what activities drain you. - Delegate or outsouce the things that drain you as much as possible. ### Health - Your mental and physical health is the most important resource we all have. - Take care of yourself and the people around you. ### Decision-making - Require that anyone who wants to discuss an issue write it up, along with the desired solution, ahead of time. - This method, thought time-consuming, yields extraordinarily thoughtful decisions in a very shrt amount of time. ### Getting buy-in - When people feel they are part of the decision and their input matters. - When people are given more influence, they feel more invested. ### Issues and proposed solution - Require that anyone who presents an issue at a team meeting do so in writing. - It should include both a detailed description of the issue and their proposed solution. They cannot say "I don't know." They must at least present a guess. - All issues should be presented at the weekly team meeting. - Allow 5 min to discuss each proposed solution. - If consensus is reached in that time - great. - Otherwise, don't spend more time debating, and use RAPID framework instead. ### Loudest voice in the roomo - Be aware of who is in the room when you have a group discussion. - Avoid influencing other people's ideas by wriring down their vote or thoughts before you share your perspective. - Let juniors ask and speak first. ### Sloppy agreements - Sloppy agreements are when people don't show up on time, or don't complete the goals they declare. - The antidote is "impeccable agreements": - precisely defined - fully agreed to by all relevant people - There must be consequences of breaking agreements. - If you can't meet the agreement, then you have an obligation to let other members of the agreement circle know asap. ### Transparency - Don't hide negative information. - Our imaginations are much more powerful than reality. - Share all relevant information with your team, both negative and positive. - Let them adapt. ### Conflict resolution - Interpersonal conflict is almost due to people: - Not fully sharing their thoughts and feelings - Not feeling heard - Prove to people that you have heard them by summarizing what you just said back to you until they say "that's right!". ### Issue identification - Ask people to pretend they're the CEO and answer: - "What are the 3 most important issues for me to solve in the next 90 days?" - Ask people to write down their thoughts about the company when they feel their joy, excitement, sadness, anger and fear. ### Conscious leadership - Be more interested in learning than been right. ### Customer obsession - Focus on the outcome, not the output. - You are solving a customer problem, not just making a product. ### Culture - You don't choose your values. You have them. - Use your values as a guide to who you hire and when you fire. - Don't forget to celebrate. Make an effort to publicly acknowledge achievements. - Don't measure hours. Measure output. - You prevent office politics by never allowing lobbying to be successful. ### Company folder system and wiki - Have a company wiki and make it mandatory that all new hires read it. - Whenever you find yourself doing something twice, write down exactly what it is that you did. - Everyone on the team should contribute. ### Goal tracking - Never assign someone an action without them agreeing to it verbally or in writing. ### Areas of responsibility - When more than one person shares a responsibility, it often does not get done well, or at all. - One person is assigned to each function in the company. ### No single point of failure - Write down all processes. - Cross-train a second person for each role. ### Key Performance Indicators (KPI) - Known your 5-6 most significant KPIs and track them religiously. Make them visible to the entire team. ### Collaboration - Set vision and goals for the company, each dept, and each individual. - Communicate that vision and those goals to every team member. - Tracking and reporting progress towards those goals on a regular timetable (usually weekly). - Feedback on what's going right and what needs to be adapted. ### Objectives and Key Results (OKR) - Target 3 objectives with 3 key results for each. - For the company, department, team, individual. - Cascade them down so they are in alignment. - The objective = "where do we want to go?". No necessarily measurable. - Key results = "how do we know that we're getting there?". It should be measurable. - Gather your leadership team and have everyone come to the meeting with their ideas for what the OKRs should be for the quarter. - Let individuals come up with their own OKRs. They will be more invested. ### Feedback - Never give negative feedback using a one-way communication method - Like email, text, or voicemail. #### The problem with no giving feedback - You won't notice your company's problems. - Communication will break down. - Your best talent will leave you. #### 4 A's of seeking feedback 1. Ask for it. 2. Acknowledge it - repeat what they said. Make them feel heard and understood. 3. Appreciate it. 4. Act on it. #### How to give negative feedback 1. Ask for permission. 2. State the behaviour (fact). 3. State how the behaviour makes you feel (feelings). 4. State your thoughts, opinions, and judgments around the situation (story). 5. Make a request - a change you'd lie to see in the future. 6. Ask if they accept the feedback. ### Fundraising - Pick a partner, not a enterprise. - When you need to speak to an investor, ask 3-5 people in your network who know that person to send an email of recommendation to them. - Stack the referrals close together (in the same week) so that you get noticed. - Talk about your company once you know that the investor likes and trust you. - Sell yourself, not the company. ### Recruiting - Spend as little time as possible with the candidates that you don't hire, and as much time as possible with the candidates that you want to hire. - As the hiring manager, write out a 90 roadmap for the position you need to fill. ### On-boarding - Give onboarding even more attention, time and energy than you give to recruiting. - Assign each new team member a buddy with whom they'll check in each day for 15 minutes for the first 2 weeks. ### Firing - Whe you make the announcement, praise the person's contributions to the company, and take ownership yourself for the fact that you weren't able to match their skills to the company's needs. - Do not blame or criticise the person. Instead, take responsibility for the situation. ### Effective sales - Build trust. - Sell results, not features. - Identify customers' pains. ### Build trust - Ask customers about them. - Listen actively and reflect back what they say. - At the second meeting show that you remember what they said at the first. - Be explicit about not talking about your company. - Ask for a limited amount of time. - Invite them to a purely social event. ### Customer development - Asking the right questions will help you identify customer's specific challenges. - You need to understand their pain before presenting your solution. 1. What are their goals? 2. What are the challenges preventing them from reaching those goals? 3. What are their ideal solutions to overcoming those obstacles? ### Sell results, not features - Most people don't care about your product functionality or features. They care about their business results. - Focus on the why. - Focus on painting the vision of a world where customer's desires are fulfilled with the help of your product. ### Building a sales team & pipeline - Don't hire sales people right away. - In most cases, sales people will never be able to sell better than the founders, and they won't be able to sell the product if you are not able to. - Only hire a sales team if: - You have found an initial version of product-market fit (this means that a significant proportion of your paying customers are renewing their contracts). - You have figure out what you are selling and who you are selling to. ### The structure of a sales team - Generating leads and closing deals are distinct functions that must be split. - Senior salespeople are expensive, so their time is best spent focusing on the most high-value activity: closing deals. - Ideal sales team structure: - Qualifiers - sales development reps: focus on generating leads. - Closers - account executives: focus on closing leads. - Farmers - customer success: focus on tending existing customers. ### Lead generation - Predictable leads is the first step to achieve predictable revenue. ### Marketing - Start by concentrating all of your efforts on the low-hanging fruit - the small customer segment that has a particular problem that your product solves 10x better than the competition. - Move on to the next customer segment only after you have the resources to do so. ### Product market fit (PMF) - Designing a significantly better solution to your target customers' problem than existing in the marketplace. - How do you know when you have achieved PMF? - Ask your customers. They will tell you by renewing their subscriptions, buying more product(s), etc. - B2B, PMF = long term contracts - B2C, PMF = second purchase, renewing subscription, sharing in social media. --- {{ youtube(id="tBimI7QNjBA") }} Matt Mochary shares insights on developing his coaching method, understanding & overcoming primal fear, addressing imposter syndrome & more. --- ## The Starfish and the Spider Date: 2022-07-19 URL: https://chemaclass.com/readings/the-starfish-and-the-spider/ Tags: leadership, team-management, philosophy > If you cut off a spider's head, it dies; if you cut off a starfish's leg it grows a new one, and that leg can grow into an entirely new starfish. Traditional top-down organizations are like spiders, but now starfish organizations are changing the face of business and the world. If you cut off a spider's head, it dies; if you cut off a starfish's leg it grows a new one, and that leg can grow into an entirely new starfish. Traditional top-down organizations are like spiders, but now starfish organizations are changing the face of business and the world. What's the hidden power behind the success of Wikipedia, craigslist, and Skype? What do eBay and General Electric have in common with the abolitionist and women's rights movements? What fundamental choice put General Motors and Toyota on vastly different paths? Ori Brafman and Rod Beckstrom have discovered some unexpected answers, gripping stories, and a tapestry of unlikely connections. The Starfish and the Spider explores what happens when starfish take on spiders and reveals how established companies and institutions, from IBM to Intuit to the U.S. government, are also learning how to incorporate starfish principles to achieve success. --- In this talk, Rod Beckstrom, does a great overview of the main ideas of his book: {{ youtube(id="fumQ0s7DCEY") }} --- ## Clean Craftsmanship Date: 2022-07-11 URL: https://chemaclass.com/readings/clean-craftsmanship/ Tags: clean-code, tdd, refactoring, testing, xp > Robert C. Martin covers the three pillars of software craftsmanship: TDD disciplines with practical examples, professional standards for teams, and the ethical responsibilities of programmers. The book is divided into three parts: the disciplines, the standards, and the ethics. The 1st part is the most technical one. It guides you with TDD examples, showing how testing can help you to design your code. The 2nd part is about productivity, quality, and courage. The 3rd part is about how did we get here in terms of people who develop software, and our responsibility within our ethics about do no harm, integrity, and teamwork. --- One of my favourite parts from the book: > Our software industry is wildly dynamic and changing; therefore, we must all be continuously aggressive learners. > > How and when do you do this learning? If your employer provides you the time and space to do this kind of learning, then take as much advantage of it as you can. If your employer is not helpful, then you'll have to learn on your own time. > > Be prepared to spend several hours per month on it. Make sure you have the personal time set aside for it. > > Yes, I know you have family obligations, bills to pay, planes to catch, and you've got a life. Okay, but you also have a profession. And professions need care and maintenance. I expect us all to be continuous aggressive learners. > > `Chapter 11. Courage - Continuous Aggressive Learning` --- ## Index ### Part I: The Disciplines #### Chapter 1. Craftsmanship - Extreme Programming - Test-Driven Development - Refactoring - Simple Design - Collaborative Programming - Acceptance Tests #### Chapter 2. Test-Driven Development - Overview - The Basics #### Chapter 3. Advanced TDD - Getting Stuck - Arrange, Act, Assert - Test Doubles - Architecture #### Chapter 4. Test Design - Testing Databases - Testing GUIs - Test Patterns - Test-Specific Subclass - Humble Object - Test Design - Breaking the Correspondence #### Chapter 5. Refactoring - What Is Refactoring? - The Basic Toolkit - Extract Method - The Disciplines #### Chapter 6. Simple Design - YAGNI - Covered by Tests - Coverage - Design? - Maximize Expression - The Underlying Abstraction - Minimize Duplication - Minimize Size #### Chapter 7. Collaborative Programming #### Chapter 8. Acceptance Tests - The Discipline - The Continuous Build ### Part II: The Standards #### Chapter 9. Productivity - We Will Never Ship S**T - Inexpensive Adaptability - We Will Always Be Ready - Stable Productivity #### Chapter 10. Quality - Continuous Improvement - Fearless Competence - Extreme Quality - We Will Not Dump on QA - QA Will Find Nothing - Test Automation - Automated Testing and User Interfaces - Testing the User Interface #### Chapter 11. Courage - We Cover for Each Other - Honest Estimates - You Must Say NO - Continuous Aggressive Learning - Mentoring ### Part III: The Ethics - The First Programmer - Seventy-Five Years - Nerds and Saviors - Role Models and Villains - We Rule the World - Catastrophes - The Oath #### Chapter 12. Harm - First, Do No Harm - Best Work - Repeatable Proof #### Chapter 13. Integrity - Small Cycles - Relentless Improvement - Maintain High Productivity #### Chapter 14. Teamwork - Work as a Team - Estimate Honestly and Fairly - Respect - Never Stop Learning --- I found this chat in YouTube where Uncle Bob talks about most of the topics form his book **Clean Craftsmanship**. {{ youtube(id="sPXk11hrWTM") }} --- ## Modern Software Engineering Date: 2022-06-29 URL: https://chemaclass.com/readings/modern-software-engineering/ Tags: software-design, testing, architecture, agile > This book presents software development as an engineering practice at every level. To master software engineering, we must become experts at learning and managing complexity. This book presents software development as an engineering practice at every level. To master software engineering, we must become experts at learning and managing complexity. ### Optimize for learning To optimize for learning, the book presents five behaviors to consider: - Working iteratively - Feedback - Incrementalism - Empiricism - Being Experimental The main idea is to work on small steps, collect feedback, and adjust. ### Optimize for managing complexity The book presents other five ideas to manage complexity: - Modularity - Cohesion - Separation of Concerns - Information Hiding and Abstraction - Managing Coupling We need to manage the complexity of our systems. ### Tools to support engineering in software Going deeper into some ideas that were already discussed in the book, like: - Testability - Deployability - Controlling the variables - Continuous Delivery --- A great video explaining the core ideas behind this book by his author: {{ youtube(id="TRqYQnCfgH8") }} --- ## Bitcoin: Blockchain y su investigación Date: 2022-05-10 URL: https://chemaclass.com/readings/bitcoin-la-tecnologia-blockchain-y-su-investigacion/ Tags: bitcoin, economics, philosophy > How is created Bitcoin address? How does it work the creation of the private & public keys and how are they known as wallets? And many other interesting questions. This book was published in 2017, so most of the technology shown is already history. And that's precisely what I really like from the book itself, the "historical part" and the origin of the blockchain. How is created Bitcoin address? How does it work the creation of the private & public keys and how are they known as wallets? And many other interesting questions. Back then, we got some websites and services that were using Bitcoin as a payment method, and there was a beauty trend. - The **first half of the book** is the best part, and I would say it's still relevant due to the origin of this tech. - The **second half**, on the other hand, I would say is "more optional" and for curious people. There are no learnings from this part, besides the trend that you can see we already had back in 2016/2017. Today in 2022 the tech (and projects using blockchain) has evolved a lot. I would really like to read a new book with an updated investigation 5 years after the first edition. > The book is available only in Spanish: [0xWord](https://0xword.com/es/libros/87-bitcoin-la-tecnologia-blockchain-y-su-investigacion.html) --- ## Docker: SecDevOps Date: 2022-04-29 URL: https://chemaclass.com/readings/docker-secdevops/ Tags: docker, devops > A great book about Docker, from introduction to advanced concepts all covered by easy-to-follow examples. A great book about Docker, from introduction to advanced concepts all covered by easy-to-follow examples. Best practices about how to build docker images and keep a good security layer when running containers as well, from the docker daemon and all tech behind docker. > The book is available only in Spanish: [0xWord](https://0xword.com/es/libros/103-docker-secdevops.html) --- ## Team Topologies Date: 2022-03-31 URL: https://chemaclass.com/readings/team-topologies/ Tags: team-management, architecture, devops, agile > Team Topologies focuses on how to set up dynamic team structures and interaction modes that can help teams adapt quickly to new conditions, and achieve fast and safe software delivery. Team Topologies focuses on how to set up dynamic team structures and interaction modes that can help teams adapt quickly to new conditions, and achieve fast and safe software delivery. ## Team structure - High cohesion: Group related things together. - Loose coupling: There must be clear boundaries between the teams. - Cognitive load: It's like the RAM of the team. The team can burn down if you load with more than the team can handle. > In order to avoid bottleneck teams, you need to make sure their cognitive load is not very high. ## Conway's Law - The organization structure will influence the architecture of the team. - Conway’s Law says that organizations will design systems that copy their communication structure. - In other words, there will be no focus on the optimal architecture for the project. - First you need to define the architecture of the project, and then form the teams. ## Team-First Thinking - Who is in the team matters less than the team dynamics. - When measuring performance, teams matter more than individuals. - Team = group of 5-9 who work towards a shared goals as a unit. - Check [Dunbar number](/blog/dunbar-number/). - Forming a team takes from 2 weeks to 3 months. - Cognitive load is the total amount of mental effort being used in the working memory. - 3 Types of cognitive load: - Intrinsic: Fundamentals of the problem space. Example: programming language. - Extraneous: Environment related. Example: how to deploy. - Germane: Special attention is required. Example: business domain. - Heuristics: - 3 types of domain: Simple, complicated, complex. - If the domain is too big, split it into subdomains. - One team, either: - 2-3 simple domains. - 1 complex domain. - Avoid 2 complicated domains, better split the team. - Define a Team API: - Code: endpoints, libraries, clients, ... - Versioning. - Documentation. - Practices and principles. - Communication tools. ## Team Topologies > Instead of structuring teams according to know-how or activities, organize teams according to business domain areas. - Success of topology depends both on team members and surrounding environment, teams and interactions. - Split responsibilities to breakdown silos. - Types of dependencies: Knowledge, task, and resource. - Four types of teams: - Stream-aligned: deliver features, projects, products to the market asap. - Enabling: grow the capabilities for the Stream-aligned team(s). - Complicated-subsystem: reduce the cognitive load of the Stream-aligned team(s). - Platform: make the Stream-aligned team(s) autonomous. ## Team Interactions - Collaboration. Work closely between teams with different skill sets. - X-as-a-Service. Clear ownership, small cognitive load. - Facilitation. Helping to clear impediments, focus on quality interactions between other teams. --- ## The Psychology of Money Date: 2022-02-27 URL: https://chemaclass.com/readings/the-psychology-of-money/ Tags: psychology, economics, philosophy > There is no reason to risk what you have and need for what you don't have and don't need. Timeless lessons on wealth, greed, and happiness. Having more money will make you happier ONLY if that means you'll have more control over your time. > "I did not intend to get rich. I just wanted to get independent." Charlie Munger. ## Money Misunderstandings ### Compounding - Start investing with whatever you can afford, and stay invested. - Leverage the power of compounding. ### Volatility - It's not possible to get high returns without volatility. - It's the emotional price you need to pay if you want good annual returns. - Embrace volatility. Volatility is a fee, not a fine. ### Tail investments - It's hard to predict what will be the "next big thing", therefore it's important to diversify. - A tail investment is single investment that massively outperform all others, and made up for several bad investments. - Make many diversified investments to benefit from a few tail investments. ## Quotes > "There is no reason to risk what you have and need for what you don't have and don't need." > "Long tails (the farthest ends of a distribution of outcomes) have tremendous influence in finance, where a small number of events can account for the majority of outcomes." > "The ability to do what you want, when you want, with who you want, for as long as you want, is priceless. It is the highest dividend money pays." > "Like everything else worthwhile, successful investing demands a price. But its currency is not dollars and cents. It's volatility, fear, doubt, uncertainty, and regret, all of which are easy to overlook until you're dealing with them in real time." > "Few things matter more with money than understanding your own time horizon and not being persuaded by the actions and behaviors of people playing different games than you are." --- ## Video Summary {{ youtube(id="yNMnjMgdIWw") }} --- ## Modern CTO Date: 2022-01-23 URL: https://chemaclass.com/readings/modern-cto/ Tags: leadership, team-management, software-design, communication > In Modern CTO, Joel Beasley provides readers with an in-depth road map on how to successfully navigate the unexplored and jagged transition between these two roles. Drawing from personal experience, Joel gives a refreshing take on the challenges, lessons, and things to avoid on this journey. Developers are not CTOs, but developers can learn how to be CTOs. In Modern CTO, Joel Beasley provides readers with an in-depth road map on how to successfully navigate the unexplored and jagged transition between these two roles. Drawing from personal experience, Joel gives a refreshing take on the challenges, lessons, and things to avoid on this journey. These are the topics you'll find in the book: #### A Modern CTO knows... - Developers are not CTOs - The spaghetti code MVP epidemic - Over-engineering is a problem - Whether to hire, buy, or out-build their competitor - How not to scale prematurely - How to solve any problem - How to work with programers when you aren't one - UX mistakes to watch out for - When to speak up - When to hire & fire consultants - How to analyze failure - How to bounce back from unforeseen constraints - Answer the question: "How difficult is it to code...?" - How to avoid the "bottom of the ninth" guy - When to respond to feedback - How to validate an expert in any field - How to effectively communicate complex ideas ### Favorite quotes > If I rest on past achievements, I'll never grow. > LEVERAGE OTHERS' EXPERIENCE Books condense a lifetime of experience into a few hours' read. Powerful right? > There are only two reasons you write bad code: > > 1)You know how to write good code, but you choose to write bad code. > 2)You don't know how to write good code. And both suck. > As the CTO, you must have a business focus. > Always return to your core goals. [...] I make sure each core goal has a clearly defined "why?" behind it, this way > if I ever get lost, I go back to my "why." - Reference to "[Start with Why](/readings/start-with-why)" by Simon Sinek. > When you're the boss, remember this golden rule: Ask people what they think instead of telling them what to do. > If I can't asses the human component, I can't lead a team. [...] Team composition carries as much or perhaps even > greater weight than programming expertise. > As CTO, if you can't explain value simply, it means you don't understand the business value behind your technology. --- ## Leaders Eat Last Date: 2022-01-16 URL: https://chemaclass.com/readings/leaders-eat-last/ Tags: leadership, team-management, psychology, communication > A company's biggest strength doesn't lie in its products or services. It always lies in its people, and in their ability to cooperate closely and rally behind the organization, especially during a crisis. A company's biggest strength doesn't lie in its products or services. It always lies in its people, and in their ability to cooperate closely and rally behind the organization, especially during a crisis. However, loyalty and commitment must be earned. Today, work has become a contractual, transactional relationship in many organizations. Intense competition and layoffs are the norm. Hardly anyone believes in loyalty to a company anymore, much less lifetime employment. ## The 4 Chemicals (E.D.S.O.) Each of us is an individual and a part of social groups. We make daily decisions that require us to weigh our self-interests against group interests. This dilemma also happens in our bodies via 4 key chemicals: - **Endorphins** and **dopamine** drive us to satisfy our personal needs, e.g. to find food, develop solutions and persevere through problems. They help us to get things done, so we can survive. - **Serotonin** and **oxytocin** encourage us to work together with others. They build feelings of trust, loyalty and camaraderie, strengthen our social bonds and increase our inclination to cooperate with others to achieve what we can't on our own. ## Circles of Safety Traditionally, our family provides a Circle of Safety where we feel safe and supported. Inside the circle, we have a healthy balance of **E.D.S.O**. and low Cortisol levels. In organizations, Circles of Safety provide people with a sense of belonging and security. This facilitates communication, cooperation, problem-solving and innovation, allowing people to direct their attention to external threats and opportunities. In contrast, when people feel threatened by internal politics and infighting, they turn their attention inward to focus on self-preservation, making the group more vulnerable as a whole. Leaders must earn others' respect and loyalty by making the most sacrifices and being willing to eat last. They must give trust to earn trust. ## A Society that's Out of Balance Each of the 4 **E.D.S.O.** chemicals play important roles in our survival. When they're in balance, people prosper the way they're designed to, and their groups/organizations prosper too. Unfortunately, the modern workplace tends to be overflowed with Cortisol and dopamine addiction. We lack Circles of Safety and have become dangerously imbalanced. How did we get here? - **Abstraction and Dehumanization**: how management via numbers, global systems and virtual interactions can be dangerous and lead to careless acts. - **Destructive Abundance**: how humans respond to shortage vs excess, and why/how leaders have become so blinded by the commercial interest that they've forgotten who they're supposed to serve. - **Social Changes**: how our societal norms and values have changed with the post-WWII Boomer Generation, followed by Gen-Xers and Gen-Ys, to become increasingly dopamine-addicted and imbalanced. > Simon Sinek offers many detailed examples and stories of leaders in all walks from the military to politics and businesses. --- ## TED Talk: Why Leaders Eat Last {{ youtube(id="ReRcHdeUG9Y") }} --- ## Jonathan Livingston Seagull Date: 2022-01-08 URL: https://chemaclass.com/readings/jonathan-livingston-seagull/ Tags: fiction, philosophy, psychology, career > A fable in novella form about a seagull who is trying to learn about life and flight, and a homily about self-perfection. A fable in novella form about a seagull who is trying to learn about life and flight, and a homily about self-perfection. ## Plot The book tells the story of Jonathan Livingston Seagull, a seagull who is bored with daily squabbles over food. Seized by a passion for flight, he pushes himself and learns everything he can about flying. His increasing unwillingness to conform finally results in his expulsion from the flock. Now an outcast, he continues to learn, becoming increasingly pleased with his abilities while leading a peaceful and happy life. One day Jonathan meets two gulls who take him to a "higher plane of existence" in which there is no heaven, but a better world found through perfection of knowledge. There he meets another seagull who loves to fly. He discovers that his sheer tenacity and desire to learn make him "pretty well a one-in-a-million bird." In this new place, Jonathan befriends the wisest gull, Chiang, who takes him beyond his previous self-education, and teaches him how to move instantaneously to anywhere else in the universe. The secret, Chiang says, is to "begin by knowing that you have already arrived." But, unsatisfied with his new life, Jonathan returns to Earth to find others like himself to tell them what he'd learned and to spread his love for flight. His mission is successful, and Jonathan gathers around himself a flock of other gulls who have been outlawed for not conforming. The first of his students, Fletcher Lynd Seagull, ultimately becomes a teacher in his own right, and Jonathan leaves to teach other flocks. > This novella has been translated into over thirty languages. --- ## Audiobook {{ youtube(id="8COt1n3jDqA") }} --- ## The Five Dysfunctions of a Team Date: 2021-12-07 URL: https://chemaclass.com/readings/the-five-dysfunctions-of-a-team/ Tags: leadership, team-management, communication, psychology > This book is a leadership fable about a tech company that is struggling to get more customers. The C level is not working as a team, and they have a hard time coming to any agreements which result in negative morale. Until the new CEO, Catherine Petersen, joins the team, and she is able to recognize the problems and help the team overcome them by understanding the situation. This book is a leadership fable about a tech company that is struggling to get more customers. The C level is not working as a team, and they have a hard time coming to any agreements which result in negative morale. Until the new CEO, Catherine Petersen, joins the team, and she is able to recognize the problems and help the team overcome them by understanding the situation. This is the first book I read from the author Patrick Lencioni, who is an American writer who writes books on business management. He is the founder and president of the Table group, a management consulting focused on organizational health. ## Book summary Kathryn Petersen, Decision Tech's CEO, faces the ultimate leadership crisis: Uniting a team in such disarray that it threatens to bring down the entire company. Will she succeed? Will she be fired? Will the company fail? Throughout the story, Lencioni reveals the five dysfunctions which go to the very heart of why teams even the best ones-often struggle. He outlines a powerful model and actionable steps that can be used to overcome these common hurdles and build a cohesive, effective team. ## The 5 dysfunction model {{ youtube(id="GCxct4CR-To") }} ### 1) Absence of trust The fear of being vulnerable prevents team members from building trust with each other. This occurs when team members are reluctant to be vulnerable with one another and are unwilling to admit their mistakes, weaknesses or needs for help. Without a certain comfort level among team members, a foundation of trust is impossible. ### 2) Fear of conflict The desire to preserve artificial harmony stifles productive ideological conflict within the team. Teams that are lacking on trust are incapable of engaging in unfiltered, passionate debate about key issues, causing situations where team conflict can easily turn into veiled discussions and back channel comments. In a work setting where team members do not openly air their opinions, inferior decisions are the result. ### 3) Lack of commitment The lack of clarity and/or buy-in prevents team members from making decisions they stick to. Without conflict, it is difficult for team members to commit to decisions, creating an environment where ambiguity prevails. Lack of direction and commitment can make employees, particularly star employees, disgruntled. ### 4) Avoidance of accountability The need to avoid interpersonal discomfort prevents team members from holding each other accountable for their behaviors and performance. When teams don't commit to a clear plan of action, even the most focused and driven individuals hesitate to call their peers on actions and behaviors that may seem counterproductive to the overall good of the team. ### 5) Inattention to results The pursuit of individual goals and personal status erodes the team's focus on collective success. Team members naturally tend to put their own needs (ego, career development, recognition, etc.) ahead of the collective goals of the team when individuals aren't held accountable. If a team has lost sight of the need for achievement, the business ultimately suffers. --- ## Video Summary {{ youtube(id="Ro0NBgHo_a8") }} --- ## Start with Why Date: 2021-11-28 URL: https://chemaclass.com/readings/start-with-why/ Tags: leadership, communication, philosophy, career > Start with Why asks (and answers) the questions: why are some people and organizations more innovative, more influential, and more profitable than others? Why do some command greater loyalty from customers and employees alike? Even among the successful, why are so few able to repeat their success over and over? *Start with Why* asks (and answers) the questions: why are some people and organizations more innovative, more influential, and more profitable than others? Why do some command greater loyalty from customers and employees alike? Even among the successful, why are so few able to repeat their success over and over? --- The ability to inspire those around you and to achieve remarkable things starts with WHY. Those who start with WHY never manipulate, they inspire. People like Martin Luther King Jr., Steve Jobs, and the Wright Brothers had little in common, but they all started with WHY. They realized that people won't truly buy into a product, service, movement, or idea until they understand the WHY behind it. - The ability to inspire those around you and to achieve remarkable things starts with WHY. - Any organization can explain what it does; some can explain how they do it; but very few can clearly articulate why. - Your WHY is your purpose, cause or belief. - Every inspiring leader and organization, regardless of size or industry, starts with WHY. - When your WHY goes fuzzy, it becomes much more difficult to maintain the growth, loyalty, and inspiration that helped drive your original success. > People don't buy WHAT you do, they buy WHY you do it. Great leaders are able to inspire people to act. And those who are able to inspire give people a sense of purpose or belonging that has little to do with any external incentive or benefit to be gained. --- ## Video Summary {{ youtube(id="u4ZoJKF_VuA") }} --- ## Leadership is Language Date: 2021-10-22 URL: https://chemaclass.com/readings/leadership-is-language/ Tags: leadership, communication, team-management, productivity > In this book, the former submarine commander Captain L. David Marquet dives deep into one of the most investigated marine disasters, the sinking of the El Faro, and surfaces with new ideas on leadership and language. A radical playbook to empower your people and put your team on a path to continuous improvement. In this book, the former submarine commander Captain [L. David Marquet](https://x.com/ldavidmarquet) dives deep into one of the most investigated marine disasters, the sinking of the El Faro, and surfaces with new ideas on leadership and language. --- You might imagine that an effective leader is someone who makes quick, intelligent decisions, gives inspiring speeches, and issues clear orders to their team, so they can execute a plan to achieve your organization's goals. Unfortunately, that's an outdated model of leadership that just doesn't work anymore. > Your words matter more than you think. David gives six plays that all leaders should use to improve how their teams operate. He says a big problem with leaders today is that they are trapped in an industrial-age playbook. In the industrial age leaders gave commands and employees followed, and that was it. But that way of leading is no longer effective, it is outdated. ### The six plays - Control the clock, don't obey the clock: pre-plan decision points and give your people the tools they need to hit pause on a plan of action if they notice something wrong. - Collaborate, don't coerce: as the leader, you should be the last one to offer your opinion. - Commit, don't comply: rather than expect your team to comply with specific directions, explain your overall goals, and get their commitment to achieving it one piece at a time. - Complete, not continue: if every day feels like a repetition of the last, you're doing something wrong. - Improve, don't prove: ask your people to improve on plans and processes, rather than prove that they can meet fixed goals or deadlines. - Connect, don't conform: flatten hierarchies in your organization and connect with your people to encourage them to contribute to decision-making --- ## Video Summary {{ youtube(id="CQfao96j1fo") }} --- ## The Bitcoin Standard Date: 2021-09-20 URL: https://chemaclass.com/readings/the-bitcoin-standard/ Tags: bitcoin, economics, philosophy > The Bitcoin Standard analyzes the historical context to the rise of Bitcoin, the economic properties that have allowed it to grow quickly, and its likely economic, political, and social implications. The Bitcoin Standard analyzes the historical context to the rise of Bitcoin, the economic properties that have allowed it to grow quickly, and its likely economic, political, and social implications. While Bitcoin is a new invention of the digital age, the problem it purports to solve is as old as human society itself: transferring value across time and space. Ammous takes the reader on an engaging journey through the history of technologies performing the functions of money, from primitive systems of trading limestones and seashells, to metals, coins, the gold standard, and modern government debt. With this background in place, the book moves on to explain the operation of Bitcoin in a functional and intuitive way. Bitcoin is a decentralized, distributed piece of software that converts electricity and processing power into indisputably accurate records, thus allowing its users to utilize the Internet to perform the traditional functions of money without having to rely on, or trust, any authorities or infrastructure in the physical world. The final chapter of the book explores some of the most common questions surrounding Bitcoin: - Is Bitcoin mining a waste of energy? - Is Bitcoin for criminals? - Who controls Bitcoin, and can they change it if they please? - How can Bitcoin be killed? The Bitcoin Standard is the essential resource for a clear understanding of the rise of the Internet's decentralized, apolitical, free-market alternative to national central banks. --- ## Video Summary {{ youtube(id="t1brCcgi174") }} > Extra: Lex Fridman Podcast with the author of this book {{ youtube(id="gp4U5aH_T6A") }} --- ## Turn the Ship Around! Date: 2021-09-12 URL: https://chemaclass.com/readings/turn-the-ship-around/ Tags: leadership, team-management, communication, mentoring > The book is about his leadership theories to how he implemented a fresh leadership model. Including the limitations of a hierarchical top-down model, why/how he failed to empower his team earlier in his career, and how the circumstances for Santa Fe were ideal for him to experiment with the new leader-leader approach. The book is about his leadership theories to how he implemented a fresh leadership model. Including the limitations of a hierarchical top-down model, why/how he failed to empower his team earlier in his career, and how the circumstances for Santa Fe were ideal for him to experiment with the new leader-leader approach. Most people unconsciously divide the world into **leaders vs followers**, and make assumptions about what each group can/can't do. Such assumptions influence our thoughts and actions that impact the performance of individual employees and the organization. It is common for enthusiastic employees to suggest new ideas, and then they are told "it's not your job" or "that won't work". People feel frustrated and eventually stop trying or leave the organization. **Bosses also feel frustrated** when their staff would rather **do the minimum** rather than to **innovate or take responsibility**. > The leader-leader model recognizes that everyone has the ability and **potential to lead**. > It taps on individual potential at all levels, reduces dependency on a single leader and delivers sustained performance. ### The 3 key components: Control, Competence and Clarity #### Control Control refers to the freedom and authority to make decisions about why, what and how you're going to work. The goal is to delegate decision-making control as far as possible in the organization. - Find the genetic code for control and rewrite it. - Act your way to new thinking. - Short, early conversations make efficient work. - Use "I intend to..." to turn passive followers into active leaders. - Resist the urge to provide solutions. - Eliminate top-down monitoring systems. - Think out loud (both superiors and subordinates). #### Competence People at every level must be technically competent to make the right decisions. If you give people additional responsibility without equipping them with the required knowledge and resources, things will fall apart. - Take deliberate action. - We learn (everywhere, all the time). - Don't brief, certify. - Continually and consistently repeat the message. - Specify goals, not methods. #### Clarity For people at all levels to make effective decisions, they must be fully aligned with the organization's purpose, and thoroughly understand the organization's goals and decision-making criteria. - Achieve excellence, don't just avoid errors. - Build trust and take care of your people. - Use your legacy for inspiration. - Use guiding principles for decision criteria. - Use immediate recognition to reinforce desired behaviours. - Begin with the end in mind. - Encourage a questioning attitude over blind obedience. ## Favourite quotes > Leadership is communicating to people their worth and potential so clearly that they are inspired to see it in themselves. --- ## Summary {{ youtube(id="OqmdLcyES_Q") }} David Marquet talks about leadership that turns the ship around in his keynote at the Worldwebforum. {{ youtube(id="ivwKQqf4ixA") }} --- ## The Catcher in the Rye Date: 2021-08-08 URL: https://chemaclass.com/readings/the-catcher-in-the-rye/ Tags: fiction, psychology, philosophy > The novel is a deeper reflection of Salinger's own youth, his complicated relationship with growing up and the generational trauma affected by World War II. It was originally intended for adults but is often read by adolescents for its themes of angst, alienation, and as a critique on superficiality in society. The novel is a deeper reflection of Salinger's own youth, his complicated relationship with growing up and the generational trauma affected by World War II. Undeniably autobiographical, Salinger drew on his personal experiences fighting in the war and his New York creating the character of **Holden Caulfield**. The novel's protagonist has become an icon for teenage rebellion. The novel also deals with complex issues of innocence, identity, belonging, loss, connection, sex, and depression. From chapter 22: > "You don't like anything that's happening." It made me even more depressed when she said that. > > "Yes I do. Yes I do. Sure I do. Don't say that. Why the hell do you say that?" > > "Because you don't. You don't like any schools. You don't like a million things. You don't." > > "I do! That's where you're wrong, that's exactly where you're wrong! Why the hell do you have to say that?" I said. Boy, was she depressing me. > > "Because you don't," she said. "Name one thing." > > "One thing? One thing I like?" I said. "Okay." > > The trouble was, I couldn't concentrate too hot. Sometimes it's hard to concentrate. ## Summary {{ youtube(id="WSq-WQgKnyE") }} --- ## Lord of the Flies Date: 2021-07-10 URL: https://chemaclass.com/readings/lord-of-the-flies/ Tags: fiction, psychology, leadership, philosophy > Labeled a parable, an allegory, a myth, a morality tale, a parody, a political treatise, even a vision of the apocalypse. It has established itself as a true classic. The book focuses on a group of British boys stranded on an uninhabited island, and their disastrous attempt to govern themselves. Labeled a parable, an allegory, a myth, a morality tale, a parody, a political treatise, even a vision of the apocalypse. It has established itself as a true classic. The book focuses on a group of British boys stranded on an uninhabited island, and their disastrous attempt to govern themselves. Themes include the tension between groupthink and individuality, between rational and emotional reactions, and between morality and immorality. The first chapters start slowly, but they are necessary to build up the context of the story, which scales pretty quickly later on. {{ youtube(id="NnnZ6y1HPqI") }} --- ## Become an Effective Software Engineering Manager Date: 2021-06-27 URL: https://chemaclass.com/readings/effective-software-em/ Tags: leadership, team-management, career, communication > A great compilation of all topics that are important for management: 1:1s, performance reviews, hiring and laying off, workplace politics, remote work, and others. A great compilation of all topics that are important for management: 1:1s, performance reviews, hiring and laying off, workplace politics, remote work, and others. The book is divided into 3 parts: the first part covers things a new manager should know, the second and third parts go into topics that all managers should master. Although I kept nodding along with the bits of advice, I sometimes felt it was too "wordy" or going into too many details that I wasn't interested in. That said, I kept moving forward, and I am glad that I finished it, gathering a lot of useful tips. --- My takeaways from this book: ## Part 1 - Getting Oriented ### Chapter 01: A New Adventure - Practical advice on things to do the first week and finding misalignment signals on your first week. ### Chapter 02: Manage Yourself First - A good reminder of how getting your things an order comes first - this is a pre-requisite to you being efficient, as a manager. > "Your calendar it is both for you and other people to use. Keep it tidy and meaningful. It represents you. Making meetings public by default can help others reason better about how to schedule time with you." ## Part 2 - Working with Individuals ### Chapter 03: Interfacing with Humans - This chapter covers a lot of ground on how to communicate with others. - Think twice before broadcasting information. - Be consistent in your communications style. > "Don't communicate when you want to, but when you need to." ### Chapter 04: One-to-Ones - It's their meeting, not yours. > "Try to get your direct reports to do 70% of the talking. If you feel like solving their problem for them, don't. Ask another question and let them arrive at the conclusion themselves. This is an art that takes some practice." ### Chapter 05: The Right Job for the Person - Motivation and the hierarchy of needs. Developing skills with some practical examples on doing so. > "However, as their manager, you can work with them to place these career achievements at the bottom of their skill tree, and then plan out the milestones along the way that they can aim for to make measurable progress. Thus pushing the frontier of their zone of proximal development further and further." ### Chapter 06: The Most Wonderful Time of the Year (Performance Reviews) - Preparing for performance reviews ahead of time. Getting peer feedback, and doing this via email, for example. ### Chapter 07: Join Us! (Hiring) - The case for not needing the most senior candidate. - Culture fit. - Setting up an interview process. ### Chapter 08: Game Over (Attrition) - People leaving is normal. - Voluntary resignations that are: - "good reasons", aka you could have not done much about it. - "bad reasons", that is you could have caught (and addressed) things early like coworker conflict, lack of challenge, compensation. > "As a manager, you are doomed to failure if you think that you are going to keep everyone in your current team indefinitely. [...] > You should never fight to keep staff if you cannot actually provide the conditions under which they can become happier than they already are. You'll just defer their departure." ### Chapter 09: How to win friends and influence people (Being well-connected) - Building your network . Making introductions, checking in with others. - Coaching and mentoring. ## Part 3 - The Bigger Picture ### Chapter 10: Humans are Hard - Working harder or faster isn't what you should be focusing on. Instead, you should be creating the conditions that make your staff happy and productive through nurturing their autonomy, mastery, and purpose. > "At more senior levels, During bad times, you will get the fingers pointed at you as you are fundamentally accountable, even though it may have not been your fault." ### Chapter 11: Projects are Hard - "The eye off Sauron" - working on high-stakes projects. - Things slowing down as the team is growing. More (legacy) code, more problems to deal with. - Scope, resources and time balance. > "Lead from the front: As a leader, you need to set the example for the rest of the team. Put in the work. The hardest projects can become career-defining moments. Own them and be there." ### Chapter 12: The Information Stock Exchange - Spies and gatekeepers. > "As a manager, you will be required to make regular decisions about how much you should share with other staff and when." - Workplace politics. > "In workplace politics, your network of peers is important as it allows you to be more broadly informed about how the wider business feels about your own initiatives and priorities." ### Chapter 13: Letting Go of Control - Remove distractions and recharge properly outside work. - Use 10% of your time each week to do nothing and let your thoughts emerge. > "Let go of outcomes that you cannot control. Be accepting of trying your best, and encourage the same behavior in your staff. Unpredictable results are normal. Failure is acceptable. As long as you are trying your best, and you are enabling your team to try your best, then you have nothing to worry about." ### Chapter 14: Good Housekeeping - Turn problems into learning opportunities. - Work on improving the team communication. ### Chapter 15: Dual Ladders - Designing an Individual Contributor and Manager track is vital to a healthy engineering organization culture. ### Chapter 16: The Modern Workplace - Diversity and inclusion. - Remote working. - Lead by example: work-life-balance. ### Chapter 17: Startups - Management doesn't mean bureaucracy. - Good management is a light touch and continued collaboration. > "Remember that start-up experience is highly sought after because being impactful in that environment involves being enterprising, self-motivated, collaborative, and quick to learn. Even if the start-up itself doesn't work out, your next gig will be all the better for it." ### Chapter 18: The Crystal Ball - Your career vision. Looking back, looking ahead. > "An important part of a long and fulfilling life is purpose. Purpose is not about economic status or feeling well-being. It's about a life worth living." --- {{ youtube(id="Cf6tX1ZPwvE") }} --- ## Peopleware Date: 2021-05-28 URL: https://chemaclass.com/readings/peopleware/ Tags: team-management, productivity, communication, psychology > Software development is about people: when, how and where they can best work together. Not about programming languages or tools. Not about fast computers, networks or internet access. Software development is about people: when, how and where they can best work together. Not about programming languages or tools. Not about fast computers, networks or internet access. Soft skills are truly important in IT, more than people tend to think. Developing software is about people that communicate with their customers and stakeholders, are supported by their managers and collaborate in teams. ### Some of my favourite quotes from this book - Staying late or arriving early is a damaging indictment of the office environment. - Someone who can help a project to take solid form and progress is worth two people who just do work. - People should be asking and wondering why things are getting done the way they are being done. - There must be always a trade between quality and quantity. - Organisations tend to expand and create a “busy day”, creating a lot of meetings rather than trust their employees to self-organize. - The human elements are usually the bottleneck of a project. - People won’t work harder if you put them under pressure. They might work more for some time, but they will also get overburden and leave. - Managers' real role is to make it possible for people to work, rather than forcing them to. - Anything you need to quantify can be measured in any way that it’s superior to not measuring at all. - The ultimate management sin is wasting people’s time. - Change won’t even get started unless people feel safe. - Change only has a chance of succeeding if failure (at least a little of failure) is also okay. - Experience gets turned into learning when an organization alters itself to take account of what experience has shown. Professionals want to develop themselves, and want to be happy at work. This book provides ideas in what managers and developers can do to address these and other similar topics. If you are concerned with people, and looking for ways to improve how you collaboratively develop and deliver software, then this book is for you. --- > 21. The Whole Is Greater Than the Sum of the Parts > > We tend to use the word team fairly loosely in the business world, calling any group of people assigned to work > together a “team.” But many of these groups just don’t seem like teams. They don’t have a common definition > of success or any identifiable team spirit. Something is missing. What is missing is a phenomenon we call jell. > > Concept of the Jelled Team > > A jelled team is a group of people so strongly knit that the whole is greater than the sum of the parts. > The production of such a team is greater than that of the same people working in unjelled form. Just as important, > the enjoyment that people derive from their work is greater than what you’d expect given the nature of the work itself. --- I found also a nice serie that shares some thoughts over each chapter of this book. {{ youtube(id="dBQMorJBueE") }} --- ## The Art of Leadership Date: 2021-04-19 URL: https://chemaclass.com/readings/the-art-of-leadership/ Tags: leadership, communication, mentoring, team-management > Leadership practices are small things done repetitively over time. Managers tell you where you are, leaders tell you where you're going. ### Some nice keynotes - Leadership practices are small things done repetitively over time. - Empathy is a powerful skillset. - The practice of one on ones is important in connecting to a team. - Asking for feedback can build trust and relationships. - Respond to feedback with a thank you and follow up comprehension questions. - Feedback is a gift. - It's not personal, it's professional. - Leadership is an outfit that you choose to wear for others to see. - Managers tell you where you are, leaders tell you where you're going. - Your peers become your allies. --- {{ youtube(id="Mf15xcXBedU") }} --- ## 97 Things Every Engineering Manager should know Date: 2021-04-05 URL: https://chemaclass.com/readings/97-things-every-em-should-know/ Tags: leadership, team-management, communication, mentoring > As a manager your work is to create clarity, clarity, and more clarity. ### The main takeaway > As a manager your work is to create clarity, clarity, and more clarity. ### Key Insights - As a manager, you need to fix your personal quirks. - Consider doing experiments instead of making decisions. - “Bad news test” - Given two tasks, which one would you rather be sharing bad news about? Delegate that task. - On a struggling team, start by answering two questions: - How do I create clarity? - How do I create capacity? - Ask for clarification. - To give constructive feedback, pay attention to how the person gets stuck, sidetracked or sloppy. - Management is not a promotion. It is a career change. - Most of the dysfunctions come from some lack of clarity goal. - For a fixed deadline, scope and quality are always negotiable. - Emotional contagion is real. - As a new manager, listen and understand before you try to change something. - Good interview questions: - What have you learned in the past six months? - Tell me about the time when you failed and what you learned from that? - Do you have the skills, expertise and experience to perform the job? - Complains are good: they show that you are trusted. --- Another blog post with way more detailed key insights: [Danlebrero Blog](https://danlebrero.com/2021/03/24/97-things-every-engineering-manager-should-know-summary/) ;) --- {{ youtube(id="oxgfehnJ7GE") }} --- ## Zombie Scrum Survival Guide Date: 2021-03-01 URL: https://chemaclass.com/readings/zombie-scrum-survival-guide/ Tags: scrum, agile, team-management, productivity > Zombie Scrum Survival Guide reveals why Scrum runs aground and shows how to supercharge your Scrum outcomes, while having a lot more fun along the way. I really enjoy the ideas and experiments presented in the book. It points out a lot of "big elephants in many rooms" for a lot of teams claiming to do Scrum or Agile in a really questionable way, aka: Zombie Scrum. ### Summary Zombie Scrum Survival Guide reveals why Scrum runs aground and shows how to supercharge your Scrum outcomes, while having a lot more fun along the way. Humorous, visual, and extremely relatable, it offers practical approaches, exercises, and tools for escaping Zombie Scrum. Even if you're surrounded by skeptics, this book will be the antidote to help you build more of what users need, ship faster, improve more continuously, interact more successfully in any team, and feel a lot better about what you're doing. Suddenly, one day soon, you'll remember: that's why we adopted Scrum in the first place! - Learn how Zombie Scrum infects you, why it spreads, and how to inoculate yourself. - Get closer to your stakeholders, and wake up to their understanding of value. - Discover why Zombie teams can't learn, and what to do about it. - Clear away the specific obstacles to real continuous improvement. - Make self-managed teams real so people can behave like humans, not Zombies. --- This is a nice webinar, when they offer a fresh perspective on Zombie Scrum, share key insights from the book, and discuss their latest findings on the relentless ongoing research. {{ youtube(id="ylGfrsXXQMs") }} --- ## Agile Product Management with Scrum Date: 2021-02-22 URL: https://chemaclass.com/readings/agile-product-management-with-scrum/ Tags: agile, scrum, management > Understanding the product owner’s role and envisioning the product. ### Coverage includes - Understanding the product owner’s role - Envisioning the product - Grooming the product backlog - Planning the release - Collaborating in sprint meetings - Transitioning into product ownership --- ## Stock market investing Date: 2021-01-31 URL: https://chemaclass.com/readings/stock-market-for-beginners/ Tags: economics > Stock market basics & essentials. - Stock Market Basics & Essentials - Fundamental, Industry and Company Research - Investment Styles Such as Value, Growth and Income Investing - Short Selling, Buying on Margin, Day Trading --- ## One up on wall street Date: 2021-01-22 URL: https://chemaclass.com/readings/one-up-on-wall-street/ Tags: economics > America's most successful money manager tells how average investors can beat the pros by using what they know. According to Lynch, investment opportunities are everywhere. America's most successful money manager tells how average investors can beat the pros by using what they know. According to Lynch, investment opportunities are everywhere. --- ## Who moved my cheese? Date: 2021-01-16 URL: https://chemaclass.com/readings/who-moved-my-cheese/ Tags: psychology, career, productivity > This book presents a tale inside the main story that consists of 4 characters: two mice, Sniff and Scurry, and two little persons, Hem and Haw. This book presents a tale inside the main story that consists of 4 characters: two mice, **Sniff** and **Scurry**, and two little persons, **Hem** and **Haw**. The tale is a beautiful metaphor of the different attitudes that people adopt as part of their identity in life when they have to confront any change. ### My favorite lessons of the book 1. Change happens. They keep moving the cheese. 1. Anticipate change. Get ready for the cheese to move. 1. Monitor change. Smell the cheese often so you know when it's getting old. 1. Adapt to change quickly. The quicker you let go of old cheese, the sooner you can enjoy new cheese. 1. Change. Move with the cheese. 1. Enjoy change. Enjoy the taste of new cheese 1. Be ready to change quickly and enjoy it again. They keep moving the cheese. > "Everyone knows that not all change is good or even necessary. But in a world that is constantly changing, it is to our advantage to learn how to adapt and enjoy something better. It is not what is in the story of "Who moved my cheese?" but how you interpret it and apply it to your own situation that gives it the value." - Ken Blanchard. {{ youtube(id="OvYCLxqkfvY") }} I wrote a blog post about this book: [Embrace the change](/blog/embrace-the-change/) --- ## Rich dad poor dad Date: 2021-01-15 URL: https://chemaclass.com/readings/rich-dad-poor-dad/ Tags: economics > Explodes the myth that you need to earn a high income to become rich. - Explodes the myth that you need to earn a high income to become rich - Challenges the belief that your house is an asset - Shows parents why they can't rely on the school system to teach their kids about money - Defines once and for all an asset and a liability - Teaches you what to teach your kids about money for their future financial success --- ## Principles of package design Date: 2020-11-12 URL: https://chemaclass.com/readings/packaging-design/ Tags: software-design, architecture, clean-code > Apply design principles to your classes, preparing them for reuse. You will use package design principles to create packages that are just right in terms of cohesion and coupling, and are user- and maintainer-friendly at the same time. Apply design principles to your classes, preparing them for reuse. You will use package design principles to create packages that are just right in terms of cohesion and coupling, and are user- and maintainer-friendly at the same time. The first part of this book walks you through the five SOLID principles that will help you improve the design of your classes. The second part introduces you to the best practices of package design, and covers both package cohesion principles and package coupling principles. Cohesion principles show you which classes should be put together in a package, when to split packages, and if a combination of classes may be considered a "package" in the first place. Package coupling principles help you choose the right dependencies and prevent wrong directions in the dependency graph of your packages. ### What You'll Learn - Apply the SOLID principles of class design - Determine if classes belong in the same package - Know whether it is safe for packages to depend on each other --- ## Animal Farm Date: 2020-11-02 URL: https://chemaclass.com/readings/animal-farm/ Tags: fiction, dystopia, philosophy, psychology > Orwell's political allegory about a farmyard rebellion that descends into tyranny, exposing how power corrupts even the most idealistic revolutions. Mr Jones of Manor Farm is so lazy and drunken that one day he forgets to feed his livestock. The ensuing rebellion under the leadership of the pigs Napoleon and Snowball leads to the animals taking over the farm. Vowing to eliminate the terrible inequities of the farmyard, the renamed Animal Farm is organised to benefit all who walk on four legs. But as time passes, the ideals of the rebellion are corrupted, then forgotten. And something new and unexpected emerges. --- ## Object design style guide Date: 2020-10-10 URL: https://chemaclass.com/readings/object-design-style-guide/ Tags: software-design, clean-code, php > Matthias Noback's practical guide to writing flexible, readable, and maintainable object-oriented code, with techniques applicable to any OO language from Python to PHP. Objects are the central concept of languages like Java, Python, C#. Applying best practices for object design means that your code will be easy to read, write, and maintain. This book captures dozens of techniques for creating pro-quality OO code that can stand the test of time. Examples are in an instantly-familiar pseudocode, teaching techniques you can apply to any OO language, from C++ to PHP. --- ## Domain-Driven Design Distilled Date: 2020-09-10 URL: https://chemaclass.com/readings/domain-driven-design-distilled/ Tags: ddd, architecture, software-design > Domain-Driven Design Distilled brings DDD to life. Whether you're a developer, consultant, or customer, it will help you understand it, so you can benefit from its power. Domain-Driven Design Distilled brings DDD to life. Whether you're a developer, consultant, or customer, it will help you understand it, so you can benefit from its power. --- This book delivers powerful results in practice, which is why developers worldwide are rapidly moving to adopt it. This is an accessible guide to the basics: - What is DDD? - What problems does it solve? - How does it work? - How to quickly gain value from it? You'll learn how to segregate domain models using the powerful **Bounded Contexts** pattern, to develop a **Ubiquitous Language** within an explicitly bounded context and help **domain experts** and **developers work together** to create that language. How to use Subdomains to handle legacy systems and integrate multiple Bounded Contexts to define team relationships and technical mechanisms. > Domain-Driven Design Distilled brings **DDD** to life. --- ## Advanced Web Application Architecture Date: 2020-08-16 URL: https://chemaclass.com/readings/advance-web-application-architecture/ Tags: architecture, php, software-design, refactoring > The best guide that brings your coding and architecture skills a level up. All the modern PHP features combined with the elegance of a well designed modular design. This book helps you get your web applications back in shape. It contains many techniques for decoupling from infrastructure (like the framework or the database). "The best guide that brings your coding and architecture skills a level up. All the modern PHP features combined with the elegance of a well-designed modular design." In Part 1 we unlock a collection of design patterns which help you establish a clean separation between core and infrastructure code. Part 2 shows how these design patterns resonate at a higher level with architectural concepts like layers, ports and adapters (a.k.a. Hexagonal architecture). The book finishes with a discussion of testing strategies and design trade-offs. ### What you'll learn - Separating mixed code into core and infrastructure code by refactoring into patterns. - Dividing your code into layers, and making a clear distinction between an application's ports and adapters. - Testing decoupled applications. > Buy the book: [https://leanpub.com/web-application-architecture](https://leanpub.com/web-application-architecture) --- ### Design patterns for modernizing legacy code bases {{ youtube(id="WI1QY6OMglE") }} --- ## Never split the difference Date: 2020-06-12 URL: https://chemaclass.com/readings/never-split-the-difference/ Tags: communication, psychology, leadership > From policing the rough streets of Kansas City, Missouri, to becoming the FBI's lead international kidnapping negotiator to teaching negotiation at leading universities, Chris Voss has tested the techniques in 'Never Split the Difference' across the full spectrum of human endeavor and proved their effectiveness. From policing the rough streets of Kansas City, Missouri, to becoming the FBI's lead international kidnapping negotiator to teaching negotiation at leading universities, Chris Voss has tested the techniques in _Never Split the Difference_ across the full spectrum of human endeavor and proved their effectiveness. --- ## Takeaways 1. Negotiation begins with listening, making it about the other people, validating their emotions, and creating enough trust and safety for a real conversation to begin. 2. Use mirrors to encourage the other side to empathize and bond with you, keep people talking, buy your side time to regroup, and encourage your counterparts to reveal their strategy. 3. Tactical empathy brings our attention to both the emotional obstacles and the potential pathways to getting an agreement done. 4. Giving someone's emotion a name, otherwise known as labeling, gets you close to someone without asking about external factors you know nothing about. 5. "No" provides a great opportunity for you, and the other party to clarify what you really want by eliminating what you don't want. ### Summary video {{ youtube(id="QIRk382yJm4") }} --- ## Scrum Date: 2020-06-10 URL: https://chemaclass.com/readings/scrum-the-art-of-doing-twice/ Tags: scrum, agile, team-management, productivity > Every organisation, whatever its size, constantly has to come to grips with delivering a product or service on time and on budget. Scrum shows you how. It explains how to define precisely what it is that you are seeking to achieve, how to set up the team to achieve it, and how to monitor progress until the project is successfully completed. Every organisation, whatever its size, constantly has to come to grips with delivering a product or service on time and on budget. Scrum shows you how. It explains how to define precisely what it is that you are seeking to achieve, how to set up the team to achieve it, and how to monitor progress until the project is successfully completed. --- ## 7 languages in 7 weeks Date: 2020-05-21 URL: https://chemaclass.com/readings/7-languages-in-7-weeks/ Tags: software-design, software, career > A hands-on tour of Clojure, Haskell, Io, Prolog, Scala, Erlang, and Ruby. Learn how each language thinks differently and broaden your perspective on programming. You should learn a programming language every year, as recommended by The Pragmatic Programmer. But if one per year is good, how about Seven Languages in Seven Weeks? In this book you'll get a hands-on tour of Clojure, Haskell, Io, Prolog, Scala, Erlang, and Ruby. Whether your favorite language is on that list, you'll broaden your perspective of programming by examining these languages side-by-side. You'll learn something new from each, and best of all, you'll learn how to learn a language quickly. --- I created this repository with all my learnings while I was reading and playing aroung with the languages from this book [https://github.com/Chemaclass/7LangIn7Weeks](https://github.com/Chemaclass/7LangIn7Weeks) --- ## The call of Cthulhu Date: 2020-05-18 URL: https://chemaclass.com/readings/call-of-cthulhu/ Tags: fiction, horror > Lovecraft's foundational cosmic horror tale about the discovery of an ancient underwater entity whose awakening threatens all of humanity and sanity itself. The Call of Cthulu, the tale of a horrifying underwater monster coming to life and threatening mankind, spawning an entire mythology, with the power to strike terror into the hearts of even the Great Old Ones. --- ## The metamorphosis Date: 2020-05-16 URL: https://chemaclass.com/readings/metamorphosis/ Tags: fiction, philosophy, psychology > Kafka's iconic novella about alienation and identity. Gregor Samsa wakes as a monstrous insect and must confront his family's revulsion and his own fading humanity. The Metamorphosis (German: Die Verwandlung, also sometimes translated as The Transformation) is a novella by Franz Kafka, first published in 1915. It has been cited as one of the seminal works of fiction of the 20th century and is studied in colleges and universities across the Western world. The story begins with a traveling salesman, Gregor Samsa, waking to find himself transformed (metamorphosed) into a large, monstrous insect-like creature. The cause of Samsa's transformation is never revealed, and Kafka never did give an explanation. The rest of Kafka's novella deals with Gregor's attempts to adjust to his new condition as he deals with being burdensome to his parents and sister, who are repulsed by the horrible, verminous creature Gregor has become. --- ## 1984 Date: 2020-05-13 URL: https://chemaclass.com/readings/1984/ Tags: fiction, dystopia, philosophy, psychology > One of Britain's most popular novels, George Orwell's Nineteen Eighty-Four is set in a society terrorised by a totalitarian ideology propagated by The Party. One of Britain's most popular novels, George Orwell's Nineteen Eighty-Four is set in a society terrorised by a totalitarian ideology propagated by The Party. Winston Smith works for the Ministry of Truth in London, chief city of Airstrip One. Big Brother stares out from every poster, the Thought Police uncover every act of betrayal. When Winston finds love with Julia, he discovers that life does not have to be dull and deadening, and awakens to new possibilities. Despite the police helicopters that hover and circle overhead, Winston and Julia begin to question the Party; they are drawn towards conspiracy. Yet Big Brother will not tolerate dissent - even in the mind. For those with original thoughts they invented Room 101. . . Nineteen Eighty-Four is George Orwell's terrifying vision of a totalitarian future in which everything and everyone is slave to a tyrannical regime. The novel also coined many new words and phrases which regular appear in popular culture, such as 'Big Brother', 'thoughtcrime', 'doublethink' and 'Newspeak'. --- {{ youtube(id="T8BA7adK6XA")}} --- ## High Output Management Date: 2020-04-03 URL: https://chemaclass.com/readings/high-output-management/ Tags: leadership, team-management, productivity > Andy Grove's management classic from Intel, covering managerial leverage, meetings, decision-making, motivation, and how to maximize team output in technology organizations. In this legendary business book and Silicon Valley staple, the former chairman and CEO of Intel shares his perspective on how to build and run a company. A practical handbook for navigating real-life business scenarios and a powerful management manifesto with the ability to revolutionize the way we work. ### Sections - Managerial Leverage - Training - Motivation - Meetings and Decisions - One-on-One Meetings - Delegation and Task-Relevant Maturity - KPIs - Performance Reviews - Interviews - Promotions and Recycling --- A pretty nice overview from the takeaways by Marc Koenig: {{ youtube(id="Yi1PSs_bpQ0") }} --- ## The Manager Path Date: 2020-03-26 URL: https://chemaclass.com/readings/the-manager-path/ Tags: leadership, team-management, mentoring, communication > Camille Fournier maps the career path from engineer to CTO, covering 1:1s, mentoring, team management, and the evolving responsibilities at each level of technical leadership. ## Key lessons 1. One-on-one meetings with your manager are an essential feature of a good working relationship. 2. A manager's job involves making it easy for her employees to get things done by creating fertile environments in which work can happen. 3. Mentoring new hires is critical. 4. Feedback works best when you, as a manager, pair that feedback with coaching. 5. It's unrealistic to think you can or should shield your team from everything. --- {{ youtube(id="oxgfehnJ7GE") }} --- ## Clean Agile Date: 2020-03-12 URL: https://chemaclass.com/readings/clean-agile/ Tags: agile, tdd, software-design > This book is about Agile. What it was, what it is, and what it will be. This is a back-to-basics talk that covers the history of Agile, what motivated it, and what has happened to it since. Clean Agile comes from Uncle Bob, one of the founding fathers of Agile, one of the seventeen people who authored the [Agile Manifesto](https://agilemanifesto.org/) back in 2001. --- This talk is about Agile. What it was, what it is, and what it will be. This is a back-to-basics talk that covers the history of Agile, what motivated it, and what has happened to it since. The talk covers the basic practices of Agile, and compares and contrasts those practices with the current menagerie of Agile processes. {{ youtube(id="FedQ2NlgxMI") }} --- ## Extreme Programming Explained Date: 2020-03-05 URL: https://chemaclass.com/readings/extreme-programming-explained/ Tags: xp, agile, tdd, pair-programming, communication > Extreme Programming (XP) is an agile software development framework that aims to produce higher quality software, and higher quality of life for the development team. XP is the most specific of the agile frameworks regarding appropriate engineering practices for software development. ## Definition Extreme Programming (XP) is an agile software development framework that aims to produce higher quality software, and higher quality of life for the development team. XP is the most specific of the agile frameworks regarding appropriate engineering practices for software development. --- ## Values The five values of XP are communication, simplicity, feedback, courage, and respect and are described in more detail below. ### Communication Software development is inherently a team sport that relies on communication to transfer knowledge from one team member to everyone else on the team. XP stresses the importance of the appropriate kind of communication: face to face discussion with the aid of a white board or other drawing mechanism. ### Simplicity Simplicity means "what is the simplest thing that will work?" The purpose of this is to avoid waste and do only absolutely necessary things such as keep the design of the system as simple as possible so that it is easier to maintain, support, and revise. Simplicity also means address only the requirements that you know about; don't try to predict the future. ### Feedback Through constant feedback about their previous efforts, teams can identify areas for improvement and revise their practices. Feedback also supports simple design. Your team builds something, gathers feedback on your design and implementation, and then adjust your product going forward. ### Courage Kent Beck defined courage as "effective action in the face of fear". This definition shows a preference for action based on other principles so that the results aren't harmful to the team. You need courage... - to raise organizational issues that reduce your team's effectiveness. - to stop doing something that doesn't work and try something else. - to accept and act on feedback, even when it's difficult to accept. ### Respect The members of your team need to respect each other in order to communicate with each other, provide and accept feedback that honors your relationship, and to work together to identify simple designs and solutions. --- ## Principles ### Humanity Human beings are the ones developing software. It is a fact. The book mentions 5 points that are needed for developers to become good: basic safety, accomplishment, belonging, growth, and intimacy. The magic of great teams is that after the team members develop trust they find that they are free to be more themselves as a result of their work together. ### Economics Software costs. Someone or multiple people paid or invested in it. Make sure what you are doing has business value, meets business goals, and serves business needs. For example, solving the highest priority business need first maximizes the value of the project. The earlier software makes money, the sooner the development is valuable. ### Mutual Benefit Mutual benefit in XP is about activities benefitting all concerned. This principle is about finding practices that benefit me now, me later, and the customers as well. The book brings up 3 points how XP mutually deals with communication-with-the-future problems: - I write automated tests that help me design and implement better today. I leave these tests for future programmers to use as well. This practice benefits me now and maintainers down the road. - I carefully refactor to remove accidental complexity, giving me both satisfaction and fewer defects and making the code easier to understand for those who encounter it later. - I choose names from a coherent and explicit set of metaphors which speeds my development and makes the code clearer to new programmers. ### Self-Similarity This principle is about copying the structure of one solution into a new context. For example, the basic structure of development is that you write a failing test and then make it work. This structure operates at all different scales. Take into account, this principle is a good start, but it may not always work. ### Improvement Do your best today but strive to do better tomorrow, strive to have a deeper understanding tomorrow. XP shines in this aspect, it is about always improving. > Put improvement to work by not waiting for perfection. Find a starting place, get started, and improve from there. ### Diversity Teams need to bring in people from different backgrounds, with different experiences, attitudes, etc. In order for the team to have different ways of thinking and solving a problem. The principle of diversity suggests that the programmers should work together on the problem and both opinions should be valued. ### Reflection Good teams reflect after action, regularly. They think about why and how they are working. - Why did we succeed? What should we continue doing? - Why did we fail? What can we do better or differently? Reflect and strive to improve. Even if everything seems perfect, know that there is always room for improvement and throw in the question: - Why do things seem perfect? What are we doing well? What can we do better in order to succeed even more? ### Flow Flow in software development is delivering a steady flow of valuable software by engaging in all the activities of development simultaneously. Don't deliver software in big portions. Deploy smaller increments of value more frequently. ### Opportunity Learn to see problems as opportunities for learning and improving. > Part of being extreme is consciously choosing to transform each problem into an opportunity: > an opportunity for personal growth, deepening relationships, and improved software. ### Redundancy The difficult problems in software development should be solved in multiple ways. > The cost of the redundancy is more than paid for by the savings from not having a disaster. ### Failure Sometimes it is extremely difficult to implement something, we don't know which way or approach to take, try the ideas you have, even if they fail! Failure isn't a waste, rather a learning experience. Be aware of falling into the trap of discussing or thinking forever and not getting things done. > When you don't know what to do though, risking failure can be the shortest, surest road to success. ### Quality Projects don't go faster by lowering the quality. Actually it's often the other way around (if not always). It results in later and less predictable delivery, especially due to the amount of time spent on fixing bugs for example. Pushing quality higher often results in faster delivery. > A concern for quality is no excuse for inaction. If you don't know a clean way to do a job that has to be done, > do it the best way you can. If you know a clean way but it would take too long, do the job as well as you have time > for now. Resolve to finish doing it the clean way later. ### Baby Steps Take baby steps. Making big changes in big steps is dangerous. People and teams can take many small steps so they appear to be moving forward rapidly. > Baby steps acknowledge that the overhead of small steps is much less than when a team wastefully recoils from aborted big changes. ### Accepted Responsibility > Responsibility cannot be assigned; it can only be accepted. If someone tries to give you responsibility, only you can decide if you are responsible or if you aren't. --- ## Practices While it is possible to do these practices in isolation, many teams have found some practices reinforce the others and should be done in conjunction to fully eliminate the risks you often face in software development. ### Sit Together Since communication is one of the five values of XP, have your team sit together in the same space without barriers to communication, such as cubicle walls. ### Whole Team Include on the team people with all the skills and perspectives necessary for the project to succeed. ### Informative Workspace Set up your team space to facilitate face to face communication, allow people to have some privacy when they need it, and make the work of the team transparent to each other and to interested parties outside the team. ### Energized Work You are most effective at software development and all knowledge work when you are focused and free from distractions. ### Pair Programming Pair Programming means all production software is developed by two people sitting at the same machine. The idea behind this practice is that two brains and four eyes are better than one brain and two eyes. You effectively get a continuous code review and quicker response to nagging problems that may stop one person dead in their tracks. Teams that have used pair programming have found that it improves quality and does not actually take twice as long because they are able to work through problems quicker, and they stay more focused on the task at hand, thereby creating less code to accomplish the same thing. Pair programmers: - Keep each other on task. - Brainstorm refinements to the system. - Clarify ideas. - Take initiative when their partner is stuck, thus lowering frustration. - Hold each other accountable to the team's practices. > Pair programming is a dialog between two people simultaneously programming (and analyzing and designing and testing) > and trying to program better. Though, if you need privacy and time to work on an idea, go ahead and do it. We need both companionship and privacy. Make sure to rotate pairs frequently and take frequent breaks, pairing can be tiring, but surely is rewarding. ### Stories Describe what the product should do in terms meaningful to customers and users. These stories are intended to be short descriptions of things users want to be able to do with the product that can be used for planning and serve as reminders for more detailed conversations when the team gets around to realizing that particular story. Give the stories a short title and a description. Write them on cards and put them on a wall that is often being passed. In XP stories are estimated extremely early, which gets the team thinking about how to get the largest return from the tiny investment. ### Weekly Cycle The Weekly Cycle is synonymous to an iteration. In the case of XP, the team meets on the first day of the week to reflect on progress to date, the customer picks the stories they would like delivered in that week, and the team determines how they will approach those stories. The intent behind the time boxed delivery period is to produce something to show to the customer for feedback. ### Ten-Minute Build The goal with the Ten-Minute Build is to automatically build the whole system and run all of the tests in ten minutes. ### Continuous Integration Continuous Integration is a practice where code changes are immediately tested when they are added to a larger code base. The benefit of this practice is you can catch and fix integration issues sooner. This practice requires some extra discipline and is highly dependent on Ten Minute Build and Test First Development. ### Test-First Programming > Write a failing automated test before changing any code. The book mentions 4 problem Test-First Programming addresses at once: - Scope creep: It's easy to get carried away programming and put in code "just in case." By stating explicitly and objectively what the program is supposed to do, you give yourself a focus for your coding. If you really want to put that other code in, write another test after you've made this one work. - Coupling and cohesion: If it's hard to write a test, it's a signal that you have a design problem, not a testing problem. Loosely coupled, highly cohesive code is easy to test. - Trust: It's hard to trust the author of code that doesn't work. By writing clean code that works and demonstrating your intentions with automated tests, you give your teammates a reason to trust you. - Rhythm: It's easy to get lost for hours when you are coding. When programming test-first, it's clearer what to do next: either write another test or make the broken test work. Soon this develops into a natural and efficient rhythm: test, code, refactor, test, code, refactor. ### Incremental Design > Invest in the design of the system every day. You do a little bit of work up front to understand the proper breadth-wise perspective of the system design, and then dive into the details of a particular aspect of that design when you deliver specific features. This approach reduces the cost of changes and allows you to make design decisions when necessary based on the most current information available. --- ## Roles Although XP specifies particular practices for your team to follow, it doesn't really establish specific roles for the people on your team. Depending on which source you read, there is either no guidance, or there is a description of how roles typically found in more traditional projects behave on XP projects. ### The Customer The Customer role is responsible for making all of the business decisions regarding the project including: The XP Customer is assumed to be a single person, however experience has shown that one person cannot adequately provide all of the business related information about a project. ### The Developer Because XP does not have much need for role definition, everyone on the team (with the exception of the customer and a couple of secondary roles listed below) is labeled a developer. Developers are responsible for realizing the stories identified by the Customer. ### The Tracker The main purpose of this role is to keep track of relevant metrics that the team feels necessary to track their progress and to identify areas for improvement. ### The Coach This is usually an outside consultant (or someone from elsewhere in your organization) who has used XP before and is included in your team to help mentor the other team members on the XP Practices and to help your team maintain your self-discipline. --- #### What is XP? (in 2 min) {{ youtube(id="hbFOwqYIOcU") }} #### Tech Talk by kent Beck: XP 20 years later {{ youtube(id="cGuTmOUdFbo") }} --- ## Symfony 5 Date: 2020-02-20 URL: https://chemaclass.com/readings/symfony-5/ Tags: php, symfony, architecture > Fabien Potencier's official guide to building web applications with Symfony 5, covering the framework from scratch to production deployment. This book, written by Symfony's creator, lays out a pragmatic approach to developing web applications with Symfony 5: from scratch to production. Whether you are discovering Symfony for the first time or refreshing your knowledge, this practical guide provides the definitive introduction to modern Symfony applications. --- ## Atomic Habits Date: 2019-11-12 URL: https://chemaclass.com/readings/atomic-habits/ Tags: psychology, productivity, career > People think that when you want to change your life, you need to think big. James Clear has discovered another way. He knows that real change comes from the compound effect of hundreds of small decisions. He calls them atomic habits. People think that when you want to change your life, you need to think big. James Clear has discovered another way. He knows that real change comes from the compound effect of hundreds of small decisions. He calls them atomic habits. ### Takeaways - Focus more on systems and processes and less on goals - Change how you identify yourself - The environment is more important than being motivated - To break a bad habit, reduce exposure to the cues that cause it - Bundle an action you want to do with an action you need to do - Instead of saying "I have to,” say "I get to” - Don't try to make a habit perfect, just repeat it - Reduce friction for good habits and increase friction for bad habits - To make something not seem like a chore, do it for short periods of time - To achieve long-term goals, make small habits rewarding - Never miss more than once of a habit I wrote a blog post about this topic: [The process itself is the goal](/blog/the-process-itself-is-the-goal/) --- {{ youtube(id="YT7tQzmGRLA") }} --- ## Working Effectively with Legacy Code Date: 2019-07-01 URL: https://chemaclass.com/readings/working-effectively-with-legacy-code/ Tags: refactoring, testing, tdd, software-design > Michael Feathers presents practical techniques for adding tests to untested code, breaking dependencies, and safely refactoring large legacy systems without introducing bugs. ## What is legacy code? > Legacy code is simply code without tests. ### Benefits of tests Behavior is central to understanding the benefits of testing: > Behavior is the most important thing about software. It is what users depend on. Users like it when we add behavior (provided it is what they really wanted), but if we change or remove behavior they depend on (introduce bugs), they stop trusting us. ### How to get tests in place in legacy codebases When we change code, we should have tests in place. To put the tests in place, we often have to change code. The suggested approach: 1. Identify change points. 2. Find test points. 3. Break dependencies. 4. Write tests. 5. Make changes and refactor. Another useful term is a "**seam**." A seam, in this context, is "**a place where you can alter behavior in your program without editing in that place**". The analogy is to a seam in clothing, the place where two parts are stitched together. In software, **these places are generally places where there are well-defined interfaces**. This can be leveraged to change the implementation using techniques such as dependency injection or mocking interfaces in the case of writing tests. --- {{ youtube(id="wRtJRkRIa2s") }} --- ## The Art of War Date: 2018-08-10 URL: https://chemaclass.com/readings/the-art-of-war/ Tags: philosophy, psychology, leadership > The Art of War is an ancient Chinese military treatise attributed to Sun Tzu, a high-ranking military general, strategist and tactician, and kindred to the Realpolitik of his time, termed in China as Legalism. The text is composed of 13 chapters, each of which is devoted to one aspect of warfare. It is commonly thought of as a definitive work on military strategy and tactics. It has been the most famous and influential of China's Seven Military Classics, and "for the last two thousand years it remained the most important military treatise in Asia, where even the common people knew it by name." It has had an influence on Eastern and Western military thinking, business tactics, legal strategy and beyond. ### Quotes - Appear weak when you are strong, and strong when you are weak. - If he is superior in strength, evade him. - Attack him where he is unprepared. Appear where you are not expected. - The general who loses a battle makes but few calculations beforehand. - There is no instance of a country having benefitted from prolonged warfare. - Supreme excellence consists in breaking the enemy’s resistance without fighting. - If you know the enemy and know yourself, you need not fear the result of a hundred battles. If you know yourself, but not the enemy, for every victory gained you will also suffer a defeat. If you know neither the enemy nor yourself, you will succumb in every battle. - One may know how to conquer without being able to do it. - In war, the victorious strategist only seeks battle after the victory has been won. - In battle, there are not more than two methods of attack: the direct and indirect. - An army may march great distances without distress if it marches through country where the enemy is not. - You can be sure in succeeding in your attacks if you only attack places which are undefended. - Military tactics are like water. For water, in its natural course, runs away from high places and hastens downwards. So, in war, the way is to avoid what is strong and strike at what is weak. - Let your plans be dark and impenetrable as night, and when you move fall like a thunderbolt. - Ponder and deliberate before you make a move. - A clever general, therefore, avoids an army when its spirit is keen, but attacks it when it is sluggish and inclined to return. - It is a military axiom not to advance uphill against the enemy nor to oppose him when he comes downhill. - The art of war teaches us to rely not on the likelihood of the enemy not coming, but on our readiness to receive him. - Make your way by unexpected routes and attack unguarded spots. - If they will face death, there is nothing they will not achieve. - The principle on which to manage an army is to set up one standard of courage which all must reach. - If it is to your advantage, make a forward move. If not, stay where you are. --- {{ youtube(id="aF2pCff3ocg") }} --- ## Clean Architecture Date: 2018-06-04 URL: https://chemaclass.com/readings/clean-architecture/ Tags: architecture, software-design, clean-code, ddd > Robert C. Martin's guide to SOLID principles, component design, and architectural boundaries that keep software systems flexible, testable, and maintainable over time. ### Code design principles (SOLID) - **Single Responsibility**: a class should have one, and only one, reason to change. Or the new version: a module should be responsible to one, and only one, actor. - **Open-closed**: a class should be open for extension but closed for modification. - **Liskov’s Substitution**: objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program. - **Interface Segregation**: many client-specific interfaces are better than one general-purpose interface. - **Dependency Inversion** : one should depend upon abstractions, not concretions. ### Component principles #### Component cohesion - **Reuse/Release Equivalence** Principle: classes and modules (i.e. a component) reused together should be released together. They should have the same version number and there should be proper documentation such as changelogs. - **Common Closure** Principle: classes that change together should be grouped together, and vice versa. The single responsibility principle at component-level. - **Common Reuse** Principle: don’t force users of a component to depend on things they don’t need. The Interface Segregation Principle at component-level. #### Component coupling - **Acyclic Dependencies** Principle: no cycle in the dependency graph. Cycles couple components and, among other things, force them to be to released together. Use the dependency inversion principle to break cycles. - **The Stable Dependency** Principle: less stable components should depend on more stable components. Depend on the direction of stability. - **Stable Abstractions** Principle: stable components should be abstract, and vice versa. An example of an abstract stable component is a high-level policy which is changed by extension following the open-closed principle. ### Architecture principles #### Setting boundaries Boundaries are lines that separate software elements. They separate things that matter from things that don’t, i.e. high-level components from low-level components. If a high-level component depends on a low-level component at the source level, changes in the low-level components will spread to the high-level component. Therefore, we place a boundary between the two, using polymorphism to invert the logic flow. This is the Dependency Inversion Principle in the SOLID principles. #### Separating layers We can identify four main layers, although the number may vary: - **Entities**: objects containing critical business logic. For example, a bank could establish that no loans are granted to customers not satisfying some credit score requirements. Entities may be shared across apps in the same enterprise. - **Use-cases**: app-specific business rules. For example, the sequence of screens to execute a bank transfer. - **Interface adapters**: Gateways, presenters and controllers. For example, this layer will contain the MVC architecture of the GUI and also objects that transform data between the format of the database and the use-cases. - **Frameworks and drivers**: web frameworks, database, the view of MVC. --- ## The Power of Habit Date: 2017-03-20 URL: https://chemaclass.com/readings/the-power-of-habits/ Tags: psychology, productivity, career > Charles Duhigg explores the science behind habit formation, showing how habits work, why they exist, and practical strategies to transform them for personal and professional growth. ## Takeaways 1. All habits operate the same way 2. Changing a habit means changing one key aspect... 3. ...and changing one habit can change a lot of things 4. Willpower is a muscle 5. Practice, practice, practice --- {{ youtube(id="Zq2LVa36ukk") }} --- ## The Pragmatic Programmer Date: 2016-10-01 URL: https://chemaclass.com/readings/the-pragmatic-programmer/ Tags: software-design, clean-code, refactoring, career > Key takeaways from Hunt and Thomas's classic on pragmatic software development, including DRY principles, the right mindset, and how to choose and master your tools. ### Takeaways - Don't Repeat Yourself. - Mindset is as important as knowledge. - Good code is easier to change than bad design. - Choose great tools and become fluent with them. --- #### Don't Repeat Yourself (DRY) - Every piece of knowledge must have a single, unambiguous, authoritative representation within a system. - DRY is about the duplication of knowledge, of intent. It's about expressing the same thing in two different places, possibly in two totally different ways. #### Mindset is as important as knowledge Some important aspects of this mindset include: - Taking responsibility for your work by not making excuses or passing blame when things go wrong. - Writing software that's good enough. This means not wasting time on things that are better than they need to be to make the product successful. - Not ignoring technical debt. The authors use the analogy of broken windows: > Don't leave "broken windows" (bad designs, wrong decisions, or poor code) unrepaired. > Fix each one as soon as it is discovered. If there is insufficient time to fix it properly, then board it up. > Perhaps you can comment out the offending code, or display a "Not Implemented" message, or substitute dummy data instead. --- ## Sprint Date: 2016-09-01 URL: https://chemaclass.com/readings/sprint/ Tags: agile, productivity, team-management > Sprint offers a transformative formula for testing ideas that works whether you’re at a startup or a large organization. Within five days, you’ll move from idea to prototype to decision, saving you and your team countless hours and countless dollars. A must read for entrepreneurs of all stripes. "Sprint offers a transformative formula for testing ideas that works whether you’re at a startup or a large organization. Within five days, you’ll move from idea to prototype to decision, saving you and your team countless hours and countless dollars. A must read for entrepreneurs of all stripes." - Eric Ries, author of The Lean Startup From three partners at Google Ventures, a unique five-day process for solving tough problems, proven at more than a hundred companies. {{ youtube(id="AuktI4lBj6M") }} --- ## The Clean Coder Date: 2016-08-01 URL: https://chemaclass.com/readings/the-clean-coder/ Tags: clean-code, career, tdd, communication > Robert C. Martin's guide to professional behavior in software development, covering time management, pressure handling, TDD practices, and what it truly means to be a software craftsman. Programmers who endure and succeed amidst swirling uncertainty and nonstop pressure share a common attribute: They care deeply about the practice of creating software. They treat it as a craft. They are professionals. ### Readers will learn - What it means to behave as a true software craftsman - How to deal with conflict, tight schedules, and unreasonable managers - How to get into the flow of coding, and get past writer's block - How to handle unrelenting pressure and avoid burnout - How to combine enduring attitudes with new development paradigms - How to manage your time, and avoid blind alleys, marshes, bogs, and swamps - How to foster environments where programmers and teams can thrive - When to say **No** and how to say it - When to say **Yes** and what yes really means --- ## Summary ### Chapter 1: Professionalism - Being a professional means taking full responsibility for one's actions. - First rule is not doing harm to the function nor the structure of the software. - You will always make occasional mistakes, but you must learn from each. - You should be certain about all code you release and firmly expect QA to find nothing wrong with it. - Test it and test it again. - Automate your tests. - Design your code to be easy to test. - You should follow the Boy Scout rule and always leave a module a little cleaner than you found it so that it becomes easier to change over time, not harder. - Your career is **your responsibility**, not your boss nor your employers. - Spending 20 hours a week beyond your normal work to improve your knowledge and skills. - Read, experiment, practice (kata), talk to other, collaborate, look over the fence, mentor. - It should be fun. - Also, know your domain, identify with your customer (no "us vs. them", ever). ### Chapter 2: Saying No - Professionals have the courage to say no to their managers. - Managers and developers have roles that are often adversarial, because on the short term, their goals tend to conflict. - The higher the stakes, the more valuable a "no" becomes, and the harder to say. - Good teams will successfully work towards a yes, but only a right yes, that will later work out in practice. ### Chapter 3: Saying Yes - There are three parts to making a commitment: - You say you will do it - You mean it - You actually do it - Your commitment must respect the limits of what you expect (based on your experience) you can and cannot do. - If you recognize you will probably not be able to meet a commitment, you need to raise a red flag immediately. ### Chapter 4: Coding - Programming requires a level of focus that few other disciplines require. - "The zone" (or "flow") is not as good as people think: you will be locally productive, but will often lose the bigger picture and possibly product not-so-good designs. - Interruptions are bad distractions. - Pair programming is helpful to cope with them. - TDD helps to make the pre-interruption context reproducible. - Minimize time spent debugging - Coding is a **marathon**, not a sprint, so conserve the energy and creativity. - Leave when it's time, even in the middle of something important. - Continuously re-estimate your best/likely/worst completion time and speak up as soon as you recognize you will likely be late. - Do not allow anyone to rush you. - Use a proper definition of "done", with sufficiently high quality requirements. - Programming is too hard for anyone, so get help and provide help to others, in particular (but not only) in mentoring style. - Don't be shy from asking. ### Chapter 5: Test-Driven Development - [TDD](https://en.wikipedia.org/wiki/Test-driven_development) is not a cure-all and is impractical or inappropriate in some (rare) cases. - TDD Cycle: 1. Add a test 2. Run all tests. The new test should fail for expected reasons 3. Write the simplest code that passes the new test 4. All tests should now pass 5. Refactor as needed 6. Repeat ### Chapter 6: Practicing - A programming Kata is a precise set of choreographed keystrokes and mouse movements that simulates the solving of some programming problem. - A Kata is about the process, not the solution. - You aren't solving the problem because you already know the solution. ### Chapter 7: Acceptance Testings - Avoid garbage in, garbage out. Make sure you understand the requirements. - Creating this understanding means removing ambiguity. - The best way to do this is defining acceptance tests: - All customer's conditions need to be fulfilled by automated tests to prove the expected software behavior. - Success of those tests constitutes the definition of "Done". - Code implementation should start only when the tests are complete. - Unlike unit tests (which are only for programmers), the audience of acceptance tests are both: business and developers. - Run all tests in a continuous integration and immediately fix any failures. ### Chapter 8: Test Strategies - Consider QA part of the team. They act as specifiers: writing acceptance tests, including the failure cases and corner cases, and perform exploratory testing. - Testing pyramid: - Most tests are unit tests. By developer and for developers. - Many tests are component or integration tests. By QA or Business assisted by Developers. For Business and Developers. ### Chapter 9: Time management - Management roles in software development requires good time management. - Meeting are necessary but are also often huge time wasters, so avoid meeting that have no clear benefit <- this is a professional obligation. - Meeting must have an agenda and a clear goal. - Agile stand up meetings can be an efficient format. - Iteration planning should take 5% of the iteration. - Concentration (focus) is a scarce resource. - Use it well when present and recharge with simpler tasks (meetings) and breaks in between. - How to improve? - Sport. - Creative input. - Short breaks every 45 minutes. ### Chapter 10: Estimation - Estimation is the source of most distrust between business people and developers because the latter provide estimate which the former treats like commitments. - Both are insufficiently aware that the estimate really is a probability distribution, not a fixed number. ### Chapter 11: Pressure - The professional developer is calm and decisive under pressure, adhering to his training and disciplines, knowing that they are the best way to meet pressing deadlines and commitments. - Avoid situations that cause pressure via: - make only commitments you can fulfill - keep your code clean - work in such a way that you need not change it when in crisis - Don't panic. Talk with your team. Don't rush. Trust your disciplines. - Offer to pair to others in crisis. ### Chapter 12: Collaboration - Not all but most programmers like working alone. But we need to understand the goals of the surrounding people, including business folks. - This requires **communication**. - Likewise, within the development team: only collective code ownership and pairing produce a good level of communication. - Programming is all about **communication**. ### Chapter 13: Teams and Projects - Teams need time (months) to gel, to really get to know each other and learn to truly work together. - Assigning fractional people to different projects is a bad idea, as is breaking up a good team at the end of a project. - Instead, assigning several projects to one team can work well. ### Chapter 14: Mentoring, Apprenticeship and Craftsmanship - Young programmers need mentoring. - Mentoring can be implicit or explicit. - Given that we entrust software with all aspects of our lives, a reasonable period of training and supervised practice would be appropriate. --- In this lesson, Uncle Bob demonstrates the need to write a clean code and establishes the bases to achieve it, being these bases of a social and scientific nature. Making it clear that the future of programming is based on an ethical and polite code. {{ youtube(id="7EmboKQH8lM") }} --- In this second lesson, Uncle Bob teaches us the purpose of comments in the code, breaking the paradigm that commenting is something "I have to do" for the simple fact that we mistakenly consider that commenting is a good practice. For Uncle Bob, writing a comment is a sign of failure, since a good code must be able explain by itself: Fewer Comments = Better Code. {{ youtube(id="2a_ytyt9sf8") }} --- In this third lesson, Uncle Bob focuses on raising awareness, given the need to increase the level of criteria in code production. Pointing to the lack of preparation in most programmers, as one of the main reasons for the inefficiency in software development today. {{ youtube(id="Qjywrq2gM8o") }} --- In this fourth lesson, Uncle Bob introduces us to a software development methodology oriented through testing. This is the Test-Driven Development (TDD), a practice with a long learning curve, but with significant results to generate a more robust, safer, more maintainable code and with greater development efficiency. {{ youtube(id="58jGpV2Cg50") }} --- ## 97 Things Every Programmer Should Know Date: 2016-07-15 URL: https://chemaclass.com/readings/97-things-every-programmer-should-know/ Tags: software-design, clean-code, career, productivity > Tap into the wisdom of experts to learn what every programmer should know, no matter what language you use. With the 97 short and extremely useful tips for programmers in this book, you'll expand your skills by adopting new approaches to old problems, learning appropriate best practices, and honing your craft through sound advice. Tap into the wisdom of experts to learn what every programmer should know, no matter what language you use. With the 97 short and extremely useful tips for programmers in this book, you'll expand your skills by adopting new approaches to old problems, learning appropriate best practices, and honing your craft through sound advice. ### My main key takeaways 01.- Pay off technical debt as soon as possible. 02.- Learn and master **functional programming**. - It makes your code less prone to error and easier to debug. 03.- Don't guess what a user would do; get users to do things and watch them. 04.- **Automate** coding standards. 05.- Write **simple** code, simple descriptive names, simple relationships. 06.- Before you refactor: consider the existing tests and code. - Work in increments, make sure the tests still pass after every change. 08.- Always leave code **cleaner** than you found it, even if you didn't write it. 10.- Choose your libraries/frameworks carefully to avoid unnecessary complexity. 11.- Make your code easy to understand using **domain** terms. 13.- The **layout** of the code is also important. 14.- Use code **reviews** focusing on knowledge-sharing among team members. 15.- Objects **immutable** whenever relevant. Each variable should have the smallest possible scope. Never include more than four function arguments. 18.- Take **responsibility** for your own education and never stop learning. - That can be done with just a bit of time each week and there are many ways to go about it (e.g. podcasts, lessons, books, etc.). 19.- When designing an API, aim to make it **easy to use**, not convenient to code. 20.- Deploy early and **often**. Do not leave it until the end of the project. 22.- Improving your skills should be on your daily basis. 23.- Adapt the technical level of your domain-specific language to your audience. 24.- **Don't be afraid** to break things if that's what's necessary to fix things. 25.- Careful with your test data because that might go public accidentally. 26.- Handle your errors as they appear, don't leave it for later. 27.- Learn **different** programming languages. - Learn their own "culture" or way of doing things. - It'll make you definitely a better programmer. 28.- Don't just catch your errors, really handle them. 29.- Understand at least some complexities of your business, not just programming. 30.- **DRY**: Don't Repeat Yourself. 32.- Encapsulate behavior, not just state. 33.- Floating point numbers inevitably can create errors in calculations. 34.- **Open source** is a great opportunity to do interesting work and develop programming skills. 36.- Give proper **context** when asking for help, because people can't just guess what's going on. 37.- It's not about the long hours. Learn to **work effectively**. - Dedicate time to continuous learning and to think about what you're doing. 38.- Write proper **bug reports**: - Precisely how to reproduce the bug, - how often it appears, - what should have happened, - what actually happened. 39.- Don't write unnecessary code. - Only write code that adds value and is needed right now. - **Remove dead code**. 41.- The main cause of delays in application response time is a high number of remote **interprocess** communications, not the algorithm. - DB connections, for example. 42.- If a compiler warning shows up in your build, fix it. - Don't leave it for later. Even if it's not going to be a problem in production. - Compiler == any static code analysis for non compiled languages. 43.- Learning to use **command line** tools is a valuable educational experience, and you might end up preferring them. 44.- Learn (at least) two different languages and paradigms well. 45.- Invest some time to **master** the IDE you're using. - It'll make your life easier and save you time in the long run. 46.- Know and work with your limitations: budget, resources, time, etc. 47.- Work in **small tasks**, don't be afraid to throw away changes. - You'll still have the insight you gained from the experience. - Know what you need to accomplish beforehand. 48.- Use a relational DB if your application is going to handle a large, persistent, interconnected set of data. 49.- Learn to **communicate** well in many "languages": not just to your machine, but also to business partners, and maybe even pick up a foreign language too. - It's good for connections and for life. 54.- Think twice before implementing "temporary solutions". 55.- Make **GUI** easy to use correctly and hard to use incorrectly. - Anticipate errors and find ways to prevent them. - It's about the user's experience, not your own. 56.- In projects, find ways to make **the invisible visible**. 57.- Message passing leads to better **scalability** in parallel systems. 58.- Write code that other people can easily **understand**. 59.- Using **polymorphism** in your classes and objects reduces the need for if/else statements, which results in smaller, safer code. 60.- QA is your friend, not your enemy. 61.- Version your releases. 62.- Make sure your source code clearly states what the program is doing. 63.- Learn about the build process. It's an important part of development. 64.- Practice **pair programming**. 65.- Prefer **domain-specific types** over primitive types. - They make the code more readable and less prone to errors in development. 67.- A professional takes **personal responsibility** for their career and their code. 68.- Use version control. 69.- Sometimes the best way to solve a problem is to step away from the computer and let the solution magically appear in your mind. 70.- Reading code is a good way to **learn**. Other people's or your old code. 72.- Reinventing the wheel is a great way to develop your skills. 75.- If the code you wrote is truly horrifying, don't try to fix. **Delete it** and start again. 76.- Apply the Single Responsibility Principle (**SRP**). 77.- If a client or team member requests a product change, don't dismiss it outright even if you don't agree. Ask why instead. - That will lead to a more productive conversation and better results. 78.- If you're doing the same thing over and over, try to find a way to **automate it**. 79.- Take advantage of code analysis tools. 80.- Write tests based on the **desired functionality** of your program, not incidental behavior. 83.- Testing takes time, but it ensures the **quality** of the end product. Do it. 85.- There are many benefits to collaborative work and pair programming. 86.- Sometimes fixing a mistake in the code leads to uncovering a hidden error. 87.- Write code **with other programmers in mind**. 88.- Learn to use Unix tools. Learn how to use the **terminal**. 89.- Use the right algorithm and data structure for the job. - To do that, you need to understand them well. 90.- Have a good logging policy. 91.- Using the DRY principle helps you identify and repair performance bottlenecks. 92.- Testers and programmers should **collaborate**. 93.- Write code as if you had to support it for the **rest of your life**. 94.- Try to write **"small" functions**. 95. Good tests act as **documentation** for the code they're testing. - They describe how the code works. 96. To be a good programmer, you have to care about the **quality** of the code. 97. Really, really **discuss things** with your customers before assuming you understand what they want. --- ## Clean Code Date: 2016-05-01 URL: https://chemaclass.com/readings/clean-code/ Tags: clean-code, software-design, testing, tdd, refactoring > Even bad code can function. But if code isn't clean, it can bring a development organization to its knees. Every year, countless hours and significant resources are lost because of poorly written code. But it doesn't have to be that way. Even bad code can function. But if code isn't clean, it can bring a development organization to its knees. Every year, countless hours and significant resources are lost because of poorly written code. But it doesn't have to be that way. --- ## Summary ### Chapter 1: What Is Clean Code? - The code can be measured with either "good" or "bad" in the code review or by how many minutes it takes you to talk about it. - A clean code should be elegant, efficient, readable, simple, without duplications, and well-written. - You should add value to the business with your code. - Clean code offers quality and understanding when we open the source file. - It is necessary that your code is clean and readable for anyone to find and easily understand. Avoid wasting others' time. ### Chapter 2: Meaningful Names - Names of the classes, variables, and methods must be meaningful and clearly indicate what a method does or what an attribute is. - Create pronounceable names to facilitate communication. - Avoid acronyms and avoid confusing names, which may bring anyone who reads the code to the wrong conclusions. - Use names that reflect the system domain, the context, and the problems that must be solved. ### Chapter 3: Functions - Methods should be easy to read and understand. - Methods should convey its intention. - Methods should be small. - They must have up to 20 lines. - Methods should only do one thing. - You should use names with words that say what it really does. - The optimal number of parameters of a method is zero, after one and two. - Three should be avoided, but if you think it should be used, have a justification. - `Boolean` type as a parameter already states that it does more than one thing. - Avoid duplication. ### Chapter 4: Comments - One of the common reasons for comments is because the code is bad. - If you're thinking about writing a comment, then the code should be refactored. - Comments do not save a bad code. - Try to explain what the code causes happening. - Comments can be useful when placed in certain places. - Don't explain your code with comments. Use informative vars/method names. - Comments can be used to express the importance of certain points. - Do not write comments with redundant, useless, or false information. - They shouldn't be used to indicate who changed or why, use versioning. - Don't comment code that will not be used. Remove it instead. ### Chapter 5: Formatting - Formatting should indicate things of importance since it is a developer of communication form. - A messy code is hard to read. - The readability of the code will take effect on all the changes that will be made. - Smaller classes are easier to understand. - Set a limit of characters per line of code. For example 120. - Try to keep more next related concepts vertically to create a code stream. - Use spaces between operators, parameters, and commas. ### Chapter 6: Objects and Data Structure - Follow the [Law of Demeter](https://en.wikipedia.org/wiki/Law_of_Demeter): - Each unit should have only limited knowledge about other units: only units "closely" related to the current unit. - Each unit should only talk to its friends; don't talk to strangers. - Only talk to your immediate friends. - Do not make dumb objects. - Objects hide the data abstraction and expose methods that operate the data. - Data structures expose your data and do not have significant methods. ### Chapter 7: Error Handling - Error handling should be planned carefully by all programmers. - When wrong things occur, we have to get it to do the right things. - Give preference to launching an exception than treating it just to hide. - Create messages with information about the error. - Mention that it failed. Where was this failure? If possible, mention why it failed. - Look at separate business rules for errors and error handling. - Avoid returning a `NULL` in methods, preferably to return an empty object. - Avoid passing `NULL` to the methods; this can generate `NullPointerExceptions`. ### Chapter 8: Boundary - In third-party code, to avoid passing objects, APIs look forward in order to keep things in the same class. - Perform tests on the API's third party. - Study the documentation and test the third API before you start using it. - Check well the features you will use. ### Chapter 9: Unit Tests - Make sure each piece of code is doing what you expect it to do. - Follow the [TDDs law](https://en.wikipedia.org/wiki/Test-driven_development): - Don't create code before you have a failing test. - Don't create more tests than necessary to fail. - You cannot write more code than enough to pass the test that is failing. - Keep your test clean. - The tests must undergo changes in the same way that the code. - The dirtier the code, the more difficult test will be to maintain. - Use the F.I.R.S.T rule for testing: - The test is fast-running. - The tests are independent of others. - The test is repeatable in various environments. - The test is self-validating. - The test is timely. - The test is as important as the production code. ### Chapter 10: Classes - By default, classes should start with the variables: - Static and constants public. - Static and variable private. - Instances and variables privates. - Soon after comes the functions. - The class name should represent its responsibility. - The class must have only [one responsibility](https://en.wikipedia.org/wiki/Single-responsibility_principle): one reason to change. - You should try to make a brief description of the class. - The methods should be small and one responsibility. --- This interview is based on Uncle Bob's book "Clean Code". They cover some existing guides that can help you become a better programmer and explore how books and current trends are shaping the software landscape. {{ youtube(id="QnmRpHFoYLk") }} # Talks - Full Articles --- ## bashunit URL: https://chemaclass.com/talks/bashunit/ Tags: bashunit, bash, testing, open-source Inspired by PHPUnit, Jest, and others, bashunit is a testing framework for bash scripts. Every developer, at some point, has needed to make a bash script, even the scripts in our pipelines. Now you can write automated tests for them. However, this talk is not simply about bash but about building up a project with standards, strong documentation, and an open roadmap, always keeping quality in mind. We can go from a simple function to an entire OSS project in weeks, thanks to the power of disinterested collaboration. --- - 2025-11-26 | Symfony User Group [**Berlin, Germany**] (EN) - [bashunit: PHPUnit Meets Bash](https://www.meetup.com/sfugberlin/events/312045935/) - 2024-10-29 | Berlin Hack & Tell [**Berlin, Germany**] (EN) - [bashunit in 5 min](https://bhnt.c-base.org/2024-10-29-no100-annivercary) ([Video](https://youtu.be/SX7iNHaSsF0)) - 2024-05-27 | International PHP Conference [**Berlin, Germany**] (EN) - [Bashunit: Testing your bash scripts, inspired by PHPUnit](https://phpconference.com/devops-continuous-delivery/bashunit-testing-bash-scripts/) ([imgs](https://www.linkedin.com/feed/update/urn:li:activity:7201174305655693312/)) - 2023-12-15 | Live interview with Manfred Awards [**Remote**] (ES) - [Winner in the category of Side Project, 2023: bashunit](https://www.youtube.com/watch?v=X0FhUzX-aI4&t=995s) - 2023-11-14 | Live interview with CodelyTV [**Remote**] (ES) - [Live coding with the team behind bashunit](https://www.youtube.com/watch?v=6Bn8gbUurdk) --- ## Gacela Project URL: https://chemaclass.com/talks/gacela/ Tags: gacela, php, architecture, modular Gacela's vision is to simplify the communication of your different modules in your web application, normalising the entry point of a module, without interfering with your domain-business logic. It encourages your modules to interact with each other in a unified way by following a few simple rules. --- - 2023-10-24/26 | International PHP Conference [**Munich, Germany**] (EN) - [Building modular applications in PHP with Gacela](https://phpconference.com/software-architecture/modular-applications-php-gacela/) ([imgs](https://www.linkedin.com/feed/update/urn:li:activity:7127206712805056513/)) - 2023-05-24/25 | International PHP Conference [**Berlin, Germany**] (EN) - [Building modular applications in PHP with Gacela](https://phpconference.com/software-architecture/modular-applications-php-gacela/) - 2022-02-24 | PHP Madrid Community [**Remote**] (ES) - [Gacela Framework 0.1](https://www.meetup.com/phpmad/events/284069182/) - 2022-01-25 | Spryker Digital User Group [**Remote**] (EN) - [Gacela Framework 0.1](https://www.meetup.com/spryker-user-group/events/282267564/) --- ## Hands-on Refactoring and TDD URL: https://chemaclass.com/talks/hands-on-refactoring-tdd/ Tags: tdd, refactoring, live-coding, pair-programming, workshop What are code katas? Have you ever wondered what a pair/mob programming session truly looks like? Join us for a live coding session that dives deep into test-first development and refactoring techniques, where you'll witness collaborative problem-solving firsthand. Together, we'll tackle a code kata from scratch, navigating the challenges and rewards of building cleaner, more robust code as a team. --- - 2026-10-26 | International JavaScript Conference [**Munich, Germany**] (EN) - [Full-day Workshop: Modernizing Legacy Code with Pair Programming](https://javascript-conference.com/munich/program-munich/) - 2026-06-08 | International PHP Conference [**Berlin, Germany**] (EN) - [Full-day Workshop: Modernizing Legacy PHP with Pair Programming](https://phpconference.com/php-core-coding/refactoring-workshop-modernizing-legacy-php-pair-programming/) - 2025-10-27 | International PHP Conference [**Munich, Germany**] (EN) - [Full-day Workshop: Modernizing Legacy PHP with Pair Programming](https://phpconference.com/php-core-coding/refactoring-workshop-modernizing-legacy-php-pair-programming/) - 2025-08-21 | International PHP Conference [**Remote**] (EN) - [Preview 1h: Refactoring Workshop](https://phpconference.com/php-core-coding/refactoring-workshop-modernizing-legacy-php-pair-programming/) - 2025-05-03 | International PHP Conference [**Berlin, Germany**] (EN) - [Solving a Testing & Refactoring Kata: Live Coding in Pair/Mob Programming](https://phpconference.com/slideless-pure-coding/testing-refactoring-kata-live-coding-pair-mob-programming/) - 2024-05-30 | International PHP Conference [**Berlin, Germany**] (EN) - [Practical TDD Workshop: Collaborative Pair Programming](https://phpconference.com/agile-culture/practical-tdd-workshop/) ([imgs](https://www.linkedin.com/feed/update/urn:li:activity:7200844992779567104/)) - 2024-03-14 | devm.io [**Remote**] (EN) - [Test Driven Development: A Hands-on Crash Course](https://devm.io/live-events/test-driven-development-a-hands-on-crash-course/) --- ## How to improve your tech talk URL: https://chemaclass.com/talks/how-to-improve-your-tech-talk/ Tags: speaking, presentations How can you start getting on a stage and talking to 5, 50, 500, or even more people? As part of your identity, sharing knowledge is a powerful tool to improve your skills. For this reason, I looked for opportunities to discover what is required for a person to stand up and talk in front of hundreds of people like a regular speaker at any conference. After some years of speaking at different events, remote and in-person meetings, meet-ups, and international conferences in other countries, I want to share my learnings. --- - 2024-11-21 | Internal talks at Purpose Green [**Berlin, Germany**] (EN) - How to improve your Tech Talk - Applies to any presentation - 2024-06-18 | Internal talks at HeyJobs [**Remote**] (EN) - How to improve your Tech Talk - Applies to any presentation [[slides](https://docs.google.com/presentation/d/1v-bMvFSR-cXtAi7MtafoTh-qEXBkH3_6wPId0ZNTv0s/view)] --- ## Phel Lang URL: https://chemaclass.com/talks/phel/ Tags: phel, php, functional-programming, lisp Phel is a functional programming language that compiles into PHP. It is a dialect of Lisp inspired by Clojure and built on PHP's ecosystem. Among other features, it has persistent data structures (Lists, Vectors, Maps, and Sets), macros, recursive functions, and a REPL. This talk covers the basics of Phel and includes a live coding demo showing its potential. --- - 2026-10-27 | International PHP Conference [**Munich, Germany**] (EN) - [Running DOOM in PHP with Phel](https://phpconference.com/php-core-coding/running-doom-php-phel/) [[slides](/slides/phel-doom/)] - 2026-06-09 | International PHP Conference [**Berlin, Germany**] (EN) - [Writing Lisp in PHP: A Journey with Phel](https://phpconference.com/php-core-coding/lisp-in-php-phel/) [[slides](/slides/phel-doom/)] - 2025-10-27 | International PHP Conference [**Munich, Germany**] (EN) - [From $this to (this): A Gentle Introduction to Phel](https://phpconference.com/web-development/phel-introduction-functional-programming-lisp/) - 2023-10-24/26 | International PHP Conference [**Munich, Germany**] (EN) - [Introducing Functional Programming in PHP with Phel](https://phpconference.com/php-core-coding/phel-language-a-native-lisp-for-php/) - 2023-07-28 | WeAreDevelopers World Congress [**Berlin, Germany**] (EN) - [Phel, a native Lisp for PHP](https://www.wearedevelopers.com/world-congress) [[slides](https://docs.google.com/presentation/d/1Zc3zxz9VIujh43enXhgTgvm2kCz9aQKSU1nsrtL_HEs)] ([imgs](https://www.linkedin.com/feed/update/urn:li:activity:7091038575588200448/)) - 2023-05-27 | PHPers Summit [**Poznan, Poland**] (EN) - [Phel Language, a native LISP for PHP](https://phpers.pl/) - 2023-05-24/25 | International PHP Conference [**Berlin, Germany**] (EN) - [Phel Language, a native LISP for PHP](https://phpconference.com/php-core-coding/phel-language-a-native-lisp-for-php/) - 2023-04-19 | PHP Madrid Community [**Remote**] (ES) - [Programación funcional en PHP (presentando Phel Lang)](https://www.meetup.com/phpmad/events/292576962) - 2023-03-28 | Berlin Hack & Tell [**Berlin, Germany**] (EN) - [Phel in 5 min](https://www.meetup.com/Berlin-Hack-and-Tell/events/292379070) ([Video](https://youtu.be/ZQTann9ItH8)) ([imgs](https://www.linkedin.com/feed/update/urn:li:activity:7046766759197999104/)) - 2022-11-10 | Software Crafters Madrid [**Remote**] (ES) - [Phel, a native LISP for PHP](https://www.meetup.com/madswcraft/events/289206891/) - 2022-06-23 | DesarrolloWeb [**Remote**] (ES) - [Phel Language ¿Programación funcional para PHP?](https://www.youtube.com/live/9pElbTEcyGA) --- ## Update your team to be more extreme URL: https://chemaclass.com/talks/update-your-team-to-be-more-extreme/ Tags: agile, xp, team-culture Our profession is constantly evolving; therefore, it demands a non-stop learning process. Embracing change is not optional in the software industry. We need to create spaces to get out of our comfort zone, so our cognitive brain can train and improve how to adapt to our surroundings, which are constantly transforming. A solution for this could be by integrating internal tech talks or katas, which provide the team with a great opportunity to have fun while learning and sharing knowledge between team members. --- - 2023-07-28 | WeAreDevelopers World Congress [**Berlin, Germany**] (EN) - [An Introduction to Extreme Programming](https://www.wearedevelopers.com/world-congress) - 2023-01-19 | devm.io [**Remote**] (EN) - [An introduction to Extreme Programming](https://devm.io/update-your-team-to-be-more-extreme/) - 2022-12-21 | IES Ginés Pérez Chirinos [**Murcia, Spain**] (ES) - Actualiza tu equipo para ser más extremo - 2022-10-26 | International PHP Conference [**Munich, Germany**] (EN) - [Update Your Team to be More Extreme](https://phpconference.com/mixed/update-your-team-to-be-more-extreme/) - 2022-09-16 | Code Talks [**Hamburg, Germany**] (EN) - [Update Your Team to be More Extreme](https://codetalks.de/) - 2022-06-26 | International PHP Conference [**Berlin, Germany**] (EN) - [Update Your Team to be More Extreme](https://phpconference.com/mixed/update-your-team-to-be-more-extreme/) ### WeAreDevelopers World Congress in Berlin (July 2023) {{ youtube(id="dqtAyl-SvaY") }} ## Related posts - [Update your team to be more extreme](/blog/update-your-team-to-be-more-extreme/) How can you help your peers to embrace the change? --- Total: 170 entries Last generated from source at build time.