Thoughts on Productivity

PedroHDP84 — Thu, 02 Jul 2026 22:09:50 +0000

If you ask a factory manager what a productive year looks like, the answer is simple: every week should look roughly like the last.

If you ask a scientist, a founder, a software engineer, a novelist, or a master craftsman, you'll probably hear a very different story.

They won't remember their careers as a sequence of ordinary Tuesdays.

They'll remember seasons.

The winter they spent obsessed with a single problem.

The month when everything suddenly clicked.

The summer that looked unproductive until it produced their best work.

The quiet period after shipping a major project, when they could barely think about it anymore.

These stories appear everywhere.

American founders talk about "going into builder mode." Open-source developers disappear for months before releasing a major version. Japanese craftsmen describe the importance of Ma—the meaningful interval between actions. Brazilian software engineers speak less about productivity than about preserving the ability to create without burning out.

The vocabulary changes.

The rhythm does not.

The Factory Taught Us to Expect Straight Lines

Most organizations still measure work as if knowledge work were factory work.

Forty hours this week.

Forty next week.

Steady output.

Predictable progress.

That made perfect sense when the goal was producing identical objects.

But building software isn't like assembling a car.

Writing a book isn't like packaging cereal.

Designing a new product isn't like tightening bolts.

Creative work depends on understanding something that didn't exist before.

That changes everything.

Every Builder Knows the Invisible Phase

One of the strangest aspects of creative work is that the most important progress is often invisible.

An engineer spends two weeks reading unfamiliar code.

A founder interviews customers but writes almost no code.

A researcher fills notebooks with failed experiments.

A writer deletes more pages than they keep.

From the outside, almost nothing seems to happen.

Then, one afternoon, a design emerges.

The architecture suddenly becomes obvious.

The experiment finally works.

The chapter writes itself.

People call it inspiration.

Builders usually call it "finally."

The breakthrough wasn't born that afternoon.

It had been forming quietly for weeks.

Creation Alternates Between Different Modes

Across different disciplines, the same pattern appears again and again.

First comes exploration.

You gather information, ask questions, follow dead ends, and tolerate uncertainty.

Then comes commitment.

The possibilities narrow.

A direction becomes clear.

Execution accelerates.

After that comes refinement.

The rough idea becomes reliable.

The prototype becomes a product.

The draft becomes a book.

Eventually comes recovery.

Not because the work is finished forever, but because the mind that created it has been stretched to its limit.

Each phase prepares the next.

Trying to remain permanently in any one of them eventually becomes counterproductive.

The Internet Already Understands This

Spend enough time reading discussions among experienced builders and you'll notice something surprising.

They rarely organize their lives around days.

They organize them around projects.

Around launches.

Around releases.

Around research questions.

Around funding rounds.

Around books.

Founders describe disappearing for two weeks to build.

Programmers batch meetings into one day to protect several days of uninterrupted work.

Researchers spend years collecting observations before publishing a paper.

Artists oscillate between making and living.

Almost nobody describes their best work as the product of a perfectly balanced weekly calendar.

Different Cultures Describe the Same Pattern

Japan offers perhaps the most beautiful description.

The concept of Ma teaches that the interval is not empty.

The silence between notes is part of the music.

The blank space shapes the painting.

The pause gives meaning to movement.

Creation is not only what happens during action.

It also depends on what happens between actions.

Brazil arrives at a similar conclusion from the opposite direction.

Instead of celebrating creative seasons, the conversation increasingly focuses on burnout.

Developers speak of losing the desire to code.

Workers describe living in "survival mode."

The concern isn't how to become more productive.

It's how to recover the mental space required to create at all.

Different cultures.

Same lesson.

Continuous pressure eventually destroys the conditions that make original work possible.

Builders Don't Need Constant Intensity

One of the biggest misconceptions about ambitious people is that they thrive under constant acceleration.

The opposite is often true.

Builders tolerate intense effort remarkably well.

What they struggle with is unending intensity.

Sprint after sprint.

Meeting after meeting.

Deadline after deadline.

Without periods of exploration, consolidation, or recovery, the quality of ideas begins to decline long before the number of hours does.

The danger isn't simply exhaustion.

It's becoming incapable of seeing something new.

A Career Is Better Measured in Seasons Than Weeks

Looking back, few people define their careers by how productive they were in an average week.

They remember the periods that changed them.

The year they learned a new field.

The months spent building a company.

The season devoted entirely to a difficult problem.

The time they stepped away, only to return with clarity.

The most meaningful work rarely emerges from maintaining maximum output indefinitely.

It emerges from completing healthy cycles.

Learning.

Exploring.

Building.

Refining.

Recovering.

Beginning again.

Perhaps that's why builders across countries, professions, and cultures tell such similar stories.

Not because they've discovered a secret productivity system.

Because they've discovered something older than productivity itself.

Human beings don't create in straight lines.

They create in seasons.

When DRY Dries Out Too Soon

PedroHDP84 — Sun, 01 Jun 2025 19:58:28 +0000

“Don’t Repeat Yourself.” A rule we all learn early. Yet real-world code has a way of proving that repetition, at times, is a clear, safe choice.

Duplication simplifies certain tasks. Fixing a bug in duplicated code may require several edits, but altering shared code can quietly unsettle distant parts of a system. Duplication offers localized safety, while abstraction carries global risks.

Both abstraction and duplication can be reversed, though abstractions typically cling stubbornly once established.

Sometimes identical code blocks appear similar yet carry distinct meanings. They're not twins—they’re strangers wearing the same clothes, speaking entirely different languages.

Imagine an abstraction crafted early, based on preliminary understanding. Months later, when business logic shifts, this abstraction no longer fits. Do you patch it endlessly with flags and parameters, or do you rebuild it entirely, courageously undertaking substantial refactoring?

Refactoring duplicated code has its own hazards, but it generally proves simpler than untangling bad abstractions.

A duplicated code block resembles an overly polite guest who quietly overstays their welcome. In contrast, abstraction behaves like an overly enthusiastic neighbor, linking every aspect of your project into a complex web of dependencies.

Duplication naturally emerges early, when patterns remain unclear. It’s safer than prematurely abstracting uncertain logic. Duplication may also reappear later during busy phases, when caution appropriately tempers aggressive restructuring.

Developers should duplicate intentionally to reduce dependencies and manage uncertainty. Effective abstractions emerge confidently as business logic stabilizes, providing lower maintenance costs when executed properly.

DRY is deeply ingrained: we instinctively raise eyebrows at duplication, problematic or merely redundant. Yet, in code—as in life—duplication isn't a cardinal sin. It's practical. Perhaps we might learn to appreciate its awkward charm while instinctively scolding it outright.

DEV Community: PedroHDP84