Developer Productivity at a Developer Productivity Startup • Robert-Jan "RJ" Huijsman • GOTO 2025

Robert-Jan Huijsman, Founding Engineer at Reboot.dev, shares insights on achieving high developer productivity, drawing from his team’s experiences. The core of their approach revolves around minimizing friction and eliminating non-determinism in both human interaction (‘humaning’) and coding tasks.

Overcoming Friction

Friction in Humaning: Defined as anything slowing progress. The primary challenge for Reboot’s globally distributed team (spanning Warsaw to Hawaii) is waiting for colleagues. They employ two modes:

• Throughput-Focused: Maintain multiple parallel workstreams. If blocked on one task due to time zone differences, switch to another unblocked task. This allows continuous progress on different items.
• Latency-Focused: For critical, time-sensitive issues, they leverage time zones for 24-hour continuous progress by handing off tasks across regions (e.g., Copenhagen to New York to Hawaii). This is an intense, less frequent mode.

An “AI alert” notes the current limitation of AI agents to handle long-term, unsupervised tasks akin to handing off work to a sleeping colleague.

Friction in Coding: Examples include slow build times (npm install) or navigating large, unfamiliar codebases. RJ highlights three “boring” but highly effective strategies:

1. Types Everywhere: Advocates for strongly typed environments (TypeScript, Python with types). Crucially, this extends beyond individual codebases to inter-component communication, ensuring types between backend and database (via ORMs) and frontend and backend (via tools like TRPC or schema-generated client SDKs). Reboot’s framework integrates this by acting as both an ORM and a code generator, ensuring full-stack type safety from client to disk.
2. Unit Tests: Described as “eating your vegetables.” An “AI alert” emphasizes that Large Language Models (LLMs) are excellent at writing unit tests. These tests are vital for agentic development, providing a safety net when an LLM’s context window is exceeded, ensuring changes don’t break existing functionality.
3. Stop Repeating Yourself (DRY): Beyond the general principle, RJ focuses on eliminating “busy work” like explicit get and set operations for persistence. He champions “orthogonal persistence,” where state is automatically stored and retrieved. Reboot’s framework allows functions to receive state directly, handling persistence implicitly and type-safely, letting developers focus on business logic.

Eliminating Non-Determinism

Non-Determinism in Humaning: Refers to unpredictable success, leading to questions like “Am I working on something useful?” or concerns about code rejection. Reboot addresses this with an “egoless” collaborative brainstorming approach:

• An individual identifies a problem and proposes an initial solution.
• This solution is iteratively refined through collaborative editing with colleagues until it is “uncontroversial” and universally agreed upon.
• The emphasis is on finding the collective best solution, not individual ownership of ideas. This ensures that submitted code is almost always useful and accepted, reducing wasted effort and boosting job satisfaction.

Non-Determinism in Coding: Manifests as flaky tests, intermittent production issues, or complex race conditions. RJ proposes three engineering fundamentals for near-complete elimination of non-determinism:

1. Retries and Idempotency: The internet is unreliable. Applications should automatically retry failed requests. To prevent unintended side effects from multiple retries, server-side operations must be idempotent (i.e., producing the same result regardless of how many times they are executed). This requires unique request identifiers and server-side tracking. Reboot builds this directly into its framework for enhanced reliability.

2. Durable Execution: Extends idempotency to client crashes. If a client working on a multi-step process crashes, it can simply restart from the beginning. The idempotent server ensures only new steps are executed, allowing work to complete even through transient failures. Frameworks like Temporal, RState, and Reboot’s own system support this, ensuring “no work is left undone.”

3. Strong Consistency: RJ asserts that the debate between strong and eventual consistency is settled: strong consistency is the answer, even at scale. He identifies three causes of inconsistency:

   • Using databases that lack strong consistency (though many modern databases offer it).
   • Code architecture that inadvertently breaks transactions across distributed components (e.g., not propagating transactional context across remote procedure calls).
   • Developer mistakes, such as performing data fetches outside of a transaction block, which are subtle and hard to catch in code reviews or by AI.

   Reboot’s framework enforces strong consistency by requiring a transaction context to be passed to all relevant calls, ensuring that distributed operations participate in a single, atomic transaction. This significantly reduces failure modes and increases confidence.

Conclusion

While friction is an ongoing battle requiring continuous trade-offs, non-determinism is a one-time investment. By building applications on robust foundations that incorporate retries, durable execution, and strong consistency, teams can significantly improve productivity and reliability. A final “AI alert” warns that if AI models are trained on poorly structured, non-deterministic code, future developers will be burdened with fixing these foundational flaws. Therefore, it is crucial to teach AI – and other humans – to build on strong, deterministic principles from the outset to ensure a more productive future.

• Tags:
• Code Generation
• Software Engineering
• Developer Productivity
• Distributed Systems
• Software Architecture
• Durable Execution
• AI in Development
• Team Collaboration
• Type Safety
• Idempotency
• Strong Consistency
• Async Work
• Unit Testing
• DRY Principle