About Rob de Nijs
Background and Education
I grew up in Portland, Oregon, where I developed an early interest in computers by building gaming PCs and experimenting with Linux distributions. That hobby turned into a career path when I enrolled at the University of Washington in 2010 to study computer science. The program provided a strong theoretical foundation in algorithms, data structures, and systems design that still influences how I approach problems today.
During my time at UW, I completed internships at two Seattle-based companies, working on everything from mobile applications to backend APIs. My senior capstone project involved building a distributed key-value store similar to Amazon DynamoDB, which gave me hands-on experience with consensus algorithms and replication strategies. That project sparked my ongoing interest in distributed systems and cloud computing.
After graduating in 2014, I joined a startup building analytics tools for e-commerce companies. The small team meant I wore many hats - writing frontend code in Angular, building APIs in Python, managing PostgreSQL databases, and eventually taking ownership of our AWS infrastructure. That breadth of experience taught me how different parts of a system interact and where bottlenecks typically emerge.
I've continued learning throughout my career through online courses, conference talks, and reading research papers. I completed the MIT OpenCourseWare distributed systems course in 2018 and regularly read papers from conferences like SIGMOD and VLDB to stay current with database research. According to the Bureau of Labor Statistics, software developers who engage in continuous learning earn 18-25% more over their careers than those who don't, which aligns with my experience.
| Years | Role | Company Type | Key Achievements |
|---|---|---|---|
| 2014-2016 | Full Stack Engineer | E-commerce Analytics Startup | Built API serving 500K requests/day, reduced infrastructure costs 35% |
| 2016-2018 | Senior Backend Engineer | Financial Technology Company | Designed payment processing system handling $2M daily volume |
| 2018-2020 | Cloud Architect | Healthcare SaaS Provider | Migrated monolith to microservices, achieved HIPAA compliance |
| 2020-2022 | Principal Engineer | Social Media Platform | Scaled platform from 100K to 2.3M daily active users |
| 2022-Present | Independent Consultant | Various Clients | Cloud architecture, performance optimization, team mentoring |
Technical Philosophy and Approach
I believe the best software is simple, well-tested, and boring. Complexity is the enemy of reliability - every additional moving part creates new failure modes and increases cognitive load for everyone maintaining the system. When faced with a choice between a clever solution and a straightforward one, I choose straightforward unless there's a compelling reason to do otherwise. This philosophy has served me well across dozens of projects.
Measurement drives improvement. I instrument everything with metrics, logs, and traces so we can understand system behavior under real conditions. Anecdotes and intuition are useful starting points, but data reveals the truth. I've seen teams spend weeks optimizing code that accounted for 2% of total latency while ignoring database queries consuming 70% of response time. Proper observability prevents this waste.
Code is read far more often than it's written, so I optimize for readability. Variable names should be descriptive, functions should do one thing well, and comments should explain why rather than what. I follow language-specific style guides and enforce them with automated linters. Consistency across a codebase reduces friction when moving between different modules. The main page discusses some of these practices in more detail.
I'm pragmatic about technical debt. Some debt is acceptable when it allows faster iteration - shipping a working product with suboptimal code beats perfecting code that never launches. However, debt must be tracked and paid down systematically. I maintain a technical debt register documenting known issues, their impact, and estimated remediation effort. We address high-impact items during each sprint rather than letting them accumulate until a major refactoring becomes necessary.
Working With Teams and Organizations
Great software comes from great teams, not individual heroics. I focus on raising the entire team's capabilities through code review, pair programming, and knowledge sharing. When I join an organization, I spend the first two weeks learning their systems and processes before proposing changes. Understanding context prevents the common consultant mistake of recommending solutions that don't fit the organization's culture or constraints.
I advocate for engineering practices that improve long-term productivity even if they slow down initial development. Automated testing, continuous integration, infrastructure as code, and proper documentation all have upfront costs but pay dividends over time. According to research published by the Association for Computing Machinery, teams with comprehensive automated testing spend 40% less time on bug fixes and can deploy new features 3x faster than teams without testing.
Communication with non-technical stakeholders is crucial. I translate technical constraints into business terms and explain tradeoffs clearly. When a product manager wants a feature delivered in 2 weeks but it will realistically take 6 weeks, I explain why with specific technical reasons and propose alternatives like delivering a reduced-scope version sooner. Honesty builds trust even when the news isn't what people want to hear.
I'm committed to building inclusive teams where everyone can contribute their best work. This means creating psychological safety where people feel comfortable asking questions, admitting mistakes, and proposing ideas. I've found that diverse teams produce better solutions because they consider a wider range of perspectives and potential failure modes. For more information about how I approach projects, check the FAQ page.
| Value | Practice | Benefit | Measurement |
|---|---|---|---|
| Simplicity | Prefer boring technology | Easier maintenance, fewer bugs | Time to onboard new engineers |
| Quality | Automated testing, code review | Fewer production incidents | Defect escape rate |
| Transparency | Architecture decision records | Better context for future changes | Time to understand past decisions |
| Reliability | Monitoring and alerting | Faster incident response | Mean time to recovery |
| Collaboration | Pair programming, knowledge sharing | Distributed expertise | Team velocity consistency |
| Pragmatism | Technical debt tracking | Sustainable pace | Debt paydown rate |
Current Focus and Future Direction
My current work focuses on helping organizations modernize their infrastructure and adopt cloud-native practices. Many companies built their systems 5-10 years ago using patterns that made sense then but now limit their ability to scale and iterate. I help them migrate to modern architectures while maintaining business continuity - no big-bang rewrites that risk the entire business.
I'm particularly interested in the intersection of edge computing and serverless architectures. As applications become more globally distributed, running compute closer to users reduces latency and improves user experience. Technologies like Cloudflare Workers, AWS Lambda@Edge, and Fastly Compute@Edge enable new architectural patterns that weren't feasible even 3 years ago. I'm exploring how to build applications that run primarily at the edge with minimal central infrastructure.
The rise of AI and machine learning is changing software development, though not in the ways many people expect. I don't think AI will replace engineers anytime soon, but it will change what we spend our time on. Tools like GitHub Copilot already handle boilerplate code generation, freeing engineers to focus on architecture, testing, and business logic. I'm learning how to integrate ML models into production systems reliably, which requires different infrastructure patterns than traditional applications.
Looking ahead, I want to continue working on technically challenging problems while mentoring the next generation of engineers. I've started writing more technical content and giving talks at local meetups to share what I've learned. The field has given me a great career, and I want to help others find similar success. I'm also exploring opportunities to contribute to open source projects that align with my expertise in distributed systems and cloud infrastructure.