Blog
Welcome to Cogitatorium - a place for thinking, questioning, and refining ideas. Quick, one-size-fits-all answers may be convenient, but they rarely stand the test of time or context. I’ve seen too many once-accepted truths become obsolete, and I know that no single perspective, mine included, can cover every situation. Instead of handing out conclusions, I share my thought process, challenging assumptions and inviting you to do the same. If that sparks new insights, better answers, or even more questions, then we’re on the right path.
Posts
-
The Limits of Influence: Expertise, Growth, and Career Evolution
How much influence can one person truly have? In software engineering and beyond, expertise drives influence - but its growth is constrained by time, evolving knowledge, and the necessity of trade-offs. This post explores how expertise develops, the natural limits we face, and how career paths evolve as individuals choose between deep technical mastery, architectural vision, and leadership. Understanding these dynamics helps us make better decisions about our careers, collaboration, and how we shape our influence over time. -
The Metrics Maze: Uncovering the Dark Side of KPIs
In the ever-evolving world of software development, the quest for the perfect Key Performance Indicators (KPIs) and metrics is akin to searching for the Holy Grail. Management eagerly seeks golden metrics to estimate, plan, and track development work and individual performance. Engineering teams often find themselves divided, debating the merits and pitfalls of each. From velocity, code churn and complexity to defect density and cycle time, these KPIs are anything but clear-cut. They come with their own set of controversies and unintended consequences that can ripple through like plot twists in thriller novels. Buckle up as we dive into the fascinating, and sometimes contentious, world of software development metrics! -
Code coverage is an indicator, not a goal
This post challenges the misconception that higher code coverage equals better testing. We highlight how blindly pursuing 100% coverage can lead to unnecessary complexity and dead code, emphasizing that the real goal is to align tests with the actual needs of the code, not just increase coverage for its own sake. -
Security: Recognizing the Inappropriate
I challenge the conventional approach to security, especially when it comes to rate limiting and authorization. While many stick to outdated methods like IP or HTTP rate limits, I argue that these approaches fall short in real-world scenarios. Instead of just slapping constraints on your infrastructure, we need a deeper, more flexible solution that accounts for the human factor, tools, and evolving user behavior. -
Authorization: A Thought Scaffold
We've all been told to secure our systems, but what does that really mean? Is it enough to authenticate users or protect API endpoints, or is there more to the story? In this post, I question the usual security wisdom and delve into the complexities that most people overlook. It's easy to think security is figured out once you've ticked the right boxes, but real protection goes far beyond that. From handling external dependencies to fine-tuning access control across multiple levels, I challenge you to rethink your approach, question assumptions, and ask the tough questions that often get ignored. This isn't a generic security guide - it's a deeper exploration of what it really takes to secure modern systems. -
REST API (4): Emperor's [New?] Clothes
REST is still hailed by many as the ultimate goal for API design, yet the reality is far more complex. I challenge conventional thinking by exposing the struggles involved in designing, implementing, evolving, and maintaining REST APIs. From the varying interpretations - ranging from purist to pragmatic - to the complexities of balancing competing needs and managing resource states, blindly adhering to RESTful practices almost always leads to inefficiencies and wasted resources. It's time to critically examine whether REST is truly the best path, or if it's just another set of invisible "clothes" that not only mask, but also create, the real challenges in API design. If you're not questioning REST's place in your system, you're missing the bigger picture. -
That's not a Road Map
I challenge the conventional understanding of business and engineering "road maps", pointing out their frequent lack of actionable guidance and their loose resemblance to actual maps. I advocate for a more authentic approach, emphasizing the importance of detailed planning and clear communication to effectively navigate the complexities of development. My perspective encourages readers to rethink traditional methodologies and embrace more practical and structured planning strategies. -
Speaking GraphQLy: Provocative Intro to GraphQL
This post takes a refreshing approach to explaining GraphQL. Instead of focusing on the usual abstractions, let's break it down: GraphQL is a composable function calling system that outputs structured JSON. No complex jargon, just a straightforward exploration of what GraphQL really is, how it works, and why it might not be the game-changer it's often made out to be. I'll guide you through the simplicity of GraphQL's API interaction, cutting through the fluff and overcomplicated theories, to show you how it actually works and how you can use it effectively without needing all the hype. -
Agile Mythodology
Explores common misconceptions and mistakes in the implementation of Agile methodology, highlighting real-world observations and their consequences. While Agile itself remains a powerful framework, the way it is often applied can lead to inefficiencies, confusion, and missed opportunities. From misunderstandings around simplicity and team structure to misguided priorities and the misuse of time metrics, the post aims to shed light on how these errors can hinder progress. The goal is to foster a deeper understanding of Agile practices, encouraging teams to adopt a more thoughtful, informed approach to achieving true agility. -
GraphQL: What it is not!
Tired of hearing the same old buzzwords about GraphQL? It's time for a reality check. In this post, I'll challenge what you think you know about it - GraphQL isn't a "graph query language", nor is it a database query tool, despite the name. Instead, it's a framework to help you design your own APIs. By busting myths and tackling misconceptions, even those held by seasoned developers, I'll strip away the hype and reveal what GraphQL really is. With a clear mind and a fresh perspective, you'll see how GraphQL can offer practical solutions to your existing problems without being as odd or intimidating as it's often made out to be. -
Collaborating Services by Functional Composition
Tired of fighting service fragmentation with bloated gateways and endless client-side juggling? In this post, I dismantle the myths of orchestration, expose why conventional strategies often collapse under real-world complexity, and make a case for a smarter, functional approach that's efficient, scalable, and already in your toolkit. Forget the chaos of overengineering - there is an alternative that correctly distributes ownership, eliminates inefficiency, and simplifies collaboration without adding layers of hype. -
Divide & Conquer in Software Development
Forget the clichés - "Divide & Conquer" is only half the story. In this post, I challenge the blind faith in endlessly splitting everything into smaller parts and argue for a balanced, thoughtful approach that combines division and cohesion in software and teams. By exploring real-world consequences, I'll confront the myths and limitations of endless division, exposing how blindly following this mantra can lead to overengineering and missed opportunities. Instead, I'll show you how functional composition, smarter abstractions, and practical strategies can help you navigate complexity, adapt to change, and thrive without losing agility. Whether it's microservices, team structures, or system design, this is a call to rethink how we build, organize, and evolve - stripping away the hype and focusing on what truly works. -
REST API (3): Tug of War
REST API design isn't as straightforward as it may seem - there's a complex tug of war between competing factors like client needs, performance, security, and maintainability. While many treat REST as a simple, one-size-fits-all solution, the reality is far messier. From managing resource states and ensuring performance to addressing failure and evolving with clients, every design decision pulls in different directions. I explore alternative approaches, such as dynamically adjusting resources or reimagining them for specific clients, and challenge the conventional wisdom by questioning the assumptions others often settle for. By diving deep into these complexities, I urge you to think critically about the real-world challenges of API design and the profound impact your choices have on the system's functionality and longevity. -
REST API (2): Carving the state(s)?
In this post, I unravel the challenges of designing REST APIs, focusing on the often-overlooked complexities of carving state into meaningful resources. While REST may sound straightforward, the reality is full of trade-offs, missteps, and hidden intricacies that many designs fail to address. This isn't about blindly adhering to REST principles - it's about questioning assumptions, rejecting superficial solutions, and tackling the hard questions: Where do you draw the line between simplicity and overengineering? This post is your wake-up call to rethink what REST truly demands vs what it gives back. -
REST API (1): What?
REST APIs are everywhere - or so we claim - but are we truly building them, or just riding the hype train? Many toss around the term 'REST' without understanding its meaning or questioning whether their APIs are actually RESTful. This post dives deep into the myths, misconceptions, and inconsistencies surrounding REST, challenging 'accepted practices' and exposing what might be sacrificed when blindly following trends. It's not about sticking to a popular label; it's about understanding REST's true demands, its constraints, and its implications. Let's rethink what we're building, separate fact from fiction, and start making intentional, informed design choices instead of chasing buzzwords.
subscribe via RSS