DEV Community: Cédric Pierre

What Makes a Strong Engineer (Beyond Writing Code)

Cédric Pierre — Wed, 18 Mar 2026 09:35:22 +0000

As a full-stack engineer, I don’t measure engineering strength by how much code I write (AI agents are way faster than me), but by how I handle complexity, make decisions, and build systems that work and last in the real world.

I Think in Systems, Not Features

In most of the projects I had the opportunity to work on, I realized than a common struggle in the lack of long term and global vision. People think in features before thinking in data structures.
I’m convinced that solid foundations are essentials to build a system that can last a decade.

I approach problems by understanding how the entire system behaves, not just individual components.

I Simplify What Others Overcomplicate

Real-world systems are messy: unreliable networks, inconsistent data, edge cases everywhere.

My role is to reduce that chaos into clear, maintainable structures. Removing unnecessary complexity while preserving flexibility.

I Make Decisions Under Uncertainty

There is rarely a perfect solution in production systems.

I’m comfortable making trade-offs, taking responsibility for technical direction, and adjusting when reality proves assumptions wrong.

I Move Fast, but With Intent

Speed matters, especially in product environments.

But I don’t sacrifice long-term stability for short-term delivery. I aim to build foundations that allow systems to evolve without constant rewrites.

I Communicate to Create Clarity

Engineering is not just about solving problems — it’s about making them understandable.

I ensure that decisions, trade-offs, and system behaviors are clear to both engineers and non-technical stakeholders.

Strong engineering is not about knowing everything.

It’s about consistently making the right decisions in complex, imperfect environments and building systems that hold up over time. A good engineer is language agnostic.

Code now. Think later. Suck it up.

Cédric Pierre — Tue, 30 Dec 2025 22:08:51 +0000

AI made execution cheap. Responsibility didn’t.

⚠️ Our industry has a problem.

We increasingly celebrate speed over quality.

Shipping fast is praised.

Launching quickly is admired.

Writing less code is framed as intelligence.

Meanwhile, quality has become:

harder to show
harder to measure
harder to defend

So it slowly disappeared from the conversation.

And when speed becomes the main signal of success,

responsibility quietly fades away.

That’s not an abstract concern.

That’s how fragile systems are born.

Most Developers Are Not Taught to Be Responsible

🧠 I don’t think most developers lack responsibility because they don’t care.

I think they were simply never taught to carry consequences.

From the very beginning, developers are trained to solve problems,

not to live with the impact of their decisions.

At school, in tutorials, in bootcamps, success looks like this:

the code runs
the tests pass
the exercise is validated
you move on

Nothing lasts long enough for responsibility to appear.

Bad decisions have no real cost.

Shortcuts don’t come back to haunt you.

You rarely have to maintain what you built months later.

So an implicit rule settles in early:

If it works, it’s good enough.

Responsibility Requires Exposure Over Time

Responsibility is not something you learn from theory.

It appears when your own decisions come back to you.

When you have to maintain your code months later.

When a shortcut becomes a blocker.

When a vague model turns every change into friction.

When there is no one else to blame.

That’s when responsibility shows up.

Not as a concept.

As a feeling.

Why Solo Projects Often Change Everything

🧱 For many developers, the first real encounter with responsibility happens when they work alone on something that actually matters.

A personal project.

A freelance contract.

A product with real users.

When you’re alone:

there is no spec to hide behind
no architect to blame
no other team to absorb the mess

Every compromise is yours.

Every flaw has your name on it.

The question stops being:

Does this work?

It becomes:

Can I live with this?

Will this hurt me later?

Would I defend this decision under pressure?

That shift changes everything.

What Being Responsible Actually Means

Being responsible as a developer is not about perfection.

It’s not about predicting the future.

And it’s definitely not about writing clever code.

Responsibility is about anticipation.

Not fixing every problem in advance,

but knowing where things can break.

Knowing which assumptions are fragile.

Knowing what will hurt when the project evolves.

A responsible developer doesn’t say:

“We didn’t know.”

They say:

“We knew this was a risk.”

That difference matters.

Responsibility Means Thinking Beyond Yourself

Most code is not written for machines.

It’s written for people.

Sometimes for colleagues.

Sometimes for people you’ll never meet.

Very often for your future self.

Being responsible means asking:

Will someone understand why this exists?
Can this be changed safely?
Is the intent clear, or only the implementation?

If your code only makes sense to you today,

you are exporting complexity to others tomorrow.

Responsibility is empathy over time.

Responsibility Is About Evolution, Not Just Features

Projects rarely fail because a feature is missing.

They fail because evolution becomes painful.

Responsibility means thinking early about:

how the model can grow
where flexibility is required
where rigidity is intentional
which parts must stay simple at all costs

This is not about predicting everything in advance.

It’s about not painting yourself into a corner.

Good systems don’t guess the future.

They tolerate change.

Scalability Is First a Human Problem

📈 Scalability is often reduced to performance.

More users. More data. More throughput.

That’s rarely the hard part.

The real scalability problem is human.

Can new developers understand the system?

Can they reason about it?

Can they change it without fear?

A system that scales technically but collapses cognitively

is already failing.

Responsibility includes thinking about conceptual scalability,

not just infrastructure.

AI Didn’t Remove Responsibility. It Made It More Visible

🤖 AI doesn’t create technical debt.

It accelerates execution.

That’s it.

When systems become messy or fragile,

it’s not because AI wrote the code.

It’s because developers accepted the structure.

AI makes bad decisions cheap to implement.

That makes responsibility more important, not less.

Blaming the tool is easy.

Owning the decisions is harder.

Responsibility Is Preventive Work, Which Is Why It’s Invisible

⏱️ Irresponsibility reacts.

Responsibility prevents.

It removes ambiguity instead of documenting it.

It creates boundaries instead of adding checks everywhere.

It eliminates entire classes of problems instead of fixing symptoms.

When it works:

nothing breaks
nothing goes down
nothing gets noticed

And that’s exactly why it’s undervalued.

Why Responsibility Is Worth It

Being responsible is rarely rewarded immediately.

It slows you down early.

It creates friction.

It forces uncomfortable discussions.

But over time, it pays back relentlessly.

Responsible developers:

write less code
undo fewer decisions
refactor less in panic
move faster as systems grow

They don’t look fast on day one.

They look solid years later.

Final Thought

Responsibility is not a soft skill.

It’s not a personality trait.

And it’s not optional.

It’s a professional stance.

AI didn’t change what developers are responsible for.

It only made it easier to forget.

A good developer doesn’t just make things work.

They make decisions they are willing to own.

And when things break later?

Well.

Suck it up.

🔫Why You Suck at Structuring Data And How to Finally Get Better 💪

Cédric Pierre — Thu, 04 Dec 2025 21:42:08 +0000

Let’s be honest.

Most developers — frontend and backend — suck at structuring data.

Not because they’re stupid.

Not because they’re lazy.

But because the industry taught them to think in screens, not systems.

Once you understand this, everything starts to make sense.

Let’s break the taboo.

1. You think in UI, not in domain

Most devs start from a Figma screen or a quick whiteboard sketch — but rarely from actual business logic.

They ask:

“What JSON do I need for this response?”

instead of:

“What does the underlying domain really look like?”

So the API becomes a reflection of the UI, not of the business.

Your tables, models, and routes start to smell like:

subtitle
isCollapsed
displayOrder
object.with.20.levels.of.depth

That’s not data modeling.

That’s serializing your component tree.

2. You merge unrelated concepts “because it’s easier”

You know this one:

{
  "user": {...},
  "orders": [...],
  "permissions": [...],
  "stats": {...}
}

Congratulations.

You've created a blob API — a JSON smoothie.

It works for one screen.

It dies everywhere else.

3. You don’t separate stable vs unstable structures

UIs change weekly.

Business rules change yearly.

If your API breaks every time someone moves a card in Figma or a customer requests a “tiny change”…

You didn’t build an API.

You built a UI transport layer.

A good data model must survive:

redesigns
mobile apps
partner integrations
analytics
AI
new features
new markets

If it doesn’t survive these → it was never a real data model.

4. You over-aggregate because you’re afraid of making 4 requests

Some developers believe:

“We need one endpoint for the entire page.”

No, you don't.

Making multiple async calls is:

cleaner
more predictable
easier to cache
easier to invalidate
far more flexible

Aggregation is a tool.

Not a default.

5. You don’t understand entities vs projections

This is the root cause of 90% of bad APIs.

Entities = the truth of your business
Projections = reshaped, convenient data for a specific use-case

If you mix them, you get:

UI fields leaking into persistence
domain rules encoded inside components
APIs that break with every design update
models nobody understands anymore

Good developers keep these two worlds separate.

Great developers document the projection boundaries.

6. You never ask the hard questions

The best data architects ask:

What is the source of truth?
What entities actually exist?
What invariants must never break?
Would a mobile app use this?
What happens if the UI changes completely?

If you never ask these questions, you're not modeling — you're sketching.

🔥 So… how do you get better?

Here’s the simple framework that instantly levels up your architecture.

✔️ 1. Model the domain before the API

If you can’t explain the business with boxes on a whiteboard → don’t write the endpoint.

✔️ 2. Keep entities pure

No UI fields.

No layout info.

No Figma-driven naming.

If your database tables look like React components, stop everything and refactor.

If you chose a document database because it mirrors the UI, ask yourself:

“What if there was no UI at all?”

✔️ 3. Prefer multiple granular endpoints

Frontend frameworks are built for composition.

Use them.

Let the UI combine the data.

Don’t let the UI dictate the data.

✔️ 4. Use projections sparingly — and name them clearly

Examples:

/orders → entity
/orders/overview → projection
/dashboard → projection
/users/:id/profile-view → projection

Good naming avoids 80% of confusion.

✔️ 5. Design for multiple frontends

Ask yourself:

Would this structure still make sense if:

I built a mobile app?
A partner consumed the API?
I fed this into an analytics pipeline?
I replaced React tomorrow?

If the answer is no, start over.

✔️ 6. Think in relationships and constraints

A real data model is not:

“Objects with stuff inside.”

It’s:

entities
references
invariants
constraints
timelines
state machines

This is where a developer becomes an architect.

✔️ 7. Simpler is better

Multiple small, meaningful entities are easier to maintain

than one giant “god object.”

✔️ 8. Avoid deep nesting — prefer flat structures

Your API should deliver flat, normalized data.

Let the UI handle grouping, filtering, nesting, aggregation.

Flat data = predictable data.

✔️ 9. Use correct naming — and be consistent

Clear naming saves lives.

UserGroupsResponse is instantly understandable.

If your naming forces people to guess → it’s wrong.

✔️ 10. Anticipate change

Your model will grow.

It will evolve.

It will get more complex.

Design with flexibility in mind.

Future-you will thank you.

🎯 Final message

You don’t suck at structuring data because you’re bad.

You suck because nobody ever taught you to think beyond the screen.

Once you learn to separate:

domain vs projection
entity vs layout
truth vs convenience

…everything becomes easier.

Screens change every week.

Good data structures last a decade.

Consume API's like a Pro with Fluentity 🔥

Cédric Pierre — Tue, 20 May 2025 21:17:42 +0000

Bring Active Record-Like API Consumption to the Frontend with Fluentity, a framework agnostic library written in Typescript.

As developers, we often face the same dilemma when working with APIs:

We want simplicity, type safety, and clean syntax — but most solutions force us to choose between low-level control (like Axios) or heavy abstractions (like TanStack Query).
Some options are really nice but totally glued to a framework, like PiniaORM which works only with... Pinia (Vuejs).

Direct comparison

Let’s say you want to fetch a Comment with id 2 from User with id 1 and update it.

// Fetch the comment
const res = await fetch('/users/1/comments/2')
const comment = await res.json()

// Update the comment
const updateRes = await fetch('/users/1/comments/2', {
  method: 'PUT',
  headers: {
    'Content-Type': 'application/json'
  },
  body: JSON.stringify({
    ...comment,
    content: 'Updated text'
  })
})
const updated = await updateRes.json()

With Fluentity

const comment = await User.id(1).comments.find(2);
await comment.update({content: 'Updated text'});

A bit of context…

Throughout my career, I’ve worked on many different projects — each with its own way of handling API data fetching.

Yet none of them offered a solution that was easy to use, type-safe, reusable, chainable, and framework-agnostic.

As a fullstack developer, I naturally think in objects. That’s why Laravel’s Eloquent, a classic implementation of Active Record, feels so intuitive to me — and I know I’m not alone.

I truly believe Eloquent is a big part of Laravel’s popularity.

So I had an idea: what if we brought the elegance of Active Record to the frontend, for APIs?

That’s how Fluentity was born.

⚠️ Note: This project is still young and actively developed. Feedback is welcome!

What is Fluentity?

Fluentity is a lightweight, framework-agnostic TypeScript library that turns your endpoints into real models — with chainable methods, auto-casting, caching, and strong typing.

It also provides a lot of flexibility, by exposing request and response interceptors, overriding the request handler,...

How to configure Fluentity

Whether you’re working in Vue, Nuxt, React, or any other frontend stack, Fluentity gives you an elegant way to query your API without boilerplate.

Working together

BRO TIP: If your backend is already written in Typescript (NestJS), you can share the DTO between backend and frontend. There's even a way to reuse the same validators!

There's also a CLI tool to allow you to create models or to convert an OpenAPI schema file into Models !

Getting Started

📦 Installation

npm install @fluentity/core
# or
yarn add @fluentity/core
# or
pnpm install @fluentity/core

Enable Typescript decorators:

{
  "compilerOptions": {
    "target": "ESNext",
    "experimentalDecorators": true,
    "useDefineForClassFields": false
  }
}

Configuration

The most basic configuration requires to define the baseUrl.
You can refer to the documentation for more informations.

import { Fluentity, RestAdapter } from '@fluentity/core';

const fluentity = Fluentity.initialize({
    adapter: new RestAdapter({
        baseUrl: 'https://api.example.com'
    })
});

Creating models

Fluentity is inspired by Active Record and Laravel Eloquent.

🧱 Example: User & Media Models

User.ts

import {
  Model,
  HasMany,
  Relation,
  Attributes,
  Cast,
  HasOne,
  RelationBuilder,
  Methods,
} from '../../src/index';

import { Company } from './Company';

import { Media } from './Media';
import { Thumbnail } from './Thumbnail';

import { QueryBuilder } from '../../src/QueryBuilder';

interface UserAttributes extends Attributes {
  name: string;
  phone: number;
  email: string;
  created_at?: string;
  updated_at?: string;
  thumbnail?: Thumbnail;
}

export class User extends Model<UserAttributes> implements UserAttributes {
  static resource = 'users';

  declare name: string;
  declare email: string;
  declare phone: number;

  declare created_at?: string;
  declare updated_at?: string;

  @HasMany(() => Media)
  medias!: Relation<Media[]>;

  @HasMany(() => Media, 'medias')
  libraries!: Relation<Media[]>;

  @HasMany(() => Media, 'custom-resource')
  customResource!: Relation<Media[]>;

  @HasOne(() => Media)
  picture!: Relation<Media>;

  @Cast(() => Thumbnail)
  thumbnail!: Thumbnail;

  @Cast(() => Thumbnail)
  thumbnails!: Thumbnail[];

  @Cast(() => Company)
  company!: Company;

  static scopes = {
    active: (query: RelationBuilder<User>) => query.where({ status: 'active' }),
  };

  static async login(username: string, password: string) {
    const queryBuilder = new QueryBuilder({
      resource: 'login',
      body: {
        username,
        password,
      },
      method: Methods.POST,
    });

    const response = await this.call(queryBuilder);

    return new this(response.data);
  }
}

Media.ts

import { Model, Relation, BelongsTo } from '@fluentity/core'

import { Thumbnail } from './Thumbnail'

export interface MediaAttributes {
    id: string
    name: string
    size: string
    extension: string
    mime_type: string
    url: string
}

export class Media extends Model<MediaAttributes> {
    static resource = 'medias'
}

Thumbnail.ts

import { Model } from '@fluentity/core'

export class Thumbnail extends Model<any> {
    static resource = 'thumbnails'
}

Using Models

Now that the models are created, the hardest part is done! 🍻

const users = await User.all(); // This makes a GET /users and returns an array of User instances.

const user = await User.find(1); // Get /users/1 - return a user instance.

await user.update({name: 'Johana'}); // This send a PUT request to /users/:id

But there is more! Let's try relationships or sub-resources:

Relationships

const medias = await User.id(1).medias.all(); // Get /users/1/medias - return an array of Media object

await media[0].delete(); // DELETE /users/1/medias/1

Conditions:

const users = await User.where({name: 'Johana'}).all() // GET /users?name=johana

Casting:

const user = await User.find(1);
console.log(user.thumbnail); // Thumbnail object

Scopes:

const users = await User.query().active().all() // GET /users?status=active

🚀 Conclusion

With Fluentity, consuming an API feels as natural as querying a database.
You define models once — and enjoy a fully typed, reusable, and object-oriented interface to your backend.

No more juggling between fetch(), Axios, and manually transforming responses.
Fluentity gives you a clean API, inspired by the elegance of Eloquent and Active Record, for the frontend world.

✅ Fluentity: Key Advantages :

Cleaner, declarative code with real models instead of imperative fetch/then chains.
Strong Typing: Safer development and fewer runtime bugs.
Framework-Agnostic: Use it anywhere TypeScript runs, including fullstack apps.
Chainable Query Builder: Express complex queries fluently.
Auto-Casting to Real Instances: Enables object-oriented logic across your app.
No Boilerplate: just define your models.
Customizable & Extensible: add custom scopes
Developer Experience (DX) Focus: Makes your API layer fun and productive to work with.

Bonus

I also created a CLI tool to generate models ❤️

fluentity generate:model [name]

This command will parse an OpenAPI Schema and generates all the models for you:

fluentity parse:openapi [filename]

Checkout this demo with Vue

👉 Star Fluentity on GitHub
🧪 Try it in your next project, and share your feedback!

Cheers,
Cédric

Linkedin
Github