DEV Community: Michael Di Prisco

Thanks Captain Obvious - Just Don't Be An A**hole

Michael Di Prisco — Wed, 21 Jan 2026 08:00:00 +0000

Leadership advice is everywhere, but.

Threads, books, courses, TED talks, frameworks, pyramids, quadrants, canvases, principles, checklists.

But after years of being a Developer / Tech Lead / Manager / everything in between, here's the uncomfortable punchline I keep coming back to:

Much of leadership starts from a brutally simple principle:

"Thanks Captain Obvious - just don't be an a**hole."

And sure, it sounds superficial... until you look closely and realize how many people fail at exactly this.

We read articles about psychological safety while publicly mocking colleagues' ideas.

We repost quotes about empowerment and then micromanage code reviews.

We celebrate team ownership while hoarding decisions.

The problem isn't knowledge.

It's interest.

It's empathy.

It's habit to dismantle.

It's the willingness to see the human being, both on the other side of the desk and especially behind your own.

And I'm not innocent either.

I'm writing this while replaying a highlight reel of all the times I failed people - the times I interrupted, dismissed, rushed to solutions, hid behind architecture, or simply didn't listen. I still regret some of those moments. And I know the next mistake is just around the corner, waiting to teach me something else about myself.

But maybe that's the point:

Leadership is not about perfection.

It's about noticing when you screwed up - and choosing to do better next time.

The Ridiculous Obviousness Behind Leadership Advice.

Let's take a tour of some universally celebrated principles and translate them into plain English.

Empower your team.

➡️ Let people do their job.

Stop solving everything for them. Stop being the human bottleneck.

I already wrote this in Authority and Accountability, where authority goes down but accountability goes up. A concept so simple it should be stapled above every manager's monitor.

Practice active listening.

➡️ Shut up. They're talking.

You don't need a workshop for this. You need self-awareness.

Create psychological safety.

➡️ Don't make people feel stupid.

If you roll your eyes at a question, congratulations - you just became the problem.

Lead by example.

➡️ Do the things you expect others to do.

I already wrote this clearly in Build a Rocket with LEGOs: great developers - and great leaders - make complexity disappear instead of showing off with it.

Avoid over-engineering / stay pragmatic.

➡️ Solve the real problem, not the one inside your head.

I already wrote this in What Sits and What Fits and expanded it in Stay in the Problem Space: clarity beats cleverness, always.

Help the team grow.

➡️ Care enough to invest in people.

If you don't genuinely want them to succeed, they will feel it. Immediately.

Leadership Isn't Learned - It's Revealed.

After years of reading, practicing, and messing up, here's the truth I can't unsee:

Leadership doesn't come from frameworks.

It mostly comes from how you see - and treat - people.

You can read 200 leadership books.

You can memorize every model.

You can preach every principle on LinkedIn.

But if you don't fundamentally care about:

what your teammates fear,

what they hope,

what drains them,

what motivates them,

what they need from you...

...then none of it matters.

Leadership is not a skillset you can copy-paste.

It's a lens.

A way of perceiving humans before processes.

A willingness to adapt yourself before asking others to adapt to you.

And most importantly:

You cannot lead people you are not willing to understand.

This is the foundation underneath all the "obvious" advice - the part books rarely emphasize, because you can't teach someone to care.

Some Real Examples (a Bit Too Real).

When someone delivers poor work

Bad leader:

Ugh, they're not good enough.

Actual leader:

Did I communicate poorly? Is the context unclear? Are they overwhelmed?

When a junior makes a mistake

Bad leader:

"We can't afford this."

Actual leader:

"Mistakes are tuition. Let's look at it together."

When the team is drowning

Bad leader:

"Push harder."

Actual leader:

"What can we remove? Who needs support? What am I missing?"

And yes - I've been both versions.
Sometimes in the same week.

P.S. These phrases are examples to make a point; each of the "bad leader" statements I indicated could be said constructively and coherently in the right context. What matters is the attitude and intention behind the words. Leadership is not an if-else statement.

Why Don't More People Do This Then?

Because it's far easier to talk about leadership than to actually live it.

Applying these principles requires two things most people avoid like Friday evening refactoring:

Self-awareness - looking your impulsive reactions, ego, and insecurities in the face.
Not everyone wants to discover that the real bottleneck isn't the team... it's them.

Vulnerability - admitting you might be wrong, that you don't have all the answers, that you need to learn when to stop.
It's much more comfortable to hide behind processes, metrics, architectures, and "best practices."

The truth is "just don't be an a**hole" sounds trivial until you realize it demands constant work on yourself.
And that work - the work on yourself - is the part of leadership you can't delegate, automate, or copy-paste from a book.

That's where most people stop.
Not because they don't know what to do - but because actually doing it takes more courage than it seems.

The Ironic Twist.

All the leadership lessons we admire - empathy, clarity, autonomy, pragmatism, communication - are the same things we celebrate in great developers.

If you read my previous articles, you'll notice a pattern:

The Truth About Test Coverage -> clarity beats vanity metrics.
Iterative Contract Testing -> simplicity beats complexity.
Colleague-Based Testing -> your code must be understandable to others.
Asynchronous Batching -> optimize for collective efficiency.

Replace "codebase" with "team", and they just became leadership mantras.

Turns out the line between a good architect and a good leader is thinner than we think.

Conclusion.

I've made enough mistakes to write a trilogy.

I'll make more.

You will too.

But if there's one thing I've learned - something no article, no podcast, no book ever taught me explicitly - it's this:

The quality of your leadership is measured by how people feel after interacting with you.

The truth is no framework can save you from yourself.

People don't remember your title, your decisions, your roadmaps.

They remember how you made them feel while all of that was happening.

Not being an a**hole isn't a leadership principle.

It's a principle of humanity applied to work.

Everything else - processes, metrics, models - is just maintenance.

Build a Rocket with LEGOs

Michael Di Prisco — Wed, 20 Aug 2025 07:15:07 +0000

Introduction

"The Art of Programming is the Art of Organizing Complexity" - Edsger Dijkstra

I'm not a dogma guy, so don't expect me to talk about "ports and adapters" or "clean architecture" here. Instead, I want to share a mindset that has helped me and many others build better software. What follows is not just about software, but about how to think like a great developer.

Let's picture the following: you hand a group of developers a huge pile of LEGO bricks and ask them to build a rocket.

Some will sketch blueprints, carefully laying out every component before placing a single brick. Others will immediately start building, creating elaborate structures, only to watch them collapse under their own complexity. But a rare few - the best developers I've worked with - will do something different.

They'll visualize the rocket in their mind and then break it down into blocks so simple that anyone in the team could assemble them. They'll start small, test as they go, and invite others to snap pieces in place. And when the rocket finally takes off, it won't just be a marvel of design - it'll be maintainable, adaptable, and collaborative by nature.

👉 Those are the developers I want to work with.

Complexity Is Not a Badge of Honor

There's a persistent myth in our industry: that the "best" developers are the ones who navigate complexity with elegance, mastering abstract patterns, functional purity, or architecture diagrams that look like subway maps.

But here's the truth: The best developers make complexity disappear.

They don't impose it on the team. They tame it. They break it down into clear, simple steps that are easy to understand and even easier to collaborate on. They understand that their job isn't to make themselves look smart - it's to help everyone move fast without breaking things.

Their brain handles the complexity - but their output doesn't show it. It shows empathy.

A practical example

In Jointly, we built a simple abstraction layer for our cache needs called cache-candidate. It is a beast, automatically managing custom keys, dependency invalidation, TTLs, thunder herding problems, and more.

It can work both in memory and with Redis, and it has a simple interface that allows us to swap implementations without changing the code that uses it.

The internal implementation? As of today, 516 lines of code just for the core functionality, ignoring what is actually exposed, so you need to add that, the Redis implementation, the in-memory implementation, the plugins system, etc, which brings the total close to 1000.

The external interface?

import { cacheCandidate } from '@jointly/cache-candidate';

function getUsers(filters = {}) {
  return db.query('SELECT * FROM users WHERE ?', filters); // Example function to cache
}

const cachedGetUsers = cacheCandidate(getUsers); // ✅ Done!

And if you want to switch to Redis, have a custom key name, a specific TTL and a different expiration mode?

const cachedGetUsers = cacheCandidate(getUsers, {
    ttl: 500,
    customKeyFunction: (rootArgs) => {
      return `users_in_system:${rootArgs[0].only_active_users ? 'active' : 'all'}`;
    },
    cache: makeRedisCache(),
    expirationMode: 'timeout-only'
  }); // ✅ Done!

Wait, what is that makeRedisCache()? It's a 25 LoC compatibility layer we built around kv - an internal Redis client - just for the cache-candidate to work with Redis. It uses the simple adapter interface of cache-candidate to provide a Redis implementation based on specific needs we expressed inside kv.

This brings the total complexity of the system to around 1300 LoC, yet the final user just had to install a package and copy three lines of code from the README to switch from in-memory to Redis.

See? The complexity is there, but it doesn't affect and afflict the Developer Experience. The interface is simple, and anyone can use it without needing to understand the underlying implementation. Paradoxically, a developer who doesn't know how to use Redis can still use the cache-candidate in such a configured way.

Great Developers Are Systems Thinkers

These developers aren't necessarily the most skilled coders or the fastest bug-fixers. But they're incredible problem solvers because they:

Deconstruct the problem space before jumping into solution mode.
Spot dependencies and friction points early.
Translate ambiguous requirements into crisp, executable building blocks.
Empower others by making their contributions plug-and-play.

In short, they're not just engineers - they're collaborative systems thinkers.

How to train your mind to think like this?

To cultivate this mindset, I always suggest the 5 Whys technique. When faced with a complex problem, ask "Why?" five times. Each answer will help you peel back layers of complexity until you reach the root cause or the simplest form of the problem.

I find the 3rd or 4th "Why?" to be the most revealing and usually solves the problem.

Skills to Cultivate

So how do you get there? Here are a few mindset shifts that separate great developers from good ones:

Think in steps, not just solutions Can someone else follow your thought process? If not, simplify it.
Design for collaboration Would you rather be a genius solo builder or the person who enables 5x progress by everyone else?
Favor boundaries over cleverness A well-defined interface is often more valuable than a brilliant internal algorithm.
Don't just ask "How do I fix this?" - ask "How do I make it easy for someone else to change this tomorrow?"

How to cultivate this mindset in a team?

To cultivate this mindset in your team, I would suggest the following practices:

Pair programming: Organize moments where developers work together on the same codebase, sharing ideas and approaches, trying to come out with a solution that is easy to understand and extend. If another dev can understand it without questions, it means it's simple enough.
Team-wide Code reviews: Encourage team members to review each other's code, all together, without the dev who wrote it present. This way, they can ask questions and suggest improvements without the pressure of the original author being there. If you can't do that, at least try to have the author present but not speaking, so they can only listen to the feedback and answer questions. If answers are needed, it means the code could be improved.
Documentation written by a dev who didn't write the code: Encourage team members to write documentation for code they didn't write. This forces them to understand the code and explain it in simple terms, which helps both the writer and the reader. This usually happens after the code review, so the clarifying questions are already answered, and the writer can focus on explaining the code in a way that is easy to understand.

"What if the system has to be complex?"

Sometimes, complexity is unavoidable. But even then, the best developers find ways to make it manageable. They create abstractions that hide the complexity behind simple interfaces. They document their thought processes so others can follow along. They build systems that are resilient to change, not brittle.

In this case, I usually suggest to focus on DevExp, Documentation and Collaboration. Make more than one person understand the system, and ensure that anyone can pick it up and work on it without needing to decipher a complex web of dependencies. It still could be a pain to work on, but at least it won't be a system people are afraid to touch.

Final Thought

A LEGO rocket built collaboratively will always outperform a duct-taped space shuttle made by one. Not because it flies higher, but because anyone can fix it when it breaks - and everyone knows how it works.

Next time you're deep in a gnarly refactor, or knee-deep in a greenfield system, ask yourself:

"Am I building a rocket, or am I just piling up bricks?"

Because the best developers? They build rockets. With LEGOs.

Stay in the problem space.

Michael Di Prisco — Fri, 04 Apr 2025 20:46:46 +0000

When a problem isn't clear, the solution can't be either.

When was the last time you jumped straight into coding or rushed to adopt the latest technology before fully grasping the core issue? 🤔 We've all been there. In software engineering, the allure of shiny new tools or clever solutions can often distract us from the foundational discipline: staying in the problem space.

Problem First, Solution Later

Imagine you're debugging a critical issue: your application randomly crashes. You might instinctively start applying patches or quick fixes. But what if the issue resurfaces? You probably didn't spend enough time understanding the true nature of the problem.

The key is to resist this initial rush toward solutions. Deeply understanding the problem helps you uncover edge cases, hidden assumptions, and unclear requirements---elements that are often overlooked yet critically impact your software's robustness.

For example, let's consider the widely misunderstood concept of test coverage:

function sum(a, b) {
  return a + b;
}

Running some tests on this function might give you 100% coverage---but does it handle unexpected input correctly, such as a string or undefined? Real-world scenarios demand thorough problem-space exploration rather than superficial solutions driven by metrics alone.

✅ Tip: Always start with clarifying edge cases and unclear requirements before writing your first line of code.

How Product Teams Can Enable Engineers

It's crucial not just for developers but also for product teams to embrace the problem-first approach. Often, product teams inadvertently present solutions disguised as problems:

"We need a button here that sends a notification."

This is a solution, not a problem. Instead, framing it as:

"Users don't notice when important changes occur."

Now, the team can creatively address the issue, potentially uncovering solutions more elegant or effective than a mere button.

Bridging Software Engineering and Product Management

Encouraging product teams to articulate problems rather than dictate solutions shifts the role of software engineers towards Product Engineers---professionals who blend deep technical expertise with product insights. In an AI-driven world, this combined perspective becomes increasingly critical.

✅ Tip: Advocate for clear problem definitions from your Product team, and become a proactive partner in finding optimal solutions.

Avoiding Over-engineering

Staying firmly in the problem space prevents the all-too-common pitfall of over-engineering. Consider the classic case of implementing an event-driven architecture for a simple, low-traffic application. While elegant on paper, such architecture might complicate the solution unnecessarily, diverting energy away from real customer value.

Focusing on the problem first---like exploring the need for batching requests asynchronously to improve performance---can reveal simpler, more effective solutions tailored precisely to the real issue.

Practical Tips for Staying Problem-Focused

Clearly Define Problems: Use techniques like "5 Whys" to drill down to root causes.
Engage Cross-Functional Teams: Encourage dialogue between developers, product managers, and stakeholders to enrich understanding.
Measure Impact, Not Activity: Focus on outcomes and impacts rather than arbitrary metrics.
Leverage Documentation Wisely: Use lightweight documentation like Architecture Decision Records (ADRs) to track decisions made from a problem-centric perspective.

Conclusion

The essence of creating impactful software lies in relentlessly staying in the problem space. Prioritize problem clarity, resist immediate solution temptations, and foster product-engineering collaboration. Embrace this discipline, and you'll drive sustainable, valuable outcomes that truly align with your business goals.

So next time you're tempted by a quick fix or a new framework, take a step back. Stay with the problem. Let solutions naturally follow.

👋 Discussion Starter: How often do you find yourself rushing into solutions before fully understanding the problem? Share your experiences below! Let's discuss how we can collectively stay grounded in the problem space.

Authority and Accountability

Michael Di Prisco — Sat, 15 Mar 2025 15:02:49 +0000

Authority Goes Bottom-Up, Accountability Goes Top-Down.

Introduction

In my small journey as a tech lead, I've learnt that effective leadership isn't about issuing commands from an ivory tower. Instead, it's about redistributing authority while still holding onto accountability. This idea might sound counterintuitive at first --- after all, traditional management put both authority and accountability at the top. Traditionally, managers made all the key decisions (authority flowed top-down) and pushed responsibility for failures onto their teams. But the model I saw bring the best results is different: one where authority goes bottom-up and accountability comes top-down.

I learnt that empowering those closest to the work leads to better results. By allowing decisions to be made by developers, designers, and other experts on the front lines, a leader taps into the collective intelligence of the team. The leader's role then shifts from being a control point to being a support structure. Yet, even as team members gain more control over how work gets done, the leader remains the one answerable for what comes of it. I've seen first-hand that this dynamic can transform a team's agility and morale --- if done right.

The Leadership Paradigm Shift

This approach represents a paradigm shift in leadership style. In the old top-down model, authority was concentrated at the top: the tech lead or manager would devise solutions, assign tasks, and dictate methods. Accountability often trickled down in a negative way, where failures were blamed on individuals or sub-teams. In the bottom-up authority model, this script is flipped: authority is distributed among team members who have the knowledge and context to make informed decisions. The tech leader still sets the vision and direction, but trusts the team to determine the best path to reach those goals.

With authority spread out, innovation and creativity flourish. Team members feel heard and valued because they're actively shaping decisions, not just following orders. This doesn't mean the leader is hands-off or absent. Instead, the leader stays highly engaged in enabling the team's success while accountability remains centralized. The leader takes responsibility for the outcomes of those team-led decisions: if things go well, the whole team shares the credit; if things go poorly, the leader shoulders the blame and seeks solutions. This clear division --- empowerment in execution, responsibility in oversight --- marks a big change from traditional management and demands a new mindset from everyone involved.

Trust and Responsibility

At the heart of pushing authority downward is trust. A tech leader must trust their engineers and designers to make choices that align with the project's objectives and the company's values. This trust isn't blind; it's built over time through communication, experience, and mutual competence on both sides. When team members feel truly trusted, they develop a greater sense of ownership. They stop just carrying out tasks and instead take responsibility for solving problems and innovating, because they know their judgment is respected.

This empowerment fosters a culture of responsibility. Each expert becomes the owner of their domain, whether it's a piece of code, a UI design, or a deployment process. They make decisions as if the project were their own --- because in a sense, it is. Meanwhile, the tech leader remains ultimately accountable for the project's success and failures. In practice, this means the leader stays aware of the big picture and is ready to step in to support or course-correct as needed, but not to second-guess every decision.

It's a delicate balance: giving people freedom to act, and being ready to catch them if they fall. When done well, the result is a team full of proactive problem-solvers who feel responsible for the outcome, rather than cogs waiting for instructions.

Challenges of This Approach

Adopting a bottom-up authority and top-down accountability model isn't without its challenges. Leaders and teams may face several dilemmas as they adjust to this balance of autonomy and oversight:

Letting Go of Control: For leaders, especially those seasoned in top-down environments, it can be difficult to step back and not micromanage. It takes discipline to allow others to make decisions (and mistakes) in areas you used to control directly.
Team Readiness: Not every team member is immediately comfortable with newfound model. Some may fear making the wrong decision and prefer clear orders. There can be a learning curve as individuals grow into their decision-making roles.
Risk Management: With greater autonomy comes the chance that teams might pursue an approach that fails or falls short. The leader, while accountable, must create a safety net for smart risk-taking. This involves encouraging experimentation but also having fallback plans or checkpoints to prevent complete derailment.
Avoiding Micromanagement in the Name of Accountability: Knowing you are accountable for the team's outcomes can tempt a leader to hover over every choice --- which defeats the whole purpose of empowerment. The challenge is to stay informed and provide guidance without dictating every move. Leaders must learn to trust but verify: implement review processes, ask questions, and then let the team execute.
Alignment and Clarity: When authority is decentralized, maintaining a unified direction requires extra effort. The leader must clearly communicate the vision, goals, and constraints so that even as team members make independent decisions, those decisions align with the broader mission. Without this clarity, bottom-up authority can lead to chaos or divergent paths. > Letting Go of Control is probably the most challenging aspect of this model, at least for me. Being a hands-on developer for years, I had to learn to trust my team and let them make decisions, even if I would have done things differently. It's a constant exercise in humility and patience, but the results are worth it, and when I fail in doing it, my team is always there to accept my moments of weakness and help me get back on track.

Navigating these challenges requires self-awareness from the leader and a commitment to open communication within the team. It's not a "set and forget" model; it demands continual tuning of how much guidance or freedom the team needs as circumstances change. The payoff, however, is a more resilient and engaged team that can adapt and innovate quickly, with the leader as a guiding force rather than a taskmaster.

The Tech Lead's Role

In a tech team, the Tech Lead plays a pivotal role in this bottom-up authority structure. Unlike a traditional boss who issues orders, a Tech Lead in this model acts as a facilitator and mentor. They use their technical expertise to guide and support rather than unilaterally decide. On a day-to-day basis, this could mean letting the team choose the tech stack or design patterns for a new feature, while the Tech Lead provides context about constraints (like performance needs or deadlines) and helps navigate trade-offs.

The Tech Lead must balance two key aspects: autonomy and oversight. On one hand, they encourage developers to propose solutions and run with their ideas. On the other hand, they keep a watchful eye on the bigger picture --- ensuring that all these individual decisions integrate into a coherent, high-quality product. If a developer's experiment is struggling, the Tech Lead offers help or finds additional resources, rather than immediately overruling the effort. They cultivate an environment where mistakes are treated as learning opportunities, not failures.

Crucially, the Tech Lead also serves as the shield for the team. In meetings with upper management or clients, the Tech Lead takes accountability for the team's output. If a deadline is missed or a feature has issues, the Tech Lead owns up to it, then works with the team to set things right. Internally, they will discuss how to improve, but externally they never throw their team under the bus. This builds trust within the team --- they know their lead has their back.

Do not misunderstand shielding your team with covering up their mistakes. It's about taking responsibility for the outcomes, not about ignoring the causes. When something goes wrong, it's the Tech Lead's job to address it, understand it, and work with the team to prevent it from happening again. Shield too much, and you'll lose credibility; shield too little, and you'll lose your team's trust.

Over time, this trust loop (team members entrusted with authority, Tech Lead accountable upwards) creates a strong bond and a high-performance culture. The Tech Lead becomes the embodiment of bottom-up authority and top-down accountability: empowering the team at every step, yet standing up to answer for the results.

Conclusion

Shifting to a bottom-up authority and top-down accountability model can feel like walking a tightrope, but the results are incredible. By giving away power and holding onto responsibility, leaders might actually strengthen their teams and outcomes. It challenges the very notion of what a leader should do: less controlling, more enabling; less commanding, more accountable.

Let's see how it goes. I'm still learning, but I'm excited to see where this path leads me and my team. I hope you are too.

My latest fatigue!

Michael Di Prisco — Fri, 24 Jan 2025 14:12:57 +0000

What Sits And What Fits.

Michael Di Prisco ・ Jan 24

#architecture #programming #career #discuss

What Sits And What Fits.

Michael Di Prisco — Fri, 24 Jan 2025 14:06:07 +0000

Introduction.

[TL;DR] It depends.

In software development, the concepts of rules, principles, and best practices form the backbone of our work. These are the foundational elements - what sits - that guide decisions, standardize processes, and ensure scalability in complex systems. They act as anchors, providing stability and a shared understanding across teams and projects.

Yet, no rule or practice exists in a vacuum. There are moments when the established path is not the best path. Context shifts, priorities change, and sometimes the solution lies in stepping outside the boundaries. These are the moments when fits - context-specific adaptations - become necessary to resolve unique challenges. The tension between sits and fits is the core of pragmatic software architecture.

In this article, I'll try to explain my vision and the value of fits, or better said, the importance of trade-offs.

The Value of "Sits": Structure and Scalability.

Every software project needs a framework - a set of rules and principles - to thrive. These frameworks are what "sits" represent. By adhering to these foundational practices, teams can create systems that are easier to maintain, extend, and scale over time.

Consistency Across the Board.

Consistency is the unsung hero of software architecture. By following well-defined rules, developers can create predictable systems where new contributors can quickly understand the codebase. Consider the widespread use of design patterns such as MVC (Model-View-Controller). These patterns act as a shared language among developers, allowing teams to discuss and implement features without endless debate.

Consistency also plays a role in reducing cognitive load. For instance, adopting a single testing framework across the organization (e.g., Vitest for JavaScript projects) means that developers don't need to switch mental gears when moving between repositories. This small reduction in mental friction can lead to significant productivity gains over time.

Maintainability Through Clear Rules.

Best practices often emerge to solve recurring problems. Take the principle of separation of concerns. By dividing code into distinct layers - presentation, logic, and data - you make it easier to identify and resolve bugs. For example, debugging a UI bug becomes simpler when the logic is encapsulated in a service layer rather than tangled in view components.

Moreover, clear rules prevent tech debt from spiraling out of control. Following SOLID principles in object-oriented programming ensures that components remain modular and adaptable. Violating these principles might work in the short term, but over time, the cost of these violations compounds, turning minor issues into systemic problems.

Scalability: Building for Growth.

When designing systems, scalability is often a key concern. Principles like horizontal scaling and stateless services allow architectures to handle increased loads without dramatic redesigns. Kubernetes, for instance, thrives on stateless containers that can be scaled up or down seamlessly. These practices might not seem essential during initial development, but as traffic grows, their importance becomes apparent.

However, sticking rigidly to these principles can sometimes choke innovation or delay delivery. This is where fits come into play.

When Fits Prevails: Breaking Rules for Context.

While sits provide structure, they can also impose constraints that are unnecessary in certain contexts. The ability to recognize when breaking the rules serves the greater good is a clear sign of an experienced architect.

Nothing is JUST a Technical Decision.

This phrase has been said many times by a dear friend of mine, Luca Mezzalira, and it resonates with me a lot.

The most important lessons I've learned in software architecture is that no decision is purely technical. Every choice we make has implications for the business, the team, and the product's future. A technical decision can impact budgets, timelines, and even team morale. It's essential to recognize this interconnectedness to make informed choices.

It's a powerful reminder that we, as architects and developers, operate at the intersection of technology and business, and our decisions must serve both dimensions.

By keeping this in mind, I've learned to approach every architectural choice with a broader perspective, considering not only the immediate technical benefits but also the ripple effects on stakeholders and long-term goals.

Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.

Melvin Conway - 1967

Examples of Sits and context-specific Fits.

Let's consider some common examples of sits in software architecture:

Polymorphism in OOP: Reducing redundancy by encapsulating shared logic in parent classes.
Comprehensive unit testing: Ensuring that changes don't introduce regressions, especially in large codebases.
Event-driven architecture: Decoupling components to improve scalability and maintainability.
Contract Testing: Verifying that APIs adhere to predefined contracts to prevent breaking changes.

Sit #1: Polymorphism in OOP.

In software circles, hardcoding a condition with an if statement is often considered a bad practice. It can lead to brittle code that's hard to maintain. Yet, in small to medium-sized businesses, where budgets and timelines are tight, a single if statement might solve a customer's issue in minutes. When a high-value client requests a specific customization, writing an elaborate, reusable abstraction using polymorphism might be overkill.

What? Breaking the rules is something to be done in no case at all? Try to be a 50-people business being asked by a 100.000+ employee Mega Corp to add some Confetti in the intranet you developed for them. What? You don't want to? Well, read the 452-page contract you blindly signed again and look at the penalty you should pay in case you don't do it respecting the SLA.

The key, here, is understanding the trade-offs:

Short-term gain: Immediate satisfaction of the client's need.
Long-term cost: Potential maintenance issues as more customizations pile up.

Sit #2: Comprehensive unit testing.

The pursuit of 100% test coverage is another example where pragmatism trumps dogma. While comprehensive testing is valuable, focusing on critical paths — like the checkout flow in an e-commerce app — often delivers more ROI (Return of interest) than exhaustive tests for minor features. In my article, The Truth About Test Coverage, I try to demonstrate how understanding the limits of metrics like coverage leads to better decision-making.

Sit #3: Event-driven architecture.

Event-driven architecture (EDA) is a powerful paradigm for building scalable, decoupled systems. However, using events everywhere can lead to unnecessary complexity in small applications. Even in distributed systems, many interactions might be synchronous, making RESTful APIs a more straightforward choice. The opposite is also true: in a monolithic application, finding a use case for asynchronous communication might bring huge value, even if that would mean breaking the "monolith" rule.

Sit #4: Contract Testing.

Contract testing is a methodology that ensures APIs adhere to a predefined contract. The standard approach involves manually defining these contracts, which can be time-consuming and error-prone in legacy codebases. Instead, in Iterative Contract Testing, we leveraged API responses themselves to generate contracts dynamically. This fit reduced overhead while maintaining reliability.

By introducing patterns like optimistic schema updates, we sidestepped the initial burden of mapping every API. While this approach might not suit every scenario, it exemplifies how bending traditional practices can yield substantial benefits in specific contexts.

Rules, Exceptions, and the Pragmatic Architect.

Pragmatism in architecture isn't about ignoring the rules; it's about knowing when to break them.

Why Rules Aren't Always Universal.

The debate between sits and fits ultimately boils down to trade-offs. Blindly following best practices can lead to inefficiencies, while ignoring them entirely invites chaos. The art of software architecture lies in discerning the appropriate path for a given context.

Over-Engineering as a Pitfall of Sits.

Over-engineering occurs when solutions are designed with more complexity than necessary. This often stems from an overzealous application of best practices. For instance, implementing a microservices architecture for a small application can introduce unnecessary overhead in deployment, monitoring, and debugging.

Strategic Fits in Action.

Conversely, there are scenarios where unconventional approaches shine. In Asynchronous Batching, grouping requests in Node.js with Fastify provided a lightweight solution to repetitive tasks, reducing computational waste. While it deviated from traditional REST principles, it delivered exceptional performance improvements.

Tracking Technical Debt in Fits Scenarios.

When breaking traditional rules in favor of a fits approach, one of the most significant risks is the accumulation of technical debt. To mitigate this, I've developed a habit of documenting these decisions through a lightweight version of Architecture Decision Records (ADRs). These simil-ADRs act as living documentation, capturing the rationale behind the deviation and providing a roadmap for revisiting the decision in the future.

Each simil-ADR includes:

Context and Problem Statement: Why the fit was chosen over the sit.
Considered Options: What was done and how it deviates from standard practices.
Outcome: Notes on whether the deviation served its purpose or needs to be readdressed.

By maintaining this practice, I ensure that deviations are not forgotten but become part of a larger strategy. Revisiting these records allows me to assess whether they should be rectified to align with long-term goals or kept as-is because they fulfill their specific purpose effectively. This approach keeps the balance between pragmatism and architectural integrity.

Intentional Governance in Software Architecture.

One fundamental yet often overlooked aspect of effective architecture is the practice of intentional governance. Governance ensures that architectural decisions align with business goals and technical needs while maintaining the flexibility to adapt to changing circumstances.

Intentional governance involves defining clear principles and boundaries without overburdening teams with unnecessary restrictions. For instance, rather than mandating the use of a specific technology stack across all projects, governance might focus on broader objectives like ensuring security, scalability, and maintainability. This approach empowers teams to make context-sensitive decisions while adhering to overarching architectural goals.

Core aspects of intentional governance include:

Guiding Principles: Establishing high-level rules that teams can interpret based on their specific contexts.
Decision Frameworks: Providing tools or processes, like Architecture Decision Records (ADRs), to document and evaluate trade-offs.
Continuous Review: Regularly revisiting decisions to ensure they remain aligned with evolving goals and constraints.

By practicing intentional governance, organizations can strike a balance between consistency and adaptability, fostering innovation while maintaining structural integrity.

Thank you, Alessandro Cappellozza, for this amazing representation.

Conclusion.

The Pragmatism Test.

When deciding between sits and fits, consider the following questions:

What is the immediate goal? Does this decision help achieve it?
What are the long-term implications? Will this create tech debt that's difficult to resolve?
Does the deviation simplify or complicate the system? Simplicity should be a guiding principle.

Luciano Mammino, a dear friend of mine, suggested to include this awesome article which explains the Amazon model, which I suggest as an addition to this test: One-way vs Two-way door decisions

See you in the Next One.

In software architecture, both sits and fits have their place. The key is not choosing one over the other but understanding when to lean on foundational principles and when to adapt them to the context. This balance - the pragmatism in architecture - separates competent developers from great architects.

As Mark Richards and Neal Ford remind us: "Everything in software architecture is a trade-off." Embrace that reality, and use it to guide your decisions.

Obvious things are always useful, especially when they are not obvious.

The alternative to roadmaps

Michael Di Prisco — Sat, 05 Oct 2024 10:45:00 +0000

The Problem with Roadmaps

I recently read a very interesting article by Marty Cagan against the concept of Roadmaps, called "The alternative to Roadmaps".

In short, Marty Cagan proposes a mixed concept of Product Vision and Team Objectives accompanied by OKRs to achieve, allowing teams to be autonomous about how to achieve certain objectives, something that a Roadmap, in itself, does not allow.

Personally, I believe that a Roadmap is not the right way to allow a company to be agile, and in this respect I agree with Marty Cagan.

At the same time, however, I understand its importance in terms of business. Answering the question "when will you give me my money back with interest?" can make the difference when looking for investors. Additionally, a Roadmap can be useful for communicating to customers what to expect in the future, and for giving direction to development teams.

The problem, as Marty Cagan points out, is that a Roadmap provides the what, but does not explain the why, removing the possibility for the teams to be autonomous.

Marty Cagan's idea is to make the team aware of the why of a project, and to let the teams themselves decide the what.

My opinion

I don't have a clear idea yet, but I think that the concept of Innovation Tokens introduced by Dan McKinley in his article Choose Boring Technology can be applied in reverse.

What do I mean? That we could have Roadmap Tokens, which allow development teams to decide for themselves what to develop, but at the same time allow the company to have a vision of what to expect in the future.

In the next quarter we have to develop 17 new features? Well, we have 4 Roadmap Tokens, which means we can take any four of these initiatives and decide to change them on the fly, adapting to market needs or business changes. Sometimes we will keep the goal but change the way to achieve it, other times we will change the goal itself. Having a limited number of Tokens allows us to maintain some control over initiatives, but at the same time allows teams to be autonomous.

The quiet, pervasive devaluation of frontend

Michael Di Prisco — Tue, 01 Oct 2024 07:00:00 +0000

Premise

What follows is a response to the beautiful article by Josh Collinsworth that you can find here.

I decided to structure this content by taking each summary quote he makes in his article and responding to each of them with my opinion.

This article is therefore to be considered a series of ideas that identify a personal opinion. Of the 12 quotes reported, I found myself agreeing with ✅ 8 of them, disagreeing with ❌ 3 and having no opinion on 🟡 1.

[TL;DR] I generally agree with the author’s opinion and his point of view, although in some cases the distorted view created by the article has led me to disagree with some statements. The analysis on prejudice has caused, in my opinion, just as much prejudice towards the world of development on the part of the author.

I feel like I’m seeing a widespread diminishment of the practice of frontend. Nearly everywhere I look, I notice its importance minimized, and its challenges trivialized.

✅ I fully agree with this statement.

The frontend has for too long been considered the “little brother” of the backend, and this is a mistake. The frontend is the part of an application that the end user sees and interacts with, and is therefore fundamental to the success of a product. Its importance cannot be underestimated, yet this happens too often, and I myself have sometimes considered my work as a frontend developer “inferior” to what I did in the backend.

Why does this happen? From my point of view, I believe it is because in the last decade the world of frontend development has been invaded by frameworks and libraries that have made work simpler and more accessible to everyone. This has led to responding to many of the problems that arose in the past, leading frontend development to become “simpler”. This has led to a devaluation of the role of the frontend developer, who is often seen as a “code monkey”. Simple, however, does not mean easy, and the frontend developer is often called upon to solve complex problems and make important decisions, precisely because he or she is no longer expected to resolve “simple” problems, already solved by the framework, but rather to enrich the user experiences in new and innovative ways.

It’s like CSS exists in some bizarre quantum state; somehow both too complex to use, yet too simple to take seriously, all at once.

✅ Here too, I agree.

CSS is one of the most underrated and devalued languages in the world of web development. CSS is a powerful and complex language, which allows you to create complex and detailed user interfaces. However, the distance from the normal way of writing code, its particular syntax and its operating logic often make it difficult to master and use. CSS is a language that requires time and dedication to master, and what happened with the CSS-in-JS movement is a clear example of how the community tried to solve a problem that didn’t exist by creating a new one, while also adding abstraction to an already very complex language.

In many ways, CSS has greater impact than any other language on a user’s experience, which often directly influences success. Why, then, is its role so belittled?

✅ I agree.

As mentioned in response to the previous quote, I believe that the problem with CSS is due to its operating logic and its particular syntax. The problem is that it is often seen as a “secondary” language compared to JavaScript, when in reality it is a language in itself, with its rules and peculiarities, and requires a learning time comparable to that of a programming. CSS is a powerful and complex language, and its role cannot be underestimated.

Mostly, nobody actually says frontend is less important, or less real, or that you don’t have to be as smart to do it. But it often seems to be implied.

✅ I partially agree.

To tell the truth, I see this theme as much more explicit than the author says. In fact, I often find myself having to debate with people who consider the frontend to be a “minor” job compared to the backend, and who believe that the frontend developer should not be a programmer, but a support to those who do the real work, the backend. When they ask me what my role is, I always answer Full-Stack, because in my training and growth there are various and different elements, and both sides of the coin have been important and significant for me.

I believe the community needs to do more to eradicate this mentality. The frontend developer is a professional in all respects, and his work is fundamental to the success of a product.

The frontend developer is called upon to solve complex problems, supported by constantly evolving tools — which greatly increases the cognitive load — and to make important decisions that directly influence the user experience, the bulwark of a successful product.

Our output is artistic, to some degree, and artistic things have a long, storied history of being tragically devalued merely because they seem simple and enjoyable.

✅ I agree.

Lack of understanding of roles and responsibilities plays a fundamental role in our industry. The frontend developer is often seen as an “artist”, a “creative”, and his work is devalued because it is not “technical” like that of the backend developer. This is a mistake in two respects.

First of all, it is often not the frontend developer who decides the design of an application, but the designer (UX, UI, call it what you want). The frontend developer is called upon to translate the design into code, and to do so in an efficient and high-performance way. This requires technical skills and specific knowledge, which go far beyond simply writing code.

Secondly, as already mentioned above, the responsibilities of a frontend developer often go far beyond simply writing code. If I modify code in my backend application, the automatic tests will most likely notice any regressions sooner than I can. If I modify code in my frontend application, it is very likely that the only way to notice any regressions is to manually test the application or wait for a report from end customers*. This makes the frontend developer’s job much more complex and demanding than one might think. Not to mention the amount of business logic and state management — both promptly poured into the frontend — which make the role increasingly integrated with the business.

*Note: I am well aware of the existence of end-to-end tests, but their implementation is much more complex and expensive than traditional automatic tests, furthermore their reliability is often questioned due to their random and external conditions.

The language implies interfaces are decoupled from the software, and not an actual part of it.

🟡 No opinion on this.

The reference here is to the paradox whereby in our sector there seems to be a difference between Developer and Engineer and which must necessarily be shown as something more. I have no opinion on the matter, but I agree that nowadays the proliferation of titles and banners does nothing but muddy the waters with respect to what each of us actually does.

Writing CSS seems to be regarded much like taking notes in a meeting, complete with the implicit sexism and devaluation of the note taker’s importance in the room.

✅ I agree.

As already mentioned previously in this article, I agree about the incorrect devaluation of CSS and the frontend world in general. Furthermore, in this part of the article, reference is made to the chauvinism present in our sector, and although I have never had a direct perception of it, I understand its reality and gravity. Our industry is still too often a hostile environment for women, and I believe the community needs to do more to combat this mentality.

As though the nearly impossible job of supporting every possible device, operating system, screen size, browser, user preference, and interface in the past, present and future is so simple we invented all the complexity ourselves, just because we were bored.

✅ I agree with the intrinsic meaning of this statement.

The complexity of today’s world makes the role of the frontend developer even more complex than it has ever been, and when frontend jokes and punchlines become bias, it’s easy to fall into the trap of devaluing the work of frontend workers.

Yes, as a group, we get excited about new things. But why doesn’t that make us curious, or adaptable, or inquisitive? Why don’t we get credit for our joy of learning, instead of denigrated for refusing to stay in place?

❌ I agree less with this one.

Although it is true that the evolution of the frontend world — as already mentioned previously — has led to a proliferation of ideas, tools and methodologies, Shiny Object Syndrome is a real and widespread problem, especially in the frontend community. This doesn’t mean that you shouldn’t be curious or adaptable, but that you often fall into the trap of adopting new technologies without fully understanding the pros and cons, and without evaluating whether they are actually necessary or not.

If our skills are valuable as duct tape over the cracks of organizational shortcomings, why aren’t they valuable during the planning and decision-making that led to those defects, when we could potentially prevent them?

✅ Totally agree.

Exactly as a Software Architect (Or Tech Lead, or whoever is in charge of the architecture) must involve every member of the team in the architectural choices — despite having the last word and ultimately the responsibility over them -, also the decision-making process that leads to the creation of an application or part of it should involve every member of the team, including frontend developers. Those who have been doing this long enough may be able to find gaps in the user experience or design that others wouldn’t see, and involving them in the decision-making process can lead to a better user experience and a successful product.

Frontend tools market themselves as though frontend is something no one wants to do, and nobody should care about any more than they have to.

❌ You can clearly see the frustration increasing as the post develops, but in this case I can only disagree.

The marketing — as Josh defines it — of frontend tools has never trivialized or tried to simplify the challenges of developers, except for a few rare exceptions. These tools increasingly aim to make the frontend developer’s work simpler and more efficient, but never banal, and it is right that the direction remains the same. The promise is never to make the frontend developer a code monkey, but to allow him to focus on what is truly important: the creation of a successful user experience and the impact on the business and the world around him . The same goes for the backend world, where tools have evolved to allow developers to focus on the product, rather than on technical choices or configuration issues.

Finally, let us remember that the world of Developer Relations has developed in a structured manner in recent years, and any missteps by some companies should not be considered the norm.

It seems like nobody thinks of frontend as a critical part of the product anymore; they only think of it as the nice box the product arrives in.

❌ Here too, alas, I disagree with Josh.

The frontend is a fundamental part of a product, and its importance cannot be underestimated, but that doesn’t mean you necessarily have to indulge in complexity and abstraction. Frontend development is already complex enough to not require super-sophisticated design or abstruse architectures, and exactly as in the backend world, standardization, if done with full knowledge of the facts, allows us not to add unnecessary cognitive load and to focus on other aspects of the product.

Inevitabot. A future as inevitable as it is unpredictable.

Michael Di Prisco — Sat, 28 Sep 2024 08:05:27 +0000

Premise

What follows is my personal opinion on what I consider plausible to happen in the not too distant future, it is not a prediction, much less a certainty, and as an opinion it must be taken and evaluated.

As a techno-optimist, I consider technological advancement as a whole to be a positive factor, and as such it must be encouraged and supported, but at the same time, like everything, it must be managed with attention, responsibility and above all: ethics.

Where deemed possible I have indicated a year in which I consider it likely that that specific aspect can be achieved or in any case take a form similar to that described.

Introduction

In the vortex of technological evolution, we are getting ever closer to a future that will radically redefine our perception of work, creativity and even the very concept of intelligence. The evolutions of artificial intelligence (AI) are laying the foundations for an epochal change, where every aspect of our daily lives will be intertwined with the omnipresent presence of algorithms and intelligent machines.

Large Language Models: The first piece.

The advent of Large Language Models (LLM) undoubtedly marks a turning point in the research and development of artificial intelligence, but it is only the first step in a race that promises to be intense and full of developments in the coming years. These models, such as the modern (November 2023) GPT-4, Claude, etc., have demonstrated the extraordinary ability to understand and generate human language at scale, paving the way for multiple applications in areas such as virtual assistance, creation of content, automatic translation and much more.

However, the race to the cutting edge of AI is set to evolve in increasingly ambitious directions. Developers are aiming for even larger and more complex models, capable of learning from more diverse data and understanding increasingly rich contexts. This implies not only an increase in the necessary computing power but also greater attention to training and the quality of the data used to train the models.

A crucial next step will be honing your contextual understanding and continuous learning ability. More sophisticated models will need to be able to understand not only the immediate meaning of words, but also the broader context in which they are used. This will require significant progress in understanding the semantics, irony, and cultural and social nuances that make human language so rich and complex.

The race to the cutting edge will not only be about the size of the models, but also their ability to adapt to specific industries and domains. Customizing and adapting the capabilities of an LLM to specific contexts will become a crucial focus, enabling more specialized and refined applications, such as advanced medical care, personalized scientific research and much more.

At the same time, the research will go beyond language alone. Vision, listening, understanding the environmental context and more complex interactions with users will become key objectives. AI will aim to become increasingly multimodal, integrating different input and output modalities to offer a more complete and natural experience.

In conclusion, Large Language Models represent an excellent starting point, but the race in artificial intelligence is destined to expand, embracing increasingly ambitious challenges and paving the way for a future in which machines will be able to understand and interact with the world more and more like humans.

I believe it is likely that Large Language Models will become less and less impactful and that instead the focus will be oriented towards AGI around 2030–2035.

My prediction is that the Turing Test will become obsolete by 2030 and will be replaced by a more sophisticated test that takes into account what, when the Turing was designed, was considered the limit to overcome.

AGI

AGI, or General Artificial Intelligence, represents the final goal in the field of artificial intelligence as we know it today, characterized by the ability to perform any human intellectual task. AGI is expected to not only reach, but radically surpass the capabilities of current Large Language Models (LLM), bringing artificial intelligence to an unprecedented level of understanding and adaptability.

LLMs are known for their exceptional ability to understand and generate natural language, but they are limited to specific contexts and do not have a deep understanding of the physical world or human interactions beyond text. AGI, in contrast, aims to overcome these limitations, demonstrating intelligence that can be generalized across a wide range of tasks and situations.

One of the key challenges in the transition to AGI will be acquiring a broader and deeper understanding of the context. The AGI should be able to extract knowledge from various sources, understand complex relationships between concepts, and apply their learning to new situations in a flexible way. While LLMs excel at manipulating language, AGI will extend to a wide range of sensory input and complex information from different sources.

Furthermore, AGI will feature an advanced form of machine learning and self-improvement. This ability to continuously learn and improve its performance over time is a key element in building general AI. LLMs are powerful in their ability to learn from large datasets, but AGI will need to go further, actively adapting to new information and improving their understanding and performance on their own.

Another crucial aspect is the ability to interact in a more sophisticated way with the physical environment and with humans. AGI should demonstrate social intelligence, understanding emotions, responding to nonverbal cues, and adapting to the nuances of human interactions. This represents a significant challenge compared to current language-focused models.

In conclusion, while the current Large Language Models represent a significant step in the evolution of artificial intelligence, AGI is destined to radically surpass them, bringing AI to a level of complexity and understanding that will radically transform our conception of artificial intelligence and its applications. The road to AGI will be characterized by technical, ethical and social challenges that will require prudent management to ensure sustainable and responsible benefits.

My prediction is that we will reach AGI by 2040, but that it will still not be able to surpass human intelligence, although it will come very close. This will happen, in my opinion, not before 2045.

Work

The traditional concept of work may gradually give way to an era in which employment is more like a paid hobby than a monotonous duty.

The automation of repetitive tasks and the efficiency of machines in performing specific tasks will free individuals from a tiring routine, allowing them to focus on more meaningful and personally rewarding activities. The evolution of AI could transform the very nature of work, pushing society towards a model in which creativity and innovation are key values.

My prediction is that work as we know it today will be obsolete by 2050, and that by 2100 no one will be working the traditional way anymore. The period is deliberately broad as the cultural change will be so drastic that it will require a generational change or two to assimilate.

Creativity

The future of creativity stands out as an evolving landscape, in which humans continue to hold the helm, despite witnessing a radical transformation that recalls, in a singular way, the roots of the past. While artificial intelligence and advanced technologies will profoundly influence the creative process, we are likely to see a rebirth of the fundamental principles of human inspiration.

In this scenario, human creativity will be more than ever a deliberate choice, a manifestation of our intrinsic capacity to imagine, innovate and express emotion. While machines can generate creative content based on models and data, the essence of human inspiration will remain irreducible to an algorithm. Art, literature, music and all forms of creative expression will retain the distinctive touch of human individuality, a signature that no algorithm can fully replicate.

We may witness a return to more traditional creative practices, inspired by manual skills and craftsmanship. Nostalgia for manual workmanship and craftsmanship could become a source of inspiration, causing people to seek a return to concreteness and authenticity in an increasingly digital world. Creativity could be shaped by a fusion of ancient and modern, incorporating age-old techniques with the possibilities offered by advanced technology.

However, as humans rediscover the roots of creativity, technology can still serve as a catalyst and amplifier of their ideas. Advanced tools can be used as a means to explore new creative frontiers, experiment with new media and take art to levels never seen before.

Ultimately, creativity in the future will remain a deliberate act of human beings, an articulation of our uniqueness and our ability to adapt to evolving challenges. The synthesis of ancient and modern could shape a creative landscape that celebrates human diversity, recognizing that creativity is, and will continue to be, an intrinsic trait of our species.

Education

The future of education promises to be a field of radical change, a place where the focus will shift from technical skills to an education more focused on humanistic, philosophical and artistic disciplines. In an era in which artificial intelligence and advanced technology will assume a predominant role in technical skills, the human essence will be increasingly reflected in subjects that challenge creativity, critical reflection and self-understanding.

The humanities will become key pillars of education, encouraging students to explore history, philosophy, literature and the arts. These subjects not only offer a critical perspective on past and present human experiences, but develop analytical, communication and critical thinking skills that are fundamental to tackling the complex challenges that the future will face us.

Philosophy, in particular, could emerge as a focus of education, stimulating critical and ethical thinking. In a world where decisions are increasingly influenced by algorithms and machines, philosophy will be able to offer a framework for addressing ethical and moral issues related to the use of artificial intelligence and advanced technology.

Artistic disciplines, including music, painting, theater and other creative expressions, will be integrated into the fabric of education to cultivate aesthetic sensitivity and stimulate individual creativity. Culture and the arts will become vehicles for exploring human diversity, promoting understanding and empathy between individuals of different origins and perspectives.

In this scenario, education will not only be a vehicle for acquiring specific knowledge, but also and above all an opportunity to develop a deep understanding of oneself and the surrounding world. The radical transformation of education will be a response to the needs of an evolving world, where distinctive human skills will be valued above simple technical knowledge, the domain of machines.

My prediction is that education will never do without technical subjects, but that they will no longer be compulsory by 2060. This ample time arises from the need for a generational change to assimilate such a radical change.

Politics

The future of politics will emerge as a context in which decisions and solutions to problems will be almost totally replaced by an ethical approach and conscious control of technological evolution.

While politics has traditionally focused on solving immediate challenges, the emergence of advanced technologies and artificial intelligence will lead society to reflect on fundamental ethical questions and the long-term implications of using certain technologies.

Controlling technological evolution will become a key responsibility for political leaders. While technological innovation offers extraordinary opportunities, it will be essential to mitigate the risks associated with it. Regulations and policies will need to be proactive in guiding technological development in an ethical way, ensuring transparency, security and accountability regarding new technologies.

The politics of the future will be characterized by greater international collaboration in managing global technology-related challenges, such as cybersecurity, the regulation of new technological initiatives and the management of ethical implications. Joint efforts to establish ethical international standards will help shape a future where technology serves the common good.

In this context, public participation and transparency will be crucial. Policy will no longer be an isolated process but will actively involve civil society, technology experts and affected communities in the decision-making process. The formation of informed and conscious policies will be essential to manage the complex challenges of an increasingly connected and technologically advanced world.

In conclusion, the politics of the future will be characterized by an ethical perspective and the awareness of the need to guide technological evolution in a responsible way. In this way, political leaders will be able to face emerging challenges with a vision oriented towards the common good and long-term sustainability.

My prediction is that in a political context the application of decentralized technologies, not necessarily via blockchain but similar, will first be strongly recommended and then made mandatory with a view to transparency by 2040.

Global Issues

Technological progress, driven by artificial intelligence and its ability to analyze data on a large scale, promises to be the bulwark that will transform our most serious daily problems into distant memories.

Global warming, a phenomenon that has threatened and continues to threaten the stability of our planet, could see a solution through the implementation of advanced technologies to monitor and mitigate greenhouse gas emissions. Intelligent systems could anticipate and manage climate fluctuations, offering preventive strategies that reduce environmental impact.

World hunger, one of the most complex challenges humanity faces today, could be overcome with the help of cutting-edge agricultural technologies. Artificial intelligence could optimize food production, improve distribution and ensure sustainable management of agricultural resources. Advanced monitoring systems, based on real-time data, could predict famines and coordinate timely responses to ensure that no individual goes hungry.

However, as we approach this potentially utopian future, it is crucial to address the ethical and social challenges that accompany the dominance of technology. We will need to ensure that access to these solutions is equitable and that decision-making power is not concentrated in limited hands. Furthermore, we will need to carefully consider the environmental impact of the very technologies we intend to use to solve environmental problems.

In summary, the future in which technology proactively prevents global problems may be on the horizon, but it is essential to adopt a holistic approach that balances technological effectiveness with an ethical and sustainable perspective. Only through a collective commitment to drive technological development responsibly can we hope to overcome the most pressing challenges of our time.

The use of the conditional is intentional in this section because although technology could allow such resolutions, politics and people will have to implement them, sometimes even giving up profits. The abandonment of unbridled capitalism is a prerequisite for the resolution of these problems but given today’s society it would be presumptuous of me to assume a plausible date of event.

The truth about test coverage

Michael Di Prisco — Sat, 28 Sep 2024 07:46:17 +0000

A powerful truth.

Look at the following, simple and straightforward code:

function sum(a, b) {
  return a + b;
}

Now, let's write some tests for it:

test('sum', () => {
  expect(sum(1, 2)).toBe(3);
  expect(sum(2, 3)).toBe(5);
  expect(sum(3, 4)).toBe(7);
  expect(sum(4, 5)).toBe(9);
});

We got 100% coverage, right? Well, yes, we do, in fact we could say we got 400% coverage as all the code is fully tested 4 times, but do we?

The truth is that we don't. We are testing the function with a limited set of inputs, and we are not considering edge cases, nor we are testing the function with invalid inputs.

Consider the following:

sum(1, '2');
sum(1, null);
sum(1, undefined);

What would happen in such a scenario? Would the function throw an error? Would it return a value? Would it break our application?

Be aware of the test coverage trap.

Test coverage is a powerful tool, but it's not the ultimate solution. It's a metric that can help you understand how much of your code is being tested, but it doesn't tell you how well it's being tested.

Test coverage can help you with quantity, but it can do little with quality. It's up to you to write good tests, to consider edge cases, to test your code with invalid inputs, and to make sure that your tests are meaningful and valuable.

Conclusion

This was a pretty short article, I admit, still, I hope it was useful to you as a reminder of the importance of writing good tests. Remember, test coverage is a tool, not a goal. It's up to you to make the most out of it.

Ciao,

Michael.

Celebrating 2000 Followers on Dev.to 🎉

Michael Di Prisco — Sat, 17 Aug 2024 13:47:52 +0000

Less than a year ago, I was celebrating my first thousand followers on Dev.to and I just noticed I reached 2.000 some days ago!

I won't repeat myself, many thanks to everyone of you for this little, but important milestone.

Let's go for the next thousand!

Node.js did not implement TypeScript

Michael Di Prisco — Thu, 15 Aug 2024 20:03:28 +0000

A brief article on the reasons why Node.js did not implement TypeScript.

First things first

What follows is an explanation of what has been and what has not been done in Node.js regarding TypeScript.

This article is not intended to be a criticism of the Node.js team or the TypeScript team.

In fact, it's quite the opposite.

I seriously think the Node.js team has made the best possible choice in "implementing" TypeScript the way they did.

What I'm really stressing here is that Node.js did not implement TypeScript. They just added some sort of support for it. This is a crucial distinction that I think is often overlooked in discussions about Node.js and TypeScript.

In the last couple of weeks, I counted more than 50 articles cited in newsletters I read that mentioned Node.js implemented TypeScript.

I think it's time to clarify this point once and for all.

Spoiler alert: Node.js did not implement TypeScript.

TypeScript: a brief history and some data

In 2010, Microsoft released TypeScript, a superset of JavaScript that adds static typing to the language. TypeScript was designed to address some of the shortcomings of JavaScript, such as the lack of type safety and the difficulty of maintaining large codebases. Since its release, TypeScript has gained popularity among developers, with many projects adopting it as their primary language.

As per the latest State Of JS Survey TypeScript is pratically everywhere. 78% developers uses TypeScript for at least 50% of their development time, so no wonder the echo of "Node.js implemented TypeScript" reached even the most profound corners of the web.

But, just to be clear, it didn't happen. And it probably never will.

The issues

There are several reasons why Node.js did not implement TypeScript. Here are what I think are the two most important ones:

#1: TypeScript injects things at runtime.

Did you know what an enum becomes at runtime? An object.

And this is just one of the - luckily - few examples of how TypeScript injects things at runtime. This is a problem for Node.js because it would mean that the runtime would have to be aware of TypeScript's features, which would introduce a lot of complexity and overhead.

If Node.js wants to keep its consistency with ECMAScript and not having to deal with dependency management for the rest of its existence, it can't accept TypeScript as a dependency in the current form.

#2: Semantic Versioning.

TypeScript doesn't follow semantic versioning (semver).

Node.js, on the other hand, follows semver strictly and has three different release lines (Currently, we have 18.x, 20.x, 22.x). This means that breaking changes can be introduced in minor or patch releases, which can cause compatibility issues with existing code.

Also, the amount of supported platforms is huge, so it's not easy to keep everything in check.

Node.js simply can't accept TypeScript as a dependency because it would break semver. This is a fundamental issue that prevents Node.js from implementing TypeScript.

So, what did they do?

This is where the confusion arises. Node.js did not implement TypeScript, but they did add type stripping under an experimental flag. This feature allows developers to write TypeScript code and have it compiled to JavaScript without the type information. This is a compromise that allows developers to use TypeScript in Node.js without introducing the issues mentioned above.

Do you want an example? Here you go:

function sum(a: number, b: number): number {
  return a + b;
}

This function, when compiled with the --experimental-strip-types flag, will become:

function sum(a        , b        )         {
  return a + b;
}

Did you see that? The types are gone and have been replaced by spaces. But, why?, you might ask. Well, because doing so preserves sourcemaps references without the hassle of having a separate build process for those.

Internally, this is done via a package called amaro which wraps swc — a well-known build tool which does the actual stripping.

Of course, limitations exist, such as the inability to use TypeScript-specific features like the before-mentioned enums. But still, it's a big step forward to prevent people from writing 135 config files to make a sum function accept two numbers and return a third one.

Ciao,
Michael.

DEV Community: Michael Di Prisco

Thanks Captain Obvious - Just Don't Be An A**hole

Leadership advice is everywhere, but.

The Ridiculous Obviousness Behind Leadership Advice.

Leadership Isn't Learned - It's Revealed.

Some Real Examples (a Bit Too Real).

When someone delivers poor work

When a junior makes a mistake

When the team is drowning

Why Don't More People Do This Then?

The Ironic Twist.

Conclusion.

Build a Rocket with LEGOs

Introduction

Complexity Is Not a Badge of Honor

A practical example

Great Developers Are Systems Thinkers

How to train your mind to think like this?

Skills to Cultivate

How to cultivate this mindset in a team?

"What if the system has to be complex?"

Final Thought

Stay in the problem space.

When a problem isn't clear, the solution can't be either.

Problem First, Solution Later

How Product Teams Can Enable Engineers

Bridging Software Engineering and Product Management

Avoiding Over-engineering

Practical Tips for Staying Problem-Focused

Conclusion

Authority and Accountability

Introduction

The Leadership Paradigm Shift

Trust and Responsibility

Challenges of This Approach

The Tech Lead's Role

Conclusion

My latest fatigue!

What Sits And What Fits.

Michael Di Prisco ・ Jan 24

What Sits And What Fits.

Introduction.

The Value of "Sits": Structure and Scalability.

Consistency Across the Board.

Maintainability Through Clear Rules.

Scalability: Building for Growth.

When Fits Prevails: Breaking Rules for Context.

Examples of Sits and context-specific Fits.

Sit #1: Polymorphism in OOP.

Sit #2: Comprehensive unit testing.

Sit #3: Event-driven architecture.

Sit #4: Contract Testing.

Rules, Exceptions, and the Pragmatic Architect.

Why Rules Aren't Always Universal.

Over-Engineering as a Pitfall of Sits.

Strategic Fits in Action.

Tracking Technical Debt in Fits Scenarios.

Intentional Governance in Software Architecture.

Conclusion.

The Pragmatism Test.

Other Powerful Questions to Ask.

See you in the Next One.

The alternative to roadmaps

The Problem with Roadmaps

My opinion

The quiet, pervasive devaluation of frontend

Premise

I feel like I’m seeing a widespread diminishment of the practice of frontend. Nearly everywhere I look, I notice its importance minimized, and its challenges trivialized.

It’s like CSS exists in some bizarre quantum state; somehow both too complex to use, yet too simple to take seriously, all at once.

In many ways, CSS has greater impact than any other language on a user’s experience, which often directly influences success. Why, then, is its role so belittled?

Mostly, nobody actually says frontend is less important, or less real, or that you don’t have to be as smart to do it. But it often seems to be implied.

Our output is artistic, to some degree, and artistic things have a long, storied history of being tragically devalued merely because they seem simple and enjoyable.

The language implies interfaces are decoupled from the software, and not an actual part of it.

Writing CSS seems to be regarded much like taking notes in a meeting, complete with the implicit sexism and devaluation of the note taker’s importance in the room.

As though the nearly impossible job of supporting every possible device, operating system, screen size, browser, user preference, and interface in the past, present and future is so simple we invented all the complexity ourselves, just because we were bored.

Yes, as a group, we get excited about new things. But why doesn’t that make us curious, or adaptable, or inquisitive? Why don’t we get credit for our joy of learning, instead of denigrated for refusing to stay in place?

If our skills are valuable as duct tape over the cracks of organizational shortcomings, why aren’t they valuable during the planning and decision-making that led to those defects, when we could potentially prevent them?

Frontend tools market themselves as though frontend is something no one wants to do, and nobody should care about any more than they have to.

It seems like nobody thinks of frontend as a critical part of the product anymore; they only think of it as the nice box the product arrives in.

Inevitabot. A future as inevitable as it is unpredictable.