Chemaclass

Inside the .claude Folder

2026-04-17T00:00:00+00:00

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

.claude/
├── CLAUDE.md # project onboarding
├── settings.json # permissions, hooks, env
├── skills/ # reusable procedures (slash commands)
├── rules/ # glob-targeted conventions
├── hooks/ # shell scripts run on events
└── agents/ # specialized roles

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, 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.

{
 "permissions": {
 "allow": [
 "Bash(composer:*)",
 "Bash(./bin/phel:*)",
 "Bash(git:*)",
 "Bash(gh:*)"
 ],
 "deny": [
 "Bash(rm -rf:*)",
 "Bash(sudo:*)"
 ]
 }
}

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 <number>: issue to branch, TDD plan, PR.
/commit: fix, analysis, tests, conventional commit.
/refactor-check: SOLID, naming, architecture smells.
/release [version]: changelog, PHAR, tag, release.

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.

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.

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.

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.

{
 "hooks": {
 "PreToolUse": [{
 "matcher": "Edit|Write",
 "hooks": [{ "type": "command", "command": ".claude/hooks/protect-files.sh" }]
 }],
 "PostToolUse": [{
 "matcher": "Edit|Write",
 "hooks": [{ "type": "command", "command": ".claude/hooks/format-php.sh" }]
 }]
 }
}

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:

Start with CLAUDE.md.
Lock down settings.json permissions.
First time you repeat yourself, write a skill.
First time the agent breaks a convention, add a rule.
First time something bad almost gets committed, add a hook.
First time a generalist is wrong for the job, define a specialist.

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

2026-04-05T00:00:00+00:00

Hidden inside Sauron’s blog, 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. 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.

The Shire: gentle patrols, soft music
Mines of Moria: you can only see within a torch radius; the Balrog waits
Lothlórien: Galadriel’s mirror slows you when you approach it
The Dead Marshes: dead faces in the water, Gollum at his most present
The Black Gate: industrial Mordor, heavy orc patrols, volcanic sky
Shelob’s Lair: a shadow telegraphs her drop; you have half a second
Minas Morgul: undead city, the Eye never closes
Pelennor Fields: the Eye distracted by war, catapults, eagles overhead
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. 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.

The Art of Being Happy

2026-03-15T00:00:00+00:00

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.

Idealism vs Pragmatism

2026-03-01T00:00:00+00:00

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, 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. 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 found TDD reduced defect density by 40-90%, with a 15-35% increase in development time. Both sides of the tension, measured.

The study 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.

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.

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, 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.

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 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.

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 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.

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, 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, 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, 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 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.

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.

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

2026-02-07T00:00:00+00:00

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, I covered how to give your AI agent access to your environment. In 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.

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.

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.

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.

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.

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.

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:

{
 "env": {
 "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
 }
}

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.

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.

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.

claude --worktree --tmux

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.

---
isolation: worktree
---

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, 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.

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.

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: 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 | claude.com
Claude Code: Agent Teams | claude.com
Claude Code Tips: Workflow Boosters | rfrolov.me

Notes from Underground

2026-02-04T00:00:00+00:00

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.

Broken Money

2026-01-17T00:00:00+00:00

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.

MCP: Giving Your AI Agent the Right Context

2026-01-11T00:00:00+00:00

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:

{
 "mcpServers": {
 "filesystem": {
 "command": "npx",
 "args": ["-y", "@modelcontextprotocol/server-filesystem", "./"]
 },
 "github": {
 "command": "npx",
 "args": ["-y", "@modelcontextprotocol/server-github"],
 "env": { "GITHUB_TOKEN": "your-token" }
 },
 "postgres": {
 "command": "npx",
 "args": ["-y", "@modelcontextprotocol/server-postgres"],
 "env": { "DATABASE_URL": "postgresql://localhost/mydb" }
 }
 }
}

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. 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

2025-12-22T00:00:00+00:00

This post explains how Bitcoin works under the hood. If you’re looking for why Bitcoin matters, start with Bitcoin Fundamentals.

For the technically curious.

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.

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.

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.

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.

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:

Hashing the transaction data
Creating a signature using the private key
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

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:

Secures the network: Rewriting history means redoing all hash work
Issues new coins: Following a predictable schedule (halving every 210,000 blocks)
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.

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.

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.

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.

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, 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:

Your wallet sends it to connected nodes
Each node validates and forwards to its peers
Within seconds, the transaction reaches most of the network
Miners include it in their candidate blocks

Blocks propagate similarly. When a miner finds a valid block, it spreads across the network in seconds.

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.

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.

Satoshi’s whitepaper includes the probability calculation. With an attacker controlling fraction q of hashpower:

If q < 0.5: Probability of catching up decreases exponentially with each confirmation
At 6 confirmations with q = 0.1 (10% hashpower): Success probability < 0.1%

The “6 confirmations” rule assumes a well-funded attacker with substantial but minority hashpower. For smaller transactions, fewer confirmations are often acceptable.

Finality in Bitcoin is probabilistic, not absolute. But after enough confirmations, the probability of reversal approaches zero for any realistic attacker.

Incentive Alignment

Bitcoin isn’t just a clever technology. It’s a system where every participant’s self-interest reinforces the network.

Miners invest in hardware and electricity. They only profit by producing valid blocks. Cheating wastes their investment because nodes reject invalid blocks instantly.
Nodes enforce the rules to protect their own holdings. A node operator who accepts invalid transactions devalues their own bitcoin. Self-interest makes them honest validators.
Users pay fees to get transactions processed. Higher fees mean faster confirmation. This creates demand for block space and funds network security.
Developers contribute to software they themselves use. Bugs hurt their own holdings. Improvements benefit everyone, including them.
Holders benefit from network security and adoption. The more secure and useful Bitcoin becomes, the more valuable their holdings. They’re incentivized to support the ecosystem.

No central coordinator. No trust required. Everyone acts in their own interest, and the system benefits everyone.

“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.

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.

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:

Alice wants to pay Carol through Bob
Carol generates a secret and gives Alice the hash
Alice creates an HTLC: “Bob gets paid if he reveals the secret within 24 hours”
Bob creates a similar HTLC with Carol
Carol reveals the secret to Bob, claiming payment
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.

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.

Bitcoin’s technical depth goes far beyond what fits in one post. Here are topics worth exploring if you want to go deeper:

SegWit (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 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: 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: 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: 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: 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.

Chapter 30: December, 2025

2025-12-09T00:00:00+00:00

Nine Branches

Eleven years later

December 2025. It’s cold outside. The kind that cleans your face and forces you to wake up.

Eleven years later, I still think about that twenty-one-year-old kid who took a flight to Lübeck without understanding what it would cost. I’m not talking about the language—an English to survive and no German at all. I’m talking about everything else: the loneliness, the fear, the freedom, the people who save you without knowing it.

It wasn’t bravery. It was urgency.

I left my city because staying was no longer an option. There was no future there. Only a past I needed to forget. And Germany, back then, was a door I couldn’t let pass.

In Lübeck I spent six months working for three hundred euros a month. I lived off my savings from my job in Murcia.

Poor, but happy.

Meeting wonderful people, searching every corner to learn, expand horizons, practice languages.

After those first months I decided I had to move. The company where I started was the typical one that paid you the minimum to exploit you to the maximum, with obsolete technologies. I felt that if I didn’t move, I would end up becoming obsolete myself.

So, after three months of intense searching, I found a job in Berlin and moved with what I had. The first days I slept on the sofa of Alberto and Maricarmen, some friends from the village choir where I spent a summer years before.

From there on, everything was adventure. At a speed I never would have imagined if I hadn’t left my city.

In 2015 I started writing as a way to communicate with my siblings from a distance. What began as loose thoughts ended up becoming a two-year diary.

I wrote in April: “I miss my family. Although I’ll see them in less than thirty days, I’m starting to get used to the idea of seeing them twice a year. And, honestly, it’s hard. Being the oldest of a whole troop means that, without intending to, one is responsible. We need to be examples.”

Eleven years later, those words are still true. We see each other once or twice a year: at Christmas and at the May festivals. I’ve learned to savor every minute when we’re together. It’s not always easy. But time is the ultimate equalizer; the color of ideological or political garments doesn’t matter. What I value most is effort, saving, hard work. That teaches us to appreciate what we achieve.

Nine different companies. Seven of them in Germany. I’ve stumbled and gotten up, always from sanity without reaching absurdities.

I’ve managed to grow both personally and professionally, opening all kinds of horizons. I’m proud of the person I’ve become.

But none of this would make sense without you.

And to understand the present, sometimes you have to look at the past. Even if it hurts.

Where we come from

I won’t lie: we had a complicated youth. A youth that left marks on all of us. Each one carries them in their own way, some more visible than others.

But here we are. Standing.

Mom left too soon.

She would be fifty-eight years old today. Forty-nine when I wrote “Numbers,” that May 25, 2016. Thirty-seven when she left.

I was eleven years old.

I don’t remember when was the last time I said “mom.” I only remember her curly hair and her kind smile behind the door frame late at night. No time to say goodbye. No time for anything.

Dad was left alone with eight kids. The oldest sister was thirteen years old. And the youngest, two weeks.

Life forced him to move forward as best he could. And he did. Not always well, but he did.

Years later came the castle. That duplex where the seven of us ended up relegated to the garage, like a backyard. With a lock on the door. Forbidden to go up to the main rooms except to eat or sleep.

The disputes. The confrontations. The storms.

Maricarmen was sent to study far away. I was the next target. Dad overwhelmed not knowing what to do.

That was a hell I barely want to remember.

Until one day we returned to the apartment where we had grown up with mom. Our home. Do you know what it’s like to wake up on a weekend, see that it’s daytime and it’s raining, and be able to stay in bed? A memory of joy I will never forget.

But you already know that. You lived it with me. I barely keep clear memories of those teenage years. My mind did its job well: it erased as much as it could to help me heal. Maybe someday they’ll come back. Maybe it’s better if they don’t.

Dad, our relationship was difficult.

The era and context in which we had to live and confront each other didn’t help us. There were years of silence, of accumulated resentment, of words that weren’t said and others that were said too much.

But today the situation seems to have calmed down. We came to forgive each other. We talk to each other from time to time again. And that, after everything we’ve been through, is more than many achieve.

It’s not perfect, but it’s real. And the real has more value than any impossible ideal.

From such a murky past, I feel fortunate not to have ended up on any other path than this one: mine. And when I say “mine,” I mean ours. Because we all come from the same place, from the same walls, from the same sky of Caravaca.

Nine branches

Eight siblings from the same father and the same mother. Eight branches that grew together. And a ninth that came later. Nine in total. From the same tree, each one seeking its own sun.

Maricarmen, the oldest sister, who had to learn to be a mom very early. When she could, she latched onto Belgian lands and there she is now, with two children and a future to make.

I never thanked her enough for those years when she carried responsibilities that weren’t hers. She was a girl taking care of children. And she did the best she could.

Now it’s her turn to build her life. The one she chose. The one she deserves.

Juan, perhaps the one who has suffered the most. The past played bad luck on him and he has had to learn through many blows. Life has been especially unfair to him in many ways.

And so was I. As children I was a bully to him. I hurt him and that’s something I carry with me.

I hope he knows how to forgive me. I hope he doesn’t forget that I’m here for whatever he needs.

Fortunately, very recently, he found his place. He still has everything ahead of him. Few have the ability to get up after falling so many times.

Jesús, the one who seems to have the calmest temperament. He learned to surpass the storms of the castle without attracting too much attention. It fills me with pride to see who he is and what he has become: a speaker at international conferences and a fundamental help in the open source projects we have together.

We live close in Berlin and seeing him from time to time reminds me what it means to have family. I really enjoy when we meet to take walks through immense parks, walking for hours until the light goes away.

Thank you for those moments. Talking to you in person and knowing you’re there is a gift.

Ángel, the math teacher. One of the smartest in the family, without a doubt. As a child, he underwent an operation in which he almost completely lost one ear. But he overcame it, as he always has.

Calm, humble, he never liked to attract attention. And he’s always there when a sibling needs him.

And that’s worth more than any degree.

A clear example of commitment and passion for his work. He knew how to take advantage of opportunities as they came. Proof that effort yields wonderful fruits.

Lola, fighter and sensitive in equal parts. It’s impossible to deny what she lived through, how bad she had it as a child. She is perhaps one of those who have had the hardest time.

But you have to see her today.

Although we have different thoughts in some aspects, we can understand each other perfectly when it comes to humanity, help, family. And that’s what counts.

From the girl who suffered, a woman who helps others suffer less has been born.

That’s turning pain into purpose.

Cosme, the little one who now programs like the big ones. He also had a difficult childhood without understanding what was happening or what surrounded him. We all disappeared when he was still a child. That lack of affection left its mark.

Empathy is hard when, as a child, you don’t receive it. But he’s learning. And that’s what counts.

Fortunately he found his passion where I also found it: in software. I was able to guide him as an older brother, help him with all my being, just as I did with Jesús and later would do with Juan.

Watching him grow professionally has been one of my greatest satisfactions.

Anica, the youngest, the smartest. She has known how to turn rage into strength. Sharp and quick-witted like few others. And to think that not long ago she hated sports…

Perhaps it was my passion for boxing that I managed to transmit to her. Today she is a gym trainer, competes in weightlifting and runs ten kilometers from time to time.

It moves me to see her compete and help others. I really enjoy going with her for a sibling walk or to shop at Lidl.

Those simple moments are worth a lot.

Transmitting passion is one of the best inheritances one can leave. And she has made it her own.

And lastly there’s Antonio. Another branch, but from the same father. From the same tree after all.

We’ve barely seen each other a couple of times in our lives. He was lucky to arrive when the waters were already calmer. He has his whole life ahead of him to study, grow as a professional, and be whoever he wants to be.

And if someday he gets curious about those past thoughts, there’s a book I published in 2017 waiting for him.

Nine branches seeking their own sun. Nine ways of surviving the same past. Nine ways of moving forward.

The uncles

But family isn’t just siblings.

There are also those who have always been there, in good times and bad: the uncles from Caravaca. My uncle Cosme and my aunt Angustias.

You have always been there. For me and for all my siblings. To talk. To listen. To say what we needed to hear.

You were also there during that castle era. I’m not going to go there. I just want to tell you that your affection in those years helped me immensely.

But this time, I prefer to keep another memory.

I remember when I was fired from my first company in Berlin, after a little over a year. From one day to the next. Something smelled off to me, but I didn’t want to believe it. Looking back, I also made mistakes more than once.

“You got complacent,” uncle Cosme told me on the phone when I got to my apartment.

That word stuck with me. He was right. I had settled.

With my savings I could have held on for a few months. But then what? What if I didn’t find work? The uncertainty forced me to look at myself straight on and recognize my mistakes.

It was time to focus and surf the waves. Two weeks into searching—getting up at eight and not letting go of the laptop until five—I found work.

I couldn’t give up. And I didn’t.

And that’s just one memory of many. The long calls. The advice without asking. The feeling of having someone who always listens.

Thank you, uncles. For being there. For being that anchor that has always been in Caravaca waiting.

I love you.

Anna-Lena

And then there’s her. The one who appeared when I least expected it.

We met at a beer bar, among strangers, on any given night.

From the moment I saw you come in, we were talking for hours until you had to leave.

Then we started going to the cinema together, to other bars, to walk. And in the end we started seeing each other almost daily. A year later we decided to live together.

In February 2026 it will be eight years. Eight years building something together, day by day, without rush but without pause.

Thank you for being there. For putting up with me. For loving me as I am. For being my home in Berlin.

Because in the end, that’s what matters: having someone to share the journey with.

The most important thing

Eleven years are enough for a lot. To fall and get up. To get lost and find yourself. To learn that life is movement and that the key is knowing how to surf each stage.

Nobody said it was easy. And when you can’t take anymore, well, time for a well-deserved rest.

The future is uncertain, but what is universal is that our life is finite. I’m not talking about living as if there’s no tomorrow, but about not forgetting that time moves forward.

Ten years ago, in December 2015, I decided to spend Christmas alone in Berlin. I had no friends then. I didn’t do anything special those days.

I felt very alone.

From there dark thoughts were born that were captured in “Eyes on a Memory.” That year, 2016, was quite intense. I spent January writing two to four hours almost every day.

I think my body and mind were trying to tell me something. They needed to express themselves.

What joy to have created a book. Another project, another of so many already completed and those yet to be done.

Small victories that sweeten the effort.

But no victory tastes the same if there’s no one to celebrate it with.

And you are that someone: Dad. Maricarmen. Juan. Jesús. Ángel. Lola. Cosme. Anica. Antonio. Uncle Cosme. Aunt Angustias. And Anna-Lena.

You are the branches—and the roots—of this tree that I continue to be.

Physical distance doesn’t diminish love. The few times we see each other a year don’t reduce what you mean to me.

Thank you for being who you are. Thank you for still being there. Thank you for forgiving when forgiveness was needed. Thank you for getting up every time life knocked you down.

I’m proud to belong to this family.

And although time passes and each one follows their path, we will always be from the same tree. Mom is still here, in each one of us.

We will always be branches seeking our own sun.

With eyes on a memory, looking forward.

Work. Love. Dream. Smile.

But together.

Bitcoin Fundamentals

2025-11-21T00:00:00+00:00

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:

Direct trade: Exchanging goods for goods. “I’ll give you my fish for your bread.”
Things used as money: Shells, salt, cattle. Valuable because they were useful or hard to find.
Precious metals: Gold and silver. Hard to find, long-lasting, easy to divide and carry.
Paper money backed by gold: Receipts representing gold stored in vaults.
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. No one knows who this person really is.

The first Bitcoin block (the 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 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.

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.

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:

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—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. 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. 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 (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, 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)
Strategy holds 660.000+ BTC as corporate treasury, inspiring others (source)
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)
Switzerland allows tax payments in Bitcoin in Canton Zug since 2021 (source)
Emerging markets lead in grassroots adoption: Vietnam, Philippines, Nigeria

Real-world usage

Square accepts Bitcoin payments since Nov. 2025 for 4M+ merchants (source)
Lightning Network (LN) processes millions of instant payments monthly (source)
Merchants worldwide accept Bitcoin, from small shops to major retailers (source)

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:

Start small: Buy a small amount on a trusted Bitcoin-only platform like:
- 21bitcoin or Relai: Simple apps for automatic Bitcoin savings
- HodlHodl: Peer-to-peer trading, non-custodial
Move it to your own wallet: Download a mobile wallet and transfer your Bitcoin there. Feel what self-custody means. Some wallets like BlueWallet, Nunchuk.
Send a transaction: Send some sats to a friend. Watch it confirm in ~10 minutes. Get curious looking at your transaction in the mempool.
Try Lightning: Send an instant, near-free payment. This is the future of everyday transactions. Some LN wallets like Alby Go, Muun.

You don’t have to go all in. Start small and keep learning, one step at a time.

Further reading

Bitcoin 101 by Cosme - Another beginner-friendly introduction
How to Buy Bitcoin Securely by Cosme - Step-by-step guide

AI Gives You Speed, Not Quality

2025-10-10T00:00:00+00:00

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, 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 and 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 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, 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

2025-09-15T00:00:00+00:00

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, 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 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, 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. 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?” 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 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 this question and inspiring this reflection.

Principles of Economics

2025-06-22T00:00:00+00:00

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) 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

Ship, Show, Ask

2025-04-12T00:00:00+00:00

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—just 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, 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

In my experience, it helps to 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.

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 (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 simply 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 just branching hygiene.

To me, it’s about building a culture of clarity, accountability, and trust—where developers are empowered to move fast while staying thoughtful.

If you’re tired of slow PR queues and over-engineered approvals, this might be worth a try.

Curious to dive deeper? Check out Rouan Wilsenach’s post.

The Road to Serfdom

2025-03-31T00:00:00+00:00

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.

Run Your LN Node on a Raspberry Pi

2025-02-17T00:00:00+00:00

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’s fundamental concepts.
I assume you know how the 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 is a free, open-source (ideally private) 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!)
- 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 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, remember it ended up with .local:

ping testhub.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:

# Source code: https://github.com/getAlby/hub/tree/master/scripts/pi-aarch64
ssh testhub@testhub.local '/bin/bash -c "$(curl -fsSL https://getalby.com/install/hub/pi-aarch64-install.sh)"'

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 for the username.

4. Alby Hub Setup

Wait another 2-3 mins and visit your host: http://testhub.local/

Your Alby hub is now running. Let’s connect it to your GetAlby account!

Creating a GetAlby Account

🔗 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. 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 - mind the KYC…

Using Your Sats

After that, you will be able to use it via the Alby Extension or the AlbyGo.

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 ;)

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

ssh testhub@testhub.local '/bin/bash -c "$(curl -fsSL https://getalby.com/install/hub/pi-aarch64-update.sh)"'

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

Digital Minimalism

2025-02-16T00:00:00+00:00

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, we can reclaim our time, improve our well-being, and refocus on what truly matters.

Video Summary

Cal Newport interviewed by Lex Fridman

Criptoria

2025-02-09T00:00:00+00:00

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 links

Book website: www.prometeabtc.com/criptoria

Bitcoin with Rigor

2025-01-18T00:00:00+00:00

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

Related links

Book website: www.bitcoinconrigor.com

Understanding Taxes

2025-01-02T00:00:00+00:00

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.

Tax journey 101
Types of Taxes
How do they work?
Why do we pay taxes?
A new perspective

Tax journey 101

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.
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.
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.
When you transfer or inherit:
- Transfer Tax: Applied to purchases like second-hand properties.
- Inheritance/Gift Tax: Payable on inherited assets or large gifts.
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.
When you use services:
- Local Fees: For waste collection, car registration, or building permits.
- Tourism/Travel Tax: For lodging or certain tourist-related services.
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

2024-12-11T00:00:00+00:00

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

To create and promote tools for encryption, anonymity, and digital cash.
To educate the public on the importance of cryptography.
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 for faster, private transactions and Taproot for enhanced transaction privacy, Bitcoin continues to evolve.

Conclusion

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.

Related links

Learn more: What is PGP encryption? A 3-minute tutorial for beginners
Wikipedia Article: wikipedia.org/Cypherpunk

Man's Search for Meaning

2024-11-29T00:00:00+00:00

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 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

Verified Git Commits

2024-11-17T00:00:00+00:00

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) 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:

gpg --full-generate-key

Find your key ID:

gpg --list-secret-keys --keyid-format=long

Tell Git to use your key:

git config --global user.signingkey <your-key-id>

Make signing commits the default:

git config --global commit.gpgsign true

Add your key to GitHub/GitLab

Export your public key:

gpg --armor --export <your-key-id>

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:

git commit -S -m "Your commit message"

You can verify the commit signature with:

git log --show-signature

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 🇪🇸

Related links

Learn more: What is PGP encryption? A 3-minute tutorial for beginners

bashunit

2024-10-30T00:00:00+00:00

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.

The story behind bashunit
Why create another testing library?
How is it nowadays?
Core features
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) 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) 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.

I decided to separate the assert function from the test cases, as shown here, 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. This structure made automated testing easier and refactoring safer.

This was a great improvement because it made it easier to separate test cases 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:

## Follow-up idea
Separate the testing logic into another repo, 
so it could be reused anywhere.

And so it began. 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, which featured a working runner and a single assertion function: assertEquals. Later, version 0.2 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.

How is it nowadays?

Today, you can install bashunit via curl, Homebrew, MacPorts, by downloading the latest GitHub release from GitHub, or even by building it yourself 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 that run tests on different platforms to check compatibility and confirm everything works as promised.

In June 2024, bashunit was integrated in PHPStan 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 in Berlin, alongside Manu, 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 and configuration values. Some of my favorites include:

--parallel
--filter
--stop-on-failure
--verbose

We also provide data providers for running the same test cases with different inputs.

For 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 is included, making it easy to verify command or script outputs over time.

bashunit offers a large set of native 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 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!

bashunit original logo designed by Antonio.

People Skills

2024-09-02T00:00:00+00:00

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.

Bitcoin: A Work in Progress

2024-08-02T00:00:00+00:00

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.

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

Related links

Book source code: GitHub/Sjors
Book website: www.btcwip.com

What Is Waterfall?

2024-08-01T00:00:00+00:00

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.

Where can you start?

As a developer, you can boost your agility by diving into pair programming and TDD.

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.

The key is collaboration, baby steps, and quick feedback on everything you work on.

My experience with Agile

I’ve talked 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 [Berlin, Germany] (EN)
2022-09-16 | Code Talks [Hamburg, Germany] (EN)
2022-10-26 | International PHP Conference [Munich, Germany] (EN)
2022-12-21 | IES Ginés Pérez Chirinos [Murcia, Spain] (ES)
2023-01-19 | devm.io [Remote] (EN)
2023-07-28 | WeAreDeveloper World Congress [Berlin, Germany] (EN)

WeAreDevelopers World Congress in Berlin

Pretty Good Privacy

2024-07-13T00:00:00+00:00

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 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.

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 and symmetric-key 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.

My public key

Fingerprint

56D5 D60B 0934 0999 199C 3750 E51B 5BF4 5F85 D160

Import directly

curl https://chemaclass.com/pgp.asc | gpg --import

Download the .asc file

Download public PGP key

Programmable Money

2024-07-06T00:00:00+00:00

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. 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.

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) 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)

Operation Codes

Bitcoin’s Script performs specific operations within transactions with its OP_Codes. 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: 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: Earliest legacy transactions using full public keys directly.
P2PKH: Begins with 1. Legacy transactions using public key hashes.
P2SH: Begins with 3. Legacy, encapsulates complex scripts like multisig.
P2MS: It is typically a type of P2SH or P2WSH address.
P2WPKH: Begins with bc1. Native SegWit, more efficient transactions.
P2WSH: Begins with bc1. SegWit for complex scripts.
P2TR: 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

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

Begins with "1" (e.g., 1A1zP1eP5QGefi2DMPTf...v7DivfNa)

A typical P2PKH script consists of two main parts:

ScriptPubKey: The locking script (also known as the output script) that specifies how funds can be spent.
ScriptSig: The unlocking script (also known as the input script) that provides the necessary data to unlock the funds.

ScriptPubKey (Locking Script)

OP_DUP OP_HASH160 <PubKHash> OP_EQUALVERIFY OP_CHECKSIG

OP_DUP: Duplicates the top stack item (the public key).
OP_HASH160: Hashes the public key with SHA-256 followed by RIPEMD-160.
<PubKHash>: 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)

<sig> <PubK>

<sig>: The digital signature generated by the private key.
<PubK>: The public key corresponding to the address.

Execution Flow

The ScriptSig (unlocking script) is pushed onto the stack.
The ScriptPubKey (locking script) is executed.

P2SH (Pay-to-Script-Hash) up

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 <ScriptHash> OP_EQUAL

OP_HASH160: Hashes the script with SHA-256 followed by RIPEMD-160.
<ScriptHash>: The hashed script (a 20-byte value).
OP_EQUAL: Checks if the hash matches the provided script hash.

ScriptSig (Unlocking Script)

<sig> <PubK> ... <ScriptSig>

<sig>: The digital signature.
<PubK>: The public key.
<ScriptSig>: The actual script that matches the script hash, which itself will be executed by the Bitcoin network.

P2MS (Pay-to-Multisig) up

Script Format

OP_M <M> <PubK1> <PubK2> ... <PubKN> OP_N OP_CHECKMULTISIG

OP_M: The minimum number of signatures required.
<PubK1>, <PubK2>, ..., <PubKN>: 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)

OP_2 <PubK1> <PubK2> <PubK3> OP_3 OP_CHECKMULTISIG

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)

<sig1> <sig2> ... <sigN> <SerializedScript>

<sig1>, <sig2>, ..., <sigN>: The public keys.
<SerializedScript>: 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

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 OP_PUSHBYTES_20 <PubKHash>

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.
<PubKHash>: 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.

<sig> <PubK>

<sig>: Digital signature for the transaction.
<PubK>: Public key used to generate the public key hash.

P2WSH (Pay-to-Witness-Script-Hash) - Segwit up

Begins with bc1q (e.g.: bc1q4a3h5sdg4cfkhftgd24tj9g2sg...yj57jmfckhkrw5gslr9g59)

ScriptPubKey (Locking Script)

OP_0 OP_PUSHBYTES_32 <ScriptHash>

OP_0: Indicates a witness version 0 (SegWit).
OP_PUSHBYTES_32: Pushes the next 32 bytes (the script hash) onto the stack.
<ScriptHash>: 32-byte hash of the redeem script.

Witness Data

<sig1> <sig2> ... <RedeemScript>

<sig1>, <sig2>: Signatures required to unlock the transaction.
<RedeemScript>: 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

Begins with bc1p (e.g.: bc1pl9dfv7kvj4hj9s3a8l.....gjstmrpjl09g8ks3ukds70q4r2j5h)

Taproot combines Schnorr signatures with MAST, 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 <x-only PubK>

OP_1: Indicates a witness version 1 (Taproot).
<x-only PubK>: A 32-byte Schnorr public key (without the y-coordinate).

Witness Data

<sig>

<sig>: A Schnorr signature proving possession of the private key corresponding to the x-only pubkey.

*There is an oddity in CHECKMULTISIG execution up

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.

OP_0 <sig2> <sig3> 2 <PubK1> <PubK2> <PubK3> 3 OP_CHECKMULTISIG

The input script in this multisig is not <sig2> <sig3> but OP_0 <sig2> <sig3>.

It because the custom early on to use OP_0 which later because a relay policy rule and eventually a consensus rule (BIP147).

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 in the Bitcoin Wiki.
Bitcoin IDE is an online Bitcoin Script visual emulator. Great for learning purposes.
Script Editor is product-driven research on Bitcoin scalability and usability.
Miniscript is a language for writing (a subset of) Bitcoin Scripts in a structured way, enabling analysis, composition, generic signing, and more.

Mastering Bitcoin

2024-07-05T00:00:00+00:00

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.

Introduction
How Bitcoin Works
Bitcoin Core: The Reference Implementation
Keys and Addresses
Wallet recovery
Transactions
Authorization and Authentication
Digital Signatures
Transaction Fees
The Bitcoin Network
The Blockchain
Mining and Consensus
Bitcoin Security
Second-Layer Applications

Full book also on GitHub.

Key takeaways

Your wallet doesn’t store any bitcoins, only the keys to access them. The coins are stored in the blockchain.
Understanding UTXOs is crucial to understanding how transactions work.
- These are outputs from previous transactions that have not yet been spent
A transaction needs:
- inputs: UTXOs and an unlocking script (scriptSig) which proves ownership.
- outputs: the recipient’s address and the amount to send.
The unlocking script is written in a custom language called 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.
Bitcoin is often referred to as “programmable money” because it allows: Multisignature, timelocking and conditional spending.
- Extends Bitcoin’s functionality beyond simple value transfers.
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.
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.
Schnorr’s signatures aren’t specific to the 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.
The best known secure secret sharing algorithm is Shamir’s Secret Sharing.
Running a full node gives you the pure Bitcoin experience: independent verification of all transactions without trusting any other system.
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.
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.
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.

Prisoner's Dilemma

2024-06-27T00:00:00+00:00

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.

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

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.

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.

Don’t trust, verify.

The Genesis Book

2024-06-21T00:00:00+00:00

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.

Part I: Foundations

Spontaneous Order
Free and Open Source
Neutral Money
Cryptography
Denationalization of Money
eCash (and Trustless Time-stamps)
The Extropians

Part II: Cypherpunks

The Cypherpunk Movement
Cypherpunk Currency
Hashcash
Bit Gold
B-money (and BitTorrent)
RPOW

Part III: Bitcoin

Twenty-First Century Fiat
The White Paper
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.

The Phoenix Project

2024-05-31T00:00:00+00:00

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:

Business projects: these are the projects that directly affect business goals. They generate revenue and deliver value to customers.
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.
Changes: the result of the previous business and internal projects, to know what to change with and within them.
Unplanned work: this is the real productivity killer. This is related to all operational issues resulted from the previous three types of work.

What Kills Agility?

2024-05-30T00:00:00+00:00

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. 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.

Radical Candor

2024-04-17T00:00:00+00:00

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

Obnoxious Aggression: Being overly critical or aggressive.
Ruinous Empathy: Being overly sympathetic or enabling.
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.

Learning Concurrency in Golang

2024-04-02T00:00:00+00:00

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 (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.

type Horse struct {
 Name string // The name of the horse
 Line int // The competition line
}

func (h Horse) Letter() string {
 return fmt.Sprintf("%c", h.Name[0])
}

func (h Horse) Equals(other *Horse) bool {
 return other != nil &&
 h.Line == other.Line &&
 h.Name == other.Name
}

func (h Horse) String() string {
 return fmt.Sprintf("%s (line:%d)", h.Name, h.Line)
}

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.

func main() {
 const lines, lineLength = 12, 30

 board := NewRaceBoard(lines, lineLength)
 go RenderGame(board)

 winnerChan := make(chan Horse)
 for line := range board {
 // each horse will be moved in different processes
 go startRunningHorseInLine(board, line, winnerChan)
 }

 // wait until one horse reaches the end
 winner := <-winnerChan
 // render one last time to ensure the latest board state
 RenderRaceBoard(board, &winner)

 fmt.Println("Race finished!")
 fmt.Printf("# Winner: %s\n", winner)
}

Generating the board

The race board is a bidimensional matrix of pointers to Horses. Each line “contains” only one Horse; aka only one pointer will point to an actual Horse, the rest will be pointers to nil. During the generation of the Board, we will create one Horse at the first position of each line.

func NewRaceBoard(lines, lineLength int) [][]*Horse {
 board := make([][]*Horse, lines)
 for line := range board {
 board[line] = make([]*Horse, lineLength)
 board[line][0] = &Horse{
 Name: generateHorseName(),
 Line: line,
 }
 }
 return board
}

The names are randomly generated using HorseNames.

var HorseNames = [][2]string{
 {"Alloping", "Giggles"},
 {"A-lot", "Gallop"},
 {"BoJack", "Jack"},
 {"Baroness", "Belle"},
 // ...
}

func generateHorseName() string {
 name := HorseNames[rand.Intn(len(HorseNames))][0]
 surname := HorseNames[rand.Intn(len(HorseNames))][1]

 return name + " " + surname
}

Rendering the game

Then RenderGame(), renderRaceBoard(), renderRaceLine() and renderRacePosition() are separated to help focus on each method’s responsibility –identifying what is the subject to be rendered.

RenderGame() is being executed in another process using 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
}

Moving the horses

In main(...), the winnerChan is a shared channel that will be used by the first Horse reaching the last position in their line.

Each Horse will run a loop until reaching the end of the line OR receiving (via the shared channel winnerChan) the message that another Horse already won the race. Until then, each horse will move independently by randomly sleeping milliseconds before moving to the next position in their line.

startRuningHorseInLine() runs in another process using 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 := <-winnerChan
 //...
}

func startRunningHorseInLine(board [][]*Horse, line int, winnerChan chan Horse) {
 for {
 select {
 case <-winnerChan: // check if another horse finished
 return // in such a case, then stop the for loop
 default:
 time.Sleep(time.Millisecond * time.Duration(rand.Intn(maxSleepDelay)))
 moveHorseOnePos(board, line, winnerChan)
 }
 }
}

func moveHorseOnePos(board [][]*Horse, line int, winnerChan chan Horse) {
 cols := len(board[line])
 for col := cols - 1; col > 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.

Thanks to my former Team Lead, Andrei Boar, who helped me review my first original solution and provided an alternative solution (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.

Effective Pair Programming

2024-03-28T00:00:00+00:00

What is pair programming? Let’s first establish what pair programming is: 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 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

Thanks to my friend Manu, who helped me with this post. We even share a workshop on this topic.

Deployments on Fridays

2024-02-25T00:00:00+00:00

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.

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.

The Lean Startup

2024-01-26T00:00:00+00:00

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

Great Engineering

2023-12-30T00:00:00+00:00

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 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.

Invincible

2023-12-09T00:00:00+00:00

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

Forming, Storming, Norming and Performing

2023-11-25T00:00:00+00:00

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, 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

The Alchemist

2023-11-07T00:00:00+00:00

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

Crucial Conversations

2023-10-31T00:00:00+00:00

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

Know your heart
Ensure safety
Beware of reverting to your style under stress
Make the content safe
Control your emotions
Share your stories
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:

Stakes are high
Opinions vary
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

Video Summary

How to Test Private Methods?

2023-10-20T00:00:00+00:00

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.

Unhealthy Working Environment

2023-10-11T00:00:00+00:00

An unhealthy working environment can have various symptoms that negatively impact employees’ physical and mental well-being.

While writing about 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 Who moved my cheese?
The process itself is the goal How to focus and have self-discipline
Have you always been like this? How to find a balance of growth and happiness

Your managers and leaders

Great leadership Leadership starts within your own life and behaviour
Understanding people Misunderstandings, effective communication, and self-reflection

The Peter Principle

2023-09-30T00:00:00+00:00

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.

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 a 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.

It's Your Ship

2023-09-20T00:00:00+00:00

“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.

The Day of the Triffids

2023-08-13T00:00:00+00:00

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

Summary based on the movie “The Day of the Triffids (2009)”

How Do You Get Everyone on Board?

2023-08-02T00:00:00+00:00

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, “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, and the primary responsibility of a good leader 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? 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 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 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”.

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.

Photos from me at WeAreDevelopers World Congress, Berlin 2023.

The Book Of Satoshi

2023-07-10T00:00:00+00:00

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.

Never Ending Loop

2023-07-05T00:00:00+00:00

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 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.

Fahrenheit 451

2023-06-28T00:00:00+00:00

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

Another great summary: https://youtu.be/_agaWPlVG8Q

The Blocksize War

2023-06-20T00:00:00+00:00

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

First strike
March to war
Scaling I - Montreal
Scaling II - Hong Kong
SegWit
Lightning network
Bitcoin Classic
Hong Kong Round table
Faketoshi
The DAO
Scaling III - Milan
Bitcoin unlimited
Exchanges
ASICBoost
Dragons’s Den
Litecoin
User - Activated softfork
New York agreement
Bitcoin Cash
SegWit2x
Victory

Summary

Learned Helplessness

2023-06-08T00:00:00+00:00

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.

Experiments

A classroom with different assessments

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 affect 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

Español

Agile Project Management

2023-05-31T00:00:00+00:00

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

The fluid manifesto
Being agile
Agile process
Planning for success
Agile communication
Scrum basics
Introduction to Kanban
Building an adaptive team
Leadership and collaborative management
Common errors behind agile failure
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.

Requirements
Analysis
Design
Code
Testing
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.

Dedicated QA Teams in Software?

2023-05-17T00:00:00+00:00

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.

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.

Effective Remote Work

2023-04-17T00:00:00+00:00

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:

Do you treat everyone as remote?
Do you provide a remote work-space setup?
Do you spend money equally on in-office and remote staff?
Do you optimize for asynchronous communication?
Do you create artifacts from synchronous interactions?
Do you measure staff by their impact?
Do you allow staff to choose flexible hours?
Are the members of the executive team remote workers?
Do you use the best collaborative tools that money can buy?
Do you hire staff anywhere in the world?
Do you support families as well as employees?
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.

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

Introducing a New Tech Stack

2023-04-14T00:00:00+00:00

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 a 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?
Does 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 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.

Thanks to my friends Manu, Antonio, and Jesus, who helped me come up with this summary of ideas after brainstorming together.

Accelerate

2023-03-19T00:00:00+00:00

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

Have You Always Been Like This?

2023-03-16T00:00:00+00:00

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, 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 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.

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 and 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?”

21 Lessons

2023-03-11T00:00:00+00:00

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

Great Leadership

2023-02-27T00:00:00+00:00

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, 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”, 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” 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”, 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?” 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” and “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!”, 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” 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” 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” 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” 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” is a great starting point.

After that one, if you want more, I can recommend something more advance with “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” a great book because this can help you understand the responsibilities from any organization’s most abstract point of view.

Similarly, “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”, and “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, Leaders Eat Last, The infinite game
Spencer Johnson: Who moved my cheese?
Charles Duhigg: The Power of Habit
James Clear: Atomic Habits
L. David Marquet: Turn the ship around!, Leadership is Language
Brené Brown: Dare to lead
Chris Voss: Never split the difference
Patrick M. Lencioni: The Five Dysfunctions of a Team
Andrew S. Grove: High Output Management
Peter F. Drucker: The Essential Drucker
Matt Mochary: The Great CEO Within
Thomas H. Douglas: Adapt or Die
Camille Fournier: The Manager Path
Michael Lopp: 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.”

Adapt or die

2023-02-26T00:00:00+00:00

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/.

The infinite game

2023-01-29T00:00:00+00:00

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:

Just Cause
Courageous leadership
Trusting teams
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.

Interview About XP and Agile

2023-01-09T00:00:00+00:00

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.

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, where I work with the e-commerce webshop team. I also enjoy open-source software, 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.

Momo

2022-12-17T00:00:00+00:00

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.

Ignoring Scrum to Get More Agile?

2022-12-06T00:00:00+00:00

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, 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.

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.

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. But, the tl;dr: Agile is about quick feedback. It’s about effective communication and reducing waste while aiming for simplicity.

Agile 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–9 people (see 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 need especial 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.

Recipes for Decoupling

2022-11-28T00:00:00+00:00

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 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/

Buy it here: leanpub.com/recipes-for-decoupling

Working Agile with Non-Agile Teams

2022-11-11T00:00:00+00:00

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. You can find a lot of documentation about DDD in books (like 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.

The Essential Drucker

2022-10-29T00:00:00+00:00

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

Management is about humans
Management should define an organization’s values, objective, goals & mission
Management must enable the organization and members to grow and develop
Results only exist outside the organization

Different Beliefs About Software Quality

2022-10-08T00:00:00+00:00

I recently got a great question on Twitter which got me thinking for a while and I decided to share my thoughts about it.

Context

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.

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.

Thanks to my former Engineer Manager, Evgenii Sokolov, who inspired me to write these extra lines after sharing the original post.

Dare to lead

2022-09-30T00:00:00+00:00

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

Setting Boundaries - respect one another’s boundaries
Reliability - which means to follow-up words with actions
Accountability - being responsible and acknowledging mistakes
Vault - the ability to keep confidential information private
Integrity - choosing courage over comfort
Non-judgment - talk to one another without judgment
Generosity - 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

The Beauty of Leadership

2022-09-25T00:00:00+00:00

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, 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 vision 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.

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.

Understanding People

2022-08-22T00:00:00+00:00

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.

Continuous Discovery Habits

2022-08-21T00:00:00+00:00

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?

The What and Why of Continuous Discovery
A Common Framework for Continuous Discovery

Part 2: The continuous discovery habits

Focusing on Outcomes Over Outputs
Visualizing What You Know
Continuous Interviewing
Mapping the Opportunity Space
Prioritizing Opportunities, Not Solutions
Supercharged Ideation
Identifying Hidden Assumptions
Testing Assumptions, Not Ideas
Measuring Impact
Managing the Cycles
Show Your Work

Part 3: Developing your continuous discovery habits

Start Small, and Iterate
What’s Next?

Focusing on outcomes over outputs will help you create the right products for your customers.

The What & Why of Continuous Discovery

The Great CEO Within

2022-08-01T00:00:00+00:00

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

Ask for it.
Acknowledge it - repeat what they said. Make them feel heard and understood.
Appreciate it.
Act on it.

How to give negative feedback

Ask for permission.
State the behaviour (fact).
State how the behaviour makes you feel (feelings).
State your thoughts, opinions, and judgments around the situation (story).
Make a request - a change you’d lie to see in the future.
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.

Matt Mochary shares insights on developing his coaching method, understanding & overcoming primal fear, addressing imposter syndrome & more.

The Project Management Triangle

2022-07-25T00:00:00+00:00

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

The Starfish and the Spider

2022-07-19T00:00:00+00:00

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:

Clean Craftsmanship

2022-07-11T00:00:00+00:00

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.

Listen out for:
* Quote & Intro - [00:00:00]
* Career Journey - [00:07:29]
* Clean Craftsmanship - [00:10:53]
* Programmer as a Profession - [00:15:31]
* Craftsmanship - [00:18:45]
* Disciplines - [00:22:45]
* Disciplines: Test-Driven Development - [00:28:49]
* Disciplines: Refactoring - [00:34:31]
* Code Coverage - [00:39:02]
* Standard: Never Ship S**t - [00:42:35]
* Standard: Always Be Ready - [00:47:15]
* Ethics: Do No Harm - [00:50:00]
* Ethics: Estimate Honestly - [00:53:56]
* 2 Tech Lead Wisdom - [00:57:50]

Modern Software Engineering

2022-06-29T00:00:00+00:00

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:

The Path to Seniority in Software

2022-06-08T00:00:00+00:00

We all have been junior developers at some point. This is easy to know because it is at the very beginning of your carrier. Your responsibilities were narrowed down by other peers who were looking after you.

Suddenly, at some point, after some 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 industry is falsified by companies’ need of having 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 just in ~10% of all seniors during my almost 10 years of experience and 7 companies I have worked with.

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 can you transmit your knowledge to others? Sharing your knowledge is an important task for a senior person.
How well can you collaborate with other people? Including the PM/PO and other teams. Collaboration is crucial to creating a constant feedback loop.
How well can you work together with your peers? Pair-programming embraces team cohesion and helps the team become better.
How well are your testing skills? Testing is highly related to the quality of your work, and a senior should aim for an incremental design.
How well is your understanding of delivering value constantly in small chunks? The sooner you deliver value, the sooner you get feedback about it.
How well is your technical knowledge related to 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 are you capable to adapt and cope with changes? Change is inevitable, and therefore we must learn how to deal with changes, especially the ones that 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.

Bikeshedding

2022-05-27T00:00:00+00:00

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” spoof of management. “Bikeshedding” is a dramatized form of the “Law of triviality”.

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

Bitcoin: Blockchain y su investigación

2022-05-10T00:00:00+00:00

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

Docker: SecDevOps

2022-04-29T00:00:00+00:00

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

Dunbar Number

2022-04-02T00:00:00+00:00

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.

Single teams: 5-9 people.
- There is a shared trust among the team members.
- The trust is build among time.
- Therefore, they must be a long term team.
Group: 50 people.
- They can have meaning relationship.
- They share a domain or subdomain.
- They understand the challenges and help each other out.
Division: 150 people

References

Team Topologies

2022-03-31T00:00:00+00:00

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.
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

2022-02-27T00:00:00+00:00

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

Update Your Team to Be More Extreme

2022-02-26T00:00:00+00:00

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.

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. 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.”

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 in different conferences about this topic.

The Power of Authority and Obedience

2022-01-24T00:00:00+00:00

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.

Milgran 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:

“Please continue.”
“The experiment requires that you continue.”
“It is absolutely essential that you continue.”
“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.

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:

The person giving the orders is perceived as legitimate for that.
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.

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

Modern CTO

2022-01-23T00:00:00+00:00

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” 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

2022-01-16T00:00:00+00:00

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

My Friend Of Misery - Metallica (bass cover)

2022-01-13T00:00:00+00:00

Jonathan Livingston Seagull

2022-01-08T00:00:00+00:00

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

The Five Dysfunctions of a Team

2021-12-07T00:00:00+00:00

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

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

Start with Why

2021-11-28T00:00:00+00:00

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

London vs Chicago

2021-11-20T00:00:00+00:00

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 in moving 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 works 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.

Conclusion

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.

References

Leadership is Language

2021-10-22T00:00:00+00:00

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 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

Red Work vs Blue Work

2021-10-21T00:00:00+00:00

“Blue Work” and “Red Work” are concepts that David Marquet describes in his book 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 for completing 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.

References

TDD vs BDD

2021-09-25T00:00:00+00:00

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

Specify what you want.
Make it work.
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 do 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.

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.
Second, you make that little thing work in the simplest possible way.
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

The Bitcoin Standard

2021-09-20T00:00:00+00:00

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

Extra: Lex Fridman Podcast with the author of this book

Turn the Ship Around!

2021-09-12T00:00:00+00:00

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

David Marquet talks about leadership that turns the ship around in his keynote at the Worldwebforum.

The Catcher in the Rye

2021-08-08T00:00:00+00:00

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

Test-Driven (Development)

2021-08-01T00:00:00+00:00

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 write 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.

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:

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.

TDD in a nutshell; it’s about the rhythm.

Specify what you want.
Make it work.
Make it better.

Kent Beck

1. Change the code as usual
2. Write a test that only passes after the change
3. Revert to before 1
4. Type the test again (copy/paste is cheating & invalidates the warranty of the exercise)
5. Make it compile by changing the code
6. See it fail
7. Change the code to make it pass
— Kent Beck 🌻 (@KentBeck) July 30, 2021

Images original by Emmanuel Valverde Ramos.

Lord of the Flies

2021-07-10T00:00:00+00:00

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.

Responsibilities of a Tech Lead

2021-07-01T00:00:00+00:00

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)

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.

Recommended books on this field

References

Become an Effective Software Engineering Manager

2021-06-27T00:00:00+00:00

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.”

Conformity Experiments

2021-06-01T00:00:00+00:00

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.

Conclusion

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.

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

Peopleware

2021-05-28T00:00:00+00:00

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.

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.

Open-Source Software

2021-05-03T00:00:00+00:00

What is Open-Source Software (OSS)? What are their benefits? How can you start contributing to any OSS? Pet projects? Knowledge sharing? Why all of these?

What is OSS?

OSS shares similarities with free software, but it’s not the same. Free software is a form of OSS, but that doesn’t necessarily mean that it has to be free. For example:

PHPUnit is an example of OSS which is free.
Spryker is an example of OSS which is not free.

OSS is basically software that is public, open to the world.

Benefits

For Companies

Adoption: the easier the access, the easier the adoption.
Training and tutorials help the system to grow.
Tech: often on the cutting edge of technology. Tech moves fast. They will get obsolete if they don’t.
Community: the people around want to improve as it grows. Public channels enable easy access and community building.
Trust: the software is public and accessible. Everyone can check the quality of the software anytime.

For Individual Contributors

Flexibility: decide on what you want to work on.
Self-confidence: the experience improves your skills.
Training: without the pressure of a PROD environment.
Tech: play with the latest features of your tech. Try upcoming versions of your coding lang, or even try new ones!
Soft skills: improve your communication skills. Good communication in the project is important. Especially when you face disagreements.

Contributing to OSS

Getting Started with GitHub

Nowadays, it’s really trivial to start contributing to OSS:

You can start your own project. A pet project fits here perfectly!
You can contribute to an existing OSS project.

Pet Projects

A pet project is a playground to create software and train your professional skills. Creating pet projects in your public GitHub profile has all the benefits of contributing to OSS, plus you’re your own boss:

You dictate the roadmap.
You decide what to do and how.
You’re your own boss.

The project is there for you.
You are responsible to play, explore and pass your limits.

My Pet Projects

Active:

php-best-practices: what I consider best practices for web-dev.
php-scaffolding: a basic PHP scaffolding with Docker.

Inactive:

stock-ticker: get a notification with the news from your favorites Tickers.
jira-status-notifier: Notify when the JIRA tickets don’t move along.
edifact-parser: a parser for a UN/EDIFACT file format in PHP.

Abandoned:

knob-mvc: a framework to create WordPress templates (2015/2017).

My OSS Organization Contributions

Active:

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
gacela-project: 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: The base template for NuevaMetal (2013–2016).

Blog Posts

Pull Requests vs Pair Programming
The process itself is the goal
The art of refactoring; When, How, and Why
The art of testing: Where design meets quality

… and many more on https://chemaclass.com/blog/

The Beauty of OSS

Seeing the corrections that you constantly keep doing
Seeing how your own code gets old with time
Seeing the many mistakes that you have done
Seeing how you are getting better at coding over time

Developing a sixth sense to smell patterns which you have already done and their positive & negative experiences.

Showing your skills and helping the community around you.

Open-Source Software offers you one of the best opportunities to start building your career path towards continuous improvement.

This is a (Spanish) talk that I did remotely on April 2021, for PHPMad Madrid Community. I basically present all these ideas together with a live demo of how to contribute to a real OSS.

The Art of Leadership

2021-04-19T00:00:00+00:00

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.

97 Things Every Engineering Manager should know

2021-04-05T00:00:00+00:00

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 ;)

Pull Requests vs Pair Programming

2021-04-01T00:00:00+00:00

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:

For discussions about code style.
To spot potential bugs.
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:

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.
Spot bugs. Bugs and desired behavior should be covered by automated tests. The developer is the first responsible person for this topic.
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?

Sharing knowledge about the proposed changes with the team.
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 don’t 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.

Summary

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

2021-03-01T00:00:00+00:00

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 mouses kept their instincts active.

One day the mousses 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 would be endless constant, so they weren’t prepared for that 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

Change happens. They keep moving the cheese.
Anticipate change. Get ready for the cheese to move.
Monitor change. Smell the cheese often so you know when it’s getting old.
Adapt to change quickly. The quicker you let go of old cheese, the sooner you can enjoy new cheese.
Change. Move with the cheese.
Enjoy change. Enjoy the taste of new cheese
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.

“Life moves on and so should we” — Spencer Johnson

Zombie Scrum Survival Guide

2021-03-01T00:00:00+00:00

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.

Agile Product Management with Scrum

2021-02-22T00:00:00+00:00

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

Phel: The Lisp That Compiles to PHP

2021-02-01T00:00:00+00:00

A new Functional Programming language build-in on the PHP ecosystem.

The Phel Language

Phel is a Functional Programming (FP) language that compiles to PHP. It is a dialect of Lisp 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”. 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, in which I learned the basics of Prolog, Erlang, Clojure, Haskell… I even created a repository in GitHub 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 work 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 books such as Object Design Style Guide, and Advanced 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:

# Define a namespace
(ns my\example)
# Define a variable with name "my-name" and value "world"
(def my-name "world")
# Define a func with name "print-name" and one argument
(defn print-name [your-name]
 (print "hello" your-name))
# Call the function
(print-name my-name)

Current status of Phel

We prepared an easy Getting Started Guide
We prepared an easy GitHub Repository with a Phel Scaffolding Template
We just released the first official version: 0.1.0

Check out the official website with all documentation: https://phel-lang.org/

Also recommended

Functional Programming with Phel - JesusValera

Stock market investing

2021-01-31T00:00:00+00:00

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

2021-01-22T00:00:00+00:00

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?

2021-01-16T00:00:00+00:00

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

Change happens. They keep moving the cheese.
Anticipate change. Get ready for the cheese to move.
Monitor change. Smell the cheese often so you know when it’s getting old.
Adapt to change quickly. The quicker you let go of old cheese, the sooner you can enjoy new cheese.
Change. Move with the cheese.
Enjoy change. Enjoy the taste of new cheese
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.

I wrote a blog post about this book: Embrace the change

Rich dad poor dad

2021-01-15T00:00:00+00:00

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

To Mock or Not to Mock

2021-01-11T00:00:00+00:00

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 (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 exclusively: encouraging final classes and interfaces.

Mock interfaces. Instantiate concrete classes.

“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 — Eric Elliott
When to mock & Test Definitions — Uncle Bob
Final classes by default — Matthias Noback
The problem with mocks — Sean Hammond
A Set of Unit Testing Rules — Michael Feathers

Sharing Your Git Patches

2020-12-01T00:00:00+00:00

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.

git diff origin develop > ../my-origin-develop.patch

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:

git apply ../my-origin-develop.patch

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

# Checkout that branch
$ ~/myProject git:(the-branch) ➜ git pull origin the-branch
# Do your suggestions and changes in the targeted branch
# Generate the patch file using the diff command
$ ~/myProject git:(the-branch) ➜ git diff > ../your-diff.patch
# Share the patch file with the author of the PR

The patch user: the person who will see the patch

# Ensure you are in that branch
$ ~/myProject git:(the-branch) ➜ git pull origin the-branch
# Apply the patch file
$ ~/myProject git:(the-branch) ➜ git apply ../your-diff.patch

References

Official documentation for “git apply”

Principles of package design

2020-11-12T00:00:00+00:00

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

Never Use array_merge in a Loop

2020-11-10T00:00:00+00:00

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:

<?php
$lists = [
 [1, 2],
 [3, 4],
 [5, 6],
];
$merged = [];
foreach($lists as $list) {
 $merged = array_merge($merged, $list);
}
// $merged === [1, 2, 3, 4, 5, 6];

This is a very bad practice because it’s a (memory) performance killer! Instead, you should use the spread operator (in PHP since 5.6!):

<?php
$lists = [
 [1, 2],
 [3, 4],
 [5, 6],
];
$merged = array_merge(...$lists);
// === [1, 2, 3, 4, 5, 6];

Unpacking an assoc-array

What if you had an assoc-array instead like this one?

<?php
$lists = [
 'key-1' => [1, 2],
 'key-2' => [3, 4],
 'key-3' => [5, 6],
];

In that case, you will need to unpack its values:

<?php
$merged = array_merge(...array_values($lists));
// === [1, 2, 3, 4, 5, 6];

In Functional Programming, this is known as flatting a list. No loops & no more performance problem.

Flatting a multilevel array

What if you wanted to flat a multilevel array like this one?

<?php
$lists = [[1], 2, [[3, 4], 5], [[[]]], [[[6]]], 7, 8, []];

Or like this one, even with key-values?

<?php
$lists = [
 'key-1' => [
 1,
 [2],
 'key-2' => [
 3,
 [
 'key-3' => [4, 5],
 ],
 ],
 ],
 6,
 'key-4' => [7, 8],
];

In these cases, you might want to use the internal standard library:

<?php
$merged = iterator_to_array(
 new RecursiveIteratorIterator(
 new RecursiveArrayIterator($lists)
 ),
 $use_keys = false
);
// $merged === [1, 2, 3, 4, 5, 6, 7, 8];

Conclusion

Usually, being aware of how to flat a “2 level” array might be sufficient:

<?php
$flattenList = array_merge(...array_values($lists));

Otherwise, the internal standard library will help you deal with it.

References

Animal Farm

2020-11-02T00:00:00+00:00

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.

Typed Arrays in PHP

2020-10-13T00:00:00+00:00

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 snipped for our examples Having a class, Customer:

<?php
/** 
 * @psalm-immutable 
 */
final class Customer
{
 // Using PHP 8 constructor property promotion
 // https://wiki.php.net/rfc/constructor_promotion
 public function __construct(
 public string $name,
 ) {}
}
// We create a list of 6 customers
$customers = array_map(
 fn(int $i): Customer => new Customer("name-{$i}"),
 range(1, 6)
);

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:

<?php
/** 
 * @param Customer[] 
 */
function createInvoiceForCustomers(array $customers): void
{
 foreach ($customers as $customer) {
 // ... some irrelevant logic for this example
 }
}

The code below would work at “compile-time”. But it might fail at “runtime”.

<?php
createInvoiceForCustomers($customers);
createInvoiceForCustomers([new Customer('any name')]);
createInvoiceForCustomers([new AnyOtherType()]);

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:

<?php
/** 
 * @param Customer[] 
 */
function createInvoiceForCustomers(array $customers): void
{
 foreach ($customers as $customer) {
 createInvoice($customer);
 }
}
function createInvoice(Customer $customer): void
{
 // ... some irrelevant logic for this example
}

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.

<?php
createInvoiceForCustomers($customers);
createInvoiceForCustomers([new Customer('any name')]);
createInvoiceForCustomers([new AnyOtherType()]); // won't work

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:

<?php
function createInvoiceForCustomers(Customer ...$customers): void
{
 foreach ($customers as $customer) {
 createInvoice($customer);
 }
}

Everything here below would work at “compile-time”. It will for sure break during “runtime” if the createInvoice() receives something different than a Customer.

<?php
createInvoiceForCustomers(...$customers); // OK
createInvoiceForCustomers(
 new Customer('any name'), 
 new Customer('any name'),
); // OK
// This is not even possible to write. The IDE will yeld at you. 
// It's expecting a `Customer`, but `AnyOtherType` is given:
createInvoiceForCustomers(new AnyOtherType());

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.

Conclusions

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

Object design style guide

2020-10-10T00:00:00+00:00

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

2020-09-10T00:00:00+00:00

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.

The Process Itself Is the Goal

2020-09-08T00:00:00+00:00

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”. 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 am I 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 Habits, 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 run. 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

Testing Effectively Legacy Code

2020-08-17T00:00:00+00:00

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.

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 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.

final class MyBusinessLogic
{
 private DependencyInterface dependencyInterface;
 private ConcreteDependency concrete;

 public function __construct(
 DependencyInterface dependencyInterface,
 ConcreteDependency concrete
 ) {
 this.dependencyInterface = dependencyInterface;
 this.concrete = concrete;
 }

 public function applySomeLogic(Input input): ReturnType
 {
 // black box responsible to create a ReturnType
 // based on the given Input
 return returnType;
 }
}

final class MyBusinessLogicTest extends TestCase
{
 public function test_apply_some_logic(): void
 {
 // I want to assert that "applying some logic"
 // from MyBusinessLogic with the given Input
 // I will receive a concrete ReturnType with a 
 // certain value as its property. Something like:
 
 returnType = myBusinessLogic.applySomeLogic(input);
 assertEquals('expected', returnType.getProperty());
 }
}

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.

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.

final class MyBusinessLogicTest extends TestCase
{
 public function test_apply_some_logic(): void
 {
 myBusinessLogic = new MyBusinessLogic(
 this.createMock(DependencyInterface.class),
 new ConcreteDependency(/* ... */)
 );
 // OR
 myBusinessLogic = new MyBusinessLogic(
 new FakeDependency(),
 new ConcreteDependency(/* ... */)
 );
 // ...
 }
}

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.

input = new Input(/* ... */);
returnType = myBusinessLogic.applySomeLogic(input);

4. Assert the output with the expected value.

From step-1 you need to know what you want. Apply the assertion(s) now.

final class MyBusinessLogicTest extends TestCase
{
 public function test_apply_some_logic(): void
 {
 myBusinessLogic = new MyBusinessLogic(
 this.createMock(DependencyInterface::class),
 new ConcreteDependency(/* ... */)
 );

 input = new Input(/* ... */);
 returnType = myBusinessLogic.applySomeLogic(input);
 assertEquals('expected', returnType.getProperty());
 }
}

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.

final class MyBusinessLogicTest extends TestCase
{
 /** @dataProvider providerApplySomeLogic */
 public function test_apply_some_logic(
 array concreteMapping,
 string argInput,
 string expectedValue
 ): void {
 myBusinessLogic = new MyBusinessLogic(
 this.createMock(DependencyInterface.class),
 new ConcreteDependency(concreteMapping),
 /* ... */
 );

 input = new Input(argInput, /* ... */);

 actual = myBusinessLogic.applySomeLogic(input);
 assertEquals($expectedValue, actual.getProperty());
 }

 public function providerApplySomeLogic(): Generator
 {
 yield [
 'concreteMapping' => ['key' => 'value'],
 'argInput' => 'something',
 'expectedValue' => 'expected-value-A',
 ];

 yield [
 'concreteMapping' => ['key2' => 'value2'],
 'argInput' => 'something-else',
 'expectedValue' => 'expected-value-B',
 ];
 }
}

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 pass 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.

myBusinessLogic = this.createBusinessLogic(concreteMapping);
input = this.createInput(argInput);
actual = myBusinessLogic.applySomeLogic(input);
assertEquals(expectedValue, actual.getProperty());

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

Legacy Code is code without tests

Of course, there is way more to learn about testing and working 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:

Identify “change points” to break your code dependencies.
Break dependencies.
Write the tests.
Make your changes.
Refactor.

Advanced Web Application Architecture

2020-08-16T00:00:00+00:00

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

Design patterns for modernizing legacy code bases

Strict Types in PHP

2020-08-09T00:00:00+00:00

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 hint type 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

The Art of Refactoring

2020-06-28T00:00:00+00:00

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 tabu 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 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 well 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.

Never split the difference

2020-06-12T00:00:00+00:00

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

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.
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.
Tactical empathy brings our attention to both the emotional obstacles and the potential pathways to getting an agreement done.
Giving someone’s emotion a name, otherwise known as labeling, gets you close to someone without asking about external factors you know nothing about.
“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

Scrum

2020-06-10T00:00:00+00:00

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.

Final Classes in PHP | Java | Any

2020-06-06T00:00:00+00:00

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 prefix 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 close 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 extends 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 too popular that 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

7 languages in 7 weeks

2020-05-21T00:00:00+00:00

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

The call of Cthulhu

2020-05-18T00:00:00+00:00

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

2020-05-16T00:00:00+00:00

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

2020-05-13T00:00:00+00:00

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’.

The Art of Testing: Where Design Meets Quality

2020-04-07T00:00:00+00:00

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.

High Output Management

2020-04-03T00:00:00+00:00

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:

The Manager Path

2020-03-26T00:00:00+00:00

Key lessons

One-on-one meetings with your manager are an essential feature of a good working relationship.
A manager’s job involves making it easy for her employees to get things done by creating fertile environments in which work can happen.
Mentoring new hires is critical.
Feedback works best when you, as a manager, pair that feedback with coaching.
It’s unrealistic to think you can or should shield your team from everything.

Clean Agile

2020-03-12T00:00:00+00:00

Clean Agile comes from Uncle Bob, one of the founding fathers of Agile, one of the seventeen people who authored the Agile Manifesto 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.

Extreme Programming Explained

2020-03-05T00:00:00+00:00

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)

Tech Talk by kent Beck: XP 20 years later

Symfony 5

2020-02-20T00:00:00+00:00

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.

Making headway

2020-02-06T00:00:00+00:00

Adrian (guitar, drums) & Chema (bass).

How to Improve Your Tech-Talk (or Any Other Presentation)

2019-11-18T00:00:00+00:00

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.

Content of the presentation: what message do you want to convey to whom and how?
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.
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.

Atomic Habits

2019-11-12T00:00:00+00:00

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

Working Effectively with Legacy Code

2019-07-01T00:00:00+00:00

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:

Identify change points.
Find test points.
Break dependencies.
Write tests.
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.

Silver lining

2019-04-25T00:00:00+00:00

Adrian (guitar) & Chema (bass).

Silver lining (solo bass)

2018-12-28T00:00:00+00:00

The Art of War

2018-08-10T00:00:00+00:00

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.

Clean Architecture

2018-06-04T00:00:00+00:00

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.

Chapter 29: July 2017

2017-07-01T00:00:00+00:00

I’m Not Talking About Self-Help

I didn’t intend to write a self-help book; instead, I aimed to make writing one of my most popular tools to help organize reason and senses.

I’m not talking about self-help but finding a balance between sanity and madness. The prudence we must consider, regardless of our different contexts, cannot falter in the face of the emotional imbalance that may be present.

Adaptation to transparency, to the rawness that disorients us without crumbling words. I’m referring to the emotional instability that needs repair.

Forgotten memory: a dream where time seemed to breathe down our necks, accompanied by a constant fear of death. A lonely older brother, a displaced migrant. Clear ideas, feelings of daily overcoming, and not wanting to be normal out of necessity. Above good and evil with forgotten memories. The most important thing will be to leave a mark and adapt—or we will have died.

Ambitious memory of renunciation and denunciation of the opposite idea of “us.” Ironies of life, like tireless thoughts that say a lot about you. Youth, unforgiving religion. It became more noticeable in the mountains when savoring hatred for God was insufficient. It’s time to speak again. There are so many constants and ignorance, and we end up unaware of what we are losing. Who will remember us? It’s just a matter of time. The most challenging part will be understanding ourselves with different eyes. You only live once. The future will become part of our sweet memories alongside our innocent youth.

I don’t want to talk about self-help but our false freedom if we aren’t occupied with our lives. Good habits that indicate the value of truth, like our tendency to unmask mediocrity.

This book concludes not without thanking your company. Not without hoping to reread us many years from now to see who we have become. And to draw the smile we deserve.

Work. Love. Dream. Smile.

I’m not talking about self-help, but about ending to begin everything with eyes on a memory.

Chapter 28: June 2017

2017-06-01T00:00:00+00:00

Perceptions

It’s not about waiting for the moment when our life is all figured out; instead, it’s about actively resolving our life, day by day, so that we’ve created a routine for our excellence.

“We are what we repeatedly do. Excellence, then, is not an act but a habit,” said Aristotle.

It’s our perception that blurs reality in front of our senses. Our efforts to strengthen our subtle thoughts should not be undervalued, as society, from times past, seems to suggest.

The development of our reasoning, subjective success, invaluable achievements, the attainment of our performances, and personal fulfillment… We are a combination of intrinsic parts, highlighting the importance of our understanding!

Our rejection of accidental excellence is crucial because it will perish shortly due to our tendency toward mediocrity. In the face of daily challenges, our efforts will define our apprehension of the vain and unjust reality to which we sometimes mistakenly look with sympathy.

Our attachment to our being can only be linked to our idea of who we are, where we come from, and where we are going. We are abstract sensations that likely have a purely biological explanation stemming from our survival instinct. Our ideas are mere emotions that evolve surreptitiously as our various experiences unfold.

Our impression (of what we believe to understand as reality) will evolve, driven by our perceptions of the actual events we can discern, resulting from categorical and possibly flawed criticism. It will be conditioned by every event that we rarely consciously perceive.

Our unconsciousness plays a decisive and demanding role in our lives. We should judge our sense of truth with sharpness using our cognitive ability. We should not allow (let alone believe!) that every sprout is the result of chance without any guiding force but some illusion.

That’s why I must once again emphasize the importance of projecting our consciousness so that we unconsciously end up exactly where we had meticulously projected.

Chapter 27: May 2017

2017-05-01T00:00:00+00:00

Masked Mediocrity

Religion is a package of pre-established habits, where the will to power is reduced to the absurdity of mere conformity to mediocrity, masked by a complacency towards the consent of lack of perseverance.

Where the lack of persistence in what we should strive for will not incur a mandatory cost…, for we will be “forgiven,” and “all will enter the kingdom of heaven.” Is it not, perhaps, infinite kindness?

Habits chained in an uncultured past where mediocrity was rewarded with apparent consistent promises for all those inconsistent in will.

Hope from those without confidence who needed stable habits within the bounds of their meager possibilities!

Let’s not mask who we are. Let’s not want to be mediocre!

Tendency

Life is nothing more than habits. That’s why when we focus on positive things when our minds aspire to the best version of ourselves, we create a routine that pushes us toward success. Conversely, the opposite happens when our thoughts are encapsulated in negative and destructive thoughts, turning our lives into a habit of mediocrity.

It won’t be the first time we hear statements like “If you had been in my situation, you would have done the same,” trying to excuse oneself when becoming aware of the gravity of an act done without wisdom. Could we invent any excuse cruder and more vulgar than guilt for the lack of responsibility in our context? That’s what it’s about! Working on our environment! Make an effort with it!

The design of our journey should be above all external ideas. We will be as strong as we educate our tendency to be so.

We will not have more opportunities to embrace what once became impossible.

Chapter 26: April 2017

2017-04-01T00:00:00+00:00

The Value

"How much are we worth?" I wondered.
"How much are you worth?" it answered.

What will truly define the value of values?

Courage,
effort,
effectiveness,
courage,
esteem,
merit,
boldness,
interest,

As well as the importance of each of our moments.

Experiences, habits, excursions, journeys…, the small achievements that contribute to helping us thrive in our short, medium, and long-term goals. Verify, try, study, and examine reality firsthand!

What can be more valuable than the very habit of our conquest, from and towards ourselves? Nothing!

The habit of our conquest should be focused—with maximum priority—on ourselves!

The Power of Habit

2017-03-20T00:00:00+00:00

Takeaways

All habits operate the same way
Changing a habit means changing one key aspect…
…and changing one habit can change a lot of things
Willpower is a muscle
Practice, practice, practice

Chapter 25: March 2017

2017-03-01T00:00:00+00:00

Truth

Truth resides in knowledge. And knowledge will always depend on the context. Knowing the truth is basically establishing a connection between the context and the knowledge one intends to assert as truth.

In a context where knowledge can only be acquired empirically, what is truth if not the subjective assertion? In this non-theoretical context, what is truth, if not a partial manifestation of understanding?

Our ability to accurately discern the truth of subjective evidence is so individual and personal that it is hard to believe we can truly reach an ideal truth globally.

We could say that truth represents our contextual state in our minds, our knowledge.

As we grow, our truths take shape; assertions seem (and should) be questioned, evidence needs stronger foundations, and our confidence in what we defend as truth must be certified. Otherwise, the pillars will fall in no time because there are not many claims we can assure as absolute, like our time and death.

Growing up should teach us the meaning of truth, starting with the sense of life, the importance of our moments, and our reflection toward others and ourselves. This means that maturity is only a matter of what we are doing with our knowledge to understand better our context and what we are doing in our environment to expand our wisdom.

Everything in this life depends on us. Even the truth, especially considering that it could change over time. And by “us,” I mean our entity in its isolated context.

Therefore, it will be our unique projection that will delineate our truths.

Without an End

Stories that accompany. Years of recorded discourse. A book born from ideas and sketches without a near end that, nevertheless, must end, as everything that begins must.

Endings don’t necessarily have to be sad, although our feelings may sometimes think otherwise. Time is the only responsible party, just as memory is the one that fights against forgetting.

Memories bring us closer to knowledge in the form of experience. Energetic virtuosity is a daily activity, not satisfied with mere subsistence.

Externalizing internal communication with apparent ease. It was well said: “All that glitters is not gold.” I was trying to be consistent.

It was an exercise in logical and personal cleansing, emphasizing everything where I could express myself openly, with, why not say it, specific fears at the beginning for not knowing how to start. Stop fearing being wrong by thinking too much before and after acting.

Embark on a journey not to finish it, but for the journey and all that, it entails the birth of a beginning without necessarily knowing an end, without having to expire if care was taken.

Let’s learn to be like the person we truly wish to meet tomorrow. And all endings will evolve into beginnings.

Chapter 24: February 2017

2017-02-01T00:00:00+00:00

Our Life

The sensation of losing everything can naturally mislead us when we fully understand our reality. What does it mean to have lost everything?

It is our context that determines the perception of what we are judging. Playing, in turn, a role that is more than important, though not definitively explicit.

Consider not expressing ourselves, not revealing ourselves to ourselves, for an excessive period. Weigh the idea of not considering our observation of what we cannot stop looking at: our life and our time, our moments and our being: ourselves.

Not reflecting on our actions in the wake of our leaving —even if involuntarily— sentences our opinion and appreciation of everything that borders our surroundings. Everything we do, therefore, will leave a trace: our immortal past, which is inevitably part of the cause, directly transforming us into the consequence we are becoming.

For the estimation of our values, we will arbitrate their resolution. Encircling our sanity and specifying what our disposition dictates. If we do not value ourselves, our values will be diminished in the possible shyness of cowardice. We cannot be upright or free individuals if we do not value ourselves. Otherwise, at least we will have the opportunity to be so to the extent of our possible considerations.

I refer to forgetting ourselves:
to our forgetting in the mornings when we wake up,
to our forgetting in every moment,
to our forgetting at night when we go to bed.

What is it to have lost everything when we still have the confusion of uncertainty to discover? Or to enjoy.

Reflecting is a way to address the daily dissatisfaction of emotional emptiness, not just as a random habit without responsibilities or expected outcomes, because who would ultimately care…?

Let us not stop meditating, observing, diagnosing our impressions, enjoying reflecting, and resolving our sensations to better appreciate everything that deserves our attention and understanding and our commitment: our life.

Habits

Reflecting as a method, as a solution to the daily dissatisfaction of lack of feelings. Routine for our being, skill for our experience.

Habits that define us determine us and even limit us in our possible dissatisfaction, from our basic instincts through simple reflexes to the most complex ones that seem unwilling to be tamed.

We are unconscious habits that we should consciously learn to understand and accept to overcome and improve because any habit that has never been questioned can never be overcome.

Skill as desire, as the practice of our mastery: trial and error to later inevitably acquire wisdom.

Where did our daily habits go? Knowledge is power. And power will allow us to choose what we truly want for ourselves. Being aware of our routines and their reasons will allow us to choose and be responsible for our actions.

Exercise our custom, our praxis. Feel useful in our reconciled dream, prudent with our judgment, and consistent with our maturity in the face of what is truly serious.

Study of our behavior, attempts, responses, observation, and empiricism beyond mere theory: pragmatism for and with us in our daily lives. Because words are superfluous when actions speak for themselves.

Chapter 23: January 2017

2017-01-01T00:00:00+00:00

False freedom

Life tends to chaos, partly because of its faults and lack of preparation. Not questioning being completely exposed momentarily makes us aware of the surrounding emptiness.

“Sharing your true self” is simply being completely sincere with yourself. Genuine understanding is impossible for someone who is insincere for their gain.

Doing something with one hand while hiding it from the other is the most impure action against our conscience. It condemns us until life, in its unfairness, judges us.

An extraordinary person should aim for deep understanding, not be sidetracked by absurd excuses. Sometimes, clarity is obscured, especially on good days or in darkness.

Hypocrisy is thinking foolishly, lying, and undermining our strength and confidence. It’s not leading by example, contradicting ourselves, and being afraid to be true to our beliefs. Before criticizing others, we should examine our actions. Examples of what?

A clear conscience is crucial for reaching the fulfillment we dream of, even if it seems like an illusion. We’re accountable for our actions and inaction. One challenge is overlooking our responsibilities and limiting our freedom in a “just” world. Avoiding responsibilities removes our self-determination, leaving us with a false sense of freedom.

Living in a false reality occurs when we think we’re someone without authority or justification. Without evidence to support our claims, our freedom is tied to our responsibilities. Demonstrations matter because we reflect our sincere intentions for the future, closely connected to our past.

Acting as if we can live without responsibilities in a fair world is hypocritical and foolish. Ignoring the chaos around us daily is akin to avoiding going outside to see the sun, choosing shadows and darkness instead.

I reject those who, upon hearing the allegory of the cave, believe that those who killed the one who saw the sun are cursed. Some just wanted to share the truth about light and the sun, but some preferred shadows and darkness, hindering sincerity and progress. I don’t respect those who express dissatisfaction after the allegory but repeat the same behavior daily with weak excuses and deceitful actions—hypocrisy filled with false testimonies and misleading seductions.

Free for what? Are you free to lead a life full of cynicism as something natural? When truth is treated with pretenses, with subjective interests…, freedom is reduced to its minimum sense, for our freedom is not only our external range of motion but also internal.

We will be freer the more we know ourselves and belong to ourselves. Our self-determination is crucial to understanding our will to power. Our confidence, daring, audacity, and intention will be the gauges of our degree of freedom.

Living occupied

We should not live worried but occupied and not neglectful of ourselves.

Occupying ourselves with ourselves for as long as necessary with the primary goal of finding what we truly desire. What could we desire more than our dedication to what we truly want? For who in their right mind would not want to take care of themselves for themselves? I refer to the healthy selfishness of our duty.

In search of our fullness, we move with fears and possible misgivings about everything we do not want to understand. Uncertain fears are born of bewilderment because no one was born knowing how to love.

To us, eager for life, I refer!
Let's not let ourselves escape so easily!
It is enough to use our consciousness
to create our path with it.

It is much less when we still use reason,
even if it sometimes seems only unconscious.
I refer primarily to those with a blind attitude,
for it is not true that we are bound hands.

Pity for those careless will, determined to stumble on the same stone repeatedly. Sorrow for the obstructed, those whose desire tends not to be, sharing their same feeling toward the rest, who have to endure them; however, they can infect anyone in their capacity as much as possible.

Only disgust and sorrow for all those who reject their power, as well as their duty to be, but above all, to want to be. Loving our passions cannot be disconnected from the occupation of them: existing with a unique sense that identifies us to the rest, which we contemplate day by day, must be linked to the activity itself without falling into the attempt to escape, preventing our sincerity from being sincere with us.

Truth be told: finding the balance of our occupation for ourselves, our first task, is the foundation where the pillars of our purpose are located. Therefore, our motivation toward our goals will notably mark a before and after to the extent of our seriousness for ourselves.

Being true to ourselves in thought and deed to evolve every day more, aspiring one day to honestly want to take care of our lives to become who we want to be.

The importance

The same disposition to the importance of everything, of moments, as well as their absences; consideration for what surrounds us and the nothingness that could approach us at any moment.

Interest in what we should value above all in no measurable magnitude. I refer to what we should consider rising towards its fullness as a transcendent entity from nothing to everything. Our life and its proportions of sizes and trends are as diverse, abstract, and eloquent as it disposes itself.

The rhetorical seduction of its abstraction and idealization is what we aspire to without reservations but, above all, without fears beyond those that situations themselves will present to us.

There will be no need to fear spontaneous meditation with scents of truth because it will always be waiting for us.

The magnitude of everything that tends towards insignificance, towards ignorance by desire, towards the emptiness of its meaning, towards the frivolity of its importance.

The impact of our interest, the effectiveness of our reach, the magnitude of our desire, the seriousness of our commitment…

"How much are we worth?" is the question.
"How much are you worth?" is the answer.

Chapter 22: December 2016

2016-12-01T00:00:00+00:00

Slave to Death

Having death so present day after day, so recurrent, is something inevitable for us. Being aware that our time is not infinite should make us question what we want—or should want—to invest it in.

My greatest fear is the sudden headache that sometimes assaults me when I try to fall asleep. I’m not talking about emotional pain but physical because, in addition to seeming random, they could be playing for the last time with no chance of a replay.

This is what happened and what could happen again: headaches in the darkness leading to the ultimate uncertainty we all fear so much—death.

Especially at a distance, where I would only have myself. If any tragedy were to occur, there would be no first ones to find out… only seconds and thirds, as these first ones could do nothing but suspect and deny what possibly happened until the truth becomes inevitable.

The origin of the tragedy could arise at any moment, which, along with the beauty of its uncertainty, unveils me until it clouds the rest of my senses.

Unveiled by death even during the day. Witnessing nothingness, as well as its apparent and absent presence.

Hunger for a defined reason, logical and rational sense, for projection consented by our cause. Thirst for understanding, for comprehension, for impulse towards what fulfills us.

Fear the slavery to the inevitable that will end any opportunity from happening.

Singularities

Complex singularities with consequent rational use. Temporal moments with projections are so unique.

Abstract experiences that continue to orbit themselves, seeking evolutions in the measurements of their interests.

Ideas explode and vanish like simple sparks when not disciplined and worked on to temper their flame.

False lack of opportunity for not wanting to transform from the same form.

Guidelines without an apparent direction, some more and less consistent with their responsibilities.

Lack of principles that isolate us from our purpose and reason for being. There is a lack of arguments that invite us to believe in what would not hold.

Belief in the boldest lack. Ignorance better internalizes prayer to the insult—dictator tales for those who dare not to question.

Death is a real determining judge.

Education

The problem with education is that it does not teach the importance of responsibilities and the background that should be acquired over time. Education is linked to responsibility and, of course, united with our freedom.

Our education comes from learning the consequences of our actions. The lack of education occurs when we are taught incorrectly about what we truly deserve, especially when we forget our responsibilities and push our obligations aside. Surprisingly, our reward ends up being the same as those with a proper education. So, the question is: What is the appropriate education then?

The correct education is the one that teaches the greatness of our actions, starting from a perspective of personal improvement: wanting to be better than ourselves day after day.

Our actions should react equally to what we do; we should act as we want the world to behave with us. We should thrive as we would like to see our loved ones thrive. We should be like that person we would like to know.

Chapter 21: November 2016

2016-11-01T00:00:00+00:00

Sweet memories

Patience and tranquility.

It is not difficult to realize that everything is constantly changing as long as we genuinely want to be a part of it.

Feel that all these adventures throughout this time have been nothing more than the result of the circumstantial needs we have found ourselves surrounded by. And we, trying to overcome all adversity with no greater guidance than the hardness and spontaneity of that which surprises us so much day after day: life itself. Without a doubt, we will be the ones to have the final say about our being and its decisions for posterity.

For those memories that still haunt us and travel wherever we go. We take care of them to the extent of their value, encouraging ourselves to improve alongside them. Still, above all, we understand that we are the product of them today but not necessarily tomorrow.

Not neglecting our aspirations, those desires we long for, that reference we might miss so much… Looking at ourselves and recognizing ourselves without the need for mirrors. Reality sometimes seems so distant and different from how we believe it should be because observing ourselves without reason will inevitably distance us from our essence.

Memories still awaiting their birth. Thirst for reflection, but above all, the desire to build the best version of ourselves. Until the end of our days. Wishing for a bitter farewell then, but inevitable and abundant sweet memories.

Even

When plans become so unrecognizable, accepting them becomes a challenge in their complexity.

Admitting the uncertain future is so complicated that even the future itself would be frightened by its unforeseen events.

Unpleasant surprises are so inevitable that even our own destiny would be alarmed by its so unnoticed and possibly commonplace tomorrow.

Blind opportunities that, along with indiscreet verses, are surprised day after day by their adventures, some so uncontrollable and others so sudden that even sleeping without dreams, living without aspirations, tend toward dissatisfied normality. I am those blind opportunities. I am those indiscreet verses.

Insecure and alarming suspicions until the moment comes and reality surprises us with firm harshness—and unbreakable certainty—regardless of our possible discontent.

Inevitable discrepancy. Discontent with that situation that seems to surpass us by too much. Still shaken to assimilate.

Adapt to everything that is yet to come. “He who stumbles and does not fall, advances.”

Our biggest mistake

The two most significant human errors are the religious and political denigration to which we have led ourselves. And I say two when I could say one; we could abstract these branches, as distant as they are linked, into a single fantasy that seeks the well-being of oneself.

What is religion if not a spiritual utopia? It is not conclusive but adaptive, according to the time and cultural trends in which, as rational beings, we have been evolving. And what is politics if not the administrative ideal of the public with which it seems we are obliged to coexist?

Both politics and religion have always gone hand in hand, to a greater or lesser extent. And I don’t mean that they are superficially linked, although historically they have been. Even if we try to unlink them today, this connection goes beyond an apparent simple connection.

Religion, like politics, reflects our failure to understand ourselves as equals. It is the purest evidence of our impurity. It is the manifesto of our reality and our lack of understanding of what is not us.

Both religion and politics are nothing more than unattainable utopias intertwined without an evident end. They are the problem without a solution, the paradox of their logic, as we will be forced to deal with these issues until the end.

I am not asserting that both politics and religion are unnecessary and senseless. I declare that we will be wrong in claiming to be right in any utopia. Politics is necessary; hence, it reflects our lack of understanding, just as religion is evidence of our backwardness as rational beings.

Ultimately, politics must — or should— ensure our well-being as collective beings. However, religion has abused ignorance, both of those who wanted it and those who had no other options.

Therefore, our biggest mistake will be any belief disposed of— even predisposed— in any utopia.

Chapter 20: October 2016

2016-10-01T00:00:00+00:00

Entropy

A simple thought is enough to make us realize how fragile we can be.

The entropy of our being tends toward disorder and chaos; just a few careless days, and we notice that life slips away in a constant struggle against the potential confusion of our every day, with its greater and lesser challenges, as well as involuntary pressures.

In the end, everything will be a battle against entropy, which tends to confusion and entanglement in itself. Our eternal struggle should revolve around combating our disorder.

All for our future, for when we remember ourselves again in a few years with affection and, why not, a bit of longing. Wishing to feel proud of who we were in the past days gone by. Above all, feeling proud of the trail we leave in the face of any adversity provoked by our concealed entropy.

The Future

The future is not for those who constantly plan or for those who dare not take a step forward and confront themselves, especially when overwhelmed and without reason to seek the motivation that seems elusive.

On the contrary, the future belongs to those who develop their present. Because motivation comes and goes, but passion is born, progresses, and grows with us.

The future is nothing more than our reward for our present. Of course, life’s surprises may sometimes leave much to be desired, but we are not referring to those in particular. It is our projection that matters for the development of our present. The influences and perspectives that make us progress as individuals will determine our growth.

What can be more important than our fulfillment in our sincere development as individuals?

Let’s not allow bad weather to prevent us from being ourselves. Let’s not stop thriving to the best of our abilities. Let’s project into the world what we would like to feel, for we are the world but, above all, the future.

The Pragmatic Programmer

2016-10-01T00:00:00+00:00

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.

Chapter 19: September 2016

2016-09-01T00:00:00+00:00

You Only Live Once

You only live once, or at least that’s as far as we can comprehend. We all have problems, to a greater or lesser extent, of importance relative to the interests and intentions that may be hidden behind them.

Lying to ourselves about our thoughts or what we believe to understand as reality will make it nothing more than a deception from and to ourselves.

In simple terms, we might say that each person has their view of reality where we live together and share things. But when we ask, “What is reality if not how we see it?” we hesitate to say there’s one reality for everyone. Instead, we create a shared reality based on our perspectives.

The most significant harm we could cause to the world, to tangible reality, and everything practical and pragmatic is and will be the lack of seriousness in our honesty towards ourselves. What diminishes us is the lack of the essential towards ourselves: our loyalty. What makes us great in the world is the overdose of sincerity that we should practice with ourselves daily.

Life has been, is, and will undoubtedly be full of difficulties. But in contrast to them, attitudes play the role of our projections, our profound realization, and our perception of objectivity.

What is our existential concern if not the ultimate taboo topic due to its already known absent answer? We should be the ones acting at all times. Our role was never written. Being the protagonist will be only a matter of predisposition to be so. Genuine predisposition, I insist!

We should not beg our apparent reality or even trust it more than what our eyes can see, for in the doubt of its existence will reside, for anyone who seeks it, the answer.

Young and Innocent

How young and innocent we have been, simply believing that we could evade the maturity that actually surrounds us. Concern, justified in our commitment, will be linked to our seriousness in our profession. Understanding that learning is and will always be a continuous thing linked to our responsible prudence.

So many mistakes we have made and will continue to make… that only with continuous improvement will we feel fulfilled, for there will always be so much to renew…

We have such limited time that boredom should not have a place; to live disheartened will be, therefore, not to live.

Learning that understanding ourselves is not easy; it will not be, either, and absolutely, something overnight. Only in the search for understanding can we learn from it.

Today, we should read ourselves with different eyes. Eyes renewed today, aiming at the triumph of the uncertain tomorrow.

This has truly been a path to our understanding where we have learned many things together, remembered many others, and dreamt a few. But undoubtedly, an experience that deserves not to be forgotten, at least for our memory.

Ending to Begin Again

Ending to begin again. I smile. I have tried to play with words in as many ways as possible. I have tried to reach the limit of their possible connections, and there are so many… I reread myself and enjoy it; it makes me feel alive.

Do you know what it is to have goosebumps when thinking about your present? About everything you have ahead waiting for you?

I am eager to see my family again, hug them, and feel them close. But I am not willing to let go of the opportunity for which I have been fighting all these years and the ones ahead.

So many things motivate me to continue… Still, among all of them, I highlight seeing my siblings grow and enjoy a present full of surprises together, not allowing them to ever feel alone or lacking an older sibling.

It has been two years in which maturity seems never to finish reaching us… even though it could pretend to be daily. The brevity of time is not the real problem, but the use we make of it. Ending without entire finishing, being able to start again and again; I refer to death, for we are still alive.

Love our family. Enjoy, but above all, seize the opportunities. Fight for personal growth, understand ourselves, and not settle for being what we do not want to be.

As if it were the last day of our lives. Let’s indeed be ourselves.

The Day After

Living is not breathing an air full of uncertainties and misfortunes.

Wanting is not stomping or hiding behind the false refuge of right or reason.

Growing is not waking up day after day without ambitions, both short and long-term.

Waking up is not opening our eyes after the dream we might prefer over our present reality.

Learning is not memorizing or repeating without understanding.

Fighting is not puffing ourselves up in a simulated breath of superiority over someone other than ourselves.

Allowing is not right when not truly deserved.

Letting insecurity judge us is not balance or harmony.

Missing is not the absence of pain.

Living is taking seriously the before and after of our days. Wanting to grow by waking up to learn to fight will allow us to stop missing living because we will be truly alive.

Sprint

2016-09-01T00:00:00+00:00

“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.

Chapter 18: August 2016

2016-08-01T00:00:00+00:00

I’m back to being myself

I don’t want to end this adventure just yet. I’m sharing my experiences and thoughts from these years, trying to gather the ones I can, even though some thoughts chose not to be written for reasons unknown.

I am back to being the one who writes to you, feels you, and thinks about you—the one who writes for himself and you who are reading me.

I am back to eating healthy, feeling alive, and exercising regularly. Taking care of myself and genuinely caring about what I do. I am back to avoiding losing my head in tornadoes that lead to unnecessary confusion. I am back to feeling alive and, with that, happy with myself and what I do.

I am aware that life consists and will consist of constant ups and downs. Sometimes seemingly arbitrary, where disorientation and concerns may cloud us on who knows how many consecutive occasions… but let that not take away our breath or our desire for self-improvement.

It has been a journey filled with countless experiences, where responsibilities and duties arose from many different places and forms, sometimes even in such short intervals. Who could have been prepared or warned of such a situation? Simply astonishing.

I want to improve as I wanted to do years ago… and I believe I have found the answer I was searching for. Continuous learning, with no more mystery, will lead us day by day toward our improvement. Learning about ourselves!

What are we? What do we want to be? Where are we going? What are we doing here? What is our purpose or motive? All these questions have the same answer. An answer that can be as different as we want it to be. The briefest and most straightforward answer, as well as the most complex in itself: the answer is you.

With Different Eyes

Guided by mature responsibility, teaching us to become our authentic selves, as if we are still figuring out our desires. This perspective aids in cultivating our basic instincts, connected to our rational and compassionate side.

What could our self-improvement be without the sincere evolution of maturity in our ideas? It will be nothing more than reconsidering our judgments and sensations, as well as our knowledge and perceptions. It will allow us to improve directly from the root of our projects and dreams, as well as convictions of all those concepts we believe we are not wrong about.

Maturity can only be directly linked to the commitment to our responsibility and seriousness in our duty, with love and passion… always.

It is true that with different eyes, we correct ourselves and speak to ourselves today. Most likely, we will continue to do so from now until one not-so-distant tomorrow, for we have learned so many things in these years…

With different eyes, I look at myself. With different eyes, we grow and want to keep growing until we lose our breath.

For you, for us.

The Clean Coder

2016-08-01T00:00:00+00:00

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 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.

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.

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.

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.

97 Things Every Programmer Should Know

2016-07-15T00:00:00+00:00

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.

Good tests act as documentation for the code they’re testing.

They describe how the code works.

To be a good programmer, you have to care about the quality of the code.
Really, really discuss things with your customers before assuming you understand what they want.

Chapter 17: July 2016

2016-07-01T00:00:00+00:00

Understanding

Realizing the delicacy of the whole, the daily and necessary effort to remain consistent in our eagerly sought satisfaction. In this yearning for emotions, sometimes so disparate that like a tide could be reflected on the same ocean.

We would like to resemble calm waters, but only to the extent necessary. Because needing what we desire is not the same as desiring what we might need. So much prudence is needed to keep ourselves coherent in this reality full of unforeseen events.

Because, in the end, everything will be a matter of comprehension and understanding the world: its responsiveness to our restlessness, its daily novels and lost stories, its desolate uncertainties forgotten in possible infinite chaos… It will be an illusion beyond understanding anything that escapes our comprehension.

This confusion is without an apparent beginning or answer. Decisions that could have annihilated us. Readings of life that we failed to understand. Arguments that didn’t even know how to find a place in our understanding.

Comprehensive understanding of reading our lives daily: that will be the majority of our deepest and most sincere unanswered questions.

Eternal Return

We will refer to an eternal return only if the sincere pursuit of our improvement is being carried out. We will make mistakes again and surely fail in many of our attempts, but in the end, we will return to our path, where our profound personal improvement will be the goal.

Realizing this return not by reading it but by living it. Experience will be our most outstanding teacher if we let it teach us. Open doors will be offered to us, or maybe we have opened them ourselves, but with the real importance of our word, it will be up to us to decide and act accordingly; we refer to the duty of whether to enter them or not.

Returning not to another possible life—uncertain as it may be—but in this one. Feeling overwhelmed to warn ourselves, another day, of our long-awaited desire, flooding us again without prior notice.

As paradoxical as answers, we might find the meaning of what we genuinely want to discover. And possibly, part of our journey lies there: in the attempt to maintain our course with more or less clarity depending on the occasions we encounter, but above all, on how we face them.

Stages that close. Beginnings that end. Endings that approach. We, as eternal temporaries.

Disposition

Thinking that we cannot or are incapable of more is simply a fallacy. What we understand as our actual capacity, or rather what we believe we know, is a mere and abstract perception of what we estimate. Estimating will be nothing but considering what is necessary to reach a settled goal.

The proximity of our perception to what we expect from the reality around us will be directly proportional to our predisposition and our preparation for it.

The simple denial of our possible predisposition to what we want to achieve will imply, without the need for words or other arguments, a disconcerting brake. A brake guilty of our lack of breath, whose mysteries will grow as the days pass, using our doubts to step stronger and stronger.

The question of the question. Let’s prepare our disposition towards and for ourselves. Improve our skills without stopping to educate ourselves, but above all, never stop wanting to improve.

It is time to pay more attention to ourselves, especially when we need it most. Who said there was a hurry in this game where the will does not necessarily always have to go along with our final decisions? This is what we mean when we talk about perseverance in our training: we will never know with certainty if this will be, fortunately, or unfortunately, the last day of our lives.

As valuable and unique as we have wanted to work on them. As invaluable and extraordinary as we have wanted to consider them. As brave and accurate as we have tried to shape them throughout this journey.

While Time Passes

As the years go by, our existence is forced to wither. The longevity of our life will be as limited as it could unexpectedly be surprised at so many accidental points.

Over time, everything happens except time itself, which, with cold blood, seems to remain static and, simultaneously, the center and root of any topic.

Maybe we are only returning again and again to that moment so longed for by us. What is casual in this life? If not, what could escape our time?

As time passes, nothing can stop; everything is conditioned by it. Everyone, without exception, is concerned. Time does not exist, but we do, and we cannot control it.

With its transition, it is the only one that does not elapse. Every second, every moment… it is not it that happens, but us.

We are not referring to what is nothing more than an invention that helps us count, measure, and calculate in the end. We talk about those moments that pass not only when we look up but also when we lower or turn our glance. The time that passes when we think we are letting time pass, what we are letting pass is not time but ourselves.

Some

We will not realize what is truly important to us until we feel desperately that sensation that empirically demonstrates, from its maximum complexity to its timid simplicity, the fruits of the path we are pursuing.

Some will never be ready, not because they cannot, but because they will not want to be more than what they could believe within their already conditioned comfort.

Because it is not about what we are now but where we are being directed at this precise moment by our attitude and will and how we pay attention to them within the limits of our possibilities. Because beyond the mere fact of the decisions we may make, we will have to assume their risks and act accordingly: that will be the main difference between some and others.

Not everyone will dare to be part of it. Not everyone will want to be, as not everyone will be willing to pay a price that could exceed us. Nothing could be further from the truth because what will indeed overwhelm us is, for the most part, the neglect of our deep and sincere listening to what we desire.

Fear of responsibilities, excess freedom, enriching experience, and well-spent time. The fear of ceasing to be what barely required effort to maintain due to its constantly changing evolution that every day requires time and attention. The Superman will not be possible overnight.

The Most Difficult

The most challenging aspect of life is understanding the coexistence that exists and will exist with ourselves. I learned that not every day will be perfect in our eyes, and there will be even more than one where we feel genuinely overwhelmed, even by ourselves.

The day will come when we realize how wrong we can be; in that realization, we are fortunate in our learning, especially when it concerns ourselves. We will become who we want to be if we are honest with ourselves.

Living in a lie or a simply unconscious reality will subtract from us the life that belongs to us and everything we could experience. We can assert, therefore, without any fear, that the truth lies in sincerity towards ourselves.

The most challenging thing in this life is to learn from and for ourselves. There will not necessarily be two identical days, but each one will be different in the degree to which we choose to invest and move forward. Undoubtedly, the most difficult will be to achieve an understanding of variety in every sense.

The most challenging part will be to renounce conformity, especially when everything seems to be heading in the direction we expected. We must take each step carefully because the most difficult will come then: surprises from life that we will have to face with no possibility of evasion.

The most difficult will be recognizing that perspectives can change our perceptions of an apparent same and unique reality.

Chapter 16: June 2016

2016-06-01T00:00:00+00:00

What if…?

What if we stopped referring to ourselves in the third person and looked at ourselves with different eyes? What if we tried calling ourselves by another name? What if we stopped worrying or thinking about setting aside our rational thoughts for a day?

Who could assure us that our objective feeling exists and is not just a variation of our unconscious belief in what is impartial? What if we called everything by its name? What names would exist? And more importantly, what name would we have?

What if we learned not to let go of the reins of our lives? How could they slip away without us realizing it overnight? What if everything didn’t have to be necessarily so challenging or complex, especially in some situations where everything seems disproportionately arranged?

What if we threw in the towel, saying ‘enough’ to everything? What if we decided to end it all once and for all? What could worry us so much to the point of leading us to such an irrational but necessarily human thought?

What if we didn’t feel with a force that could even provide pain? A force is born from the same feeling of joy or sadness because if we were not passionate beings and rational, what would we be then?

What if our time was not directly linked to our understanding of it? Wouldn’t this be chaos? What if everything wasn’t as we might believe it to be from its complexity tied to apparent confusion with no way out?

What if everything were simpler? What if we were wrong? What if everything turned out well, returning to normalcy and its deserved tranquility?

The abundance of disorder in harmony with its idea of normality and desire is astonishing. ‘What if…?’ We might ask ourselves.

Who will remember us?

Who will remind us of how much we’re worth when we forget? When harsh reality shows its face, we are scandalized to see ourselves completely naked in our consumed sensation born out of our ignorance.

Who will remind us how much we’re worth and how wrong we can be? Especially when our thoughts or value judgments might be about us, lacking consensus and not at all constructive.

Who could remind us, if not you, of the legacy of our interest? Even if it may not be widely shared, we are sure there is much more in common than we could initially see with our own eyes.

Who but you could remind us of who we are!? Extend a helping hand and help us get up when we stumble. And I’m not talking about us, but about you, who has a name and a surname. You, who are reading this. You, who knows who you are, even though sometimes, like us, you might forget. You, who, in your doubts and uncertainties, wanted to hide, as was typical.

As if anyone had done it, and we didn’t care. But not you. You do matter to us. And that’s why we write with you in mind. We know we’ll rely on each other, so they won’t be alone when we face challenges. Together, we can navigate through tough times, making the journey as bright as possible despite the occasional darkness.

Not you. You are here to remind us how much we’re worth, just as we will be here to remind you how much you will be worth.

A matter of time

Growing up is not just a matter of time; it’s about learning from mistakes. Observing life pass by without motivation is a significant error, yet it’s an unavoidable symptom.

Things don’t happen simply because they were destined to; it’s nonsensical to believe in a predetermined destiny, especially when we could attribute events to convenience.

The idea that everything is preordained or written, even in the most absurd or random ways, is unfounded. Pretending that time has a life of its own is a self-deception. Time doesn’t exist independently; it’s a construct of our perception.

Growing up in a questionable environment, we may have been influenced by arbitrary choices and exposed to controversial places without even realizing it.

Our perception of truth is essentially what our subconscious uses to grasp our apparent reality. Time, another tool we’ve created, helps us make sense of our journey and circumstances. After all, who else but us can thoroughly analyze the aspects directly tied to our senses?

The wilting of flowers isn’t about time passing but the absence of support in the face of life’s challenges, leaving us all equally confined with no recourse. What does time matter when our time has run out?

Growing up isn’t just a matter of time; it’s about experiencing and learning from suffering without prior warning. It involves thriving in our concept of good and evil, progressing within our limits, and developing into what we desire or could have desired.

Treating our understanding with sincere perseverance is never a matter of time; it’s a constant effort.

Starting at 23

Let’s take a moment to look back, but not too much. Just over two years ago, we began our professional journey, dreaming about what we have achieved with great effort. We started in our hometown and turned the place where we went into our own.

An exemplary effort with a smile that bloomed every day from the most absolute sincerity. Where we became aware that we had the opportunity within our reach. Starting from the bottom to gradually climb the mountain of what was to come, what we could distinguish as our learning.

So many diverse thoughts have passed through our minds, so much time in such a short space… that if we had to emphasize one in particular, we would have it clear right now: the stress we may experience at times, the result of the overwhelming feeling of not being able to handle everything that might come our way. Perhaps because it is the last sensation suffered with greater intensity. When putting everything on the line, half-measures will only leave arbitrary stains that we must deal with regardless of our possible dissatisfaction. Let’s hope we learn to overcome all this more easily, a product of an unconscious world where concerns sometimes seem to limit us and not let us see possible solutions.

It is worth noting how much we have learned about everything in general, but especially about ourselves. Those moments undoubtedly help us to converse with ourselves, more or less restless depending on the day and time. There have been so many unwritten dialogues that only our unconscious will remind them when necessary.

We will start at 23 as we never dreamed of in our childhood, but as we have been striving for these brief but intense years.“

Chapter 15: May 2016

2016-05-01T00:00:00+00:00

In the end

One step away from everything and one step away from absolute nothingness. Unlike everyone and no one. Where the true reason for being hides behind the vain intentions of perishable purposes that fade over time. In the end, only the memory of what truly interested us will remain.

We tend to mix so many different concepts that we end up combining them all, making it something admirable if we could differentiate and classify what we mix. We are talking about our value judgments; there is often so much distance between our personal understanding and the real objectivity that each situation might deserve…

We should learn to discern, at least as much as possible and always make an effort, what truly arises from our feelings and what arises from our reason argued empirically. For we are so human… letting ourselves be carried away by the same emotions betrays us time and time again. And we are so human… that our pride will blind us again and again without necessarily warning us first.

We will all end up being right about so many things and not so much about others, none even. We would be scared if we became aware that such statements coexist in the same shared space. In the end, only we will remain, and no one will be right because everyone will have been. That’s why the important thing here shouldn’t be about a “And in the end?”

As if they were necessary contradictions, with which this life is filled. Tonight we write without the intention of inventing anything new. We’ll discover only as much about ourselves as if we were strangers, tuning in to listen and read carefully to what truly matters to us, finding clarity in it, and getting ready for any potential outcome.

Having lost

Feeling that we have lost some part of that essence that made us, in that sincere way, feel. Noticing that the same notes sound different than they did not so long ago in an altruistic way.

Furrowing the brow in doubt about oneself. Realizing a slight psychological confusion in our foundations, which were once fundamental pillars, will cause us fear and apprehension accordingly.

Finding and solving problems was our greatest reward, for now, like those cowards we used to criticize so much, we see ourselves reflected: scared in our confusion. Problems need to be solved, not just with patches that simulate their correction or hide the root of those discomforts.

How far do we still have to go? How great can the abyss in which this life, with its disparate emotions, become? How little can we know about knowledge itself in our attempt?

Perhaps it has been an unnecessary concern. Perhaps it has been in small accumulated doses like a snowball that grows as it rolls down the hill.

Conformity, lack of motivation, the absence of a smile without reason. The excessive absence of unselfish affection. Fear is not the culprit of anything, but the symptom of motivation’s lack in the face of the reality we have to confront day after day.

Perhaps it has been nothing. Perhaps we still have so much to fight for without fear, to achieve what we truly desire. For what could we long for more than to have that motivation to reach those altruistically predisposed dreams?

Perhaps there is less simply from this daily reflection that has lately tormented us, a reflection that some days seems to have lost control.

What is it to have lost something, after all?

Are we really?

What are we really? What could we consider as our true selves? What is that identity that could differentiate us from the rest? Are we the same person in essence as we were some years ago? What if we change the time of the previous question?

Are we different people every day? What is it that identifies us as individual beings to the rest? What is it that distinguishes us from our surroundings and by which it recognizes us? What is that essence that sets us apart in this paradox full of random questions and apparently dictated laws from the most absolute senselessness?

What will identify us, that will truly make us, that will represent us to the outside world? That which defines and characterizes us but, above all, individualizes us and sets us apart from the rest of the vast ensemble: it is our past directly linked to what we have learned from it.

The importance of our experience and perspective, of our projection and confidence, of the investment we wanted to make of our time.

The difference between wanting to be and truly being is not as vast as it might seem or as some wanted to paint us. The same is found in the projection of success.

Our past is our purest self: when we die, there will be no more identity of ours than the one we wanted to reflect.

Therefore, our present representation will be the result of our past understanding linked to our unbreakable and true understanding that will not stop testing us again and again until our breath rests without permission and without return.

The history

History is the open book of our lives, recorded for remembrance and learning that only a few dare to read. Destined to repeat the same situations, the same mistakes that others may have already made, it seems that committing them was in our nature.

What mistakes are more than purposes that make us feel wrong in the end, conveying that unmistakable disinterested anguish? Anger… towards those fools who did not know or did not want to read the signs in time to learn when to hit the brakes.

Like a book complete with mistakes and successes where the battle between them seems balanced no matter how many days pass. As if there were no tendency towards the existence of an ending with a clear winner. It is as if our disposition leaned towards repetition to the absurd because sometimes it’s not that we are blind, but that we do not want to appreciate. And that’s when the value of history scares because there is no blinder than the one who does not want to see.

We could keep writing about this, but we are tired, furious, and perhaps even disgusted to think that there might be people who don’t want to think.

Let’s reflect then on our history, especially the one we already lived, projecting it onto what we want for our future.

Numbers

Forty-nine, as the number representing this day: May 25.

Thirty-seven, as the ephemeral memory, inconsolable by excellence.

Eleven, like the one who, without seeking it, addresses himself in the third person today.

Nine, like those who remained and were forced, with no other options, to learn however they could from that situation, unexpected for everyone.

2004 was the most human and heartless year.

Zero, like opportunities for possible farewells after his departure. I don’t even remember how the day before looked, but his curly hair and her kind smile… And only reaching in our memory his reflection behind the door frame in the dark hours of the night, with no time even to say goodbye. Because no one could have guessed what was about to happen a few weeks after his departure, his impossible involuntary return.

Hundreds of nights have passed since then, and we can hardly find moments of intimacy in these letters that we both know you will never be able to read. We won’t get to know each other, but I am sure we could recognize each other… and let’s be clear that there will never be a greater desire than a smile from you back towards our gaze as you search for us.

I don’t remember when I last said “mom,” and I think that’s something my first person will never forget.

It’s pretty challenging and complex. It was the most expensive price we could ever experience. It is one of the most painful experiences we could have, and undoubtedly, all, without exception, will end up having sooner or later. And we will understand, perhaps with different eyes, the one who writes about himself in the third person today.

Trying to understand ourselves

This final stretch is just a few days away from the internal time change, with boiling tea as a supplement to those sad thoughts that could unintentionally invade our minds at these hours.

And we realize the lack of genuine interest we sometimes desperately need. Because what seemed evident in its normality not so long ago took a bit more effort to practice today. We are changeable for better or for worse.

The theory could never be easier than being written in itself. However, putting any theory into practice requires greater effort than its simple understanding: it means making that theory a reality, for there is no greater theoretical truth than the one that can be demonstrated.

With boiling tea, we realize we are in the final stretch, just a few weeks away from who knows what. And by this, we are not referring to living carelessly, but quite the opposite, to living in love until we consume ourselves in it! We are in love with what we do, with what we feel, with what we truly desire, and with ourselves. Beyond mere vain ideas or unknown concepts, let’s get to know each other in-depth! Let’s feel as we genuinely want to feel! Let’s wake up with those devouring eagerness to sweep through the day that we dreamed so much about! What the hell are we waiting for?

We did it once, evidence enough to realize that it is possible, that the word “impossible” is mistaken when it could refer to us.

We are nothing but possibilities, still waiting to be awakened without fear, eager to see the rising sun until we lay down in our well-deserved rest. Accompanied, at least, by our idea and global vision of the conquered day, and conquered it will be, for we will be the ones who have won. We should, therefore, perceive the days as achieved and not as past or lost.

Contemplate and learn to discern what we would like to change. What is it that we would really like to improve? What is it that we would honestly want for ourselves? Let’s dream about these questions. Whether they remain in a theoretical or practical dream will solely be a matter of our reward.

Clean Code

2016-05-01T00:00:00+00:00

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:
- 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:
- 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: 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.

Chapter 14: April 2016

2016-04-01T00:00:00+00:00

To Appear or to Be

We can appear as many things and act in so many possible ways… to the point, perhaps, of clouding the true self. What is this self really if not the sea of its continuous appearances? We can appear at all times, but could we truly be what we appear to be?

The problem of identity arises when our appearance confronts our sense of being. That’s when our main inner conflict arises. Are we more than constantly evolving appearances where adaptation is linked to survival? What are we really if not the simple feeling that distinguishes us from our surroundings, referring to other beings?

Do we have a greater right to consider ourselves special or something more than simple living beings? Who can assure us every morning when we wake up that we are not just a product of some experiment, where in reality and memory, we have nothing more than some pre-programmed memory ready to observe our behavior?

Sometimes we will doubt even who we are, what we are seeking, or simply what we hope to find. Could doubt themselves be their own answers?

So Many

There are so many things to do and so many wishes to fulfill. So many sighs still waiting for their moment as we take turns with our restlessness, letting it guide us to the paths we will eventually shape.

So much haste, so much unused joy, so many undeserved tears, and other forgotten stories.

Our perception of reality is so different and so dependent on ourselves that we couldn’t even be aware of the countless varieties and their different qualities so distinct from each other.

A scorching sensation that confuses us when we let our guard down. An alarming emotion that accompanies us in its unveiled conformity. Intuition that leaves no trace of its passage. Longed-for relief, as well as missed, in complicated times.

So many goals, so much future, so many stories… that we might even end up forgetting where we come from and where we are going. Feeling the desire for a pause. Feel the confusion of not knowing what we need to know now, lost in these moments of entangled reality.

There is still so much to tell and to live, so much to know and to desire, so much… that we hope everything will turn out well when the time comes.

Constants

We are a silent constant of ideas. Constantly dependent, to a greater extent, on what we do not desire but have somehow suffered. Not desiring is not the same as not having desired, just as not wanting to have suffered does not imply not having done so.

Time is undoubtedly the greatest unknown in its truth: extreme relativism, the change of stages… Finding ourselves to lose ourselves moments later. Having ourselves and fearing what we might miss again.

Feeling how the whole and its preference tend toward the purest and most arbitrary abstraction. Experiencing how our thoughts are nothing more than immature fruits and that, come the day, any unexpected storm could tear them away without any remorse.

Remembering that stage where hope directed and guided us like a mother concerned for her children, but what do we really know about this after all?

Remembering nothing more than the longed-for illusion, perhaps its mere nostalgia, perhaps years and years naked like the time that did nothing but accompany us without real intentions. Jet-black purposes rest on the purest longing for sincerity towards and with ourselves. For us, eternal constants are destined for continuous transformation alongside our change.

Let’s Talk Again

Realizing what prevented us from feeling beyond suffering, in the continuous doubt of not knowing which direction to take. Faltering again and again until possible fatigue is long forgotten. I sincerely wish to end this uncomfortable feeling of anonymous confusion.

Caressing the farewell, unable to foresee the chaos and its impending disturbance towards our person. Foolish helplessness.

Teaching ourselves over and over again, so many times even the same things. Stumbling and falling with and without shame, as if we were searching for our own limits that we once thought were nonexistent; oh, how wrong we were.

There are so many things certain and so many not so clear… But what I think we learned was to discern, at least, what truly overwhelmed us: the loss of control over the situation, not knowing what to do or how to react after faltering in all our failed attempts to achieve what was entrusted to us.

The simple idea of doubt about our doubts will be decisive if we let it sprout. Could everything return to what it once was? It will, of course, it will. Let’s be again.

It’s Time to

It’s time to say “goodbye” to so many things. Feel like nomads in our lives searching for that feeling of fulfillment where the senses desire beyond themselves and feel part of the whole with their fellow beings.

It’s time to start saying “goodbye” to so many things. In our overcoming, we grew and did not want and do not want to allow that loss of control that could make us lose our heads, finding ourselves in continuous dissatisfaction for more time than we could desire.

It’s time to be aware that we should start saying “goodbye” to many things. Not in vain; everything learned will remain, as it will be written from now until the day we decide and grow by choosing to be.

It’s time to decide on changes for and with ourselves, with the purpose of their creation being the reason for it. Feeling unable to endure so much makes us ultimately capable of tolerating to a greater extent, but that was not our original intention. The feeling towards the external should not be greater than the internal, as our trace and appearance will depend, directly conditioned, on our most intimate self.

The time will come when the decisions made will carry such a high degree of importance, possibly even changing the course of what we established in the past months for the coming ones. And there is still so much for us to be wrong about and to change…

It is indeed true, as it should already be well known, that in the pure abstraction of errors, as well as successes, decisions we make are in common to the best of our abilities. There will be no better attitude than what we see with our eyes.

We shouldn’t do many things and do many others that we should. It is time to decide what responsibilities we want to be accountable for and at what cost, but above all, what level and what goals we can achieve.

It’s time to welcome so many others and to become aware of the changes at these levels that could initially exceed any youthful perspective.

What Could It Be?

What could it be that hasn’t yet occurred? Letting ourselves be carried away by emotions, allowing ourselves to act without greater intentions… Experiencing that tingling sensation, those eager butterflies seeking protagonism. Eight months have passed since we last saw each other in person. That’s the reality of living abroad.

Tomorrow we will wake up again in Berlin, but we will sleep in our warm homeland where we were born. Where the family awaits what will be the long-awaited moment of a new shared reunion after so much time.

What could it be that hasn’t yet occurred? After truly experiencing everything, I would even dare to say “reborn,” having been in any manner. I wouldn’t want to think too much at these moments but rather release the words that come to mind moments before falling asleep before this brief return journey. And I feel the urgent need to write just a few hours before departing on this flight. It will be a week loaded with so many emotions that I hope nerves don’t betray us and that we can channel them gradually.

Knowing myself, and in the little that I still know about myself, I am sure it will be an unforgettable week. One of many weeks that we still have to travel and tell…

I’m looking forward to seeing my uncles, my father, my cousins, all of them: my family in general. But especially, I’m eager to see and embrace my brothers and sisters, whom I miss so much every day. I just hope that they can understand someday the meaning of all this, that they comprehend this motivation and apply it not only in theory.

I don’t want to go into more detail today. It’s time to rest because tomorrow will be a great day: the beginning of an unforgettable week.

Chapter 13: March 2016

2016-03-01T00:00:00+00:00

It Becomes More Noticeable

The value of our time becomes more noticeable, along with the memory of death, evoking that constant nostalgia, wishing to make its way on this path full of uncertainties and, at times, disheartening.

The scent becomes more noticeable when the winged souls of the roses are absent. When that essence is missing, allowing us to relive with enthusiasm, that’s precisely when it becomes more noticeable—remembering what? What were we supposed to remember?

I felt how the training wheels were taken away, like when we learned to ride a bike, the ones that gave us confidence. However, above all, I felt it today with the same reality regarding how the pressure of different situations can be, at times, an honest and unpleasant enigma.

We soak ourselves in experiences that we didn’t expect to find initially, yet they end up finding us, not knowing how to respond.

Time drags us without mercy and fear. It obliges us with serenity, becoming more noticeable when it reminds us of who we are, but above all, who it is.

We are newcomers in this game with no rules beyond the ones we invent or want to conceive. Beyond our sincere understanding, where for reason and truth, we despise those who use different prisms to observe.

Wanting to exist as an eternal beginner is like water flowing down the stream, destined for the ocean’s vastness and its abandoned forgetfulness. The carelessness linked to the disinterest in everything is our most significant risk. Living with the excuse of the uncertain tomorrow and the same indifference towards ourselves can only end in an infinite void devoid of all possibility and opportunity.

Slowly withering away, we see the value of our time pass before our eyes.

It’s When

It is more challenging to believe it’s possible when the blank canvases are still white when that mature thought feels somewhat withered because of who knows what and how…

Interweaving of ideas no further than our mere and subjective thoughts, and perhaps, they no longer deserve much more… “Clarity” is the word with which, in its absence, everything darkens.

Both in a simple and complex way, our ideas can coexist with this practice we understand as life, where the purpose, beyond learning, escapes our knowledge because we couldn’t conceive another idea. Our experience is motor and bold comprehension; the more reflected, the deeper we decide to delve. The cause of the cause and its consequence sometimes prevent us from smiling.

Movement without return is destined for doubt and the continuity of its absence. Because not everything will be science, and much less some unnecessary belief.

Time and its relentless non-stop pursuit… No one was born prepared. In diapers, in front of every question that one day we will have to face, it will be then that we realize what we are worth.

In our sincerity, we should admit that, at the very least, we should be; otherwise, we wouldn’t be fulfilling our purpose because if there’s anything we’re responsible for, it’s being sure of what we would like to have lived.

We tend to confuse and mix between causes and consequences, where questions pretend to be answered before they are formulated. What, then, is our task if not the one that should already be more than evident?

And I don’t write for you who hear us but for you who listen to us.

On the Mountain

Tremor. Fear. Failure. Suffering. Disheartening…

Fearing failure and its horror, suffering with tremors in our despair for not seeing ourselves capable of achieving more remarkable feats in the coming days.

Where did we end up? When will be the perfect moment to conclude once and for all? An overdose of meaning’s lack guarantees helplessness in an abyss. A rusty clock is about to make its last turn. Betrayal betrayed… Perhaps forgiven for being ourselves? Who could live without their forgiveness, after all?

Rocky Mountain, years ago, accompanied by sips of discouragement that sought less confusion in that chaos without a name but with surnames.

Lurking admission, the ambiguous purpose in a disillusion that turned out to be out of control. Accompanied by deception and loneliness, but above all by our constant lack of belonging to a false reality, especially behind closed doors.

Pity for the one who was almost… Our treachery to our betrayal saved us from that mountain and its disguised nighttime cold that attacks at night.

Eyes from back then were cruelly blinded due to the lack of understanding and the pressure in all possible directions. Remembering with each sip at the top of the mountain while the music played and tears were born to succumb a few seconds later, during the wait…

Memories that felt their fading,
real, and deep sadness without breath.
Confusion served in every feeling.

We could have flown on that mountain, ashamed also by the unnecessary complication we introduced to many third parties. But it’s not shame we feel now, but sadness that it could have been possible and the many probabilities of different endings that, fortunately, more than unfortunately, we never came to know.

It seems that that mountain had a surprise in store for us. Or, instead, we were the ones who invented that uncontrolled surprise with an entirely different — as well as rewarding — ending from what we, on that misguided day, set out to achieve. Reason enough for joy from that day to now.

Savor

Savor the sweetness of that moment
when we wrote with goosebumps.
Feel alive, protagonists of this tale;
it seems like we chose it in its day.

Not seeing ourselves as something fully defined,
feeling how there's still so much left.
Dressing alongside the not-so-quiet storm
that day and night reproaches us for how much.

Let the moon dawn clear,
with a strange fear of having lived.
Be born again adventurous,
stay awake until its oblivion.

Abundant joy perseveres, graced,
sometimes distressed by the wind.
In its simplicity, along with its gaze,
she enjoyed and waited in her seat.

Tasting the bitterness along with pleasure;
Let it serve us once as a lesson.

Having as our only fear the reality that, at times, we can behave as if there were no simple rules of conduct. Reality where colors, with their grays, lose even all the sense they might have had in their day.

To those hands that drew and now write with so much pleasure. To those who remind us how it’s possible to express, reflect, and bring mere ideas into reality even before they exist. To those with whom we grew up and who made us grow. To that idea that timidly arose and wanted to train and trained to stop being cowardly. To that whose purpose was, is, and will be in itself.

To the depth of confusion, the sea and its oceans, and the infinite abyss and inner chaos. Fear? Whom should we fear more than ourselves? We want to speak from another perspective, but at this point, it’s challenging to turn our heads and look the other way, not as others did to us more than once, where we still remember names and surnames.

Should we perhaps write with some predefined order? Who could expect more from us than ourselves? Here, no one has written anything.

The taste of lack is undoubtedly the dish par excellence that will teach us so much and leave us so little. A dish where prudence and disorder seem to try the same, disputing among themselves the helm of suspicion.

Sometimes savoring reasonable moments, appearing like authentic nonsense… but above all, relishing the uncertainty of the lines yet to be written, finding them pleasant and not so sweet. Sensible moments where emotions shoot without fear of who they might hurt, reviving us in our eagerness for resolutions.

Hatred for God

Our most sincere rejection to the figure of that almighty and omnipresent God that so many people try to persuade us. To that figure superior to us who watches over or protects us to the extent of who knows what possibilities.

Our most profound hatred and rejection of the idea of that benevolent, as well as annihilating God, where contradictions are constant, constant, and interested in those who try to sell it to us.

Our most sincere repudiation, hatred, and rejection of that superior figure’s putrid idea. To that God and prophet who claimed to come in the name of who knows who. To the one who claimed to be cowardly today, many still trust in his foolishness.

Our greatest disgust, repudiation, hatred, and rejection towards the very idea of God’s existence as something superior to us. To that who claims to love us and yet is permissive with everything that is not love. To that which hides the egocentric interests of an idea devoid of everything, especially humanity.

Our greatest and most sincere contempt, disgust, repudiation, hatred, and rejection towards God and everything that his idea represents in itself as long as we are not ourselves. There will be no greater fallacy than denying that we were born to be our gods.

Our most sincere pity for those cowards who hide behind their lack of interest. To those who today blindly believe in some of the words born from some tale, either out of tradition or simply due to a lack of logic or intellect.

Our most significant intolerance is for anyone who claims to preach the truth through their mouth and contradicts it through their actions, excusing themselves by saying “the flesh is weak” or “the devil deceived us.” Damn you, too, fools and hypocrites. You are the evil ones!

Even having more logic than the idea of God itself, which they try to instill through religions in our youth, is not at all complicated. Who can hate us more than the idea of God itself? An idea full of human gains, lies, and deceit. An idea rich in falsehoods and disdain, but above all in uncertainties within the abyss that all this can become if we cannot say “enough.”

And It Won’t Be Enough

And it won’t be enough to wish for everything to end, for all this concern to dissipate once and for all.

To turn a possible grain of rice into a mountain full of uncertainties and terrors. To wish to end all this pressure that abducted us by surprise. The fear of uncertainty and its confusion is what overwhelms us the most.

And it won’t be enough to believe to be, even being at times within the limits of our possibilities. Talking about intention is not always the correct thing, and it won’t be enough to avoid specific fears or help us clear simple doubts.

And it won’t be enough to be without being, for being is and will be forever our main mission, where the very idea of emptiness and its absurdity may visit us on so many occasions without permission.

And we cannot allow ourselves not to feel! Although missing each other may be, at times, also something inevitable. What are we doing now? And with our life? “It won’t be enough, therefore,” we tell you! We have survived pity and falls: enough once and for all this poor and senseless idea, for surviving is not living.

And it won’t be enough for them to tell us! We will be the ones to say to ourselves…! I hope that everything will be fine and will continue to be so.

The Complexity of Obligation

When we forget who we are, it is when we tend, to a greater extent, to the anguish born of confusion. That enigma that scares us and makes us feel uncomfortable. Something that might seem unnecessary initially but surely should lead to a compulsory conclusion: educating ourselves on the matter.

When we forget who we are, we should remember ourselves the most. Hurriedly… In a race where time is forced not to stop for a second. Decisions with a clear mind become complicated, especially when the identity that should belong to us feels overwhelmed and lacking in essence.

Everything revolves around an aura of conjectures, dizziness, and linked fears. Forgetting our beginning, our personality is unequivocally in the wrong direction of what we want.

How would we avoid those situations or knowledge that we would like to evade and do, learn, or know in advance many others that we could forget or not interpret correctly in time?

To what extent are we willing to go? To what extent are we ready to give up certain things for others? What is this, if not an exchange of decisions and priorities?

That’s why anxiety pursues us when we err, with more or less guilt, in our commitment because it is about the feeling of proximity from us to ourselves. Our fulfillment should be nothing more than our understanding of ourselves.

The complexity of obligation lies in its responsibility, which is proportional to the burden we are willing to carry, which should never be imposed but desired.

Longing

When everything passes, and nothing remains, we will remember with possible nostalgia those moments that happened, especially those that made us feel. We will miss the desire to write, as everything will end up like a fire consumed by a lack of oxygen.

We will miss those desires for madness for learning, perhaps even for that same self-improvement or identity… Who knows how much we will miss? We already miss it, and it is not strange a little every day. Growing up makes us more aware of our pulse, breath, and chained purpose.

We will miss the water flowing, the sun waking us up in the mornings, and spending hours reflecting on what we will miss…

But it won’t be today.

Chapter 12: February 2016

2016-02-01T00:00:00+00:00

Traveling to Our Encounter

A continuous and changing void. Full of everything and nothing, of convergences as well as deficiencies, and occasionally, of ordered essences.

Traveling has taught us, among other things, to better understand that life is so different from how we used to conceive it… Opening new doors day after day with barely any breaks in between, where tranquility was already counted.

Minimum requirements evolve, and maximum possibilities disappear. There is no trace of the limits imposed in our youth on what we are capable or incapable of achieving. Limits? What expression is that…

Borders that did nothing but confuse our vision, prevent us from seeing beyond, and not allow us to feel what, otherwise, we might never have accessed.

Traveling has opened our minds more than we could have ever thought. Studying has given us the key to opening the doors we dream of and will dream of. Being ourselves has allowed us to be with those we truly wanted and will want. Dreaming has granted us to live, and living is allowing us to dream.

Unforgivable Youth

An unforgivable youth that consumes us along with our time in an apparent subjective sense that we decide to create ourselves.

The passage of days, of years…, of time in general. Careful! Let’s not oversleep more than planned, or we’ll be too clever, making a mistake once again.

When is the moment? When should it be? The problem is not that this moment has not arrived or seems not to arrive; the problem is not being awake and not going out to seek what we want to find. That means not being asleep but attentive in these waters that can swallow us at any moment. Not being asleep means learning to rest when we are exhausted. It means learning to swim, not letting ourselves be carried away by the current without apparent reason. It means learning to breathe even beneath the same sea. It means walking with and against the wind, learning from it and its freedom of movement.

Unforgiving youth is the one that, cowardly, hides, delegating its responsibilities to time, letting it carry them out without much intention in its understanding of its own unanimity. Devoid of meaning, our youth does not forgive. Confronting our adolescence with real linked suffering, as everything we have not yet overcome for our future will remain in our conscience. Who decided to be older? Did youth itself escape despondently? Who decided to be this or that?

When did we grow up? When did we stop being what we don’t remember? We should be satisfied with our decisions, especially if there were no other intentions than just being; breathing accordingly, and, as a future result, pardoning our past, an irreversible effect of our present in our consequent reality.

Religion

We must understand religion as something natural, inherent to a fragile race prone to mediocrity, where lies and deceptions stroll without our permission, being, therefore, intrinsic to our humanity. We could think with every right: “Poor those who want to be of this world,” but poorer will be those who do not.

Religion was born out of our cowardice, our lack of understanding, and our lack of commitment, but above all, our lack of sense and feeling as a divine species.

Is religion an error in itself? I don’t think so. I believe that religion is simply the result of another reflection, a symptom that we still have much to evolve.

The belief in something superior to us is nothing more than a reflection’s lack of strength in our world: our life. Religion is nothing more than the consequence of a significant lack that existed years ago. The fact that it still exists and is practiced with even a bit of enthusiasm says it all: a picture is worth a thousand words.

Faith in one religion or another, without distinction, reveals a lack of trust, as well as personal and individual meaning. We are not here seeking or pointing fingers. We are all part of our ecosystem; we are all part of the same in the end.

Religion is nothing more than a false and unnecessary self-suggestion of the existence of a higher authority. We speak here of “unnecessary” from a perspective above the norm: as a species that doesn’t understand that there is nothing superior to itself.

Is it possible to understand religion differently? Of course, look at the people who, though backward and cowardly, understand this topic. We say “backward and cowardly” referring to those who do not dare to be above themselves. Therefore, they lag behind in their potential compared to those who dare to live in their deserved greatness. Many simply excuse themselves by saying that religion is good and helpful; damn religion! It wasn’t her, but us!

Religion is the belief that we were neither nor are. What nonsense! We were, are, and will be. It was us who annihilated in the name of religion. It was us who helped in its name. We do everything, not God or any of his children or prophets!

Don’t be fearful! The world can be as wonderful as we decide with our attitude toward life, for there is no greater secret than knowing ourselves and being aware of our power and wisdom. The use we give it will be decisive in defining our successes and failures and, thus, the quality and meaning of our existence.

What is the difference between believing in a God and believing ourselves to be the gods of our lives? It is straightforward: self-determination, as well as the responsibility it entails. We are not here trying to dismantle any falsehood or certainty. Everything is in our minds; the direction we decide on will reflect our maturity.

There will be no God or destiny that can guide us toward correct conduct or absolute truth. Within our logical limitations, we are unlimited beings. Above any belief will always be our freedom, which will steer the course of our path, above any inevitability, where the transience of our goals becomes evident. Above any divinity or belief, we will be ourselves as we were, eventually ceasing to be and resting from so much turmoil.

Definitely

Definitely, we are not supermen, but that shouldn’t be any problem, but rather our sincere feeling toward its tendency. Definitely, we are not, but believing it at times could bring us closer to it.

Destined for life to live until death. Destined until our last days to a tireless life of weariness. Destined for an immature and senseless destiny where it wouldn’t even recognize itself.

Definitely, we should learn that tiredness can sometimes be inevitable and that our reading comprehension of life can and should evolve. We can be as much as we can imagine but, above all, we will be as much as we demonstrate.

Definitely, the wind will carry words away so far and so far… until they remain in their warm forgetfulness, thus nullifying any memory and abundant absence of them.

We should decide to write a book, our book. Write it slowly, savor each of its words as we have never been able to enjoy, imagine each paragraph as the last one we could write, and carry it out as if our life depended on it.

We are not supermen, and definitely, believing so wouldn’t make us one. It is, therefore, from where this simple, logical, and absurd obvious sentence arises: believing that something is or exists is not even a minimally conclusive proof of its truth. Believing it would be ridiculously foolish.

It’s a matter of a sincere feeling toward what we really say or think, that is, what we are. Not saying or thinking inevitably leads to not being.

Turns and More Turns

Ideas that flood us and accompany us without notice, without even warning us of their arrival. The same ideas that will linger in our minds without a date announced for their final instance.

An immeasurable sensation of questions without answers. A cautious and distrustful restlessness, wrapped in paper. In love with itself, but, in the same way, with its opposite, as nothing will remain in the end.

Warm emotions without warning interfere with our minds without permission, alarming our most prudent beings and invading the course and everything we carry in our minds.

Distrustful of external ideas that pierce and reveal in a spring of mysteries that don’t stop turning among themselves or playing tricks, inviting us to madness. A world where the sensible people seem to be those who do not know or love not knowing.

Where ideas play without rules, disordered and arranged, governed by what we still do not know. A world of possibilities that surprises us every day. It floods us with its wisdom and brings us closer to our idea of being. It transforms us and shapes us with the mold we began to carve in the past.

Accurate suspicions that point to more. Outlined opinions that only wish to be born to shine as they deserve and die as they should.

Warning us of what is happening. So many nerves without an apparent name that, of course, deliberately hide it. We must appear and warn ourselves, as it is a simple alarm where the cause hides behind a possible discouragement.

Repairing our breathing again… Imagining that all these turns were born from somewhere.

Everything is in its place, each in its orderly measure. Apparent concerns don’t have to be evident or even exist beyond our minds. Let’s stop believing in this or that without alarming reason, as the only urgency is to know that in our power everything ultimately resides.

But it is true that clarity may take time to manifest, and until then, it is more than understandable to feel misunderstood, disturbed, and even scared. Let’s feel free to feel it, to feel like ourselves. But let’s not forget who we are, please; write if necessary.

So Easy

It’s so easy to get lost when everything seems to be achieved… When everything appears to have assured stability, and we believe it, that’s when everything tends to become unstable. Where did our desire to thrive and improve go when everything wasn’t won yet? I think we simply fell asleep or, in other words, let ourselves be lulled to sleep.

We shouldn’t believe that this is something negative at all. Our primary task is to learn, especially from those situations or moments that we wouldn’t want to experience again. Learn that appearances tend to deceive at first glance, but above all, learn that we must be bolder with our reality.

It seems that we tend to neglect when we fall asleep or even leave the autopilot on because we think everything is already done. We couldn’t be more wrong. Inactivity is what will ultimately destroy us and shape us into something far removed from the idea of Superman.

The lack of action on our part as individuals crumble us and rob us of meaning with all our rights. And it’s so easy to end up asleep without ambitions that awaken us… Because we tend towards mediocrity.

It’s so challenging, apparently, to stay awake in this reality where sleepwalking predominates, where the main issues seem to lack clarity in their perspective. Where normalcy suggests having found a place to stay without being obliged to pay for its stay.

The difficulties we encounter in our reality could not be more interesting from the point of view of those who observe or suffer them, automatically becoming achievements to attain and overcome. It is true that there are obstacles and inconveniences that make life, at times, a continuous torture where we can’t help but desire to escape until it all passes.

The real problem is not the problems themselves. Life is full of tragedies, riddles, and mysteries to discover… The real problem is not confronting what causes these uncomfortable feelings, not facing our difficulties for fear of unleashing another possibly internal conflict against ourselves because who could contradict themselves?

It’s so easy to fall asleep wishing to escape from everything…, especially when life doesn’t seem to have intentions of extending a helping hand. Staying alive is, at times, so difficult to believe, as wherever we look, we commonly see extinguished souls, aimless, not knowing even where they are going or where they are headed.

I believe, therefore, that these should always be our main concerns. Sleeping is healthy, but “sleeping through life” will cost us the same. In this context, we should stay awake, but it’s not easy. Who said it would be, after all?

Chapter 11: January 2016

2016-01-01T00:00:00+00:00

Ambition in a Dream

Ambition is wanting more and better; it’s not giving up, especially not for just anything.

Ambition to change, learn, and enjoy growth, breaking continuous patterns of half-truths. Even whole mirages of truths. Truths… which ones? Are we a truth, after all? How much truth is there in us?

Ambition to laugh and smile every day. For everything… for anything. Learning to enjoy every moment, whether salty or sweet, bitter or spicy; all have a place. After all, it’s just a matter of taste and understanding. Understanding and reason, where ambition becomes more apparent. Where verses can converge without as much fear as we might sometimes fear life itself.

Ambition for life, our most precious gift, and for our dream. Our logical capacity allows us to discern illusion from truth, life from a dream, and dreams from true reality.

Ambition to live, to grow, to laugh, to dream, to do, to unite, to create… This should be our true reality, our project as mortals because, in the end, only what we have been will remain.

I Renounce God

Does God exist? How dare you affirm the existence of a God? I know the illusion of ignorance. The illusion of ignorance and sentiment above reason.

Without any real proof beyond individual illusions, there is a need to create a God “for our own good” to accentuate the limits of good and evil, as cowards dare not define them themselves. They need to lean on a divine idea superior to them. They would fall otherwise because they are weak, as well as fearful of their reality.

Show me real proof! Show the world where your blessed God is; prove it to me. I’ve seen nothing but empty words on the subject. I’ve heard nothing but vain beliefs and personally valueless experiences, especially those without the possibility of being proven. Beyond those who want to believe in something nonexistent.

Having faith is wanting to remain ignorant. Not daring to think with cause and knowledge. Not daring to be God is what leads them to failure in their belief and fear of responsibility and freedom.

I denounce the false single God and all those who feed it in their cowardice because we are the gods of our lives. The proof is quite simple: open your eyes and look around you. What can you see? Look at your hands. Dare to be aware of your power, your wisdom, your past…

Think about your future, what’s to come, everything you have ahead. Dream these seconds with your time, breathe slowly, and enjoy it because you are truly being God. The greatest thing in your life is simply you.

My Purposes

It is widely generalized that at the beginning of each year, certain proposals are made for the upcoming year. Today is the eighth day of this new year, and for several weeks, one of the main topics of conversation has been the “resolutions” for this new year.

Of course, it’s an important topic, where encouraging ourselves to set short and medium-term goals becomes more noticeable. But I think we should do something different. I think we could do it differently: look from another angle to highlight the true purpose of our sincere intentions.

Our main resolutions tend to be unoriginal and repetitive, year after year. Imagination gets boring if it doesn’t play and create, especially if it doesn’t have fun. Why are our resolutions so short-lived? Do we really achieve our set goals in these early days of the year?

Let’s visualize this situation from another perspective and play with our reality. It’s great to set new goals to achieve in the coming year, but I prefer to think about where we will be the next year. Set long-term goals. Think about where we really want to be in two, three, or even four years. The resolutions for this just-started year are too simple: simply enjoy it while striving to become our best version.

We refer to projecting our future, making each awakening a purpose in itself, focusing and realizing what we really yearn for.

Change the fleeting days to incredible experiences. Full of vitality, strength, and energy in the search for our true selves. Enjoying our journey and finding ways to feel fulfilled, especially with ourselves.

Sometimes

Sometimes life can seem strange, especially when everything happens differently than we planned or thought.

Sometimes we may feel that we won’t be strong enough, as if we’ve lost all our strength, or that we simply don’t want to continue playing this game, which seems to have no meaning.

Sometimes we may feel terrible. Everything we did was not what we really wanted to do, and the future awaiting us seemed to have no better options.

Sometimes we might wonder, “But… why? Every day is the same and gets worse. I can’t do anything. This doesn’t work, this is wrong… I don’t belong here. No one could understand me.” It’s normal. We’ve all thought about these things at least once, especially in our childhood.

Sometimes we can be wrong. I said to be wrong, of course! Wake up! We are human, what did you think? We can become incredible, especially because we can prove it. And it’s certainly not complicated: all we need is patience with ourselves. The rest will come on its own. We simply need time.

Enjoy your life by making it unique!

Eyes in a Memory

Feeling how our ideas grow and mature, eager for reading and learning. Feeling the fatigue born of an active life full of vitality and energy as it deserves. Feeling ourselves as a vital part of a whole, as well as an individual part of the entirety.

Full of emotions and wild ideas that yearn to be born. Sleepless nights where not dreaming is forbidden are the protagonists of our story. If at any moment we find ourselves without them, that’s when we should be scared and correct ourselves quickly.

Missing a fleeting and dreamy young person, but lacking in courage. Regretting not being there to tell him how wrong he was and how much he was worth. That he was important and that he would be even more so at times. That each day of his life would be a before and an after in itself.

Longing for a land warmer than cold, but not too much, and not for the land itself, but for what was in it. Wishing to see our memories, our family, our past, our home, ourselves in that rude time with different eyes… to be able to affirm today that we are so satisfied…

Traveling. Living away from everything we always had around us has made us more aware of everything that we have today, of how ephemeral everything is in general, and how valuable little things can become in particular. And I’m not just referring to mere details: great friendships from a distance, younger siblings who still need help not to get lost, where laughter is still achievable, and hope in every success flourishes in every comfort and experience.

Memories in an uncertain but certain future. Dreams in the vastness of desires, where each passage can shine without any fear until its full transformation, forever leaving fiction behind to become full reality.

Starting to materialize, to create where there was nothing before. Reusing, reinventing our ideas and thoughts, improvising with everything that doesn’t let itself be defined. Breaking the vain ideas of inferiority and, above all, with the “you can’t.”

Beautiful detail they had, and we had with us a few years ago, learning to adjust the sail of our ship to the wind so that it doesn’t end up breaking, no matter how hard it blows… No matter how difficult something may seem, nothing will be impossible to be stored in our eyes as a memory.

Where Success Begins

Success begins in oneself, in believing to have achieved it even before actually doing so. Not because of false hopes, but because everything should point to that being the case.

Of course, there are chances that what is set may not be fully achieved, but it shouldn’t be our fault. We should have bet and worked hard and fully on it.

Success is, in part, mathematical: a matter of probability. Like grades on a test when we were young: the scores didn’t measure actual abilities compared to other classmates. What they measured were the probabilities of our success: the more we studied, the more chances we had of achieving a higher grade.

With success in life, it’s the same: the more we fight to obtain a higher grade, to get what we desire the most, or to achieve our goals, it doesn’t certainly mean guarantee completely that we will achieve it, but it does increase the chances of it happening. It’s even possible to learn to control certain probabilities, making them tend to the maximum.

Life is too complex to play its game. It’s too complicated to listen to it. Seeking happiness in its difficulties without making an effort is excessively challenging. That’s why we must create and apply our rules, in their simplicity, to achieve success and, therefore, our happiness.

Fed Up

Undoubtedly, I think if you asked people close to me, they would all agree on at least one common adjective to describe me: patient. I consider myself a person with significant patience. In fact, it is undoubtedly one of my main virtues: knowing that time does not stand still and that everything ends up being caught by it.

Why am I like this? Simple. I’m fed up with hearing how little we are worth or how little we are. Years and years listening to the same nonsense. These words and situations that seem too obvious to me now, which I believed as ignorant and deceiving when we weren’t even aware of who we were or where we were.

First in a church, in abnormal beliefs more than paranormal, typical of the sick and devoid of meaning. Fearful, but above all, self-deceived. Where hypocrisy, jealousy, and all those things these cowards complain about end up being the first traits to be contradicted. “By their deeds, you will know them,” said a character that will be familiar to many, and he was not wrong there, as no faith is needed to be happy. Not at all. What is needed is a good education where good values of coexistence and mutual respect, as well as personal growth, are present, and not stupid confessions where everything bad and wrong—according to the book we are reading—is previously established, as if it were a role-playing game.

And second in a “castle,” where the previous point stands out so much, shines, and glows… that it ends up burning more than ten suns together. Where learning to survive became everyday bread. Where memories want to disappear. Where I began to discover the value of my true family, as well as my neighbors and the people who, day by day, surrounded me.

I got fed up with hearing so many senseless things together… that I had to learn to be patient by the obligation imposed on myself, as a necessity. I got fed up with not valuing what really deserved it.

—“And who or what is it that really deserves to be valued? Everyone, perhaps? But above all, to what extent?”

Sure. Everyone deserves to be valued, but not everyone equally. Some are worth more than others. We are not the same. We are all different, that’s the charm and part of our meaning. It’s part of our history and our future. Monotony was never our final or even initial purpose.

I’m fed up with not valuing what deserves to be valued as it really deserves. And measuring that valuation is quite simple, as well as personal. We can easily obtain the answer to the previous question, in addition to being suitable for all audiences. All we need is time, effort, and sincere self-criticism. The rest is simply patience.

Ironies of Life

Biting the hand that feeds us.

Ironies of life include that, thanks to “hear, see, and be silent,” one learns to desire to shout to the four winds and to think more clearly. Wishing that everything was a dream from which to wake up, only to end up yearning for a childhood that will never return.

Ironies of life are learning to work, leaving home, and wanting to start anew. Wishing to start from scratch, seeking another opportunity while missing a time that will never come back.

Belonging unintentionally.

Ironies of life are forcing oneself to be older, to strip away a childhood that never existed; at times, wishing not to have been born, only to end up loving what was once hated; ending up loving life, proving to the world how wrongly one lived.

Ironies of life are ending up fighting to the death, facing without fear everything that one could fear, wishing for everything to end once and for all, swimming against the current and against all odds, poorly predisposed by misguided authorities, unable to question without prior permission.

Ironies of life are climbing forbidden stairs under the most wicked, mistaken, and vile authorities ever encountered. A wicked, miserable, and spiteful serpent; its irony will be its punishment during its wait. Let it enjoy as much as it can; indifference is all that remains on my part.

Ironies of life are our art, as ephemeral in a moment as temporal in a memory. In my reserve will remain everything I don’t write. Interpret as you wish. Nothing will be for you but my forgetfulness.

Ironies, it was you and everything that came with you. Thanks, I say now, for having been a witness and participant in the most beautiful creation we could ever achieve: us, of course, I mean, both me and myself. Because there will be no greater irony in this life than the mere fact of feeling minimally grateful for someone as undeserving as you once may have been.

Thank you. To your irony, I say.

To Not Die

Playing with death, to not die. We are the embodiment of our experience, of what they tried to teach us, and of what we truly learned.

It’s not our fear of creating, but of seeing what we create destroyed, whether by the simple passage of time, the course of the season, or our existential end as individuals.

Playing at being ourselves, not to die. Escaping from the boring, whether simple or complex. Tempting fate in the right measure. In our nature, it is written: “Our time will not return. Never.”

We are perfect abstractions of our unique reality. From our most sincere complexity to our most absurd simplicity. A reality where nothing and everything could converge without reservations. Where no one is nothing and we are all everything at the same time.

It would be so boring to always talk about the same things, do the same things, or not think about anything new… We must evolve, improve our thoughts, and never stop believing in ourselves; as Gods of our only reality that we are.

Playing with death, not to die. Confronting life without fear of our evolution, our power, our true being: our Self.

We won’t be fit for the world if we are not predisposed to be. We are both so much and so little at the same time as we decide. In our courage hides our true power: the power to change the world, our world. Cowardice is nothing more than a symptom of a lack of confidence. A symptom that reveals the absence of the will to power when it is necessary and possessed, and the lack of knowledge of it itself.

We refer to personal and individual cowardice. Cowardice in not daring to be, in not telling ourselves the truth for fear of having to face it. Sometimes it is our fear of the fear itself that does not let us live. We couldn’t be more wrong in our fear!

Fear of dying without having lived, not fear of dying!

Tired

Sometimes we are tired. It’s not normal for us, but we have to understand ourselves. It’s not something bad, not at all. It’s simply a symptom of the need for a break, of tranquility, accompanied by reflection like the one we are having now.

Let’s go to bed. Let’s read for a couple of hours until we can’t anymore and sleep in deep sleep. This way, we will help our body, as well as our will, to replenish all the strength we need so that when we wake up, we smile as usual.

My Skin Crawls

My skin crawls when I think about us. In the vastness within our restlessness. In that unique moment that seems immortal every second we let pass before our eyes.

My skin crawls when I think about our future. In our life ahead, in every second, in every moment that, along with our mischievous self, we let rest. Enjoying that shared moment that is born only to be lived in our eyes.

My skin crawls when I dream of us. In our lived and still expected moments. In the shared moments, as well as the ones left behind, they are never divided even if they can be longed for.

My skin crawls when I write for us. With poetic tendencies is what I mean. Seeking rhymes out of nothing until I generate, and the result in my mind sometimes I conceive.

My skin crawls when I play with our past. Sometimes in our language, I try, but I am no one if I do not mature, even venturing with fire.

My skin crawls when I pretend with our dreams. Without envying certainly being no one, for I will be the only one who radiates until I finally fall asleep.

My skin crawls when I finish, when I start, or when I guess in every moment of this time, which I try not to ruin. What is truly exciting is that, in these early morning hours, we are still here in front of us.

My skin crawls when I think about us, when I dream with you when I write for you, or simply when I play by your side.

Necessary Insecurity

We refer to unnecessary insecurity, the fruit of a poorly nourished tree. Where the land has been fertilized with continuous disorder in an area of scarce life and abundant ironies.

Where metaphors flourished by themselves without anything or anyone seeming to water them, alongside a continuous rain of despair and bewilderment. Where the notion of identity faded away day by day, and our roots wished to be pulled out in any way to migrate elsewhere.

Regardless of the method or date, as the notion of time was lost between hours and even days, waiting for something to change implies some improvement because worse irrigation and fertilization than what we took would be quite a challenge in its difficulty.

The harvest obtained from poor irrigation tends to be poor fruit.

But the funny thing in this play on words is precisely that we could learn to water ourselves. We learned, at least, to change fertilizer. Watering ourselves with different water every day, experimenting and trying; removing the blindfolds from our eyes that hindered us so much from seeing.

We learned to learn.

Not Enough

Life is not enough to just be lived. We must face it and not let it slip away. Every moment of our breathing is not that it won’t come back; it will disappear like a speck of dust in the cosmos, never to return.

Swimming against the current, against ourselves because, believe me, it will be necessary. This should be a battle. The greatest personal encounter of our lives, for there will be no more important conflict for ourselves than the one we wage against ourselves.

With tact and understanding, as well as with fury and passion. Let’s rise with all our courage, overcome our smallness once and for all; let’s learn to fight against our inferiority as individuals! It’s not enough to simply exist, let alone survive!

No star will shine on its own; even less if it has nothing to illuminate. The light we radiate would be useless if it did not inspire or ignite those who are still extinguished.

It will not be enough with a “could…” or a “maybe someday…”. We must not allow ourselves to fall into the simplicity of a dim life where routine dominates us and does not allow us to create. Invent a superhuman, push ourselves towards continuous success, choose what we really want, and never cease in our purpose.

Because life is not enough to just live it! It will be synonymous with not living if we do not shape ourselves because to live, it will take more than just breathing…, and that is to feel and never stop pursuing until we become who we truly desire. And if we have never dreamed of our future before, it is because we have not yet been born.

What I am completely convinced of is that withering away without even having blossomed will undoubtedly be the greatest mistake to which we will have led ourselves.

Therefore, it will not be enough to be without being! Let’s be!

I Am Not

I am not a writer, and that is one of the reasons why I love to write. I do not consider myself a musician either, even though I can make an instrument sound pleasant. Many years have passed communicating with music, especially because it has always made me feel all kinds of emotions. I remember that I also had several periods in which I composed songs, but that did not make me a composer.

Precisely not being a writer is one of the things I like the most: I don’t depend on anyone, and no one depends on me. There is no reason to fear words, letting them play freely, both together and apart. Where the only responsible one is the one who reads and enjoys them in their own measure, not the one who might think or write them. It’s true that the author of them is guilty, as it was their own harvest, but I am not afraid of anything they write. Perhaps in the future, when I look back and realize that I was not a writer. Then, surely, I will understand myself.

I love to write simply because I am not a writer, to find a place where I can express, without fear of what might happen, what I have wanted to express for so long. In the past, I experienced a life that no one in their right mind would choose: so much craziness in so little time…, so many disparate and unhealthy emotions…, and I found myself on the brink of chaos. I was simply learning to read and write at the same time. Where forgiveness and mercy seemed to play hide and seek every day. Where games and their memories portrayed nothing but a non-existent childhood.

It’s challenging for me to speak in the past using the first-person singular, for I was never anything or at least believed so; sometimes perhaps too much. It is possible that not being a writer, I can tremble without fear when writing. Or perhaps, not being a writer, I can write without fear of trembling.

I am not a writer. Moreover, it is precisely not being one that gives me more strength to prove to myself how wrong I still am, but above all, to prove to myself that I still have much to discover about myself.

To Another Level

To another level we play, where gazes revolve around a clear understanding. Where sadness remains a mere illusion that fails to cast a shadow on our confidence. We entered this world without permission, where clarity does not stand out for its presence. Everything is rather lacking in essence, and a bit more warning wouldn’t hurt either.

Born of memory, of remembrance and forgetting. The fruit of our third person and that introverted event. Unexpectedly, we could see each other on another level, at a price that became impossible not to pay. Apparently predestined, we might think, but destiny is slow and, at times, truly grotesque. It’s not even close, but still, we will be obligated to go through life with it always hand in hand.

On another level against destiny, against the world, against the path that some blindly choose in their daring ignorance. On another level against life itself, which, in our humble understanding, we learned to discern from its own paradox.

What is our breathing if not a sway of unasked sensations and a mixture of everything and nothing? At what level will each knowledge be if not the one we, in our judgment, grant it? On another level, we will understand but never be grateful for an unspecified ending but unequivocally destined.

To another level, simply. Where people and minds wander in search of comfort. It ceased to be a secret long ago thanks to our real and courageous suspicion while many, locked in their harvest, preferred not to realize the obsolescence. More of their mistakes than their successes, where memories with preferences are scarce. And the qualities of their stays were counted in brief moments.

As if our goal were to become, above all, passionate professionals of passionate life, as well as rational; each in its due measure. We must now say without any fear: “To another level we play,” for we are the fruit of memory against destiny in our breathing with other minds.

Precisely

There are certain things that are still frowned upon. Especially taboo topics in a close environment; even family. Delicate topics that we are forced to handle with care if we do not want to burst a bubble that continues to grow day by day in its own stupidity and meaninglessness.

Topics that were born seemingly unnoticed, and that, in the end, will be precisely those that make us question: “How the hell have we come to this?” It is already too late to undo the absurdity, the nonsense, and the chaos into which it has degenerated.

Precisely because it is a taboo subject, it affects our inner self. Precisely because we are not and will not be until we free ourselves from everything we want to be freed from. Precisely because we are our true gods and should love our lives, as well as their continuous improvement. We learned not to be silent when people normally remain silent and to try not to limit ourselves by taboos, especially the most delicate ones.

And it is in our passion that we tend to be creative, to push the limits of our creations, and, of course, to be ourselves. It is precisely for this reason that we write not only about our thoughts but with them, leaving our minds free to roam.

We might be more or less correct on some issues and, of course, wrong on others. As we should already know, our mind is not a box of absolute truths. Instead, it should be filled with true and sincere realities where knowledge overflows in a restless sea and is supported by the pillars of wind and tide. Where objectivity does not have to detach from the mood, nor our existence from desire. Where our arguments are so broad that they are hard to believe, not for lack of arguments but for their incredible connection among themselves.

It is precisely for all this: because we can and should be wrong. We were born without warning and without permission. Let us live exactly what we really wanted and want. Let us die without fear of having lived.

It Says a Lot About You

Perhaps you are right, perhaps you are wrong. Maybe everything you believe is accurate, or maybe everything is false at all with no distinction between tales. What will always be evident is that everything you practice with blind faith will say a lot about you.

Beyond being pragmatic, being realistic, and conceiving our reality as something tangible where enjoyment and success in knowing ourselves are linked together. Beyond being ourselves, being thinkers and savoring our senses are the most important things in our lives, where pleasure resides mainly in actions and the decisions we make.

It will say a lot about you, those who, scared by fear of your own self, hide. Fear of the unknown: I mean yourselves.

What good does it do you to hide, hoping to be right about something that is not evident? What good does it do you to believe blindly in something that does not lift you up as superhuman but rather diminishes you and insults you in your greatness?

Wake up, I tell you! Those who are still asleep or who will sleep will not enter the greatness of wisdom, will not deserve their sense, and will not be blessed. To those who slept but woke up, I congratulate you because you will know your true sense and will enjoy it, being really yourselves, everything you deserve.

Perhaps it is true, perhaps not. Perhaps we are wrong, perhaps not. The rules of our game should be dictated only by us and our experience.

To those who are awake, I write to you. Never forget that you will be what you say, and you will say everything you are. Be without fear!

Capricious Destiny

I love dressing virgin pages with different garments, where there is no room for fear, and courage becomes even bolder. Playing at being ourselves, feeling alive, and aware of our own being and our ego, as well as our smile.

Enjoying each morning as if it were the last. Growing every minute imagining our insistent evolution, clinging to our person, and where moments become ephemeral experiences to end up transforming into a whole full of sensations.

Intuiting at every moment, still and in motion, what chance sometimes finds it difficult to recognize: its moments in time. Chance is nothing more than the probability that something possible happens, making us participants in it to the extent that we have fixed it.

I love diversity, as well as the courage that the nonexistent destiny has to make itself present when we least expect it. In our immensity as in our person. Nothing more than fleeting experiences in time that will wither sooner or later.

In our smallness lies our greatness: the power of our evolution and our own change, as well as adaptation. That is what should truly excite us about all this: our constant in life next to a capricious and nonexistent destiny.

The trajectory of our luck will be, in itself, a paradox where time will be the only judge that equalizes us all, without distinction.

Let’s not live aspiring to dream that someday we will reach the life that belongs to us; let’s live the life that we once dreamed of, without fear of the absent, witty, and nonexistent destiny.

Chapter 10: December 2015

2015-12-01T00:00:00+00:00

The Art of Adaptation

To fear routine and repetition.

Sitting on the subway, longing to get home to think calmly and enjoy it with good background music. I fear not being able to finish what I started, leaving unfinished all that I would like to complete, or at least, relegate it to a stable version.

What is philosophy if not questions about questions or ideas about ideas? How apparent are things that seem evident? Who could regulate or decide their degree?

If I had to choose one word to define myself, it would be “improvisation,” like the art of adaptation.

Who can assure us that we will wake up tomorrow? Tomorrow does not exist without us. Only today and where we are heading without a decided ultimate goal.

Thinking that tomorrow is uncertain should compel us to live truly as ourselves, not to exhaust ourselves doing nothing, as if nothing mattered. I think about it every day, so making today the best day of our life shouldn’t be an option. Let’s make today the best day of our life.

I feel sad with the bleeding news, as well as happy in the company of those who make me enjoy feeling truly alive. Everything is so complex… Sometimes so beautiful, sometimes simply nostalgic and melancholic. Overnight, everything can turn cold or warm in an instant.

We are bound to our past and destined to be to our future: hence the importance of our decisions and their consequences. Feel, reflect, learn, improvise… Simply, little by little, with great patience. We will amaze the world, especially ourselves.

We don’t know when the last time will be, when we will dream, breathe, or desire. Let’s make each moment ours without excuses, without possible tomorrows that never come, without “there will be other moments” or “I’m not sure.” Self-assurance is our main key to happiness and our confidence, as well as its continuous pursuit.

It’s not about seeking unattainable and endless happiness. Instead, it’s about shaping ourselves to become what we genuinely want in this place that no one chose, where we all exist, amidst the mix of challenging yet sweet moments.

I couldn’t smile until I decided to improvise with myself. And now, everything is possible.

We Will Die

I will die. We will all die.
Cries, memories, and longing,
like ephemeral feelings
in a forgotten comfort.

You will die. It will be without return.
Nothing will remain after your wake
if you decide it that way.
Your past reveals it.

We must be more patient
because soon, we won't be...
It won't matter if you don't feel it.
Together and alone, we will cry.

At what cost does all this come?
What is the cost of this game?
No rules were set, that's true...
There will never be another "see you later."

Memory may fail us,
the memory will be forgotten.
And every person as an individual,
everything will stay by their side.

Next to their oblivion, alongside their death;
in our future, to our fate.
We won't see you again
or have you to read you.

Death as an absolute truth.
Time as a divine equalizer.
We... as mere mortals.
And then I. That is, you.

Sudden Emotions

Like a game that never ends. Like a cycle in which we find ourselves immersed without realizing it. Like a continuous loss and gain with no return.

Like a swing of emotions. Like a cold summer and a hot winter at the same time. Like a never-ending series of impressions.

Like none of us could imagine. Like we all suspected… and as happens at the end of all chapters of life.

Simply waiting for something to happen, as nothing has to be where we, in principle, believed it should be. It’s not foolish to think about it: about nothing in particular and everything in general.

So much to do and to desire, so much… that sometimes we simply don’t have the strength due to the great surprise that some days can bring us. And it’s not necessary to reject the unknown simply because it is unknown. Especially concerning emotions, without referring to any specific one. Because there are so many and so different from each other… that to avoid forgetting any, let’s speak from this abstract perspective where we all understand each other.

Without any apparent reason, and indeed, it doesn’t have one. Because everything is in our ideas and expectations, in an expectation that no one promised, submerged here and there.

Like a dream we could aspire to, a dream where an image is worth more than a thousand words, where passion and reason go hand in hand, where we are the true protagonists beyond unnecessary suspicions.

Feeling shivers in who knows how many thoughts that, like birds, simply want to leave their cage to fly freely where their instinct guides them and the wind allows them.

Like a game that will end someday. Like a continuous cycle of decision-making in which we will be involved unwillingly. Like we all imagined someday and only a few suspected. And, as with chapters, all stages eventually end. But not all in the same way. Herein lies the main difference between some and others.

Each of us will exude different emotions. It will make those around vibrate in one way or another. Emotions that will depend on everything, on the day and the time, on the who and the how.

We are so unique and valuable, especially in our diversity of sudden emotions.

Not Life

Not everything has to be decided now. It’s not about that, but it is about having a rewarding goal where we would really like to be. Something we would really like to achieve after an effort made. Something to think about that motivates us to work in our daily lives, to get up and study with more enthusiasm. To think beyond a routine, where things simply happen without apparently anyone needing to change them because, in the end, they seem to have always been that way.

It’s about motivating ourselves, incentivizing ourselves, cultivating ourselves, and not letting ourselves be carried away by life without answers or questions, without real learnings or new experiences beyond the monotony of the boring.

And it’s in our hands, in our power, and in our will to change for better or worse all of this. We are our own God, our guide. We are our last word.

A life is useless if there is no passion for living it.

The Problem with Christmas

The problem with Christmas lies behind its false values of forgiveness, love, and sincere family gatherings. I am looking forward to the day when I can see this from another perspective, really, but nowadays, it is something impossible for me, at least in my case, and it’s not precisely something that depends on me.

The problem with religion is, again, all the simulated values hidden behind it. Illusions in beautiful words that humanly end up being conveniently forgotten.

Masks that constantly play without permission. Uninvited double standards. And you, unwilling to know exactly what’s happening despite trying so hard without reward. “Hear, see, and be silent.”

Everything comes from much further back: years and years of error without correction and without hope for the future beyond an excess of confidence in responsibility, in a non-existent and foolish God. Miserable.

But more guilty than God and His non-existence is the deficiency that some have due to their excessive belief. More culpable than God are the humans who abuse Him and use Him: they modify His meaning at their whim and try to instill it as an absolute truth to their peers. Incompetent and foolish, locked in their damn hypocritical and disloyal “faith.” The context of our words can so much vary our real intention…

The problem is not Christmas itself, much less its celebration or the idea of a special family gathering. It is the one who deceives and the one who allows himself to be deceived. The problem is not the tools or what we have, but the use we make of them, especially with regard to those who matter to us.

Chapter 09: November 2015

2015-11-01T00:00:00+00:00

To the Motive

There has always been a purpose. There always will be. Something to keep in mind. Cause and motivation for our writings. Our actions, as well as decisions, are governed and inspired by a motive.

Motivation as a fundamental basis. Vital, I would even dare to say, because without motivation, one could not live, and I’m not talking about simple breathing. It is what inspires us to create, to smile, and to fight against the current if necessary. Our motivation is our inspiration, our muse, the one who gives us courage, who reminds us of the value of what we are carrying out, and who dreams alongside us.

Ideas, illusions, sorrows, aspirations… All are born from our most emotional selves, wanting to feel fulfilled always within the limits of our possibilities. For the motive and by itself. Cause and cause of its existence. For its elegance, I write to it: to motivation.

Who else but she inspires me to write to you? I write to you, who suggest and give me more than enough reasons to express all this that I so eagerly want to convey. For my motivation, for herself. For knowing more than anyone what to desire and to what extent. For being mine. For questioning and helping me. For being me.

To my motive, my motivation.

My Project, Our Project

Our project doesn’t have to be common or even shared, but I’m sure both of us would like the same goal: to achieve it. And there is nothing more satisfying than achieving our goals, from those we set in the past to those born just a few seconds ago. Time doesn’t matter when it comes to creating oneself.

Let’s change, breathe, and evolve without losing our essence, being the ones who decide. There will be no prayer or creed to guide us. Let’s enjoy ourselves and our decisions, as well as our mistakes; but above all, let’s learn from them— from our decisions! Let’s not stop, let’s keep moving forward. We will manage to surprise ourselves, without a doubt.

Maturity is not achieved with age but with experience.

To Necessary Mediocrity

To necessary mediocrity. The before and after.

To what extent and with what certainty can we play at refuting ourselves? Thinking in reverse, believing that we are really deceiving ourselves.

How can we not be sad or depressed with our entire past? It is our focus that will have the final say about our attitude and person. How could we smile today? Thinking about everything we have learned and are doing now.

Learning as anticipation. Anticipating the mistake but without fear that it will happen, and if it does, let’s face it without fear because it will be nothing more than an emotion and illusion; and there will be none that we cannot control.

Your Last Day

Who can assure us that we will wake up the next day? With what certainty can we confirm that tomorrow we will wake up to continue our routine? Who would dare to be so unconscious as to ignore these questions?

How would you like to end your last day? Whom would you like to have in mind?

Let’s think about that day for a moment. Let’s look back. What can we see? How satisfied are we really? What would we like to have changed? What would we like to have improved? What would we have really liked to do instead of what we did?

Words are unnecessary due to the great obviousness of what I will write next, but I’m afraid I must reflect it: we should ask ourselves these questions every night before going to sleep. Talk to ourselves, laugh, express ourselves, and listen to ourselves, but above all, understand ourselves. We are who we are, but above all, we have to be who we really want to be.

No one can assure us that we will wake up the next day. No one can assure us of a tomorrow, except us, our effort, and our willpower. Our last breath will be determined by our actions.

Everyone can have ideas. More or less brilliant. Even brilliant. But only the few who dare to turn those ideas into reality will be the ones who make a difference.

Know our duties, perform them, and understand them to feel fulfilled.

Let’s transcend!

Leave a Mark

It won't be enough to wish
and leave in past days.
It will only remain if we want,
even if we continue very tired.

Without a posthumous date and waiting,
without delay... we remain.
Everything will always come in its time.
Calm, for we will be.

A little more, don't retire,
remember those sunny days.
It is enough just to look:
no more erased memories.

Look for new challenges to do.
At late hours, without delay.
You must seek to be born again;
let that moment be now.

Feel, grow, die of laughter.
Live each day dreaming.
Please, don't be in a hurry,
with time everything will change.

It is time that keeps us
a countdown that endures
until our day comes.
And our word matures.

I will conclude as a master said:
"The future is something inevitable.
The sooner we make it ours,
the sooner it will become kind."

Chapter 08: October 2015

2015-10-01T00:00:00+00:00

Above Good and Evil

Above everything possible and impossible.
Above the real and the fantastic.
Above dreams, life, and death.
Above ourselves.
Above your frustrations and suspicions.
Above everything you once dreamed and will dream.
Above your dreams and goals to achieve.
Above Good and Evil.

Above emotions, success, and failure.
Above sadness and joy.
Above tears and smiles.
Above fatigue and euphoria.
Above time, which consumes us all equally.
Above learning, which, linked to overcoming,
drives us to keep growing.
Above Good and Evil.

Above any forecast.
Above any thought, whether similar or different.
Above any difference.
Above ourselves, Good, and Evil.
There I will be, and you, if you want, with me.

What are we?

Let me take this moment to remember… What do we want to be? A mere illusion of a forgotten memory, or do we want to become a transcendental reality?

What is our life but a memory of lived moments, of our experiences that, along with our expectations, lead us to a constant illusion of desire: to desire and to be desired? What good is our memory if we cannot remember? What would our mind be for if it couldn’t process? Let’s teach ourselves to think. Let’s create memories!

A life is useless if not lived; no one will live for us. We must learn, therefore, to use our common sense and to live using the mind and reason.

Let’s make mistakes! Let’s make a lot of mistakes, but not the same thing. Let’s stumble with as many stones as we want, but let’s not repeat, and if we repeat, let’s do it with a clear head because, otherwise, we will be in an illusion. An illusion that once existed but never again. And there will be no longing or desire for what once was without being; in fact, no one will miss it.

We are decisions, responsibilities, as well as final results. Everything matters even if there are always different situations, each with its different degree of importance; our obligation will be to conclude with an average above itself. Our commitment will be linked to our experience; our duty, only to us. It is also true that we owe everything to everyone, but especially to ourselves, for our decisions, for being who we are and who we want to be.

We are the final result without end… until there is one. And then, what will we have been?

Memories of a Forgotten Memory

I barely have memories of my childhood.
Memories that faded with time.
Mention specific moments with nostalgia.
Desire to overcome that thing called ego.

Let’s start with the end: I am better than ever.

I wouldn’t want us to feel pity for those days of an unforgiving past, but that doesn’t mean I don’t feel remorse, sorrow for a lost youth, and, above all, for the number of desires that perished along the way.

In those days, I learned a lot. I learned like no one should learn. I learned how things shouldn’t be done. I learned that there are always different versions of the same situation. I wouldn’t call them points of view but rather realities.

What is reality if not our illusion of understanding? Why should one situation be more real than another equally true? Reality is nothing more than our perception. Our truth, yes, the one we believe is unique and real, is just another conception of the world.

And those were years that, luckily, disappeared. They vanished as much as possible, giving way to a new today where I now settle because my mind is wiser than I am and learned to forget all that without my permission. It’s funny because, in part, I feel cared for by myself, and that makes me happy and relieved.

After my eleventh, a tragedy I couldn’t understand but also couldn’t foresee coming. And by the time I wanted to realize it, I was already thirteen in a basement where everything was too late: latches that prevented our movement and stairs that only went down… toward despair. Day after day filled with uncertainties, sorrow, and longing. Longing for a reality beyond promises and wasted time. Nothing seemed real. Appearances were deceptive.

A constant and daily emptiness. Waiting for everything to change, to see some green sprout, it didn’t matter where… Everything was insignificant, and that’s how it made me feel.

“People don’t change,” as well as other unpleasant sentences that I still, “fortunately,” remember.

The world is full of people of all kinds. At that moment, I couldn’t smile because with so much pressure on my back, sometimes it’s difficult to discern. Let’s keep in mind that we are talking about the period between fourteen and seventeen years old, approximately. I hardly remember anything. As I said before, my mind is wiser than I am. Hopefully, we never have to read this again.

Let’s finish with the beginning: today, I am better than ever.

I Think Too Much

I think all the time. I even believe I sometimes think too much. I understand so many obvious things as natural that I am surprised when I perceive that not everyone has the same understanding of what is natural.

I think so much that I believe I haven’t thought of anything. At least not enough to say that I’ve thought of something because I still have a lot to think about. Exemplify, reason, demonstrate, teach. Everything in a little can be a lot.

You won’t be the last to read me or the first, but you will have had the luck to have done so, and that is what truly matters. Who am I to write to you, and who are you to read me?

Nothing is eternal, especially when it is nothing more than a fruit of our illusion, like our dreams or hopes, as well as longings in our desires.

From an early age, I wanted to know a truth that could not be denied or dismantled. Fed up with so much talk… Now, I simply smile with my happiness for having found one of the most beautiful truths.

I plan to enjoy this absolute truth: the non-existence of the eternal. Just as I plan to enjoy everything that exists because there is nothing more pleasant than learning to enjoy everything, as well as nothing.

I don’t believe in anything above man, I don’t believe in anything or anyone above us. Let no one be afraid of their freedom. We are individuals and, at the same time, collective. We can be everything and, even more easily, be nothing. Everything is left to our final choice, and I am clear about mine.

I love early nights
and late dawns,
exalted in a dream without memory
like an empty memory.

I would really like to be read, why else would I write? Perhaps for the simple enjoyment of thinking. Perhaps for the joy in oneself.

With our dreams and in a dream. A thinker like no other, mortal like everyone.

Chapter 07: September 2015

2015-09-01T00:00:00+00:00

God exists: it’s me, and so are you

I am an undead. I am alive—more alive than ever! I am a person who likes to have things clear. Character, fair.

I am a life-loving person, embracing the moment and time, as well as my circumstances. I would never want to be a person idolized by the masses who cannot see beyond their reality.

I won’t go into details about whether it’s more or less correct to be faithful to one belief or another. Everyone can do what they want—that’s our freedom—but freedom is linked to responsibility. Each becomes responsible for themselves; each one, guard your beliefs, and I will guard mine. Guarding mine means not staying silent when something bothers me, when something is not right in my eyes, or when I believe something doesn’t make sense. Then, I will speak up to try to correct it.

No malice here; no one has come to discuss good and evil. That’s something everyone can handle on their own. I am against any religion that does not uphold individual human value above all, above any divine entity.

I argue that we are the greatest. But, beware! This is not valid for anyone who denies their power, their will, and their greatness as a human: their freedom. To all such, I simply wish an enjoyable stay, but nothing more.

However, to every person who knows or wants to discover their true greatness, to all without exception, my encouragement. Because it is the attitude we choose towards life that truly plays at our forefront, and this is precisely where I wanted to get: the attitude of any God is that of following mediocrity, rejecting our real value and human potential.

To achieve success, we must have an attitude of personal improvement, not a rise in life to, after death, have an encounter with a supposed God.

God exists: it’s me, and you will be too if your attitude predisposes it. Because God is nothing more than an idea, a philosophy, an attitude towards life. Believing in a God says a lot about you, says a lot to the world, and says a lot about your attitude.

My encouragement to anyone who wants to surpass themselves. To every soul that wants to surpass itself one day because it will all be yours, you will be God, and life will truly belong to you.

I needed to dream

I needed to dream because nothing is forever, except what we set out to make so. It won’t be a question then of being right or not; it doesn’t matter here. It’s about setting goals beyond our possibilities. The capacity for self-improvement that we can seemingly demonstrate out of nowhere is impressive. Just as working on another attitude, the more we exercise our will, the greater and more precise it becomes.

What is normality if not what is previously established by our environment and accepted by the majority as the norm? What is normality? If not, what predisposes us to what has not yet happened? What is normality? If not, what pigeonholes and limits us as beings free of will?

I needed to dream… and I dreamed, just as I continue to dream every day, hoping to keep doing so until my last breath. I had a dream: to be myself.

We will make a before and an after. Who knows who this might reach? The best thing about the meaning of life is that it will have the meaning you choose.

The art of thought

We could understand philosophy as the purest and most abstract science based on subjectivism, which, instead of providing answers, seeks to find the right questions. To philosophize is to question.

The purpose of this art should not end with being read. Philosophy should strive to be skeptical and pragmatic. Reading philosophy is healthy. Studying it, if we like or are passionate about it, can provide us with a rich cultural level, but that should never have been its ultimate purpose. The art of thinking did not arise to be read or written. Writing philosophy is useless if we do not contribute any questions. Reading philosophy is useless if we have not equipped ourselves—with new or existing tools—to continue building ourselves because philosophy is useless in itself: we are the ones who will give it the value we consider.

There is no absolute truth that regulates its importance and value, because something so abstract, how could we quantify it? The value of doubt. There lies its true value: it is doubt itself!

I dare say that, just as other branches were conceived with the ultimate goal of being read, written, and studied, such as engineering, philosophy did not arise for this same purpose. Philosophy was born, above all, to learn and put into practice questions, to learn to question whether we are really asking the right questions.

Philosophy did not arise to be engraved on paper or read by others. It arose from the basic needs of our most rational being, from our need for knowledge. Philosophy did not specifically arise to be told but to be lived. Be the one who lives it and then tells it!

Being right

Being right is having arguments that defend and prove our convictions and thoughts. Being right is being able to silence, to leave pride speechless no matter how much it insists by raising its voice. Having solid arguments is synonymous with a clear mind, a mind organized in its firm and solid ideas.

Because unreason has its days numbered. A house without good foundations is destined to be destroyed by itself. Being right must go beyond simple words or beliefs, as they are useless if our actions are different.

The complexity of everything must be understood from simplicity to gradually learn to understand everything.

There are so many possible variants and parameters… that no matter how much we know, it will never be enough. Hence, the importance of demonstration, of reason beyond mere conjectures.

Defend your interests, but always with arguments, and the day these are not true foundations, I propose to you: destroy them and start again. For building on something rotten…, that’s how it will be established.

A closed mind where ideas cannot converge is synonymous with failure. A closed place where ideas cannot converge is destined to be forgotten.

Chapter 06: August 2015

2015-08-01T00:00:00+00:00

Everything is stages

We are stages and moments, with their highs and lows, like everything in this life. We are stages and moments. It will depend on our context to understand if we should step firmly or delicately.

We are moments. Without them, we couldn’t be, directly. We are our personified description. How we face our stages, each different from the other will define us not only for today but for tomorrow, engraved in yesterday.

We are in stages of constant evolution whose main duty is to define our own direction. We must choose our favorable direction in this journey full of surprises. This journey gives me so much to think about. In this journey that, in the end, constantly gives us so much.

Moments and stages are so different. Experiences that would deserve to be captured in a song, a drawing, or an image for remembrance. We are on a continuous journey in a sea where the arbitrary tide neither forgives nor has preferences. Being creative, flexible, passionate, and rational will be our duties.

We cannot guarantee with total certainty which stages we may encounter, but we can define our way of understanding them, starting with ourselves.

New friendships to discover, new places to visit, new experiences to live…, new moments to tell.

Whose world is it?

To whom does the world belong? The world should belong only to those who claim it, to those who fight for it, to those who truly want it. There are those who are just passing through. They don’t expect a better future because they think they don’t need it. They don’t know what to do with their lives or don’t want to know. They are not interested in the world; they just exist. There has to be everything, but the world is not theirs, not as long as they think this way.

The world should be for the fighters, for those who don’t give up, for those who dream and don’t stop until they achieve their goals, and for those who, even tired, continue in the arena for their improvement. It should be for them to better themselves, as well as their surroundings.

Whose world is it? For those who aim to find new goals. For restless souls. For those who manage to find a reason for success in their lives. For those who, in the face of all adversities, manage to move forward. For those who, despite all difficulties, manage to seize any moment to learn something new. For those who, instead of spending the whole day complaining, spend it looking for solutions. For those who don’t give up.

For those who seek to change the world. It belongs to them. The world is theirs.

Your purpose

“Let’s be honest: we are nothing. We are the most insignificant thing that has ever existed. We are mediocre by nature. Simple humans. Sometimes even cruel, sometimes unnatural.

Let’s be honest, we are nothing. We waste time constantly. We are not productive and don’t want to be. We do nothing to solve our problems or to avoid the future that may come.

Watching time pass, being consumed by it, and we let it pass. Losing day after day without doing anything truly productive, throwing away a whole life, and we are so calm. We have everything within our reach. We really have everything. And we, foolish and stupid, don’t want to change. We don’t dare to act, think, or truly improve as a species.

We are cowards, and as such, we won’t get anywhere tomorrow. No one will remember our existence, our passage, or our name. We will be what we have decided: nothing. Because that’s what we wanted. It was in our hands to change our destiny day by day, progressively, and now we have what we deserve.

We are nothing, and in nothing, we will remain.“

If you identify with any of the previous statements, please reconsider the meaning, as well as the reason and purpose, of your life, for there is nothing sadder than a lack of purpose and nothing more urgent than finding it.

To the attempt, I say

Coward, liar, mediocre.

How do you expect to get different results if you always use the same patterns? Who do you intend to deceive with your intention? You deceive no one but yourself. Stop running away from yourself and face it, stop being just another mediocre.

Stop deceiving yourself into believing that you tried and couldn’t do more, for it is false, and you are the first to know it. You could always, just as you can do more until your last day. Stop lamenting in the shadows. Go out and face it once and for all! Stop blaming the world for your problems. Go out and solve them!

Stop hiding among complaints, and stop living in mediocrity. Come out of your hiding place, where you entered a long time ago, and now you don’t dare to leave. “Dare!” I tell you. Because you are the only one who can. My words will remain written; your life will be forgotten.

Go out! Now! Stand up and stop lamenting. You know alternatives, use them and stop being a fool! I insist!

To you, I am talking to you. Stand up and learn to live for once! I don’t want more intentions. I want actions and demonstrations!

To you, who are reading me. I say to you. To you, who come with intentions.

Chapter 05: July 2015

2015-07-01T00:00:00+00:00

Actions and words

I’d dare to think that there is no more significant order than to act according to one’s thoughts as if they were about a young utopia for society. All that we wish for, but only a few make it.

We are what we do, and we’ll be who we wish to be in the end. Is there anything more beautiful than living the life we dream of? Yes. Following it.

You agree with yourself on the way, on this adventure called life, in this path, in the end, of phases that are so different. Let’s be wind, water, or fire because when we’re on earth, there will be nothing left but dust and all that we have marked on our way, and that’s when the how and when will resound more than ever. That how and when will be all that will be left of us.

Let’s be wind: let’s learn to fly and not limit our imagination. Let’s be water: let’s know to fit in, mold ourselves to our surroundings, and study our ecosystem and its behavior. Let’s be fire: no obstacle can stop us from reaching our goals. Let’s be because we’ll be only earth and memories when we stop being.

Life should be measured in instants. Let’s make those part of the memories of those with whom we share those moments.

To listen unnoticed

Sometimes all we need to do is to listen. To stop, meditate, and observe. In the same way, we need to be heard; we need to listen to the world to comprehend it and show it that we’re with it and the world with us.

In the same way, I like going unnoticed, but only for the world, not myself. I’m not too fond of the idea of being famous or popular. I prefer anonymous heroes, like those considered crazy in their epoch, mainly because they were different, just because they took other roads. I like peace and tranquility. I want to enjoy my moments of solitude, reflection, of inner order.

I like to express myself, mainly when alone, as I have to listen to myself.

What is clear

We all have moments of clarity now and then. I want to record this moment so that, when I forget it, I can remember it or at least read it, never to lose sight of it.

Many things are still unclear, such as what I have to grow or what needs time to evolve, but there is one that I have clear enough: I would never want to work if forced.

I’m not a fan of “forced work,” referring to working on something I don’t want. The type of work where I’d have to get up day after day to do something I don’t want to do, do something that doesn’t motivate me or thrill me, that doesn’t complete me or add anything, something that will be left obsolete in the short future, something that I did not choose nor will want to select.

I don’t want to work. I don’t want a job; I enjoy challenges and continue with non-stop growth. I want to develop myself as an architect and artist in my profession. I want each morning to be a new challenge. I want each sentence I write to be flawless, just as I want to improve it the following day. Because if there is one true thing that needs to be learned with time, no matter how well you do something, it can continuously be enhanced. And it is not at all something negative. On the contrary, that’s the real improvement!

I don’t like monotony, conformism, or much less. I am in love with time. I try to be with it whenever I can. I try to take a moment to enjoy and innovate with it: to create projects, complete them, improve, turn them completely around, not stop thinking about them, and to use a side thought that sometimes will take them to achieve success.

It’s all about proposals. To learn three new things each day will make it twenty a week and around ninety a month. Don’t you think it’s worth trying?

The question is straightforward: if someone before you made it possible, couldn’t you? No doubt it. I will raise the stakes if no one before you has done it. Does that mean that you can’t be the first? Is everything invented already? We are still working on that. What do you think we do each day other than creating ourselves? Reinvent ourselves, clarify ideas, and order our thoughts. If nothing else, what is clear is what I want to be. And I will be.

Chapter 04: June 2015

2015-06-01T00:00:00+00:00

Older brother

We must want to be the older brother we would have liked to have. We have to be everything we wanted yesterday so that we can be that tomorrow. We need references, more so when it’s about making way. I wish I had an older brother to look up to, learn from him, and help myself with him by my side.

It was complicated, but it was no use to live to hide, day after day. I saw myself forced to go out, observe, grow, and fight. I would have liked to have one, especially at those moments that got so complex and complicated. My main reason is to be a role model to my siblings so that they do not have to throw the same things I had to throw.

I want to be that older brother I would have liked to have. That role model I would have wanted to follow. That one I would have liked to admire. Especially at hard times, helping to avoid any of my brothers and sisters feeling that way, as it is not only about us but about what they make of us. To help us make our way, help us, and give a hand.

The 22’s end

Today is my last day as a twenty-two-year-old; tomorrow, I’ll be starting to be twenty-three. And it is today that I am completing my twenty-two twenty-two complete years. Starting tomorrow, I’ll start living my twenty-three. People celebrate on the day of their birthdays that they have completed the phase that just ended. In standard terms, I should “celebrate” that I reached twenty-two. However, I prefer the idea of celebrating that I got to the next phase and still have all this time to enjoy. Not my twenty-twos; my twenty-three. My twenty-twos have already been lived. Now I want more.

It is true that now I will live for twenty-two years, reason enough for joy, but I am more motivated by the idea that I still am, which is essential.

I have never felt as alive and young as now, and I hope to aim for more with time. Younger and more active. I feel like having birthdays is rejuvenating. Having birthdays is more than the idea; everything comes with them.

Today is the day I will complete my twenty-two years; tomorrow, I will begin my twenty-third. If you’re reading this, I appreciate it in advance, and with a smile, congratulations. The only thing I ask in exchange is for you to smile back. So do it because it’s never too late to smile.

Solitude

I enjoy having company at its most, but I also appreciate its absence. I love being surrounded by people, but I also need moments alone. When I am always busy with others, I even miss myself. Those moments of solitude in which I talk to myself without giving anyone excuses other than myself—those moments of putting in order, reflection, listening, and silence. Usually, music accompanied me in the background—smiling music, like me.

Notes and ideas that shout endlessly to the rhythm of memories, ambitions, desires, and the future. Those moments of analysis, recreation, uncertainties, and inspiration. Of wanting to do everything and eagerness to do so.

Dreams and emotions that still must wait. Enjoying a song, as well as its meaning. Without lyrics, the lyrics will be created by all those thoughts that she will make us remember. All while losing track of time, forgetting everything, and remembering nothing—focusing all our attention on the music’s rhythm, evading everything that could worry us.

To play to write, disconnect, and connect again. To worry and stop worrying. It’s our minute. Let’s give ourselves a breath. Nothing will happen independently, but it’s also not a mystery from another world. You have to make it happen. Waiting with our arms crossed is of no use. It has never been helpful. That’s why it’s not about wanting to dream but about doing. Here we are to do everything we can and always a little more.

It’s solitary sometimes, but not alone.

There are

Some lament themselves, and others live.

Some live in constant fear of life, and others dare to confront it.

Some only consume their time, and others fight in their realities.

Some don’t realize the real value they’re throwing away, and others enjoy small details.

Some don’t dare to dream, and others desire.

Some have nothing, and others are courageous, uncomplicated, and full of life.

Some lack sense, and not precisely because of those who have it.

Some waste their potential on excuses that not even they can believe. And others who take advantage of all their potential to change themselves and, in that way, change the world.

There are, and there will be, as there always should be a bit of everything: that’s how it is in our nature. The only difference will be: who will we be? Who do we want to be?

Some find it impossible to smile when they wake up, while others sleep with a smile.

There are those we wish not to see all day long and those we constantly need by our side.

Some emit negative energy just through their stare, and those that, when you see them, you can’t avoid smiling innocently due to the joy they share.

There are, and there will be because it’s in our nature. There will always be a bit of everything, but the question will be: who will you be?

To create

One of the reasons why I love my job is because of the simple fact that I can create something out of nothing, and I think that it is a feeling that is shared in many other professions.

I like what I do, to feel free within it. To feel accomplished is fundamental in our routine. Creating solutions, solving problems, creating new challenges, and reaching our goals should be our main job.

I get up each day excited to create and write down each idea, madness, possible solution, and each try in the end. To progress creating and daydreaming. To make all those ideas that were once born from an illusion.

To establish new challenges, to create more and more. To demonstrate to ourselves the responsibility boundaries of our imagination, proving our enormous power and responsibility. To give something to the world, innovate, show, and not just talk.

To reveal all that we can create. To prosper in the world, making. These are the reasons why we should love our work.

Chapter 03: May 2015

2015-05-01T00:00:00+00:00

On-time

Is there anything more relative than time? A second, a minute, an hour, a day, a pause.

Like the first time we dreamed of, that moment was like an encounter after that much time. Like that result that we see with satisfaction after our efforts.

What is time? I see time as our tester — the one that teaches and corrects, the one that involves us directly in life. We could see it frequently as our enemy, like a liar with its absence, but I prefer to see it as a gift and outcome of our patient. We shouldn’t have a reason to have it, yet, there it is, waiting for us.

Sometimes we wish it would pass. Let’s be us who face time against it and in its favor. Let’s learn; let’s adapt our sail to its wind.

How much time will it take us to learn to live? The answer is straightforward: an entire life. Therefore, let’s not be afraid to make mistakes. Enjoy each pause, every moment, any instant, all words, every second in which we are genuinely ourselves, to fight against our time.

About being worried

A new day, a further reflection. For her, my days, but above all, my nights.

Again, tired, shouldn’t we? Of course, we should. Sometimes storms are coming, or at least that’s what we think. We get used to anticipating problems, thinking they are already here, and without noticing, we find them before they start being. That’s when the game begins when it should not.

Anticipating life is okay, but exaggerating these expectations can lead to mistakes because we can never be sure of our assumptions. We must prepare ourselves for the future but never focus too much on “possible” scenarios that didn’t happen yet. What a stupid idea, though. Thousands of things can happen until then!

The turns that life gave and will give. The number of variables that govern our surroundings. The number of parameters, possibilities, and opportunities. Those amounts are uncountable!

There are and should be preoccupations, of course. We must learn to have responsibilities and to worry about them. That’s why I say: “Let’s not allow non-existent ideas to ruin even a second for us!” Let’s anticipate some future, but be careful carrying too much uncertainty. Don’t waste time with unnecessary distractions.

We already have enough worries with the work-life requirements to be worrying about situations or possible results.

Get up and face yourself; you can go for it all. Don’t let a false and sad illusion damage a day. Don’t hurry when it’s not necessary. Patience is one of the most tasteful virtues. We need to give ourselves a little time to reflect. Everything will be okay.

Each different path

Create, enjoy, imagine, think, dream, and cry for happiness if necessary. Express and be yourself; that’s the most beautiful thing: improvise on each path in life.

What is our passion? What are we waiting for to make our day-to-day real? Is there anything more natural than ourselves? I don’t think so.

How many alternatives do we have? How many choices? How many possible paths? Which path will we choose for today? For what will you be remembered today? Today, you can choose. Would you please go out and breathe everything you deserve? Breathe as if there was no tomorrow; enjoy each breath, each sigh.

Each different path is there as if it were the last. It’s one of the biggest things in our life: the ability to choose. We create our way and enjoy doing it, walking towards everything, without stopping on our journey. Don’t miss out on anything!

Dream and fight for it. Let’s think that time is in our imagination as an illusion; this is the most beautiful thing. Write for yourself. We are going to a safe port, I am sure.

We are here to show ourselves what we are worth. That is our most significant duty: beating ourselves. Let’s create our path, something unique that no one could have ever imagined. Can you feel it? It’s you!

On the death

If you knew that you would die tomorrow, what would you do today? Would you go to someone? Who would you go somewhere? What would you do on the last day of your life? Do you think you could do something significant? Write? Go out? Think? Sleep until everything happens?

What if tomorrow you find you have cancer? Would it change your life completely? What if you lost your mother tomorrow? Wouldn’t it change anyway?

I am only afraid of what can slip through our fingers, of what doesn’t depend on us. We shouldn’t fear death itself, but the fact of not living the life we would have wanted to live. Let’s worry about what is necessary. Please do not live in fear, but don’t forget that she will always lurk.

What have we done in our life? For what things will we be remembered? Will we be recognized? Do you think you could do something significant today if you died tomorrow? Stupid and fool if you did nothing in your life. Stop feeling sorry for yourself due to your lack of will. Go out and seek your determination to do so! Let’s fight death if necessary.

Let’s leave foolishness once and for all. Stop not believing in yourself! You are the only one that can fight against yourself!

You will win. That’s why you’re here. Everything will be fine, as it cannot be any other way. You will make an extraordinary life so that your last day is the least of your problems. And when that day comes – and be sure it will come – it will be the least of your problems. That day should not matter at all compared to all the other ones.

That day will be the end of your immense phase as Superman of all that you have been. Beyond simple mortality. Beyond an idea or concept. You will be yourself. And then it shall be the day when you will be happiest because you will have lived.

Be proud when the day comes and you look back and see everything you have created, as not everyone can say the same. Let’s be part of your grandeur, of yourself. Fight against all odds to someday become a superman.

Chapter 02: April 2015

2015-04-01T00:00:00+00:00

The art of writing

I like to write without thinking about anything. I want to reread myself someday: maybe it’ll help me to understand myself better.

I am writing to reread it. Could there be something more exciting than being able to talk to yourself and agree?

Writing is an art where the language itself is the only limit. And what about the beauty of being able to write in other languages? I hope to be able to do that soon. All these years were spent learning languages for machines, and I never thought of learning other languages for people. It was never my strong suit, I always thought. However, now in another country, I can ensure that it’s one of the most beautiful experiences a person can have.

Starting from the beginning to learn a new language: understanding it from its root, enjoying it, tasting each new word, each new expression.

Exciting, as if it was a children’s game. Writing is part of a language. I want to read myself. I want to be able to read myself with my eyes closed, the same way I can dream with my eyes open.

Of a dream

I miss my family. Even though I’ll see them in less than 30 days, I consider seeing them twice yearly. And, to be honest, it isn’t easy. Being the oldest of our group makes one, without wanting to, have to be responsible. I need to be a role model.

After such a dark past, I am happy not to have fallen on any other path that wasn’t this one: my own. It’s not that it would have been easier. Nothing matters here but what there is: a young, happy dreamer, nostalgic and passionate.

I still wait eagerly to see more rain. Here, in the north of Germany, it is easier for me. I want to see more water falling.

I wake up each day wanting to continue dreaming. I want to live with passion and smile with my nostalgia, hoping someday to come back and hug my family without setting aside the dream I am fighting.

I hope to fulfill my goals: I want to move forward. “We are going to make it” is the phrase I repeat to myself the most, making me smile daily. Dreaming isn’t everything but the beginning of an entire life. Holding on to our dreams is the key to success.

We must learn to move, ask for help when necessary, and try not to stop until we make it. Life must teach us to educate ourselves. We must be our teachers: let’s focus only on the good examples.

Doubts

We must create doubts, questions, and uncertainties because that’s the only way we will find answers. We want to know more and discover new horizons, challenges, adventures, goals, and dreams. The name doesn’t matter. With or without help, but let’s do it. Let’s ask ourselves each day. Never stop doing that!

Let’s not have faith in anything other than ourselves. Above a possible God and any other life form, this is our own. By luck or disgrace and until proven otherwise, our life is only one, this one. Let’s not waste it living in constant uncertainty or a life in which we can’t find enough joy.

Each doubt is there to be resolved. From doubt comes actual knowledge and confidence. From doubts, we will be born.

Let’s doubt everything but not live in constant doubt. Doubt is a philosophy that we must learn to question before affirming. Doubt as a method: not flawless, but productive. Doubt, to clarify, enjoying our decisions.

Let’s make mistakes. Let’s choose! Let’s ask the world, our family, whomever we want, but above all, ourselves.

Let’s question ourselves each day as if our life depends on it because it will. And, following the question, let’s give ourselves answers. Let’s contemplate different alternatives as well as their reasons. All the parameters are essential. Let’s study each one’s origin.

Enjoy because you’ll be learning to live. Make mistakes, learn, live!

On the forefront

We should live more on the forefront and not so much on the back. Let’s reinvent ourselves and imagine yourself being what you think.

Who said fear? We should only be afraid of death, not life. Fear of death because it’s something that will come to all of us, luckily or not. It will be something we will all have to face once, twice, and more until it’s our time. Until then, who said fear?

“We are nothing” or “we are insignificant”: how wrong those phrases are. We are the greatest. We must be so. Live on the forefront, on the first line, discovering ourselves, as well as our surroundings, which are so different from us. As if we lived in other realities.

We are the most authentic and natural thing that ever existed. Each unit, as its match, makes oneself a piece of art, a unique reality. We are, and that is what matters.

We understand the reality of making progress each day and learning to fight at the forefront; this is our goal: to shine. It’s enough to listen to a song, read a book, study something that makes us passionate, go out for a run, and think about what motivates us, but let’s not live so much in the rearguard.

Let’s laugh and grow. We can give so much more of ourselves, and each day is a new chance to demonstrate it. Let’s live at the forefront!

Let’s show ourselves just how wrong we were not too many years ago, and let’s fight in our reality to shine each day even more. Shine for the world. Shine for us.

On the unexpected and necessary

It doesn’t seem very easy. And it might be that way until it ends to notice that it was simply something unexpected —a beautiful journey of experiences and emotions of every kind.

In the beginning, everything can seem so chaotic, strange, and confusing, but it’s nothing more than something unexpected. It has been a rich experience. Let’s not stay alone at home. The isolation won’t help us; let’s go out for a walk, the fresh air will clear our minds.

The world is full of unexpected opportunities. We should count life by moments, by those sudden occasions that end up being significant. Our life’s worth is made of the expected moments, as well as the unexpected ones. Both remain so necessary.

Just thinking of it gives me a sensation of sweetness, as if it were a gift for no reason. Let’s deserve this gift, then. Let’s fight to earn this unexpected and necessary thing in life. Let’s make ourselves deserving of each facility. Let’s take our time, always. But don’t forget that these unexpected will never stop being there.

Chapter 01: March 2015

2015-03-01T00:00:00+00:00

In one drink

It is funny to go hand in hand with time, first feeling so many things, so many emotions concentrated instantly, and second, without meaning the same emotions.

I try not to fall, but it’s impossible: sooner or later, you rush yourself; one way or another, we all must drop. And I will not talk about getting up, not this time. I will talk about understanding reason and understanding ourselves.

Beyond overcoming things, there is the understanding of the reason. What failed? Why did it fail? It is not a matter of finding someone to blame but to find solutions. Even before doing that, one has to search for the actual reason. Do you think there is none?

I do not believe in destiny. I do not believe in anything other than the value of each person.

It is impossible to know everything, and we should not want to. We need to learn how to delegate responsibilities without ever forgetting our own. We must comprehend and understand ourselves. To be realistic and never lose focus.

“Don’t miss out on anything. Enjoy, but don’t drink life in a single sip.” That was one of the most valuable advice my uncles gave me before I parted on this journey.

Understanding and pursuit. It is never useless to talk to yourself to organize your thoughts and stop them from bringing you down.

Everything should be born from passion and sanity. Because all love has a minimum sincerity, and sanity is what allows passion to remain alive.

Everything should be born from sincerity and the desire for passion.

For the music

Cold… a bit, but not enough to stop thinking.

Constantly agitated reforms, but fun. As if it was a game, the most authentic we could play. I raise the volume, breathe, and direct my stare to myself. I don’t see myself. I look for myself, but it’s not me who finds me. I raise the volume.

I can’t recognize myself. How long has it been? When was the last time we played blithely on the streets? I can’t remember anymore…

For the music that accompanied me on the rainy days, the sunny ones, the ones filled with tears, and the ones with joy. The soundtrack of the life, of our lives. When was the last time we thanked it for its company?

That company that listens to us and tucks us in, even on the coldest nights. Naked or dressed, In bed or on a walk. Listen, and you will not be able to escape its charm. We must learn to smile and live in love, but we must listen above all.

It is the one who writes. Profound, rebellious, furious, relaxed. In constant evolution, with an eagerness to overcome herself. We can find it organized, chaotic, with a smile, with its arms open, and to hold us and not let us go.

Learn to listen, learn from it, and with it.

The art of learning

Daydreaming. Remembering. Thinking about everything that has changed, what will change, what arouses each day, in each proposal we make ourselves, in each breath.

Get sick, and sick with life. Thinking in the dark. Imagining a dreamy future. A future that, even in our childhood, we feared being too good, an impossible end.

Just talk. Try it as well as you can; no one is born knowing how to talk. Learn how to talk. Conquer yourself. Get up each day as if it was the last. Some days pass, and when they do, we don’t realize they happened. Don’t allow that. Fall in love with your life and future as you learn to distinguish your reality and see and understand your surroundings and ecosystem.

Listen to the sun. It’s a reason for joy. Move, give yourself a few minutes a day. Play with your life. Enjoy your growth more and more. Challenge yourself like never before and show yourself how wrong you were not long ago. Compare yourself, always with yourself first. Say yes to everything you can and will, but do not forget to say no.

Cheer yourself up! Cheer yourself in a way you never have! Grow, dream, live, be. You’re all art, and your lifestyle depends only on you. It’s your attitude that will determine your quality of life.

Write if necessary; if not, listen to your thoughts. We must organize them frequently, or they will rust. Enjoy it. Enjoy yourself. You are everything and the most significant thing you have. Care for it in a way you would never have imagined years ago.

You are all art. Form yourself, be patient, and you’ll be talking when you least expect it.

Cheer yourself up in a way you never have! Dare to smile while learning.

We are a reflection

What do we do each day? Where is the echo of our actions? These are a few of the most exciting questions we can ask ourselves, which almost made me lose my mind back in the day.

We are a reflection of ourselves. We couldn’t be anything else. Each day is a new opportunity to do everything we still haven’t done and to repeat everything with which we feel complete: our thoughts, crazes, goals, our journey.

We must transmit to the world everything we want to feel from life. We are our hope and chance. What we do will have an echo, not in eternity, but in our tomorrow. It will respond when we get up each day and look at the world in the eye with a hopeful glance. It will be our reflection, as we are the world.

Each instant is vital to understand the real sense and ourselves.

Smiling without reason is pointless, but don’t we have many reasons? Let’s take care of our reasons. It’s our most significant task: to smile with reason. Let’s rise higher than ever. Let’s learn to fly, to dream, not to settle.

Let’s give ourselves a reflection, a glance, a breath, a “cheer”!

Let’s reflect on who we want to be. Let’s be unique and essential to ourselves, different, original, and unpredictable.

Let’s be bright and never stop shining. Let’s fall in love with our image as we are its reflection.

Prologue

2015-02-01T00:00:00+00:00

By the Author

This book is a compilation of brief and personal reflections that I started compiling at the beginning of my new life in a different country, Germany, without any knowledge of German and with a poor level of English. Fortunately, things have changed a lot since then.

This book was born by itself. It is not a diary nor a manual. It is a compilation where we will experience the mind of someone who would not settle but fight to improve himself.

The order of the reflections is by the written date; therefore, we can see their evolution, as of their prose and the different expressions. Addressing different and broad subjects is a book with unique ideas that others who don’t know the author (who writes through these sentences) have no reason to identify.

All this journey has not been made for the reader to like it but for the author. Therefore, I feel invited to get to know myself better.

By Jesús Valera Reales

The book you have in your hands is the work of more than two years of one of the most skilled persons that I have ever met: my brother, José María. The real reason to write this prologue is to put the reader in a situation where, while reading the book, they can understand the context of specific chapters.

In the year 2004, at the age of 37, our mother passed away. She had a stroke and left my father responsible for raising eight children by himself – the oldest was 13, José María was 11, and the youngest was just 19 days old. We all had to change schools and redo our lives.

Three years later, he married another woman, who made our lives a living hell. After many discussions with our older sister, who had taken up the responsibility of being “the woman of the house,” she sent her to finish her university-level studies in another city, which she perfectly could have done in ours. By order of age, her next “target” was José María.

Our father was overwhelmed by what was happening. The encounters between him and us got bigger and bigger until we relegated – all seven of us – to the garage in the duplex where we “lived,” as the backyard of a castle. Additionally, we were utterly forbidden to go upstairs where the main rooms were (kitchen, living room, bathrooms, and bedrooms) unless it was time to eat or go to sleep, with all the “human necessities” that implies.

The disagreements with her continued as time passed until my father was forced to decide that we all would return to the flat where we grew up with our mother, our home.

The repercussions were so severe on José María that he tried to end his life unsuccessfully at a mountain not too long after returning home. That was an inflection point at which he moved on to be our older brother even more. We couldn’t learn much from our mother, but as siblings, we always used to stick with each other, and with him leading by example, to support one another and overcome difficulties together, I owe him a lot.

By Francisco Javier

At the beginning of 2016, I heard of the idea of publishing this book, and when I felt that I “have to” make my contribution so this idea could become a reality. Throughout this time, I have tried to contribute everything I can by offering suggestions and corrections at every possible level.

There have been many hours of searching, reflecting, and talking (with laughter now and then), trying to help the author to express his ideas in a better way. And all of this under the selflessness behind these 16 years of friendship.

I want to add to the previous prologue a question that José María asked me one morning at the high school, a few days after they returned to the place where the eight siblings had grown up, “Do you know how it feels like to wake up on a weekend morning, to see it’s raining and to just stay in bed?” It was shocking because, usually, he had to go out anyway.

Chapters

2015-01-02T00:00:00+00:00

Prologue
- From the Author
- By Jesús Valera Reales
- By Francisco Javier

2015

Chapter 1: March
- In one drink
- For music
- The art of learning
- We are a reflection
Chapter 2: April
- The art of writing
- From a dream
- Doubts
- At the forefront
- To the unexpected and necessary
Chapter 3: May
- At time
- Of concern
- Each different path
- On the death
Chapter 4: June
- Older brother
- The 22’s end
- Solitaire
- There are
- To create
Chapter 5: July
- Actions and words
- To listen unnoticed
- What is clear
Chapter 6: August
- Everything is stages
- Whose world is it?
- Your sense
- To the intention, I say
Chapter 7: September
- God exists: it’s me, and you too
- I needed to dream
- The art of thinking
- Be right
Chapter 8: October
- Above good and evil
- What are we?
- Memories of a forgotten memory
- I believe I think too much
Chapter 9: November
- To the motive
- My project, our project
- To the needed mediocrity
- Your last day
- Leaving a mark
Chapter 10: December
- The art of adapting
- We will die
- Sudden emotions
- It’s not life
- The problem with Christmas

2016

Chapter 11: January
- Ambition in a dream
- I resign to God
- My purposes
- Sometimes
- Eyes on a memory
- Where success starts
- Fed up
- Ironies of life
- What not to die
- Tired
- My skin bristles
- Necessary insecurity
- Not enough
- I am not
- On another level
- Precisely
- It says a lot about you
- Whimsical fate
Chapter 12: February
- Travel to our encounter
- Unforgivable youth
- Religion
- Definitely
- Turns and rounds
- So easy
Chapter 13: March
- It becomes more noticeable
- It is when
- On the mountain
- To taste
- Hatred towards God
- And it won’t be enough
- The complexity of obligation
- We will miss
Chapter 14: April
- To pretend or to be
- So many
- Constants
- Let us talk again
- It is time to
- What could it be?
Chapter 15: May
- At the end
- Having lost
- Are we really?
- History
- Numbers
- Trying to understand ourselves
Chapter 16: June
- What if?
- Who will remember us?
- A matter of time
- Starting the 23
Chapter 17: July
- Understanding
- Eternal return
- Disposition
- While time passes by
- Some
- The hardest
Chapter 18: August
- Being myself again
- With different eyes
Chapter 19: September
- You only live once
- Young and innocent
- Finishing to start
- Tomorrow
Chapter 20: October
- Entropy
- The future
Chapter 21: November
- Sweet Memories
- Even when
- Our biggest mistake
Chapter 22: December
- Slave of death
- Singularities
- Education

2017

Chapter 23: January
- False freedom
- Living busy
- The importance
Chapter 24: February
- Our life
- Habits
Chapter 25: March
- The truth
- Endless
Chapter 26: April
Chapter 26: April
- The value
Chapter 27: May
- Masked mediocrity
- Trend
Chapter 28: June
- Perceptions
Chapter 29: July
- I am not talking about self-help

2025

Chapter 30: December
- Nine Branches

About this book

2015-01-01T00:00:00+00:00