DEV Community: Dominik

Reading The Pragmatic Programmer in the age of AI

Dominik — Tue, 07 Jul 2026 13:51:39 +0000

I bought The Pragmatic Programmer a few years ago but never finished it. As part of my current effort to sharpen my fundamentals, I decided to finally read it from cover to cover.

I expected it to feel slightly dated. The first edition was written in 1999. The second edition came out in 2019, just before generative AI reshaped how many of us work. Instead I found the opposite: most of the principles still hold. What changed isn't their validity — it's the level at which they apply.

The first thing that stopped me was one sentence in chapter 2. The authors note, almost in passing, that there are still no compilers capable of generating software from a concise description of requirements. Reading that struck a strange tone in my mind. We still don't have the compiler they were imagining, but we do have LLMs and AI agents that occupy a surprisingly similar role — turning a few paragraphs of natural language into working software. A later chapter reinforces the feeling: the authors argue that programming can't be reduced to a mechanical process, or CASE tools would have replaced programmers long ago. History spent twenty years appearing to prove them right. Then it stopped being so obvious.

That became the question I read the rest of the book with: if implementation is finally being automated, which of these ideas become more important, and which become less?

The Knowledge Portfolio, revisited

Take the Knowledge Portfolio. On the surface, AI seems to reduce the need to learn deeply. Why spend months mastering something an assistant can explain or generate in seconds?

My strongest evidence to the contrary came from a React migration. I'm primarily a backend developer with little frontend experience. With AI's help I produced a UI that matched the mockups and met every functional requirement. To me, the code looked fine. The senior frontend engineers reviewing it disagreed — it ignored several established patterns in the codebase, and I didn't have enough experience to recognize the problems myself.

Later, on smaller and more clearly defined tasks, I noticed something. AI followed project conventions much more reliably when I could extract and state those conventions explicitly. The better I understood the rules of the system, the more useful the AI became. The lesson wasn't that AI replaced expertise. It was that expertise determined whether I could recognize good output when I saw it.

So learning and gaining expertise is still essential. Otherwise how will you notice mistakes in AI thinking? For me, the valuable investment is in mental models — functional programming, distributed systems, architecture, security, AI systems themselves. The goal is no longer accumulating syntax knowledge across many languages but understanding how software behaves.

Orthogonality, DRY, and the cost of unclear thinking

The idea that gained the most weight for me was orthogonality. Clear boundaries between modules and responsibilities have always been good practice; in the AI era they're closer to a prerequisite. AI increasingly writes the implementation while the engineer defines interfaces, constraints, and responsibilities — and the quality of those boundaries determines how effectively AI can contribute. Vague definitions produce tangled, duplicated, hard-to-verify output. Clear ones produce something you can actually review and trust.

This sharpens DRY, too. The principle was always about duplicated knowledge, not duplicated code — but AI scatters business logic across services and modules so reliably when left unsupervised that the distinction becomes impossible to ignore.

There's one idea I initially thought was new, then reconsidered. I'd written in my notes that AI makes poor thinking more expensive — a vague prompt burns tokens, time, and iterations. True, but engineers have always paid for unclear thinking. The currency used to be debugging and rework; now it's tokens and review cycles. The cost isn't new. What's new is how fast and how visibly it arrives. AI acts less like a new source of risk and more like a mirror: it doesn't create bad habits, it reflects them back faster.

The Blackboard pattern, reframed

Master your tools, invest in your environment — still valid. But increasingly the tool is operated by an agent, not typed directly by a developer. Which makes plain text more central, not less: it's the medium through which intent reaches both humans and machines, in prompts, configuration files, and instructions. The skill that used to be "master your tools" is becoming "design workflows that you and an AI can both operate in effectively."

That reframing shows up most clearly in the Blackboard pattern — one of the book's more academic-feeling ideas, where independent specialists post partial solutions to a shared space until a solution emerges. It suddenly resembles modern multi-agent systems, where specialized agents collaborate through a shared space rather than a shared conversation.

The reframe I keep coming back to is that what agents need to share isn't conversational context, which gets expensive fast, but structured knowledge: goals, decisions, findings, tasks.

Shared knowledge rather than shared context.

The more I experiment with agentic systems, the more I believe preserving useful knowledge matters more than preserving every step of the conversation that produced it.

Testing: don't let AI do the thinking part

One place that caught my interest was testing. The authors frame tests as valuable less for catching bugs than for forcing you to reason about your code before you write it — and that matches what TDD taught me: deciding how to test something is part of designing it.

Which is why I'm cautious about handing testing entirely to an AI. Ask an agent to "add test coverage" and it will — but if it does the thinking too, you skip the part that was actually useful. You never ask what the code should guarantee, where it might break, or what "correct" means here. The tests exist, but the design reasoning they usually prompt didn't happen. So in practice I let the AI write the tests while I stay responsible for what to test — writing assertions is mechanical; deciding what to verify is where the thinking is.

The lizard brain, and where instinct comes from

That worry generalizes. The authors tell you to trust your "lizard brain" — the instinct you develop from years of writing, debugging, and refactoring code yourself. That instinct is earned, and it's earned specifically by doing the work. So what happens when AI does more and more of that work? Can you build the same intuition reviewing generated code that you'd build writing it yourself? Or will the next generation of developers grow a different instinct — one tuned to architecture, decomposition, and judging AI output rather than to implementation detail?

I genuinely enjoy working with AI. It automates the repetitive parts and lets me explore ideas faster than before. But every problem it solves for me is a problem I don't solve myself — and solving problems is how experience accumulates. There's a balance to strike between using AI as a productivity tool and protecting the learning that produces judgment in the first place.

That, in the end, is what rereading The Pragmatic Programmer left me with. Software engineering is becoming less about writing code and more about making decisions — architecture, domain modeling, contracts, boundaries. You can't reason well about AI-generated code if you don't understand software engineering yourself. Knowledge hasn't become less important; it's shifted from producing code to evaluating and guiding it.

The book didn't change my mind about AI. It sharpened it. The implementation was never the hardest part of the job. If AI keeps automating the mechanics, the ability to think clearly about software may become the most valuable skill a developer can have — and I'm genuinely unsure how we'll keep teaching it once the machine is doing the reps.

Rails Integration Testing with Fixtures: A Practical Approach for Complex Data Sets

Dominik — Tue, 07 May 2024 07:47:48 +0000

The Challenge of Realistic Test Data

I recently faced a unique challenge in writing integration specs for a Rails application. The goal was to simulate real-world complexity within our test environment, involving interactions across 13 models like orders, line items, and products. The catch? I needed to generate around 10,000 interrelated records, reflecting the kind of volume and complexity we see in production. Typically, I'd reach for the factory_bot gem for test data generation, but due to the sheer volume and the need for persistent data, this method proved too slow. My ideal solution needed to enable the insertion of a large volume of data into the database efficiently, mirroring production data characteristics as closely as possible.

Solution: Tapping into Production DB and Fixtures

After exploring several avenues, I discovered that leveraging Rails' default fixtures, combined with our staging database (which mirrors the last three months of production records), provided an unexpectedly effective solution. Here’s how I transformed real production data into a manageable, anonymized test suite:

def fixture_creator(model, anonymized)
  File.open(
    "#{Rails.root}/spec/fixtures/#{model.table_name}.yml",
    "w+"
  ) do |f|
    fixture_data = {}
    model.in_batches(of: 100) do |batch|
      batch.each do |record|
        fixture_data["#{record.id}_#{fixture_data.size + 1}"] =
          record.attributes.dup.merge(anonymized)
      end
    end
    f.write fixture_data.to_yaml
  end
end

Exploring the Code

In this snippet, fixture_creator function does the heavy lifting:

Batch Processing: By processing the data in batches (model.in_batches(of: 100)), we efficiently handle large volumes of data without overwhelming memory usage.
Unique Keys for Fixtures: We create unique keys for each record ("#{record.id}_#{fixture_data.size + 1}"), ensuring each entry in our fixtures file is distinct and easily identifiable.
Anonymization: The anonymized parameter is a hash that overrides sensitive attributes with dummy values, crucial for maintaining data privacy.

This approach significantly speeds up the process compared to individually creating records via factory_bot. By directly exporting data from a staging environment (a subset of our production data), we ensure our tests are running against data that closely reflects real user interactions, both in volume and complexity.

Anonymization and Security

One key aspect of using production data for testing is ensuring all sensitive information is thoroughly anonymized. In my case, the anonymized hash includes mappings of original attribute names to anonymized values, applied to each record. This step is crucial not just for security and privacy, but also for complying with legal obligations like GDPR.

Conclusion

This method of generating fixtures from production data presents a robust way to create realistic, high-volume test environments for Rails applications. It's particularly useful when the test scenarios are complex, and the realism of data interrelations is crucial. While this approach worked well in my case, it's important to tailor the solution to the specific needs and constraints of your project and always prioritize data security in any testing strategy.

Memoization in Modern Ruby: How a Shape-Based Approach to Instance Variables Lookup Impacts Performance.

Dominik — Thu, 02 Nov 2023 11:32:39 +0000

Memoization is a classic technique in Ruby programming, greatly assisting in boosting performance. With Ruby's ongoing evolution, particularly towards a shape-based method in instance variable lookups, thoughtfully implementing memoization can be beneficial. Inspired by Jean Boussier's insights on RailsAtScale.com, this post highlights some suggested best practices.

Why Consider Memoization?

Memoization helps cache results of resource-heavy function calls, aiming to speed up subsequent executions. Ruby’s newer shape-based mechanism for instance variable lookups suggests organizing objects based on their instance variables. This approach influences performance and memory usage, but it's important to note that using memoization indiscriminately could lead to a range of object shapes, which might inadvertently affect performance. Understanding these subtleties can be helpful for developers looking to craft efficient and thoughtful Ruby code.

Suggested Best Practices

Aligning with Ruby's shape-based approach and optimizing memoization strategies, developers might consider the following approaches:

Mindful Use of Memoized Variables: It’s generally a good idea to keep memoized variables to a minimum. Ideally, aiming for one or two per class helps. If you find yourself needing more, initializing these variables to nil in the constructor could be a proposed better approach:

class MyClass 
    def initialize     
        @expensive_value = nil   
    end    

    def expensive_value     
        @expensive_value ||= compute_expensive_value   
    end 
end

Handling Falsy Values with Tokens: When dealing with memoized values that might return falsy results, using a token could be a neat way to differentiate between an uninitialized state and a value that's legitimately falsy:

class MyClass   
    NOT_SET = Module.new   
    private_constant :NOT_SET    
    def initialize     
        @expensive_value = NOT_SET   
    end    

    def expensive_value     
        return @expensive_value unless @expensive_value == NOT_SET     @expensive_value = compute_expensive_value   
        end 
    end
end

Wrapping Up

Adjusting to Ruby's shape-based approach for variable lookups, we might consider refining our memoization tactics to help maintain efficient performance and thoughtful memory usage. For those interested in exploring this topic further, Jean Boussier provides a deeper dive in his article at RailsAtScale. It's a thought-provoking read for anyone interested in evolving their Ruby coding practices in harmony with the latest language developments.

This summary reflects ideas from Jean Boussier's article published on October 24, 2023, on RailsAtScale.com. To broaden your understanding, the original article is well worth a read.