Chemaclass - productivity

Cut the Token Bill on Both Ends

2026-06-26T00:00:00+00:00

Every agentic session burns tokens in two directions at once. The agent talks back to you, and the terminal pipes its output in. Both flow through the same context window, and both of them leak.

Run a session long enough and you hit the wall. The answers get worse and the bill climbs.

Same model. Same prompts. Lighter bill.

Open any session transcript and the biggest blocks aren’t your prompts:

Agent responses: small talk, hedging, repetition, “Sure! Happy to help…”.
Tool output: npm install logs, git status walls of text, grep dumps with full file paths.

The two tools below each go after one of those. Caveman handles what the agent says back. RTK handles what the shell sends in.

Caveman trims the output #

Caveman is an Agent Skill. Run /caveman full once and the agent stops padding its replies: no articles, no filler, no small talk. Fragments are fine, and the technical terms stay exact.

Install:

curl -fsSL https://raw.githubusercontent.com/JuliusBrussee/caveman/main/install.sh | bash

What dies:

Articles: a, an, the.
Fillers: just, really, basically, actually, simply.
Small talk: sure, of course, happy to.
Hedging: might, perhaps, it depends.

What stays:

Code blocks, exact errors, file paths, commands.
Security warnings and destructive ops (skill auto-clarifies).

Normal mode:

Sure! I’d be happy to help you with that. The issue you’re experiencing is likely caused by an off-by-one error in your token expiry check. The middleware compares the current time using < when it should really be using <=. Here’s the fix:

Caveman mode:

Bug in auth middleware. Token expiry check use < not <=. Fix:

Same fix, and the code block that follows is identical. All that shrank is the prose around it, down to about a quarter.

There are three levels: lite, full, and ultra. Start at full, since ultra reads like a telegram. If an answer ever lands too terse for you, type normal mode and it backs off.

The agent doesn’t lose intelligence when you take away its small talk.

RTK trims the input #

RTK (Rust Token Killer) wraps the commands your agent runs. A hook rewrites git status into rtk git status behind the scenes, so there’s nothing extra to type and no overhead to notice.

Install:

brew install rtk
rtk init -g # install the hook that auto-rewrites commands

If rtk gain later errors, a different tool with the same name slipped in; install from the repo instead.

The wrapped version strips the noise before it ever reaches the agent: color codes, repeated separators, npm install banners, verbose timestamps.

Here’s the same git status, raw and then wrapped:

$ rtk proxy git status
On branch main
Your branch is up to date with 'origin/main'.

Untracked files:
 (use "git add <file>..." to include in what will be committed)
 content/blog/new-draft.md

nothing added to commit but untracked files present (use "git add" to track)

$ rtk git status
* main...origin/main
? Untracked: 1 file
 content/blog/new-draft.md

Same information in half the lines. On a busy repo the gap only grows, as dozens of untracked files, branch hints, and instruction lines all collapse into one small block.

rtk gain # see how many tokens it saved you
rtk gain --history # per-command breakdown
rtk discover # scan your agent history for missed wins

RTK reports 60-90% fewer tokens on common dev commands. Run rtk gain after some real use to see your own number.

It never touches the payload, only the noise around it, so errors and stack traces come through exactly as they are. If a filter ever eats something you actually need, bypass it for that one call with rtk proxy <cmd>.

Output you never read is still output the model has to read.

Why the combo compounds #

On their own, each tool helps a little. Run them together and the effect compounds, because they hit different halves of the same loop. A turn goes like this: you prompt, the agent thinks, it runs a command, the terminal answers, the agent reads that, then it replies to you. RTK shrinks the terminal half and Caveman shrinks the reply, so every turn gets cheaper and you fit more of them in one window.

Here’s the real check, on a $100/month plan. Before I added these, I hit the weekly usage cap all the time, sometimes from a single project. Now I run several projects in parallel and the cap rarely shows up. The plan didn’t get bigger; the sessions got smaller.

Set it once, then forget it #

Both installs are global, and you do them once. After that you keep typing git status, grep, and npm install exactly as before. The hook rewrites them for you and Caveman kicks in on its own, so there are no new habits to learn.

Not sure where to start? Pick whichever leak hurts more right now. If long replies on every little fix are the problem, start with Caveman. If it’s floods of grep and npm install output, start with RTK. Add the other one whenever you feel like it, since they don’t get in each other’s way.

You didn’t upgrade the model. You stopped wasting its attention.

Skills Over Agents

2026-05-19T00:00:00+00:00

People compare coding agents. Claude Code, Codex, Gemini CLI. Which one is smarter, faster, cheaper. New benchmarks every month.

Wrong question.

After a year wiring agents into real projects, what moved the needle wasn’t the agent. It was the skills I wrote for it.

Agents are commodities #

Every coding agent has the same shape. A language model, a runtime, filesystem access. Read, reason, write. Generalist by design.

Two teams use the same agent. One ships clean, tested code. The other ships garbage that looks good. Same model. Different teaching.

The model is the engine. Skills are the map. Without a map, a powerful engine gets you lost sooner.

Intelligence is not expertise #

Who handles your taxes? A 300 IQ genius who never read tax law, or an accountant with 20 years of filings?

An accountant knows which deductions apply, which filings your business needs, which mistakes get flagged. Not intelligence. Expertise.

AI agents have the same gap. A model reasons about code and writes solutions. It doesn’t know your hexagonal layers. It doesn’t know domain entities must never import framework code. It doesn’t know every feature starts with a failing test.

Skills close that gap.

Skills load context on demand #

A skill is a markdown file in .claude/skills/. A procedure, a pattern, a slice of domain knowledge. Plain markdown with frontmatter.

The key is how they load. The agent reads only names and descriptions at startup. Loads the full skill when the task matches. Follows links to references only when it needs to dig deeper.

That on-demand loading is what makes skills scale. Twenty skills cost almost nothing until one fits the task. Specialized agents, by contrast, carry their full instructions every time they run. More agents, more fixed cost.

.claude/skills/
 code-review/
 SKILL.md # main instructions
 reference/
 solid-checklist.md # detailed SOLID examples
 test-patterns.md # test quality guidelines

The SKILL.md:

---
description: "Review code changes for SOLID violations, test quality, and architecture alignment"
allowed-tools: Read, Grep, Glob
argument-hint: "[file or PR]"
---

# Code Review

Review code changes against project conventions.

## Steps

1. Read the diff or specified files
2. Check architecture: domain layer has no framework imports, infrastructure stays thin
3. Check SOLID principles (see reference/solid-checklist.md for patterns)
4. Check test quality: tests verify behavior, not implementation details
5. Flag issues with the specific principle violated and a suggested fix

## Output

For each issue found:
- File and line
- What's wrong (which principle or convention)
- What the fix looks like

Agent sees the description in the skill list. Ask for a review, it loads SKILL.md. Needs a SOLID pattern, reads the reference. Two levels, on demand.

Skills vs specialized agents #

I covered specialized agents already: isolated workers with their own prompt and tool set. Great for parallel work and clean context boundaries.

Specialized agents are coarse. One agent, one role, one fixed prompt. If you want three kinds of review quality, you either write three agents or stuff one agent with everything.

Skills are finer. One agent, many skills. The right skill loads for the task. Context stays small. Quality stays high.

Rule of thumb:

Use a skill when you need a procedure or pattern. From phel-lang: /gh-issue (issue to PR), /commit (conventional commit), /refactor-check (SOLID review).
Use an agent when you need isolation. From phel-lang: tdd-coach (TDD pairing), clean-code-reviewer (PR review), domain-architect (architecture exploration).

Most needs are skills, not agents.

Agents give you speed. Skills give you quality. If you must pick one first, pick skills.

Skills are your edge #

Models improve every month. This year’s best is next year’s baseline. The major families converge. Better tool shows up, you switch.

Your skills don’t switch with the tool. They encode your domain, conventions, architecture. They live in your repo. They travel with your code. Point a new model at the library, productive day one.

The agent is replaceable. Your skills are not.

Start with the first repeated prompt #

You don’t need 20 skills on day one.

Zero. Then one.

The signal is repetition. The second time you type the same context, that’s a skill waiting. Extract it into a markdown file. Next session, the agent knows.

Concrete example. On phel-lang, I kept pasting the same brief every session: read issue #N, branch from the labels, TDD, open the PR. Third repeat, I extracted it into a /gh-issue skill. Now I type /gh-issue 142 and the agent picks up the issue, creates fix/... or feat/... from the labels, writes the failing test first, implements, opens the PR. One markdown file. The session no longer starts from zero.

Don’t write from scratch. Ask the agent: “Read this project and draft a minimal code review skill based on what you see.” It scans, picks up conventions, drafts v1. Then you adjust. Add what it missed. Cut what doesn’t apply. Sharpen the description.

The second skill usually comes from a mistake. Agent breaks a convention. Write a skill that teaches the correct approach. It won’t happen again.

Skills add up. Each one lifts the baseline. A markdown file, maybe 50 lines. Permanent payoff.

People who don’t write skills keep re-explaining what they “really want.” Every session from zero. Not a tool problem. A knowledge management problem.

The agent ships next year. The skill ships forever.

Write the skill once. Every session after that starts where the last one ended.

The Levels of AI Adoption

2026-05-01T00:00:00+00:00

Most companies use AI today, but few know where they stand on the AI adoption ladder. At one end, you paste code into ChatGPT. At the other, agents open PRs while you sleep. Beyond that, AI reaches people who never touched a terminal. This post maps the path.

Where we started #

Using AI to code meant a second tab. Write a function, get stuck, paste the error into chat, paste the answer back, and hope it works. It was slow, messy, and disconnected from your code.

GitHub Copilot, built on OpenAI’s early Codex, added suggestions inside the editor, often confidently wrong. It was trained on public code, and most public code isn’t great. It also knew nothing about your domain, your conventions, your architecture. It was autocomplete that sometimes guessed right.

The first generation of AI coding tools gave you a parrot trained on the whole internet. Fluent, confident, and often saying things that made no sense in your codebase.

This was vibe-coding in its first form: you gave the vibe by pasting context, and the AI filled in code that looked right. It compiled often enough to feel useful, and broke often enough to feel dangerous.

The IDE generation #

The next step was obvious: if the AI needs context, give it the whole editor.

Cursor, Windsurf, and similar IDEs moved the model inside your coding flow. The assistant could read files, follow imports, and see more than one function at a time. Vibe-coding became a conversation with your project, and productivity jumped. For a moment, it felt like the endgame.

It wasn’t. Editing files is only part of the job. The rest is running tests, reading logs, opening branches, reviewing diffs, and understanding what the codebase already does. Editor-only assistants helped you type faster, but they couldn’t take a task from “fix this bug” to “PR ready for review.”

The agentic shift #

OpenAI launched Codex as a cloud agent: give it a task, it works on a branch, and you come back to a PR. Anthropic shipped Claude Code, a CLI agent in your terminal, on your repo, with your tools.

This was the big shift, and not because the models were smarter. The unit of work changed. You stopped prompting line by line and started delegating tasks: read the ticket, write the change, run the tests, explain what you did. An agent doesn’t need hand-holding. It needs a goal and the right context.

The jump from assistant to agent is not a speed improvement. It’s a change of job description. You move from typing code to directing work.

Claude Code needs almost no setup. No editor lock-in. Point it at your repo, drop a .claude folder with rules and conventions, and it adapts. I covered that in Inside the .claude Folder.

The model you pick matters more than before. Today’s frontier models are way ahead of where they were a year ago. The gap between “can draft a function” and “can refactor a module with judgment” closed faster than expected, and it keeps closing as Claude, Codex, and Gemini push each other forward every month. Prices are getting closer too, which is a polite way of saying everyone copies whoever figures out the sustainable version first.

Agents with their own home #

The next leap wasn’t smarter models, it was agents with their own machine.

OpenClaw is the clearest example. It’s an open-source gateway you run on your own hardware (Mac Mini, old laptop, VPS), an always-on agent connected to your messaging apps, files, and calendar. You bring your own brain: Opus, GPT, or a local model via Ollama. When a provider tightens limits or raises prices, you switch. You own the setup.

A coding agent lives inside one repo for a task. An OpenClaw-style agent lives in your life, across days and tools. Sauron is mine. It reviews my PRs, opens issues, drafts code, ships open source contributions, and pushes back when I’m about to tunnel on something. Anything I can do on a computer, it can do too, just faster. It stops being a tool you open and becomes a place you work in.

A coding agent is a coworker you invite to a task. A gateway agent is a coworker who lives on a machine and shows up every day.

Providers change their plans and limits faster than anyone tracks, so people build setups that aren’t tied to one vendor. The logo on the model matters less every quarter, and the architecture around it matters more.

AI beyond developers #

AI coding was the loudest story because developers are loud. The bigger story is agentic tools reaching people who never wrote a line of code.

ChatGPT agent mode and Claude’s Cowork are the obvious examples: an AI that reads your documents, fills your spreadsheets, drafts your slides, and runs code for you in the background. Claude Design launched on April 17 and dropped Figma’s stock over 7% on launch day. The pitch is simple: describe what you want, get a working prototype, hand it to Claude Code to ship. A workflow that used to need a designer, a PM, a frontend engineer, and three review rounds is squeezed into one conversation.

Lovable, v0, Canva, and Figma itself are all under pressure to rethink their positioning. Whether Claude Design “kills” any of them is the wrong question. The right one is what happens when making a usable prototype drops from “hire a designer” to “describe it out loud.”

The companies feeling this first aren’t the design tools. They’re the small businesses that couldn’t afford design work, the founders building a pitch deck at midnight, the PMs testing an idea before booking a meeting. There’s a minority of cases where someone would have paid a designer and now won’t, and that cost is real. But in most of them, AI didn’t replace anyone: it filled a space where no designer was ever going to exist.

The levels of AI adoption #

Every company I talk to sits somewhere on this ladder. The levels aren’t about how much you pay in licenses, but about how deeply AI is built into the way work gets done, and not just in engineering.

Level 0: Denial #

A company-level stance. No AI, officially. Some people use ChatGPT on personal laptops and don’t mention it. Leadership worries about IP leaks, or hasn’t made it a priority. The conversation stays at “we should look into this someday.”

The risk here isn’t technology, it’s time. Every month at Level 0 is a month your competitors grow their lead.

Level 1: Personal productivity #

Individual adoption. AI is allowed, maybe encouraged. Each person uses it their own way: ChatGPT in a tab, Copilot in the IDE, Claude for the tricky stuff, a design tool for mockups. Output goes up, but the know-how stays inside each person’s head. Two engineers, or two PMs, or two designers on the same team get very different results because they prompt differently.

Most companies are here in early 2026. It’s a real improvement over Level 0, and it’s where the myth of “AI gives you speed” gets born. As I argued before, speed without shared direction is faster chaos.

Level 2: Shared practices #

The team agrees on how to use AI: shared conventions, prompts people reuse, rules in the repo, a shared sense of when to trust the output and when to push back. Code reviews catch AI mistakes the same way they catch human ones, and design reviews do too. Tests are required whether a person or a model wrote the code.

This is the first level where AI becomes a team skill rather than a personal habit. Higher ceiling, higher floor. New people ramp up faster because the prompts and rules capture how the team works.

Level 3: Context-aware tooling #

The team invests in context: rules files, conventions, architecture docs agents can read, and MCP servers connecting agents to the databases, APIs, and internal tools they need. The AI stops being a generic assistant and becomes closer to a coworker who has read the onboarding docs.

At this level, quality depends less on the model and more on the context around it. A weaker model with great context beats a frontier model with none. Good docs and clean architecture pay off twice: they help both humans and agents.

Level 4: Agentic teams #

Instead of one assistant, you get a squad: a TDD coach, a clean code reviewer, a domain architect, a docs maintainer. Outside engineering, the same idea applies with research, design, and ops agents. I covered the developer side in Build Your Own Team of Agents, and the leverage is real.

Humans stop competing with AI on speed and start directing it. You review, decide, and set the bar. Agents handle typing, and increasingly the thinking. Pair programming with a person still wins on complex trade-offs, but an agent pair is always there for the rest.

At the company level, the org chart, roles, and processes are still the same. What changes is that each person produces a lot more, and the team’s output reflects it. Level 4 multiplies output inside the existing structure. Level 5 changes the structure.

Level 5: AI-native workflows #

The final shift is about how the company runs. Processes are designed around agents instead of just fitting them in. Tickets are written so an agent can act on them, and reviews assume part of the work was written by a machine. Architecture decisions take into account what agents do and don’t do well. Even hiring changes: a senior IC at Level 5 is closer to a tech lead leading people and agents than a classic individual contributor.

Few companies are fully here in 2026, but the direction is obvious enough that ignoring it is its own decision.

You don’t move up a level by buying better tools. You move up by changing how work is organized and reviewed.

AI is not stealing jobs #

I keep hearing people call this a layoff story, and that framing is lazy.

The industrial revolution didn’t end work. It ended specific kinds of work and created others. The people who lost the most refused to re-skill, and the people who gained the most learned to operate the new machines instead of competing with them.

Same pattern here. AI isn’t taking your job, it’s changing what your job is. A developer who learns to lead agents out-ships one who refuses. A designer making ten versions before lunch with Claude Design out-designs one still opening Figma from scratch. A PM who ships prototypes out-prioritizes one writing specs nobody reads.

AI doesn’t replace the skilled worker. It replaces the worker who thinks skill is a fixed asset instead of a moving target.

With the right training, model, and setup for your context, AI gives you 10x speed without losing quality. I’ve seen it, and it’s not marketing. But the 10x only shows up when you already know what good looks like. Without that foundation, AI happily produces 10x more mediocre work.

That’s the honest version of the promise: AI can produce crap ten times faster, and excellent work ten times faster. Which one you get is on you.

The shift in where your attention goes #

You stop thinking about details first and start thinking about direction: what are we building, who for, what shape, and which trade-offs. Agents then do most of the implementation while you protect quality and coherence.

This sounds like good news for anyone who prefers architecture to typing, and it is. But there’s a trap: you can only work at the high level if you know the low level well enough to catch drift. When the agent produces something subtly wrong (a test that passes for the wrong reason, a refactor that changes behavior under load, a design that breaks on mobile), you need to spot it instantly. If you can’t, you’re not directing, you’re signing off on whatever shows up.

AI lets you spend more time on direction, but only if you’ve already earned the right to ignore the details. You earn that by having mastered them first.

Why the ladder matters #

I see teams skip levels and fail. A team jumps from Level 1 to Level 4 because leadership read a blog post about agent squads, and the agents produce mountains of low-quality code because nobody agreed on what quality means. The agents aren’t the problem, the missing foundation is.

The ladder is an order that matters. Shared practices come before context engineering, context engineering before agent teams, and agent teams before AI-native workflows. Each level builds on the previous one, the same way clean code builds on naming, and naming builds on knowing what you’re modelling.

The companies that win the next few years aren’t the ones with the biggest AI budget. They’re the ones that climb this ladder deliberately, one level at a time, without skipping the parts that look boring.

Where to start #

At Level 0 or 1, the next move isn’t more licenses. It’s deciding, as a team, how to use these tools. Write it down, commit it to the repo, and review it every week or month as the tools evolve.

At Level 2 or 3, look at where context is missing. What does your AI not know about your codebase, product, or brand that a new hire would learn in week one? Write it down. An afternoon of rules and docs pays back for months.

Further along, the question flips. You stop asking “how do I use AI better?” and start asking “how does my team need to change so AI amplifies what we already do well?” That’s a leadership question, not a tooling one.

AI is moving fast, but the work of adoption is still slow and human. The tools are the easy part. The hard part is deciding what good looks like, writing it down, and holding the line.

AI can execute, but it doesn’t know where you’re going. It can produce, but it doesn’t know what’s worth producing. That part is still on us. Speed is a gift, and direction is a responsibility. From the solo engineer at Level 1 to the AI-native org at Level 5, the same truth holds: the human supervises, understands, and gives meaning. The machine does the rest.

When the hype settles (and it will), the question won’t be “did you use AI?” Everyone will. The question will be “at what level, and with what direction?”

Inside the .claude Folder

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.

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.

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

Treat every change, even the small ones, as something worth sharing. I always create a branch and open a PR. It provides visibility, builds a shared history, and creates a space for optional or asynchronous feedback. It’s working with the garage door open, applied to code.

But not all PRs need to follow the same review process.

I default to Ask #

I prefer to wait for a peer review when:

The change involves risky or complex logic
It could impact other developers or teams
It introduces architectural or structural decisions that haven’t been agreed on yet
It benefits from shared input or a second pair of eyes

That said, Ask doesn’t mean over-engineering the process. Often, one thoughtful reviewer is enough, especially if they’re familiar with the domain. If the change touches a specific area, I’ll ask for feedback from the person who owns (or best understands) that part of the code. It doesn’t need to involve everyone.

In small teams, requiring two approvals on every PR can quickly become a bottleneck and slow down the delivery of value. The goal is alignment and quality, not ceremony for its own sake.

I use Show for safe, low-impact changes #

I might merge immediately when:

Practicing pair programming (the review already happened live)
Fixing typos or broken links
Updating documentation or changelogs
Refactoring within a module I own
Adding tests for existing behavior
Making non-functional tweaks (formatting, logs, comments)
Applying UI or style adjustments with no logic change

The key principle: Show is optional, never mandatory. I choose Show only if the change is low-risk and fits within team expectations. When I use Show, I own the outcome. The responsibility is mine.

Why this approach works for me #

This model helps me:

Ship faster without compromising quality
Work with greater autonomy and ownership
Avoid bottlenecks, especially in small or async teams
Foster a mindset of trust, accountability, and thoughtful decision-making

It shifts the goal from getting approval to sharing intent and owning the outcome.

What makes a good “Show”? #

A Show PR might be the right choice when:

The change is trivial and within my area of responsibility
No one is available to review, and waiting would block progress
The PR includes clear context and reasoning
I’m open to post-merge feedback
I’m ready to follow up with adjustments if needed

Tips for making it work #

Some practical advice from experience:

Clarify team expectations for when to use Show vs Ask
Always provide context in your PR, even if merging immediately
Write tests for any new logic or behavior
Welcome post-merge feedback, review doesn’t stop at merge
Reflect regularly as a team and adjust the approach as needed

Ship, Show, Ask is more than branching hygiene. It builds a culture of clarity, accountability, and trust, where developers move fast while staying thoughtful.

If you’re tired of slow PR queues and over-engineered approvals, try it on your next change. Want to dive deeper? Read Rouan Wilsenach’s original post.

Match the review to the risk. Own what you merge.

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 #

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 #

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 #

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 #

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.

Learned Helplessness

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

Learned helplessness is the behavior exhibited by a subject after enduring repeated aversive stimuli beyond their control.

It was initially thought to be caused by the subject’s acceptance of their powerlessness by discontinuing attempts to escape or avoid the aversive stimulus.

Experiments #

A classroom with different assessments #

Charisse Nixon, Ph.D Developmental Psychologist at Penn State Erie, The Behrend College and Director of Research and Evaluation for The Ophelia Project discusses the phenomenon of learned helplessness.

Original: Docking shocks and harnesses #

In 1967, the American psychologist Martin Seligman at the University of Pennsylvania researched docking shocks and harnesses.

In Part 1 of this study, three groups of dogs were placed in harnesses. Group 1 dogs were put in a harness for some time and released later. Groups 2 and 3 consisted of “yoked pairs.” Dogs in Group 2 were given electric shocks randomly, which the dog could end by pressing a lever. Each dog in Group 3 was paired with a Group 2 dog; whenever a Group 2 dog got a shock, its paired dog in Group 3 got a shock of the same intensity and duration, but its lever did not stop the shock. To a dog in Group 3, it seemed that the shock ended randomly because their paired dog in Group 2 was causing it to stop. Thus, for Group 3 dogs, the shock was “inescapable.”

In Part 2 of the experiment, the same three groups of dogs were tested in a shuttle-box apparatus (a chamber containing two rectangular compartments divided by a barrier a few inches high). The dogs could escape shocks on one side of the box by jumping over a low partition to the other. The dogs in Groups 1 and 2 quickly learned this task and escaped the shock. Most of the Group 3 dogs, which had previously “learned” that nothing they did affected the shocks, lay down passively and whined when shocked.

Even though this experiment was demonstrated with different types of animals, it also applies to people. This is visible in children when they integrate early failure to ask for help, frustration, giving up, poor motivation, and procrastination. And these points carry on as people age.

Because, if you “cannot do anything”, why would you even try it?

All this leads to anxiety and depression, and people think nothing can be done about their current situations and feelings.

Learned optimism #

The antidote to learned helplessness is learned optimism. These people are higher achievers, have better overall health, and have lower levels of depression.

How do you practice it? #

Permanence: bad events or failures are not permanent. So, you can recover faster than people stuck in these situations. However, good things or events happen for a good reason that you’ve worked on.
Pervasiveness: do not generalize failure. Failing in one area in your life should not affect other areas.
Personalization: bad events are external to blame, outside yourself, as you did all you could have done.

Isolate the problem and don’t extrapolate it to other areas. Stop generalizing failure.

English #

Español #

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 #

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

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

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 to 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 needs special attention or help.
Refinement: 2h? meeting to make sure the tickets are in a good shape before planning them to be worked on in the next sprint.
Planning: 2h? meeting to plan the work to be done in the next sprint.
Demo/Review: 2h? meeting to show the work done for the whole team, stakeholders and other interested people.
Retrospective: 2h? meeting intended to enable the team to reflect and improve.

The critical question is how your team organizes these meetings and, most important of all, how effective these are. These above are just some of the important meetings you have in any “Scrum Team” nowadays.

Still, apart from those, you might encounter a lot of additional meetings that pile up, and suddenly your entire working day is gone, and you feel you didn’t produce the value you expected. Unless your job is being in meetings every time, like coordinating projects and talking to people all the time, it seems something is wrong.

Boring meetings #

Have you ever been in any of those meetings and thought, “This is boring, what a waste of time…”. Well, I’ve experienced that more than once. Who’s to blame? That would be the very first question that could come to your mind. Followed by, “My boss, obviously, because he/she organized that meeting, to which I got invited, therefore I am forced to attend, and this wasting time is their fault.”

This is a tricky question, and I don’t think it is an honest answer. However, there is an easy explanation for this answer: pushing away responsibilities and blaming others rather than yourself is way easier.

“I am forced to attend, and this wasting time is their fault” it could be that that’s actually the actual fact. You were really forced, and you’re wasting your time, and there is no other way… but is there no way to act on it, really?

When something doesn’t work the way I expect (e.g., I don’t like the outcome, or I think something is off), before blaming and pushing away responsibilities to others, I want to reflect on it and identify the root of the issue. What could I do to make the situation better?

What can you do about it? #

Coming back to this context of “many meetings”, if you see yourself in a meeting again that feels off or boring, try asking yourself:

Am I feeling bored? Why so? Is it possible that I am not participating in the desired outcome of the meeting? And if so, is my presence here in this meeting really necessary? Could I simply ask for a summary afterward and jump outside the meeting to do something more productive?

Contrarily, is it OK to feel bored in this meeting? Or should I participate and engage with my peers to contribute to the outcome of the meeting?

In these situations, I encounter a pattern such as:

If the meeting is not boring, it is productive and will produce a rich outcome for you and, hopefully, all participants.
If the meeting is boring, then either A) it is OK to be boring, politely ask to leave, and you will get the summary afterward, or B) it is not OK to be boring. Your participation is necessary for the outcome of the meeting. Try being more engaging with your peers, and the meeting won’t be boring.

In the end, there are a lot of strategies, and it’s up to you to act on them whenever you see something that could be improved.

It’s OK to point out the “elephant in the room” and ask for help to improve any situation you think (or feel) is not working as it should.

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 #

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 #

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 to complete a task without a lot of need for deciding what or how. Red Work is being in control and taking control. Such as:

Process work and avoid errors.
Having predictability and controllability.

We need a mechanism to stop Red Work and ask: are we doing the right thing?

What is “Blue Work”? #

Blue Work is about deciding, thinking, planning. Blue Work focuses on improving with an embarrassing mindset.

The correct place to do Blue Work is at the beginning and at the end of a decision point.

Blue Work is crucial for a good starting point, allowing us to decide the best way to do something with the information that we have right now.

It’s also important to establish short iterations between the different actions or activities that we want to complete, so we can have some “Blue Work time” and reflect again. Blue Work is perfect to do retrospectives and see what could be improved.

It’s the time to stop and “control the clock”, collaborate and make a commitment for the next iteration. Blue Work is also about:

Thinking work.
Decision-making.
Looking to achieve excellence.
Getting more people to do independent thinking answers.
Embracing variability and looking for different inputs.

Blue Work in isolation is useless. The job of Blue Work is to make Red Work better. Endless Blue Work, planning without outcome doesn’t bring any real benefits.

Nowadays, especially in our modern software industry, there is no room for the old school of “Red-Workers” and “Blue-Workers”, but “Red Work” and “Blue Work”, and everyone should be involved in both.

It is, therefore, everyone’s responsibility to be aware of these different types of work and find a good balance between them. Leaders involve everyone in both Red Work and Blue Work.

References #

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

Every project you ship stands on open-source software. Your framework, your test runner, your compiler, the small library you never think about.

You use it every day. The real question is whether you ever give back.

Giving back is not charity. It is one of the fastest ways to grow as a developer.

What is OSS? #

Open-source is not the same as free software. Free software is one kind of open-source, but open-source does not have to be free to use. Two examples draw the line. PHPUnit is open-source and free. Spryker is open-source and paid. Both publish their code for anyone to read.

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

Benefits #

Two groups win from open-source: the companies that publish it, and the people who contribute.

For companies #

Open access drives adoption. The easier the code is to get, the faster people build on it. Training and tutorials pull in newcomers and grow the ecosystem. The code tends to sit on the cutting edge, because software that stands still goes obsolete. A public project gathers a community around it, and public channels make that community easy to join.

And because anyone can read the source, anyone can check its quality. That is trust you cannot fake.

For individual contributors #

You pick what you work on. You practice real skills without the pressure of a production outage. You get to play with the newest features of your language, or try a language you have never touched.

You also sharpen the soft skills that carry a career: writing clearly, explaining a change, holding your ground when people disagree.

The code teaches the hard skills. The disagreements teach the rest.

Contributing to OSS #

Getting started with GitHub #

Starting is easy, and you have two doors. Open your own project, or contribute to one that already exists. A pet project fits the first door perfectly.

Pet projects #

A pet project is a playground to build real software and train real skills. Put it on your public GitHub profile and you get every benefit of contributing to OSS, plus one more: you answer to nobody. You set the roadmap. You decide what to build and how. You are your own boss.

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

My pet projects #

Active:

agnostic-ai: write AI agents, skills, rules, and hooks once, use them in every AI CLI.
bashdep: a simple dependency manager for Bash.
phel-snake: the snake game in your terminal, written in Phel.
edifact-parser: a parser for a UN/EDIFACT file format in PHP.
unspent: a PHP library for UTXO-like bookkeeping with unspent entries.

Inactive:

create-pr: a Bash script to open a pull request from your branch and context.

Abandoned:

stock-ticker: get a notification with the news from your favorite Tickers.
jira-status-notifier: Notify when the JIRA tickets don’t move along.
php-best-practices: what I considered best practices for web-dev (archived).
php-scaffolding: a basic PHP scaffolding with Docker (archived).
knob-mvc: a framework to create WordPress templates (2015/2017).

… and many more on github.com/Chemaclass

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

Code is only half of it. The other half is what you write down and hand to the next person.

Blog posts #

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

The beauty of OSS #

Contribute in public long enough and you start to see your own growth. The corrections you keep making. The code you wrote last year, already aged. The mistakes, all of them, in the open. And underneath, the slow proof that you are getting better.

You build a sixth sense for patterns you have hit before, the good ones and the painful ones.

Show your skills. Help the people around you. That is working with the garage door open.

Open-source software offers you one of the best opportunities to start building a career of continuous improvement.

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

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.

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

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 I am nowadays.

Sports #

Exercise helps my mind to disconnect from the tech area. It keeps my body active using some energy in a different environment. But most importantly, it helps to get fully tired before going to bed. I feel myself resting much better if I’ve done some sport during the day: contact sports, fitness studio, or simply running.

The specific sport itself is an irrelevant detail as far as you feel comfortable. The act of doing sport is the key here.

Books #

I try to read tech throughout the day and non-tech during the night. For example, some days before going to work or after working time I might read a tech book. And some days before going to sleep I like to read a non-tech one. This way, I feed my brain with knowledge and I also provide it with non-tech space, so it can rest from code and enjoy other “universes” as well. Some suggestions that helped me to understand how we behave, why we do what we do, and therefore build some habits that I didn’t know how to:

The Power of Habit, by Charles Duhigg.
Atomic Habits, by James Clear.
Scrum: Doing Twice the Work in Half the Time, by Jeff Sutherland.

Personal tricks #

I wish I would have read much more. Nowadays, with the number of distractions that we have, keeping yourself focused is pretty hard. Some tricks that help me a lot when I want to focus:

I keep my personal phone always in silence and vibration mode.
I used to spend hours on social media; a lot of time wasted. Not anymore. I reduced the social media noise to the minimum by removing the apps that prevent me from being as productive as I want. Some of them from my phone, others the account itself.
I used to play video games. Not anymore. Instead, I go to GitHub to work on my pet projects, contribute to an open-source project, or simply read a book.
When I go for a run, I enjoy it twice by listening to a 45-min podcast that I want to listen to since the very morning. The reward of listening to the podcast is linked with the act of going out and running. I conscientiously created that habit.

It’s not about removing your old habits but replacing them with new ones.

How to improve your habits #

Habits emerge without our consent. To save energy, the brain creates a habit loop that looks for a trigger to cue a behavior.

Willpower can be learned. It needs exercise, like a muscle.
Small successes are the building blocks of bigger wins.
Focus less on goals and more on systems and processes.
To change habits, change how you identify yourself.
To build good habits, the environment is more important than being motivated.
To break a bad habit, reduce exposure to the cues that cause it.
Bundle an action you want to do with an action you need to do.
Don’t try to make a habit perfect, just repeat it.
Reduce friction for good habits and increase friction for bad habits.
Like in Scrum, removing waste is fundamental to get better.

Repetition is the key. Make it easier to do what you want to do. Make it harder to do what you want to stop doing. Enjoy the process: that’s the goal.

Interesting links #

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.

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:

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

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

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.

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.