DEV Community: Alfred Okedi

The Tech Gods Are Just Products

Alfred Okedi — Thu, 31 Jul 2025 21:28:04 +0000

This morning, I woke up with a strange, unsettling thought:
What if Elon Musk, Bill Gates, Mark Zuckerberg, Steve Jobs, Larry Page, Sergey Brin - the tech gods aren’t really who we think they are?

What if they’re not gods at all?
What if they’re just products?

The Myth of the Tech Genius

We’ve been fed the same story again and again. The brilliant dropout. The visionary founder. The misfit in the garage who ends up changing the world. These stories have been told so many times, in books, on TED stages, in Netflix documentaries, that they feel like truth. They’re not just success stories - they’re cultural scripture.

We’re told these figures succeeded because they were smarter, faster, and bolder than everyone else. Because they 'thought different.'
But step back, and the cracks in the myth start to show.

Systems Make the Individual

Behind every so-called tech genius is a system:

Elite institutions like Stanford, Harvard, MIT.
Wealthy families or early access to technology.
Networks of investors, incubators, and advisors.
Cultural timing that rewards specific ideas at specific moments.

Bill Gates had early access to computers at a private school in the 1960s. Steve Jobs was mentored by engineers at HP. Elon Musk came up during a time when clean energy and Mars colonization were just becoming viable (and marketable). Zuckerberg built Facebook in a Harvard dorm, but the infrastructure to scale it existed long before he wrote the code.

They didn’t build these systems - they used them.
They didn’t emerge from the void - they were shaped by environment, timing, capital, and culture.

In other words, they’re products of their systems.

Manufactured Icons

The tech world needs figureheads. Investors need poster boys. The media loves a good origin story. So we take complexity and reduce it to something easily consumable:

Jobs as the tortured artist.
Musk as the iron-willed futurist.
Gates as the cold-blooded genius.
Zuck as the social-network savant.

But these aren’t complete people - they’re brands.
They’re narratives designed to sell products, raise stock prices, win loyalty, and build empires.

The real work? Often done by teams, by researchers, by people you’ll never hear about.
The genius? Often built on the backs of lesser-known pioneers.

The idea that a single person changed the world with pure brilliance is not just inaccurate - it’s dangerous. It discourages collaboration. It glorifies hustle over ethics. It feeds the myth that you’re either born a genius or you're nobody.

Why This Realization Matters

When we stop idolizing individuals and start examining the systems behind them, everything shifts:

We start asking harder questions. Who gets left out of these narratives? Who’s not in the room when the “next big thing” is being built?
We stop chasing unicorn myths and start thinking about how innovation actually happens - incrementally, collaboratively, and imperfectly.
We realize we’re in a system too. And if we’re not careful, it’s shaping us into products as well - optimized for likes, productivity, and hustle until we’re just another myth in the making.

A More Honest Narrative

What if we stopped looking for the next Steve Jobs, and started building better systems?
What if we stopped telling kids to be the next Elon, and started asking: What kind of world would you design if you had real power?

What if we measured success not by wealth or disruption, but by how well we understood the forces shaping us - and how consciously we shaped them in return?

You Are a Product, Too

If the tech gods are just products, then the logical next question is:
What kind of product is the system making out of you?

Are you designing your life - or are you being manufactured?

Once you start asking that, it becomes harder to sleepwalk through the myths.
It becomes harder to worship icons.
It becomes harder to play someone else’s game.

And maybe - just maybe - that’s the point.

[Boost]

Alfred Okedi — Tue, 01 Jul 2025 05:51:37 +0000

Abdulrahman Alblooshi

Apr 20 '24

That Time I Installed Linux (Again) 🐧

#discuss #linux #productivity #opinion

Comments 2

3 min read

Frontend vs. Backend Dev't: Did We Go Too Far?

Alfred Okedi — Fri, 23 May 2025 06:20:34 +0000

There Was a Time Before Frontend and Backend Development

In the modern world of software development, the divide between frontend and backend seems almost elemental. We speak of the two as if they’ve always existed-opposite sides of a coin, inseparable but distinct. But the truth is, there was a time before this dichotomy existed. To understand where we are now, it helps to look back at where we came from.

The Early Days: Full-Stack by Necessity

In the earliest days of computing, there was no such thing as a "frontend developer" or "backend engineer." There were simply programmers. These were the pioneers who wrote code directly for the machines-often using punch cards or assembly language. If you were programming in the 1960s or 70s, you were responsible for everything. You managed data storage, user interfaces (if any), logic, and often the hardware itself.

Even as higher-level languages like COBOL, FORTRAN, and later C came into use, the notion of application architecture was monolithic. Applications were self-contained and tightly coupled to the systems they ran on. There was little reason to separate concerns into different layers because computing itself was limited to the mainframe or, later, the personal computer.

The Rise of the Web and the Birth of the Frontend/Backend Split

The 1990s brought the World Wide Web-and with it, the seeds of frontend and backend separation. Early websites were static HTML documents, but as interactivity became a demand, scripting languages like JavaScript (for the client) and Perl or PHP (for the server) took hold.

Suddenly, developers had to make a choice: build the interface or handle the data. The "frontend" became the realm of user interaction, design, and layout, while the "backend" evolved to handle business logic, databases, and authentication.

Frameworks like Laravel (PHP), Rails (Ruby), and Django (Python) made the split more explicit, bundling tools for routing, controllers, models-and increasingly, APIs. Laravel, in particular, reinforced this with a dedicated api.php routing file, suggesting a clean, distinct boundary between web routes and API routes.

On the frontend, JavaScript frameworks like Vue and React leaned hard into component-based development, thriving under the assumption that they would always consume data from an API.

The Unintended Consequence: Mistaking API as Architecture

Here’s where things began to fracture. Many developers-especially newer ones-interpreted the API layer not just as a communication mechanism, but as the architecture itself. Laravel’s api.php seemed to suggest that a frontend should always talk to a backend via HTTP, even when they were part of the same app.

This misunderstanding created a pattern of over-architecting introducing new downsides:

1. Complexity Inflation

Projects that could have been built as simple monolithic apps are now sometimes split into multiple services by default. This adds complexity in development, testing, and deployment. Over-engineering becomes a trap-more moving parts, more coordination, more potential for failure.

2. Communication Overhead

When frontend and backend teams are siloed, communication becomes a bottleneck. Mismatched expectations, poorly documented APIs, and long feedback loops can turn collaboration into friction. Instead of streamlining development, specialization sometimes slows it down.

3. Loss of Product Ownership

In hyper-specialized environments, developers may only see a narrow slice of the product. This can lead to a loss of holistic understanding. A frontend developer might not grasp why certain backend limitations exist, while backend engineers may not fully understand how their choices impact the user experience.

4. Dependency Hell

Frontend projects often rely on backend teams to expose APIs and endpoints, while backend teams depend on frontend teams for real-world usage feedback. When either side gets blocked or delayed, the whole project suffers. Velocity drops, not because of technical difficulty, but because of the artificial barriers between teams.

5. Innovation Bottlenecks

Specialization can breed rigidity. When a problem crosses boundaries-for example, performance issues that touch both client-side rendering and database query structure-it becomes harder to solve. No one team feels fully responsible, and the solution space gets muddled by ownership boundaries.

6. The API as a Misapplied Contract

Originally, APIs were designed for application-to-application communication: backend systems talking to other backend systems-often within the same trust boundary. But with the rigid frontend/backend split, APIs have been pushed into new roles: acting as the sole mediator between client and server.
This shift introduced several unintended consequences:

Security Risks: APIs exposed to frontend clients (especially public APIs) increase the attack surface dramatically. Many weren’t built with the granularity or authorization controls necessary for direct user access.
Performance Overheads: APIs originally meant for machines are now consumed by browsers and mobile apps, introducing inefficiencies like over-fetching or under-fetching data, leading to awkward compensations in the frontend.
Versioning Nightmares: Once APIs become public-facing, they need to be treated like products themselves-with documentation, backward compatibility, and support cycles that add long-term maintenance burden.
Architecture Misalignment: Teams start designing backends “API-first” to cater to the frontend, rather than based on system logic or data flow needs. This can distort the architecture in ways that are difficult to undo.

In short, APIs became the boundary not because it made sense architecturally, but because the frontend/backend model demanded it.

A Return to just Stack?

Interestingly, we may be coming full circle. The rise of frameworks like Next.js and Remix is blurring the lines again. Serverless computing, edge functions, and tools like Supabase and Firebase are reducing the backend burden on frontend developers. Conversely, backend developers are now using tools like Tailwind and HTMX to push logic closer to the UI.

Laravel's Quiet Reversal-and Vue’s Similar Shift

In a subtle but significant move, Laravel recently made the api.php file optional. While Taylor Otwell hasn’t publicly framed this as a philosophical pivot, the message is clear: not every app needs to be API-first. The separation is a choice, not a requirement.

This echoes a broader shift in the frontend world. Vue-once a poster child for building SPAs that exclusively consumed APIs-is also emphasizing tools like Inertia.js and full-stack rendering.

These approaches reduce the distance between frontend and backend logic, encouraging a more cohesive experience.

This quiet course correction from both camps suggests a realization: we may have trained developers into false complexity.

In essence, we're seeing a return to a more unified way of thinking-not unlike the early days, but now empowered by decades of progress and abstraction.

Conclusion

"There was a time before frontend and backend development" isn't just a nostalgic statement. It’s a reminder that technological boundaries are not static. They're shaped by tools, user needs, and the relentless push for better experiences.

The frontend/backend model brought much-needed structure to a rapidly growing discipline. But like any model, it’s only useful when applied thoughtfully. When overextended-especially through an overreliance on APIs not designed for frontend exposure-it can introduce more friction than it resolves.

As technology continues to evolve, we may find that breaking down these boundaries, or at least softening them, leads to more elegant, secure, and user-centered software systems.

What the Timescale License Means for Database Administrators in the Cloud Era

Alfred Okedi — Sat, 12 Apr 2025 08:23:55 +0000

You're responsible for reliability, performance, and compliance. So when a database vendor introduces a custom license, what does that really mean for you?

As a database administrator, you’ve got a long list of priorities: uptime, scalability, query performance, cost-efficiency, data governance, vendor relationships—the works.

And in this landscape, open-source databases have long been the go-to. They offer freedom, transparency, and control. But now, with the rise of cloud-first everything, we’re seeing a shift: more and more open-source projects are adopting non-OSI licenses—like the Timescale License (TSL).

So what is the Timescale License?
Why did Timescale adopt it?
And most importantly: what does it mean for DBAs like you?

Let’s break it down.

First, a Quick Primer: What Is TimescaleDB?

If you’re not already familiar, TimescaleDB is a PostgreSQL-based time-series database built for scale, speed, and SQL simplicity.

It’s widely used for workloads like:

IoT metrics
Application performance monitoring
Financial tick data
Sensor streams
Infrastructure observability

And it powers systems at companies like Comcast, Bosch, Netflix, and DigitalOcean.

Why Timescale Introduced a Custom License

Back in 2018, Timescale made a move that turned heads: they introduced the Timescale License (TSL)—a source-available license designed to address one specific issue:

Cloud providers were monetizing open-source databases without contributing to their development.

This isn’t theoretical. AWS forked Elasticsearch into OpenSearch and began offering it as a managed service, sidestepping Elastic entirely. Similar stories happened with MongoDB, Redis, and others.

The Timescale License was created to prevent public cloud vendors from offering TimescaleDB as a hosted database service, while still giving everyday users, like DBAs and developers, the freedom to run and modify the software.

The Core Principle: No TimescaleDB-as-a-Service

Here’s the TL;DR of the license:

You can use, deploy, and modify TimescaleDB all you want. You just can’t package and sell it as a managed database service.

This matters only if you're in the business of reselling TimescaleDB. If you're using it as part of your infrastructure stack, whether on-prem, in containers, or on the cloud, you're in the clear.

Let’s look at this from your perspective.

What the Timescale License Means for DBAs

✅ You Can Still Do Your Job. Fully.

The TSL allows you to:

Run TimescaleDB in your infrastructure (on-prem or cloud)
Use all its features—including native compression, continuous aggregates, and time-series tooling
Modify the source code for internal needs (bug fixes, patches, extensions)
Deploy at any scale, internally or as part of your SaaS product stack

As long as you’re not offering a hosted TimescaleDB service to third parties, you’re free to go.

🔐 It Helps Protect Against Vendor Lock-In

For many DBAs, “source-available” raises red flags—especially around long-term sustainability or vendor lock-in.

But here’s what the Timescale License doesn’t do:

❌ It doesn’t lock you into proprietary cloud deployment
❌ It doesn’t restrict internal use or self-hosting
❌ It doesn’t prohibit commercial use or embedding in your applications

In fact, it explicitly supports right-to-repair and right-to-improve. If you need to tweak something under the hood, you can. If you want to upstream those changes, you can do that too.

🤝 It Maintains Compatibility with the Open-Source Ecosystem

TimescaleDB builds on PostgreSQL, and none of the core PostgreSQL components are re-licensed. The open-source foundation remains intact. You still get:

Standard PostgreSQL behavior
Compatibility with tools like pgAdmin, Grafana, Prometheus exporters
Extensions support
Transparent data handling

The only differentiation lies in advanced time-series features, like continuous aggregates, compression, and tiered storage—licensed under the TSL.

🚫 The Only Thing You Can't Do

If your company is a cloud provider, or if you're thinking of turning TimescaleDB into a standalone managed service offering (think: your own "Timescale-as-a-Service"), that’s where the restriction kicks in.

You can’t run a hosted TimescaleDB service unless you’re Timescale Inc. or you have an explicit agreement with them.

This is how Timescale funds continued innovation, R&D, and support for the product you're using.

Why This Matters in the Cloud Era

For DBAs working in hybrid or multi-cloud environments, the rules of open-source are changing.

The classic “run it yourself, buy support if you need it” model is being replaced by “click to deploy on someone else’s cloud”—and the business models behind open-source need to adapt.

The Timescale License is one answer to that shift. It ensures that the teams actually building the software (and fielding your GitHub issues) aren’t cut out of the ecosystem by trillion-dollar cloud platforms.

It’s not about limiting use—it’s about preserving sustainability.

TL;DR for Database Admins

Here’s your cheat sheet:

💡 Action	✅ Allowed under TSL?
Run TimescaleDB on-prem or in your cloud	✅
Modify TimescaleDB for internal use	✅
Embed in your own apps or services	✅
Distribute unmodified binaries	✅
Use in commercial software	✅
Offer TimescaleDB as a hosted DB service	❌
Distribute modified source code	❌ (unless upstreamed)

Final Thoughts

As a DBA, your main concern is building reliable, performant, and maintainable systems. The Timescale License doesn't get in your way—it gives you modern time-series capabilities, full control, and source-level transparency, with just one restriction that doesn’t affect 99.999% of use cases.

If anything, it gives you confidence that the company behind the tech has a viable future and a reason to keep improving the database you rely on.

Want to deploy TimescaleDB today? You can. Want to modify it? You’re free to. Just don’t repackage it as a service, and you’re all good.