DEV Community: Ibrahima D.

Build a multi-platform Design System, step by step

Ibrahima D. — Mon, 08 Jun 2026 09:11:30 +0000

Let's build a multi-platform Design System, step by step

Web, iOS, Android. One color definition. Changed once, propagated everywhere.

Instead of a theory article, we're going to build a working POC, step by step. By the end, you'll have a mini design system that generates CSS, Swift, and Kotlin from a single source, with two brands, light/dark themes, a demo, and regression tests. All the code is on GitHub — clone it and follow along.

The guiding thread: a design decision should exist in only one place, in a neutral form; everything else is derived from it automatically.

The problem we're solving

Your brand's primary color — a blue — lives in parallel in CSS variables (web), Swift (iOS), Kotlin (Android)… The problem isn't creating those values, it's keeping them in sync over time. One day someone changes the blue on web but not on Android, and the product becomes inconsistent. Multiply by 2 brands and 2 themes: the inconsistency becomes structural.

The root cause: the same decision is copied by hand into different formats. We're going to kill the copy.

Step 0 — The project

mkdir design-system-poc && cd design-system-poc
npm init -y
npm install -D style-dictionary typescript @types/node

Style Dictionary is the reference tool for turning "tokens → multiple targets". Add "type": "module" to your package.json (we write ESM) and a tsconfig.json in strict mode. We code in TypeScript: Node 24 runs it natively (type stripping), so node build.ts works with no compile step — tsc --noEmit is only there for type-checking.

Step 1 — Primitives (the ingredients)

A design token is a name → value pair describing a design intent, independent of any language. We start with the raw palette, with no business meaning.

tokens/primitives.json:

{
  "color": {
    "blue":  { "300": { "value": "#60A5FA", "type": "color" },
               "500": { "value": "#2563EB", "type": "color" },
               "700": { "value": "#1D4ED8", "type": "color" } },
    "green": { "500": { "value": "#059669", "type": "color" },
               "700": { "value": "#047857", "type": "color" } },
    "grey":  { "0":   { "value": "#FFFFFF", "type": "color" },
               "100": { "value": "#F3F4F6", "type": "color" },
               "900": { "value": "#111827", "type": "color" } }
  },
  "space":  { "2": { "value": "8px",  "type": "spacing" },
              "4": { "value": "16px", "type": "spacing" } },
  "radius": { "sm": { "value": "4px", "type": "borderRadius" },
              "md": { "value": "8px", "type": "borderRadius" } }
}

These values "know" nothing about web or mobile. They're the neutral form everything else will derive from.

Step 2 — Semantic tokens (the secret to multi-brand)

The beginner trap: putting #2563EB directly in components. Instead, we create a semantic level that describes usage and points to a primitive (the {color.blue.500} syntax is a Style Dictionary reference).

tokens/semantic.brandA.light.json:

{
  "color": {
    "primary":       { "value": "{color.blue.500}", "type": "color" },
    "primary-hover": { "value": "{color.blue.700}", "type": "color" },
    "on-primary":    { "value": "{color.grey.0}",   "type": "color" },
    "surface":       { "value": "{color.grey.0}",   "type": "color" },
    "on-surface":    { "value": "{color.grey.900}", "type": "color" }
  }
}

The dark theme keeps the same semantic names, but rewires to different primitives — tokens/semantic.brandA.dark.json:

{
  "color": {
    "primary":    { "value": "{color.blue.300}", "type": "color" },
    "surface":    { "value": "{color.grey.900}", "type": "color" },
    "on-surface": { "value": "{color.grey.100}", "type": "color" }
  }
}

And a 2nd brand = just different wiring — tokens/semantic.brandB.light.json:

{
  "color": {
    "primary":       { "value": "{color.green.500}", "type": "color" },
    "primary-hover": { "value": "{color.green.700}", "type": "color" },
    "surface":       { "value": "{color.grey.0}",    "type": "color" }
  }
}

Why this matters: your components reference only color-primary, never blue-500. Switching brand or theme = rewiring the semantic links, without touching a single line of any component.

Step 3 — Generate for each platform

We give Style Dictionary the tokens + the target formats, and it generates the rest. The key point: ship idiomatic code per platform, not raw JSON. An iOS dev wants typed Swift.

We have 3 combinations (brand × theme) to generate, so we loop. build.ts:

import StyleDictionary from 'style-dictionary';
import type { Config } from 'style-dictionary/types';

const combinations = [
  { brand: 'brandA', theme: 'light' },
  { brand: 'brandA', theme: 'dark' },
  { brand: 'brandB', theme: 'light' },
];

const platformsFor = (name: string): Config['platforms'] => ({
  css: { transformGroup: 'css', buildPath: 'build/web/',
         files: [{ destination: `${name}.css`, format: 'css/variables' }] },
  ios: { transformGroup: 'ios-swift', buildPath: 'build/ios/',
         files: [{ destination: `${name}.swift`, format: 'ios-swift/class.swift',
                   options: { className: 'Tokens' } }] },
  android: { transformGroup: 'compose', buildPath: 'build/android/',
             files: [{ destination: `${name}.kt`, format: 'compose/object',
                       options: { className: 'Tokens', packageName: 'com.monorg.tokens' } }] },
  json: { transformGroup: 'js', buildPath: 'build/json/',
          files: [{ destination: `${name}.json`, format: 'json/flat' }] },
});

for (const { brand, theme } of combinations) {
  const name = `${brand}-${theme}`;
  const sd = new StyleDictionary({
    // Source = the common layer (primitives) + this combination's semantic links.
    source: ['tokens/primitives.json', `tokens/semantic.${brand}.${theme}.json`],
    platforms: platformsFor(name),
  });
  await sd.buildAllPlatforms();
}

node build.ts

And there's the same decision, translated into each language. Web (build/web/brandA-light.css):

:root {
  --color-primary: #2563eb;
  --color-on-primary: #ffffff;
  --color-surface: #ffffff;
  --color-on-surface: #111827;
  --space-4: 16px;
  --radius-md: 8px;
}

iOS (build/ios/brandA-light.swift):

public class Tokens {
    public static let colorPrimary = UIColor(red: 0.145, green: 0.388, blue: 0.922, alpha: 1)
    // ...
}

Android / Compose (build/android/brandB-light.kt):

package com.monorg.tokens
object Tokens {
  val colorPrimary = Color(0xff059669)   // brandB → green
  val colorPrimaryHover = Color(0xff047857)
}

One source, three languages, idiomatic.

Step 4 — A component that consumes (and the magic of the switch)

The component uses only semantic tokens, no hard-coded colors. demo/index.html:

<link id="theme" rel="stylesheet" href="../build/web/brandA-light.css" />
<style>
  .btn {
    background: var(--color-primary);
    color: var(--color-on-primary);
    padding: var(--space-2) var(--space-4);
    border-radius: var(--radius-sm);
  }
  .btn:hover { background: var(--color-primary-hover); }
</style>

<button class="btn">Primary action</button>

<script>
  // The only switch: we swap the token stylesheet. The component does not change.
  document.getElementById('theme').href = '../build/web/brandA-dark.css';
</script>

Change brandA-light → brandA-dark → brandB-light: the button re-themes itself. Not a single line of the component moves. That's the whole point of the semantic level.

Step 5 — Test regressions (the indispensable safety net)

In a system consumed everywhere, a silent regression spreads everywhere at once. We add a net, with zero dependencies, using node:test.

A deliberate choice: writing these tests in Gherkin (Feature / Scenario / Given / When / Then). Why? Because a design system is consumed as much by non-developers (designers, PMs) as by devs. Phrased this way, the tests become documentation that reads like sentences: "Given brand A in dark, when generated, then primary points to blue 300". No need to read code to know what the system guarantees. test/tokens.test.ts:

import { describe, it } from 'node:test';
import assert from 'node:assert/strict';
import { readFileSync } from 'node:fs';

const read = (combo: string): Record<string, string> =>
  JSON.parse(readFileSync(new URL(`../build/json/${combo}.json`, import.meta.url), 'utf8'));

describe('Feature: semantic links resolve to the right primitives', () => {
  describe('Scenario: the dark theme reuses the same semantic names', () => {
    it('Given brand A in dark, When generated, Then primary points to blue 300', () => {
      const tokens = read('brandA-dark');
      assert.equal(tokens.ColorPrimary, '#60a5fa');
      assert.equal(tokens.ColorSurface, '#111827');
    });
  });

  describe('Scenario: switching brand is just re-wiring the links', () => {
    it('Given brand B in light, When generated, Then primary = green', () => {
      assert.equal(read('brandB-light').ColorPrimary, '#059669');
    });
  });
});

node build.ts && node --test "test/**/*.test.ts"
# ✔ Feature: semantic links resolve to the right primitives
#   ✔ Scenario: the dark theme reuses the same semantic names
#   ✔ Scenario: switching brand is just re-wiring the links

If someone breaks a primitive or a link, the test fails before the regression reaches the products. The repo wires this into a GitHub Actions CI that, on every push, builds all combinations, checks the multi-platform artifacts were actually generated, and runs the tests — so a broken link never reaches main. In production, you complement this with snapshot tests on the generated files (any change to an output becomes explicit in review) and, on the component side, a Storybook + automated visual review (Chromatic-style).

Step 6 — Assets (the real challenge: icons & fonts)

Colors are the easy part. Where a design system earns its stripes is on assets: an icon or a font must also start from a single source and be translated into each platform's format.

The most telling case: Android doesn't read SVG natively, it needs a Vector Drawable XML. So we write a small SVG → Vector Drawable converter (excerpt):

export function svgToVectorDrawable(svg: string, { size = 24 } = {}): string {
  const [, , w, h] = svg.match(/viewBox="([\d.\s-]+)"/)![1].trim().split(/\s+/).map(Number);
  const paths = [...svg.matchAll(/<path\b[^>]*\bd="([^"]+)"[^>]*>/gi)].map((m) => {
    const fill = (m[0].match(/fill="([^"]+)"/) || [])[1] ?? 'currentColor';
    const color = fill === 'currentColor' ? '#FF000000' : `#FF${fill.slice(1).toUpperCase()}`;
    return `    <path android:fillColor="${color}" android:pathData="${m[1]}" />`;
  });
  return `<vector xmlns:android="http://schemas.android.com/apk/res/android"
    android:width="${size}dp" android:height="${size}dp"
    android:viewportWidth="${w}" android:viewportHeight="${h}">
${paths.join('\n')}
</vector>`;
}

From a single assets/icons/check.svg, the pipeline produces:

Web → the SVG as-is + a JSON manifest;
iOS → a type-safe enum Icon (no more "magic strings") + the SVG;
Android → ic_check.xml (Vector Drawable) + an enum Icon.

Same logic for the font: one Inter.ttf → @font-face (web), FontRegistrar.swift (iOS), res/font/ (Android). The full code is in the repo (src/buildAssets.ts).

That's the difference between "a shared color file" and a real design system: the multi-platform asset chain.

Step 7 — Distribute it like a real product

A design system only has value if it's easy to consume. Never ask people to copy files: publish to native package managers, and version with SemVer (with alpha / beta / rc / stable channels).

npm install @monorg/design-tokens@1.2.0      # web

implementation("monorg:design-tokens:1.2.0") // android (Maven)

Automate it via CI: a version tag triggers a pipeline that builds all formats and publishes each package to its registry (npm / SPM / Maven). No manual step = no drift between the repo and what's shipped.

# pseudo-pipeline
on: tag 'tokens-v*'
jobs:
  build:   node build.ts
  publish: [ npm, spm, maven ]   # one job per registry

The real win: each consumer pins ITS version

This is the point people underestimate at first. Once tokens are published as versioned packages, each application picks the version it consumes — and that's what makes the system usable at scale:

Total decoupling. The design team can publish 1.3.0 today without breaking anything: the iOS app stays on 1.2.0 until it decides to bump. Nobody is forced to move at the same time.
Progressive rollout. You test a new palette on one product (which goes to 1.3.0-alpha.1) while the others stay stable. If it breaks, the blast radius is one repo, not all of them.
Reproducible builds. A lockfile pinned to 1.2.0 produces exactly the same rendering in six months. A "shared folder" that changes under your feet does not.
History and rollback. A visual regression in prod? Revert to the previous version in one line (@1.1.0) while you fix it. No panicked hotfix across 6 codebases.

design-tokens   v1.3.0  ← latest published
   ├── web app      "@monorg/design-tokens": "1.3.0"   (up to date)
   ├── iOS app      from: "1.2.0"                       (bumps when it wants)
   └── Android app  "monorg:design-tokens:1.2.0"         (same)

The design system becomes a dependency like any other: you update it when you're ready, you read the CHANGELOG, you pin, you roll back. It's exactly this versioning mechanism that turns a "shared folder" into infrastructure.

Wrapping up

A design system is not a button library. It's infrastructure, and its value is in the chain:

A single source of truth: the tokens, in neutral form.
Three levels: primitives → semantic → component. That's what makes multi-brand manageable.
A generation to idiomatic code per platform (Style Dictionary).
A distribution versioned with SemVer, via native package managers.
Tests (Gherkin + snapshots + visual review) to change without fear — and that document the system, even for non-devs.

The full POC code is here → github.com/ibrahimdans/design-system-poc. Clone it, npm install, npm run demo.

The real question isn't "which components should go in my design system?". It's:

"Do my design decisions have a single source of truth, or are they copied by hand?"

Start there.

Unifying several products or several platforms? I design design systems that scale. Let's talk on LinkedIn.

The Principles I Code By: Small Rules, Big Difference

Ibrahima D. — Sat, 06 Jun 2026 16:09:32 +0000

Frameworks come and go. Principles stay. ✨

After a few years of writing software — from MVPs built from scratch 🚀 to legacy systems nobody dared to touch 👻 — I've come to realize something: the developers I admire most aren't the ones who know the most frameworks. They're the ones who follow a few simple principles, consistently, on every line they write.

Over time, I've collected my own set of principles. They act like a compass 🧭: whenever I'm unsure how to approach a problem, I come back to them. None of them are mine — they've been shaped by people much smarter than me — but together they form the way I work. Let me walk you through each one, with examples from real life. 👇

⚡ Make it work, make it right, make it fast

This one, from Kent Beck, is the backbone of everything else. It's an order of priorities, and the order matters:

✅ Make it work — first, get a working solution. Don't optimize, don't over-engineer. Just solve the problem.
🧹 Make it right — now refactor. Clean names, clear structure, tests. Make it readable for the next person (often your future self).
🏎️ Make it fast — only then, if needed, optimize for performance.

An example 💡. You need to display a list of users. The trap is to immediately think about caching, pagination, and database indexes. Don't. First, fetch the list and render it (it works). Then extract a clean component and add a test (it's right). Then, only if the page is actually slow, add caching (it's fast).

Most performance problems we obsess over never materialize. Respect the order, and you'll move faster overall. 🎯

🔮 YAGNI — You Aren't Gonna Need It

We love to build for a future that rarely comes. 🔭 "We might need this option later", "let's make it configurable just in case"... and we end up maintaining code nobody uses.

An example 💡. You're asked to export data as CSV. You think: "I'll build a generic exporter that also supports JSON, XML, and PDF, so we're ready for anything." Six months later, only CSV is used — but you're still maintaining (and debugging 🐛) three formats nobody asked for.

YAGNI is a reminder: build for the need you have today, not the one you imagine for tomorrow. ⏳ When tomorrow actually arrives, you'll have better information to build the right thing.

🎲 The Principle of Least Surprise

Code should behave the way the reader expects it to. The best code is boring: when someone opens your file, nothing makes them go "wait, what?" 😵 Surprise is where bugs hide.

An example 💡. A function called getUser() that also silently updates the last-login timestamp in the database. The name promises a read; the body does a write. Six months later, someone calls it in a loop to display names — and accidentally hammers the database. The code wasn't complex. It was surprising. A function should do what its name says, nothing more.

Here's a subtle one — and it sets up the next principle nicely: predictable often wins over simple. Sometimes slightly more verbose, "boring" code that follows the conventions of your codebase beats a clever one-liner that makes the next reader stop and squint. Be the developer whose code holds no surprises. 🧘

✂️ KISS — Keep It Simple

The simplest solution that solves the problem is almost always the best one. Complexity is easy to add and very hard to remove. 🧨

An example 💡. I've seen a single function grow to 200 lines because it tried to handle every imaginable case with a pile of flags: processData(data, true, false, true). 😵‍💫 Nobody could read it. Split into three small, well-named functions, the same logic became obvious at a glance.

Before writing a clever abstraction, ask yourself: do I really need this, or am I just showing off? 🤔 Simple code is code your teammates can read, debug, and change without fear. That's worth more than cleverness — but remember the previous principle: if "simple" means "surprising," go for predictable instead.

♻️ DRY — Don't Repeat Yourself

Every piece of knowledge should have a single source of truth in your codebase. When the same logic lives in three places, fixing a bug means remembering all three — and you never do.

An example 💡. A password validation rule (8 characters, one uppercase, one digit) copy-pasted into the signup form, the reset form, and the back-end. The day the rule changes, you'll fix two of them and ship the bug in the third. 😬 Extract it once, use it everywhere.

But be careful ⚠️ — don't apply DRY too early. Two pieces of code that look similar today might evolve in different directions tomorrow. Forcing them into one abstraction creates a tangled mess. As the saying goes: duplication is cheaper than the wrong abstraction. Wait until you see the pattern repeat a third time before extracting it.

🧱 SOLID — Five Letters for Maintainable Code

SOLID is a set of five principles for object-oriented design. People recite them like a spell, but each one solves a very concrete pain:

S — Single Responsibility. A class (or function) should have one reason to change. A User class that handles authentication and sends emails and formats invoices will break in three different ways. Split responsibilities.
O — Open/Closed. Open for extension, closed for modification. Adding a new payment method shouldn't mean editing a giant if/else. You should be able to plug in the new case without touching the existing, tested code.
L — Liskov Substitution. A subtype must work anywhere its parent is expected. If your Square extends Rectangle but breaks when you set width and height independently, your hierarchy is lying to you.
I — Interface Segregation. Many small, focused interfaces beat one giant one. Don't force a class to implement methods it doesn't need just because they live in the same interface.
D — Dependency Inversion. Depend on abstractions, not concrete details. Your business logic shouldn't know which database you use. Pass it an interface, and you can swap the implementation (or mock it in tests) freely.

You don't need to recite them. You need to feel them: code that's easy to extend and hard to break. 💪

👣 Baby Steps — Small, Validated Increments

Big changes are scary because they fail in big, mysterious ways. Small changes fail small, and they tell you exactly what went wrong.

An example 💡. Instead of writing 300 lines and running everything at the end (then spending an hour figuring out which part broke), I write a few lines, run the tests, commit, and repeat. When something fails, I know it's in the last tiny change — not somewhere in 300 lines. And because I commit often, git bisect becomes a superpower. 🦸

Progress made of tiny, reversible steps is faster than it looks — and far less stressful. 😌

🌳 The Mikado Method — Taming the Big Refactor

Sometimes a change looks simple, then you pull the thread and the whole sweater unravels. 🧶 The Mikado Method is how I handle that.

An example 💡. You want to upgrade a library. You change it — and 12 files break. The naive approach is to fix them all at once and pray. 😅 The Mikado approach: try the change, see what breaks, write down the prerequisites, then revert. Now tackle one prerequisite at a time, each as its own small, safe commit. Once the groundwork is done, the original change becomes trivial.

The result: no more half-finished refactors stuck in a branch for three weeks. You always have working code, and a clear map of what's left. 🗺️

🧩 How they fit together

None of these principles work alone:

🪶 KISS, YAGNI and Least Surprise keep me from building too much — and from building it weird.
🛠️ DRY and SOLID keep what I build maintainable.
🛡️ Baby Steps and Mikado keep me safe when I change existing code.
🧭 And "make it work, make it right, make it fast" sets the order for all of it.

But here's the uncomfortable truth nobody tells you when you first learn these: principles contradict each other. 💥 YAGNI says don't build it, while SOLID says add this layer of abstraction. DRY says extract the duplicate, while Least Surprise says keep it consistent and obvious. So which one wins?

The trick is to treat them as a hierarchy, not a checklist. 🏛️ The foundational ones come first, and a "higher" principle is only allowed to apply when it doesn't break a "lower" one. Roughly: make it work → YAGNI → least surprise → KISS → DRY → SOLID → and make it fast dead last. When two principles clash, the more foundational one wins. That's how you stop arguing in circles in code review.

They're not rules I follow blindly — every one of them has a "but" attached, as you've seen. They're a starting point, a default. The judgment of when to bend them — and which one outranks which — comes with experience.

So next time you're staring at a problem, unsure where to start, ask yourself the simplest question:

"What's the smallest, simplest thing that makes this work?"

Start there. Your code, your teammates, and your future self will thank you. 🙌

These are my principles — but I'm always looking to sharpen my compass. 🧭

What about you? Which principle has saved you the most pain? Is there a rule you swear by that I didn't mention here? Or maybe one of these you've learned to break on purpose?

👇 Drop your favorite tip in the comments — I read every one, and I'd love to learn from yours. And if this article resonated with you, a ❤️ or a 🔖 helps it reach another dev who needs it.

Happy coding! 🚀

How to use two instances of Claude Code

Ibrahima D. — Tue, 19 Aug 2025 15:24:44 +0000

You have reached the limit for Claude Code

It's quite frustrating, especially since it often happens when our treatment isn't finished.
It's not ideal to have two instances of Claude, because it means paying for Claude Pro twice, but it's cheaper than having Claude Max, which costs over €100.

First, at the root of your account, create a new folder that will hold your Claude configurations, credentials, etc.

If you have specific configurations such as commands, don't forget to copy them. That's what I do when I activate another instance of Claude.

cp -R .claude .claude-2

in zshrc $HOME/.zshrc|.bashrc

cc() {
 claude
}

ccp() {

CLAUDE_CONFIG_DIR=~/.claude-2 claude

}

Now you just need to launch cc for claude or ccp for claude-2.

Note: cc and ccp are arbitrary you can call them whatever you want.

Enjoy

Essential Code Review Terms Every Developer Should Know

Ibrahima D. — Mon, 07 Jul 2025 09:12:09 +0000

When I first started out in this profession, I would often come across certain terms and acronyms in code reviews and team discussions, and I always wondered what they meant. If you’re new to software development or just want a refresher, here’s a handy list that might help you navigate those conversations more confidently.

Common Terms and Acronyms
WIP (Work In Progress): Indicates that the work or pull request is not finished yet and is not ready for a full review.

LGTM (Looks Good To Me): The proposed code looks correct and can be merged.

NIT (Nitpick): A minor suggestion or remark, often about style or readability, with no functional impact.

ACK (Acknowledge): Confirms that a comment has been read and considered.

PTAL (Please Take A Look): A request to review or re-review the code.

RFC (Request For Comments): An invitation for feedback or opinions on a proposal or change.

IMO/IMHO (In My [Humble] Opinion): Indicates that what follows is a personal opinion.

Blocking: A comment or issue that must be addressed before the code can be merged.

Non-blocking: A suggestion or remark that does not prevent the code from being merged.

Ship It: Informal way of saying the code is ready to be delivered or merged.

Stale: A review or pull request that hasn’t seen activity in a long time.

Self-review: Reviewing your own code before submitting it to others.

Refactor: Rewriting code to improve its structure or readability without changing its functionality.

Patch: A software fix or update.

Hotfix: A quick fix for a critical bug, usually deployed urgently.

DRY (Don’t Repeat Yourself): Principle to avoid code duplication.

Bump: To increase or update a version number, or to make a small improvement or fix.

Chore: A technical or maintenance task that doesn’t add a new user-facing feature, but is necessary for the health of the project (e.g., code cleanup, updating dependencies, configuring tools).

FYI (For Your Information): Sharing information without expecting an immediate response or action.

TBR (To Be Reviewed): Indicates that a piece of code or change is waiting for review.

Dead code: Unused or obsolete code that should be removed.

Needs Rebase: The branch needs to be updated to resolve conflicts or incorporate the latest changes from the main branch.

Outdated: A comment made on an older version of the code, often after a rebase or new commit.

TBD (To Be Determined/Defined): Something that still needs to be specified or decided.

If you know more terms or acronyms that are commonly used in code reviews, feel free to share them in the comments! This list is not exhaustive, and your input can help others in the community.

Enhancing Testability with Dynamic Data-testid Attributes

Ibrahima D. — Thu, 28 Mar 2024 14:21:39 +0000

We've all been faced with the challenge of choosing a better test ID for our component at some point. Why not leverage the logic we already use for CSS, like BEM (Block Element Modifier)? What is the best solution for achieving consistent and logical IDs across the board? What are the existing best practices?

✅ The Solution:
The best solution I've found with React is to create a custom hook that generates an ID, making it easier to locate them in our tests.

📚 Code Examples:

Create a custom hook useTestIdGenerator.ts:

Use the custom hook in your grid component:

Now, each element in your grid has unique "data-testid" attributes!

This approach greatly facilitates testing of dynamic components while maintaining the cleanliness and maintainability of your code. 🔥

An example test using this unique attribute:

Don't hesitate If you have another even better solution, to suggest it in the comments.

The boy scout rule : Small Steps, Big Impact

Ibrahima D. — Mon, 04 Sep 2023 10:01:31 +0000

In his book 'Clean Code,' Robert C. Martin introduces us to an essential principle for writing beautiful code, the famous Boy Scout Rule, which can be summed up in one sentence: 'Always leave a place in a better state than you found it.'

As developers, we are constantly faced with challenges to produce clean, readable, and maintainable code. One of the simplest yet most powerful methods to achieve this goal is the Boy Scout Rule. Inspired by the idea of leaving the environment in a better state than we found it, this rule can have a significant impact on the quality of our code. In this article, we will explore this concept and discover how it can enhance our development process

The Boy Scout Rule, popularized by software engineering veteran Robert C. Martin, encourages us to improve the code with every change we make, even if that change is not directly related to our current task. This can include minor adjustments such as renaming variables for clarity, adding comments to explain complex parts of the code, or reorganizing sections for better readability.

The Benefits of Following the Rule

Cleaner Code: By adopting this rule, we ensure that our code remains consistently clean and organized. The cumulative effect of small improvements over time contributes to overall quality maintenance.

Ease of Maintenance: Well-maintained code is easier to understand and modify. Future development teams will appreciate code that reads like a well-written book.

Reducing Technical Debt: By preventing the accumulation of poor code, we avoid technical debt, allowing development to proceed smoothly without being hindered by quality issues.

How to Apply the Boy Scout Rule

Be Conscious: Every time you modify a part of the code, be mindful of opportunities for improvement. Ask yourself, "How can I leave this part of the code in a better state?"

Prioritize: Not all improvements are equal. Focus on changes that will have the most impact on code readability, maintainability, and clarity.

Communicate: Share the Boy Scout Rule with your colleagues. Encourage a development culture where a commitment to quality is valued.

The Boy Scout Rule is a simple yet effective approach to ensuring the ongoing quality of our code. By incorporating this philosophy into our development process, we contribute to an environment where code respect and a continuous improvement mindset are at the core of our work. So, the next time you make a change, ask yourself,

'Am I leaving the code in a better state than I found it?'

Your code, your colleagues, and your future self will thank you.

11 Pieces of Advice I Wish I Had Known as a Junior Developer

Ibrahima D. — Wed, 16 Aug 2023 10:41:40 +0000

Being a junior developer is an exciting stage, but it's often filled with challenges and learning experiences. Looking back, many developers realize that there were several things they would have liked to know at the beginning of their careers. This article delves into the valuable lessons and advice that I would have wished to receive when starting out in the field.

1. Don't Neglect the Basics !!!

One of the most common mistakes made by junior developers is to focus solely on memorizing syntax and using ready-made solutions. In reality, understanding the fundamental concepts of programming and specific languages is essential. This enables more effective problem-solving, adaptation of solutions to needs, and building a solid foundation for further development.

2. Read the Documentation

Reading, re-reading, and reading documentation again is often underestimated, but it can make all the difference in the development process. Junior developers should learn to read and create accurate documentation from the start. This facilitates collaboration with other team members, understanding libraries and frameworks, and contributes to quick problem resolution.

3. Learn How to Learn

The development industry evolves rapidly with new technologies and emerging best practices constantly. Developers should become familiar with the idea that learning never stops. Participating in online courses, following relevant blogs, and working on personal projects are all ways to stay updated and continue evolving.

4. Code Simply, Then Format the Code

It's easy to fall into the trap of wanting to write perfect code from the start. However, it's more important to focus on efficient problem-solving. Developers should learn to iterate, test their ideas quickly, and improve gradually. Perfection comes with experience.

5. Don't Hesitate to Ask Questions and Seek Help

Development isn't limited to just programming. Communication with team members, clients, and stakeholders is crucial for understanding needs, sharing ideas, and solving problems. Developers should cultivate their communication skills to become valuable team members.

6. Don't Fear Failure

Making mistakes is part of learning, so don't be afraid of making them. Even great software developers have been fired, made mistakes, and felt down, but what makes them great is that they rise and learn from their mistakes. Don't be discouraged by errors or bugs; use them as learning and growth opportunities.

7. Contribute to Open Source Software

You'll learn a lot by contributing to an open-source project, so by helping the community, you're helping yourself, and maintainers are happy. Start small and learn about the project; begin with a framework/tool you use. There are many ways to contribute to open-source projects, such as reporting a bug, reproducing the bug, and writing code to fix a bug or implement a new feature.

8. Be Open to Feedback and Criticism

Receiving constructive feedback on your code is a chance to learn and improve. Be open to critiques and consider them as opportunities for growth. Practicing egoless programming can be beneficial.

9. Manage Your Time

Development can be time-intensive. Learn to manage your time by planning, setting priorities, and avoiding getting overwhelmed by secondary tasks. The day you're satisfied with your development is the day you'll no longer grow.

10. Version Your Code (GitHub, GitLab, Bitbucket ...)

Use a version control system like Git from the start. This allows you to track the evolution of your code, collaborate more effectively with other developers, and revert changes if necessary.

11. Enjoy the Journey

Taking breaks and vacations is essential to maintain a healthy balance between work and personal life. Schedule short, regular breaks throughout the day to rest your mind. Techniques like the Pomodoro technique recommend working for about 25 minutes and then taking a 5-minute break. Use this time to stand up, stretch, take deep breaths, or simply step away from your screen.

Don't underestimate the importance of vacations. Plan your time off in advance and make sure to adhere to it. When you go on vacation, truly disconnect from work. Avoid checking your work emails or thinking about ongoing projects. Allow yourself the necessary time to rest, relax, and recharge.

Regardless of the experience gained over the years, being junior or senior isn't determined by time alone, but by the level of professionalism one achieves. Each day is an opportunity to continue learning, growing, and refining one's skills. This mindset enables me not only to embrace new technologies and tackle challenges but also to stay connected to the very essence of programming – a constant quest for improvement and understanding. Recognizing that development is a perpetually evolving field, I remain linked to its ever-changing dynamics.

Egoless Programming

Ibrahima D. — Thu, 10 Aug 2023 12:21:55 +0000

In the dynamic landscape of software development, a transformative concept is gaining prominence: "Egoless Programming." Rooted in collaboration and humility, this approach transcends individual ego to prioritize collective success. This article delves into the tenets of egoless programming, its impact on project quality, and its role in cultivating a harmonious development environment. A fresh perspective that could steer developers toward more efficient and fulfilling horizons.

Egoless programming," also known as "programming without ego" in French, is a concept in the field of computer programming that encourages developers to embrace a humble and collaborative approach when creating software. The fundamental idea behind egoless programming is for developers to set aside their ego, biases, and personal desires in order to work together constructively and produce high-quality code.

The key principles of egoless programming include:

Focus on Results, Not Individuals: Emphasis is placed on achieving project objectives rather than seeking personal credit or recognition. Programmers prioritize what's best for the software and its users, rather than their own glory.

Embrace Constructive Criticism: Programmers should be open to feedback and suggestions from peers. They should be willing to challenge their own code and make improvements based on received feedback.

Team Collaboration: Egoless programming promotes effective collaboration and communication among team members. Programmers should be ready to share knowledge and learn from others, rather than monopolizing expertise.

Continuous Learning: Programmers acknowledge that there's always something new to learn and discover. They should be open to continuous learning and skill improvement.

Minimize Code Ownership: Instead of clinging to specific code as if it were their exclusive creation, programmers should encourage code sharing and collective improvement.

Egoless programming can contribute to code quality enhancement, reduce conflicts within the development team, and foster a more positive and collaborative work environment. Ultimately, the focus is on creating high-quality software rather than individual programmer ego.