Forem: Sourav Dey

My Blog Syndication Strategy 📣

Sourav Dey — Wed, 15 Apr 2026 12:00:00 +0000

For a long time, I treated publishing a blog post like crossing a finish line. I would write the post, hit publish, share it once, and move on. It felt tidy. It also meant I kept confusing publication with discovery. 😅

My blog syndication strategy came from that mistake. 📌

The source of truth lives on souravdey.space. Dev.to and Hashnode help me distribute the same idea further, but they do not become the home of the work. That distinction sounds small until you have been writing long enough to care about URLs, long tails, and the difference between being discoverable and being dependent.

I wrote about this in Portfolio Website Development Part 4, where I said I should have moved canonical hosting to my own domain much sooner. I meant that. The older I get in public writing, the less romantic I am about platforms. A platform is useful. A platform is not ownership.

The workflow at a glance

This is the shape I keep in my head.

Flow: Write the blog, open a PR, merge it into main, then let GitHub Actions fan the post out to Dev.to, Hashnode, Medium, and the GitHub issue checklist.

The process is simple: I write the blog, I open a PR, and once that PR lands in main, GitHub Actions pick up the follow-up work.

At the command line, the ritual is small enough to remember:

yarn build
yarn crosspost -- blog-syndication-strategy

The first command checks whether the post can survive syndication cleanly. The second is the escape hatch I use when I want to inspect or trigger a single post by hand.

What those two commands actually do

This looks tiny. It is not tiny.

yarn build is my rehearsal. In this repo it does not just build the Next.js site. It runs yarn check:syndication first, then the site build. So before I ever merge, the pipeline has already asked a useful question: if this post leaves my website, will it still make sense?

yarn crosspost -- slug is narrower and more practical. It resolves one MDX file, reads the frontmatter, converts the body into platform-friendly Markdown, talks to the Dev.to and Hashnode APIs, and updates the saved crosspost state so the next run knows whether it is creating something new or updating something that already exists.

That division matters. One command protects quality. The other handles distribution.

The mental model in code is even simpler: publish once, then automate the platform copies that are truly repeatable.

const syndicationTargets = ["Dev.to", "Hashnode"] as const;

function publish(post) {
  publishCanonical(post);
  syndicationTargets.forEach((target) => {
    crosspost(post, target);
  });
}

publishCanonical(post) is the whole philosophy in one line. Home first. 🏠

Then the loop fans out only across targets that are predictable enough to automate. That is why the array is short. Dev.to and Hashnode fit that model. Medium does not sit in that loop because the action I care about there is different. I do not want “post some Markdown.” I want “import this canonical URL and preserve the original source.”

Medium stays outside that automated loop on purpose. I handle it manually through link import, because preserving the canonical URL matters more to me than forcing every destination to behave the same way.

There are GitHub Actions around this too. I think of them as guardrails, not magic. The local commands are how I work. The workflows are how I stop that process from depending on my memory.

Canonical first

My site is where the post starts, where it gets updated, and where it stays.

That choice shapes everything else. I write in MDX under src/content/blogs, and the frontmatter decides whether a draft is ready to leave the building. If a post is published, the site treats it as part of the content graph, not as a one-off asset. Search, sitemap entries, RSS, structured data, and the page itself all point back to the same canonical home.

That is the part I care about most.

If someone finds me on Dev.to or Hashnode, I still want the post to know where home is. If search finds the original article, I want that version to be the one search engines remember. If I update the post later, the canonical copy should be the one that carries the truth forward.

Ownership is not just a philosophical preference. It is a maintenance strategy.

What the actual loop looks like

The loop is simpler than it sounds.

I write the post. I open a PR. Review happens there. When that PR lands in main, that is the moment the canonical post becomes live and the follow-up automation starts.

Before any of that merge machinery matters, yarn build runs the syndication checks locally so I get early feedback if a post contains something the crosspost pipeline cannot translate cleanly.

Then GitHub Actions repeat that discipline in CI.

What the GitHub Actions actually do

The first workflow is syndication-check.yml. It runs on pull requests and on pushes to main when blog files or the syndication code changes. I like that detail more than I expected to. It means the check is not some vague “content pipeline” that wakes up for everything. It wakes up only when the parts that matter change. If I change the syndication logic, or I change a blog post that will be published, the workflow reruns the exact question I care about: can this MDX survive outside my site without falling apart?

That workflow is the skeptical friend in the system. 👀 It does not publish anything. It just refuses to let me feel prematurely done.

At the YAML level, it is doing something very plain:

on:
  pull_request:
    paths:
      - "src/content/blogs/**"
  push:
    branches: [main]

That is not glamorous. It is also the reason the workflow feels trustworthy. It runs when blog content changes, and when the code that handles syndication changes. Not on every random edit in the repo.

The second workflow is post-publish-blogs.yml, and this one is the real follow-through. It runs only after content lands on main. That boundary matters to me. Drafting is one phase. Review is another. Distribution starts only when the canonical post is actually live on my domain.

Once that workflow wakes up, it diffs what changed, filters down to published blog slugs, and runs the follow-up work in one place. It can generate OG thumbnails when the image is missing, create audio, crosspost to Dev.to and Hashnode, send social announcements, and open the GitHub distribution checklist issue that reminds me about the manual side of the job. Medium lives there indirectly. Not as an automated API call, but as a deliberate item in the checklist.

The code path is surprisingly readable:

const publishedSlugs = publishedBlogSlugsFromChanged(changed);

runOgThumbnails(publishedSlugs);
runAudio();
crosspostOk = runCrosspost(publishedSlugs);
socialOk = runSocialAnnounce(publishedSlugs);
runDistributionChecklist(publishedSlugs, crosspostOk, socialOk);

That sequence is the process in miniature. First figure out which published posts actually changed. Then do the repeatable work around them. Then open the checklist for the parts that still deserve a human hand.

That is the real payoff for me. I do not want to remember five slightly different publishing rituals. I want one publishing model. Let the machine handle repetition. Let me handle judgment.

The crosspost layer does the boring work well. Under the hood, it is basically this:

const markdown = mdxToCrosspostMarkdown(body, siteUrl);
const footer = originAttributionFooter("souravdey.space", siteUrl);

What that conversion code is really doing

That little pair of lines carries most of the weight. It turns MDX into platform-friendly Markdown, absolutizes links, strips out components that only make sense on my site, and adds the attribution footer that tells readers where the original lives. In practice, that is the bridge between the thing I enjoy writing and the thing platforms are willing to accept.

mdxToCrosspostMarkdown is the messy realism function in this whole setup. It is where custom site-only components stop being UI elements and start becoming readable plain Markdown. It is where local image paths become absolute URLs. It is where embeds that work beautifully on my site turn into links, summaries, or simplified fallbacks for platforms that do not know anything about my component system.

originAttributionFooter is simpler, but maybe more important. It is the line that keeps ownership visible after the post travels. Without that footer, syndication can quietly become duplication. With it, the copied post still remembers where home is.

There is another small detail here that makes the whole setup feel grown-up to me. The post-publish workflow commits generated assets back with [skip ci], so the automation does not keep waking itself up in a loop. That sounds like a tiny implementation detail. It is also the difference between “automation” and “a bot that eats its own tail.” ♻️

A blog post is not done when I finish writing it. It is done when it survives distribution without losing its shape.

That is a different bar.

The GitHub issue checklist

The automated path is only half the story. I also keep a GitHub issue open for the manual side of distribution, so Medium, social shares, and aggregator submissions do not live in my head. The issue is created from the post metadata and labeled distribution by the same follow-up workflow that handles crossposting.

That part matters more than it sounds. A lot of publishing systems look “automated” right up until the moment they quietly dump the human steps back into your brain. I did not want that. If a step is manual, I still want it in the system. Visible. Attached to the post, not floating around as a half-remembered note.

The Medium row is still a direct link paste, because I want the import tool to preserve the canonical URL:

- [ ] [Medium](https://medium.com/new-story) *(use Import tool to preserve canonical URL: https://souravdey.space/blogs/blog-syndication-strategy)*

That line is intentionally verbose. I do not want future me guessing what “publish to Medium” meant on a sleepy evening.

And if I need to recreate the issue itself by hand, the CLI version is straightforward:

gh issue create --title "📢 Distribution: My Blog Syndication Strategy 📣" --label distribution --body-file checklist.md

That checklist is the human half of the system. It catches the little things automation should not guess.

Why I still syndicate

I do not syndicate because I am unsure where my work belongs.

I syndicate because attention is fragmented, and readers do not all arrive through the same door. Some people discover a post through Dev.to. Some through Hashnode. Some through RSS. Some through search. Some land on my homepage because they already know my name. I want to meet all of them without making every post depend on one channel.

That is the balance I was after: reach without surrendering the original. ✨

If I only published on my own site, I would own everything and reach fewer people. If I only published on platforms, I would get reach and lose some control. Syndication is the middle path I actually believe in. It is not a compromise if the canonical story is strong.

There is also a softer reason. Crossposting makes my writing travel. A good post should be able to sit in different places and still feel like the same thought. That constraint makes me write cleaner, structure better, and keep my MDX honest. If a post depends too heavily on site-specific presentation, I usually need to think harder about whether the core idea stands clearly enough on its own.

The tradeoffs are real

I am not pretending this setup is free.

Every layer of automation adds another place where content can break. Some MDX components do not translate neatly. Some images need better alt text than I would otherwise bother with when I am in a hurry. Some internal links need to become absolute URLs on syndicated copies. That is why I like having check:syndication wired into the build. I would rather learn about a conversion problem before the post is public than after I have shared two broken copies.

There is also a mental tradeoff. Syndication can tempt you into caring too much about platform performance. I try not to let that happen. If Dev.to gets more clicks on one post and Hashnode gets more comments on another, that is interesting, but it is not the point. The point is that the original post stays intact, searchable, and under my control.

I want the platform to amplify the writing, not define it.

That line keeps me honest.

What I would do differently

I would move canonical hosting to my own domain even earlier.

That is the cleanest lesson in the whole thing. For years I cared too much about where a post could travel and not enough about where it should live. In Part 4 I admitted that. The older version of me thought syndication was a distribution decision. The better version of me sees it as an architecture decision.

I would also document my content conventions sooner. Once a site has more than one content type, memory stops being a reliable system. Frontmatter, tags, images, series, and syndication rules all start to interact. A short internal doc saves future me from guessing, and guessing gets expensive when it happens at publish time.

If I were starting again today, I would still syndicate. I would just be much less sentimental about the platform copy and much more protective of the original.

That is the whole strategy, really.

Write once. Keep the canonical copy at home. Let other platforms do the discovery work. Update the source, and let the copies follow.

The original should always know where home is. 🏠

Originally published on April 15, 2026 at souravdey.space.

Facebook Developer Circle 🏆 - Open Source Immersion Challenge 2020

Sourav Dey — Tue, 14 Apr 2026 11:06:18 +0000

Got Facebook Developer Swags 😁😁 for Contributions to Facebook-led Open Source projects in Facebook Open Source Immersion Challenge, a month-long initiative by Developer Circles from Facebook.

What is Facebook Open Source Immersion Challenge?

Facebook Open Source Immersion Challenge initiative is a month-long celebration of Open Source technology, run by Facebook. The goal of this initiative is to provide developers with practical education and experience contributing to Open Source projects in preparation for our annual Developer Circles Community Challenge later this year.

✨ Want to know more about it: here

Steps to Participate

Register or login at github.com
Sign up on the Developer Circles Open Source Immersion registration page
Sign Facebook’s contributor license agreement (CLA) here
Create a minimum of 4 contributions/PR into Open Source projects with at least 1 out of 4 PR towards any project within DevC GitHub Org or any Facebook-led Open Source project. Make sure you submit these before the deadline, August 15, 2020, at 11:59:59 PM PST.
Share your GitHub profile or the link of your PR to your local Developer Circles Facebook group.

Here is the list of Pull Requests:

You can also check the PRs in my Github profile.

Finally, Got the email

Achieved Swags from Facebook for being in the top 1000 of the Open Source Developer Immersion 2020

I have also shared a LinkedIn post regarding the same.

Contact me

Originally published on December 7, 2020 at souravdey.space.

Winning the HackGPT 2.0 Hackathon: 2nd Runner-up Position 🧑🏻‍💻

Sourav Dey — Tue, 14 Apr 2026 11:06:15 +0000

⏱️ 24 hours of non-stop building. ☕ 12 cups of coffee. 🃏 2 hours of poker (someone had to lose their dignity 😂). And somehow, in between all of that, we shipped a working AI-powered code quality platform that might actually change how developer assessments work.

This is the story of HackGPT 2.0, HackerRank's internal 24-hour hackathon during our May P&E Offsite. Our team of 8 engineers reached 2nd runner-up position, but the real win was proving something the product team had been theorizing about for months: AI-powered holistic code review isn't just feasible, it's practical at scale.

Kudos to the entire team: Ankur, Ankush, Hannad, Sudarshan, Satyam, Dinesh, and Dhruv 🙏.

🎯 The Problem: Scoring Developers on a Single Axis

Here's the reality of how most coding assessments work today: a candidate writes code, the platform runs testcases, and the output is a single number. Pass 7 out of 10 testcases? That's your score.

But anyone who's done a real code review knows that the score tells you almost nothing about the developer. Two candidates can both score 70%, but one of them wrote clean, well-structured code with thoughtful edge case handling, while the other brute-forced a solution with global variables everywhere and got lucky on the test cases.

The current model measures two things: correctness and partial performance. Everything else (code style, maintainability, security patterns, debugging skills, how the candidate actually approached the problem) is invisible.

This has real consequences. At enterprise scale, one of our customers was manually reviewing 74,000 candidates per year to compensate for what automated scoring couldn't capture. That's over 12,000 hours of engineering time spent on manual code review, every single year.

We wanted to build something that could see what the score can't.

🗺️ Designing a Holistic Skill Profile

Before writing any code, we spent the first couple of hours whiteboarding what a "complete" developer evaluation would actually look like. We landed on five dimensions:

✅ Solution: Does the code work? Is it performant? This is the baseline that existing systems already cover.

🧹 Code Quality: Is it readable? Is it maintainable? Would you want to inherit this codebase?

🛡️ Reliability: Does the candidate think about security, scalability, exception handling, and technical design? These are the signals that separate a junior developer from a senior one.

♿ User Experience: Does the code consider accessibility? This is especially relevant for frontend assessments.

🧠 Logical Progression: This is the one that got us most excited. Instead of just reviewing the final submission, what if we could understand how the candidate got there? Their debugging patterns, their persistence when stuck, the moments where they pivoted their approach.

That last dimension is what made our project different from "just another AI code reviewer." We weren't just analyzing code. We were analyzing the process of writing code.

🏗️ The Architecture (Plus 12 Cups of Coffee)

Hour 3. Whiteboard phase over. Coffee cup #3. Time to build.

We designed the system as a standalone platform service, intentionally decoupled from any single product UI so it could eventually plug into screening, interviews, and skill assessments across the board.

The data flow looks like this:

⌨️ Keystroke ingestion:

Flow: Assessment Frontend → Attempt Processing Worker → Candidate DB

🔬 Code quality analysis:

Flow: Candidate DB → Code Quality Platform Service → Core API

🤖 AI review engine:

Flow: Code Review Rubric → Next.js App → AI Platform (LLM)

The Code Quality Platform Service is the central piece. It receives attempt data (including raw keystroke streams), runs a combination of static analysis and LLM-powered review against a configurable rubric, and pushes structured results back to the API layer for rendering.

The Next.js app handles the review orchestration, consuming rubric definitions and coordinating with the AI platform to produce categorized, line-level code comments.

And then there was the part I spent most of my 24 hours on.

⏪ My Contribution: Turning Keystrokes into a Time Machine

Here's the thing about keystroke data: it's raw. Really raw. A stream of individual key events with timestamps. Insert character. Delete character. Cursor move. Paste. Undo. Thousands of events per coding session.

My job was to turn that raw stream into something an AI reviewer could actually reason about.

I built a keystroke serialization engine that reconstructs snapshots of the candidate's code at configurable intervals. Instead of just handing the LLM the final submission and saying "review this," the engine generates a sequence of code states, a snapshot every n keystrokes, that captures the candidate's code at different points in their journey.

Think of it like git commits, but automatic and granular 📸. Snapshot at keystroke 50. Snapshot at keystroke 150. Snapshot at keystroke 300. Each one is a frozen moment of the candidate's progress.

This changes what the AI reviewer can see. It's not just what the candidate wrote, it's how they got there 🕵️.

Did they start with a brute-force approach and refactor? Did they handle the happy path first and then circle back for edge cases? Did they get stuck on a syntax error for 10 minutes or catch it in 30 seconds? Did they delete half their code and restart with a better approach, or did they keep patching a broken foundation?

The configurable gap parameter is where the real tradeoff lives: you tune snapshot frequency based on question complexity. For a quick algorithm question, every 30 keystrokes gives enough resolution. For a longer system design problem, every 100.

More granular snapshots = more LLM calls, higher latency, and higher inference cost. The cost-to-resolution curve is a real production problem this approach needs to address before it can scale.

On top of the serialization engine, I built the Next.js frontend that surfaces all of this: the code playback UI, the inline AI review comments, and the attempt timeline that shows the candidate's phases visually.

By hour 18, keystroke-to-snapshot serialization was working end to end. By hour 22, it was integrated with the AI review pipeline and rendering in the UI. The last two hours were pure polish and demo prep (and coffee cups #11 and #12).

📊 What the AI Reviewer Actually Outputs

The review engine produces structured, line-level comments. Not vague "this could be better" feedback, but specific, categorized, severity-tagged observations:

{
  "severity": "High",
  "category": "Code Style",
  "lines": "5-6",
  "comment": "Extensive use of global variables. Leads to unexpected side effects and complicates debugging."
}

These comments overlay directly on the code playback, so a reviewer sees the AI's observations at the exact lines where issues appear.

Beyond line-level feedback, the system generates an Attempt Summary, a natural-language overview designed for non-technical hiring stakeholders. It includes a composite score, a phase timeline (initial setup → debugging → edge-case handling → optimization), and structured highlights and lowlights.

Defined evaluation criteria fed as structured prompts is what makes LLM code review reliable enough to surface to hiring teams. Without the rubric layer, you get opinions. With it, you get a repeatable process.

🌙 24 Hours of In-Office Hackathon Culture

I want to talk about the vibe for a second, because it matters.

There's something different about building alongside your team in a room at 3 AM with empty coffee cups and a deadline. The brainstorming is faster. The decisions are bolder. Nobody's overthinking a PR review. You're just shipping. The energy of an in-office hackathon compresses months of "we should build this someday" into one intense, focused burst.

The first hour was chaos, eight people talking over each other about what to build. Then someone pulled up a whiteboard and it clicked. The next 22 hours were a mix of deep focus sprints, quick syncs standing around someone's laptop, and exactly the right amount of distraction (the poker game was competitive, I'll leave it at that 🃏).

This is the stuff that builds team trust. You learn more about how someone thinks and works in 24 hours of hackathon pressure than in months of regular sprint work.

🚀 From Hackathon to Product

By demo time, we had two things working end to end:

A fully operational Code Quality Platform Service: keystroke ingestion, snapshot serialization, AI-powered multi-dimensional review, and structured output via API.
A working frontend integration: inline code review comments, skill dimension indicators, attempt timeline, and natural-language summary, all rendered in the assessment UI.

We placed 2nd runner-up 🥉 out of all teams at HackGPT 2.0. More importantly, the prototype demonstrated something the product team had been theorizing about for months: that AI-powered holistic code review is not just feasible, but practical at scale.

Our CEO later called it out publicly 📢:

Post on X

That validation felt great 🙌. But what I keep thinking about is the second-order implication: if keystroke data becomes a first-class evaluation signal, the way assessments get designed changes. Question complexity, time windows, the balance between free-form coding and structured problems, all of it needs rethinking. The technology isn't the hard part. Rethinking the assessment design around it is 🤝.

💡 What I Learned

⛏️ Keystroke data is an underrated goldmine. Most platforms throw it away or use it only for proctoring. Treating it as a first-class data source for skill assessment opens up an entirely new evaluation dimension.
🤖 LLMs are good at code review, with guardrails. You can't just dump code into an LLM and expect consistent, structured output. The rubric-driven approach, where you define evaluation criteria separately and feed them as structured prompts, is what makes the output reliable enough to surface to hiring teams.
⚡ Hackathons compress learning. I went deeper on keystroke event processing, snapshot reconstruction, and LLM orchestration in 24 hours than I would have in weeks of regular work. Constraints breed focus.

Eight people with different expertise areas, 24 hours, one shared vision. That's how real systems get built ✨

Originally published on June 5, 2024 at souravdey.space.

Why Side Projects Compound 🏗️

Sourav Dey — Mon, 06 Apr 2026 07:56:56 +0000

For years I treated side projects like a second job I was failing at. 😅

I was still building. The fuel was not a trophy list. It was ideas: problems I could not drop, small "what ifs," things I wanted to exist whether or not anyone asked. Some turned into code and demos. Some stayed half-born in notes. When something did ship, I parked it on Side Projects so I could point back without turning the build into a performance. The hard part was not a lack of sparks. It was guilt. Every hour on a personal repo felt like an hour I stole from rest, from my day job, from whatever version of adulthood the noise online says you should perform.

If you have ever closed your laptop at 1 AM 🌙 and thought, this does not count, you know the feeling.

Here is the lesson that took me too long to learn: side projects add up over time even when they never become startups. Not because every repo needs a prize. Because they train skills your sprint board rarely optimizes for. ✨

What side projects teach beyond your job 🧾

At work, someone else shapes the problem, writes the ticket, and often picks the hard choices for you. That is not a knock on you. It is how real companies ship.

Side projects push you into the step before that: choosing what is worth building when no one asked, when the scope is yours, when the only deadline is your own pride. That is where you practice decisions when nothing is spelled out, the same habit that later helps when two technical options are both "fine" and someone has to pick.

You also get shipping in public if you publish the work. 📣 A private spike teaches syntax. A public repo teaches taste, communication, and the slow work of explaining your own mess.

Figure from Austin Kleon's Show Your Work!.

That book is where I first saw the learn and teach loop drawn as one circle. You learn, you share what you know, and sharing feeds the next round of learning. Austin Kleon's "show your work" idea is not about showing off. It is about letting your thinking meet real people. I wrote about why that cycle is a career catalyst for builders, and how I use it in mentorship, in this LinkedIn post.

And Guess what? The web is not fair. Polished demos can flop. Rough hacks can take off. You cannot chase likes without turning the whole thing into a second social media job. You can still chase practice reps: ship, write it down, cut scope, finish something. 🎯

What compounding means for side projects 📈

When I say compound, I do not mean every project becomes a clean story for interviews. I mean a set of skills that still help you after you stop opening the repo every week.

Spotting patterns is the big one. After you debug your own auth flow, deploy surprises, and your own "why is this slow" hunts, incidents at work start to look familiar. The details change. The shape of the problem often does not.

Knowing your tools is the quiet kind of compound interest. 🛠️ You learn a framework because a weekend idea needed it. Two years later that is not just a resume line. It is speed when the team needs a prototype, or when you read someone else's system and you actually get the constraints.

Proof you can ship matters more than people say, especially early. ✅ Not proof you are a genius. Proof you can take an idea from zero to something another person can run. That is a different signal than "I finished courses."

There is a follow-on effect too. 🤖 You can ship side projects lightning fast now: AI handles boilerplate, glue code, and first drafts so an idea can become a working thing in hours, not weeks. As that wall gets lower, the hard part moves earlier. The rare skill is not typing UI faster. It is naming the problem, picking limits, and knowing what "good enough" means for a user. Side projects are a low-risk place to grow that product sense without treating a tutorial like owning a real feature.

Product engineering is part of that same stack, and it grows fast when you build for yourself. You are the user, the scope owner, and the engineer in one loop, so tradeoffs land in your head instead of across three roles in a meeting. I wrote about why that mindset is the skill that survives when AI handles more of the code in product engineering in the AI era.

Side projects are not free ⚖️

Growth needs finish lines, not only new ideas. If every spark becomes a new foundation and nothing ships, you get the joke instead of the skills.

Strip: West Side-project story (CommitStrip, 2014).

Side projects still cost something. Sleep. 😴 Relationships. The trap of using "hustle" to skip rest. I will not tell you every engineer needs a perfect GitHub graph. That is not wellness. It is stress with a brand. 😬

The useful idea is smaller: if you already build on the side, stop treating it like a character flaw. Call it practice that stacks over time, then guard your time like a grown person. A side project that ships in six weeks with weekends intact beats a "rewrite everything" dream that eats six months of guilt.

What I would do differently 🧭

I would pick smaller scope and celebrate done more loudly. I would treat docs as part of the product, not an afterthought, because future me is also a user. 📝

I would split real learning from "learning for the feed." Some spikes stay private. Not everything needs a post. The value still lands in your head. 🧠

Most of all, I would stop forcing side projects to prove themselves in the same frame as my job. They are not copies of each other. They are different gyms. One pays your salary. The other builds more choices, speed, and confidence when you see a work problem no one filed yet.

If you are building something odd this weekend and part of you feels guilty for not "optimizing" your career, that build might already be the optimization. Ship the smallest version. Ship it. Then step away.

The compound part was never the repo. It was the person all those reps built. ✨

Originally published at souravdey.space.

LeetCode #376: Wiggle Subsequence

Sourav Dey — Tue, 31 Mar 2026 13:59:03 +0000

LeetCode Question - 376. Wiggle Subsequence 🧠

About the Series

Problem-solving is a key skill set for any tech-related stuff you might be working on.

When it comes to developers it's one of the most crucial skills which is needed in almost any day-to-day code you might be writing.

So, this series of blogs is all about practicing Daily LeetCode Challenges & Problem-solving. 🚀

Earlier in this series: LeetCode #1465: Maximum Area of Cake After Cuts.

Problem Statement

Wiggle Subsequence

A wiggle sequence is a sequence where the differences between successive numbers strictly alternate between positive and negative. The first difference (if one exists) may be either positive or negative. A sequence with one element and a sequence with two non-equal elements are trivially wiggle sequences.

For example, [1, 7, 4, 9, 2, 5] is a wiggle sequence because the differences (6, -3, 5, -7, 3) alternate between positive and negative.

In contrast, [1, 4, 7, 2, 5] and [1, 7, 4, 5, 5] are not wiggle sequences. The first is not because its first two differences are positive, and the second is not because its last difference is zero. A subsequence is obtained by deleting some elements (possibly zero) from the original sequence, leaving the remaining elements in their original order.

Given an integer array nums, return the length of the longest wiggle subsequence of nums.

Video Explanation

Watch on YouTube

Solution

Algorithm

First check if the length of the nums array is smaller than two or not. If yes, we will simply return the length of the array ie. 0 for [] and 1 for [x] (where x can be any value)
We check the first difference between the 1st from the 0th value in the nums array and store it in the previousdiff
If the values are not equal we will count both the no. for the wiggle sequence thus our counter will be 2 and if equal we take our counter to be 1
Now, While iterating the nums array we will compare the compare current difference and the previous difference. If one is positive the other should be negative or vice versa. Now, we will increment the count if the conditions are satisfied and update the previous difference with the current difference.
Finally return the count of the wiggle sequence.

Code in JS 🧑‍💻

/**
 * @param {number[]} nums
 * @return {number}
 */
var wiggleMaxLength = function (nums) {
  if (nums.length < 2) {
    return nums.length;
  }
  var previousdiff = nums[1] - nums[0];
  var counter = previousdiff != 0 ? 2 : 1;

  for (var i = 1; i < nums.length; i++) {
    const currentDiff = nums[i] - nums[i - 1];
    if (
      (currentDiff > 0 && previousdiff <= 0) ||
      (currentDiff < 0 && previousdiff >= 0)
    ) {
      counter++;
      previousdiff = currentDiff;
    }
  }
  return counter;
};

Time Complexity : O(n)

Space Complexity: O(1)

You can find me on the web 🌍

Add your solution or approach in the comments below. Also, show your love by Sharing the blog. 🤗

"Dream big. Start small. But most of all, start."

~ Simon Sinek

Originally published on July 3, 2022 at souravdey.space.

LeetCode #1465: Maximum Area of Cake After Cuts

Sourav Dey — Tue, 31 Mar 2026 13:59:01 +0000

LeetCode Question - 1465. Maximum Area of a Piece of Cake After Horizontal and Vertical Cuts 🍰

About the Series

Problem-solving is a key skill set for any tech-related stuff you might be working on.

When it comes to developers it's one of the most crucial skills which is needed in almost any day-to-day code you might be writing.

So, this series of blogs is all about practicing Daily LeetCode Challenges & Problem-solving. 🚀

Earlier in this series: LeetCode #1710: Maximum Units on a Truck.

Problem Statement

Maximum Area of a Piece of Cake After Horizontal and Vertical Cuts 🍰

You are given a rectangular cake of size h x w and two arrays of integers horizontalCuts and verticalCuts where:

horizontalCuts[i] is the distance from the top of the rectangular cake to the ith horizontal cut and similarly, and

verticalCuts[j] is the distance from the left of the rectangular cake to the jth vertical cut.

Return the maximum area of a piece of cake after you cut at each horizontal and vertical position provided in the arrays horizontalCuts and verticalCuts. Since the answer can be a large number, return this modulo 109 + 7

Video Explanation

Watch on YouTube

Solution

Algorithm

Push 0 and h in the horizontalCuts.
Sort the horizontalCuts array in Ascending Order.
Take the maximum difference between the cuts by iterating on the list of horizontalCuts
Push 0 and h in the horizontalCuts.
Sort the horizontalCuts array in Ascending Order.
Take the maximum difference between the cuts by iterating on the list of horizontalCuts
Multiply both the max values and return the modulo 10^9 + 7
Now, we got the largest piece of Cake 🍰

Code in JS 🧑‍💻

/**
 * @param {number} h
 * @param {number} w
 * @param {number[]} horizontalCuts
 * @param {number[]} verticalCuts
 * @return {number}
 */
var maxArea = function (h, w, horizontalCuts, verticalCuts) {
  horizontalCuts.push(0, h);
  horizontalCuts.sort((a, b) => a - b);
  var maxH = 0;
  verticalCuts.push(0, w);
  verticalCuts.sort((a, b) => a - b);
  var maxW = 0;

  for (var i = 1; i < horizontalCuts.length; i++) {
    maxH = Math.max(maxH, horizontalCuts[i] - horizontalCuts[i - 1]);
  }

  for (var j = 1; j < verticalCuts.length; j++) {
    maxW = Math.max(maxW, verticalCuts[j] - verticalCuts[j - 1]);
  }

  return (BigInt(maxH) * BigInt(maxW)) % BigInt(1e9 + 7);
};

Time Complexity : O(nlogn)

Space Complexity: O(1)

You can find me on the web 🌍

Add your solution or approach in the comments below.

Show your love by Sharing the blog. 🤗

“The best way to predict the future is to create it.”

~ Peter Drucker

Originally published on July 2, 2022 at souravdey.space.

Product Engineering: The Only Skill That Survives AI 🏗️

Sourav Dey — Mon, 30 Mar 2026 08:16:54 +0000

I've been building customer-facing products for seven years now. From the Test Creation Experience used across 1.9M+ tests at HackerRank to GPT-4o powered features in production, I've seen what separates products that stick from those that get shelved after three months of development.

Here's what I've learned: the only limitation in the AI era is product thinking.

The AI Acceleration Problem

Everyone's talking about AI making us 10x faster. Write a prompt, get a component. Describe a feature, get working code. The demos are compelling. The productivity gains are real.

But here's what nobody's talking about: speed without direction is just expensive motion.

I see engineers shipping faster than ever and wondering why their features don't land. They can build anything now. The question they can't answer is: what should I build? 🤔

That gap is product engineering.

What Product Engineering Actually Means

Product engineering isn't about choosing React over Vue. It's not about microservices architecture or deployment pipelines.

Product engineering is building with the user's problem as your north star, not the technology.

Back in 2023, I was discussing my promotion with my manager at HackerRank. Around the same time, I stumbled upon Gergely Orosz's The Product-Minded Software Engineer on The Pragmatic Engineer blog. Reading it felt like someone had written down exactly what I do. Every trait he described, from proactive product ideas to end-to-end feature ownership, mapped to how I have been working for years. That article became my pitch for the promotion. I've never been the strongest "pure coder" in the room, but I've always been a solid product engineer. That's what sets me apart 💪 There is another book on this, The Product-Minded Engineer (November 2025) by Drew Hoskins, and it reinforces the same core truth: the engineers who have the most impact are the ones who care deeply about the product, not just the code.

When we built the Test Creation Experience at HackerRank, the engineering challenge wasn't the hardest part. The hard part was understanding that recruiters weren't failing to create tests because our UI was clunky. They were failing because they didn't know what good technical questions looked like in the first place.

The feature that moved the needle wasn't better form validation. It was a question recommendation engine that suggested problems based on the role they were hiring for.

Product engineering is seeing the gap between what users say they want and what they actually need.

For the longer career arc behind that idea, see seven years as a software engineer. For shipping under a brutal clock with a product-shaped goal.

Why AI Makes This More Critical, Not Less

In 2019, if you wanted to build a feature, you needed to:

Design the database schema
Write the API endpoints
Build the frontend components
Handle edge cases and error states
Deploy and monitor

That took weeks. The friction forced you to think: is this worth building?

In 2026, I can describe a feature to Claude and have working code in 20 minutes. The friction is gone. The forcing function for good judgment disappeared. 🫠

Now anyone can build anything. The engineers who survive aren't the ones who can prompt better. They're the ones who know what's worth building.

The Obsession With "Great Engineering"

I've worked with brilliant engineers who could optimize a database query from 200ms to 15ms, architect systems that handle millions of requests, and debug race conditions in distributed systems.

Some of them built features nobody used. 😅

The ones who had impact? They started every conversation with: "What problem are we solving, and for whom?"

They asked questions like:

Who specifically has this problem?
How do they solve it today?
What would make them change their workflow?
How do we know if we fixed it?

Those questions matter more than knowing the latest JavaScript framework.

My Product Engineering Principles

After seven years and dozens of shipped features, here's what I've learned:

1. Fall in love with the problem, not your solution.
I've killed features I spent months building because user research showed we were solving the wrong problem. It hurt. But shipping the wrong thing perfectly is worse than not shipping at all.

2. Build for one person first.
Every successful feature I've shipped started with understanding one specific user's workflow in detail. Generic "user personas" don't build products. Real humans with real problems do.

3. The best code is code you don't write.
Before building anything, ask: what's the simplest thing that could work? Half the features I thought I needed to build turned out to be configuration changes.

4. Measure behavior, not opinions.
Users will tell you they want feature X. Then you build feature X and nobody uses it. Watch what they do, not what they say they'll do.

The AI Era Divide

I predict a split in our industry:

AI-Assisted Code Writers: Fast at implementation, focused on technical craft. They can build anything you spec out.

Product Engineers: Focused on what to build and why. They use AI as a tool to ship faster, but they're solving the right problems.

Both roles matter. But if you're building customer-facing products, you need to be in the second category.

The companies that win in the AI era won't be the ones with the best AI engineers. They'll be the ones with the best product engineers who happen to use AI. 🚀

What I'd Do Differently

If I were starting my career today, I wouldn't spend time learning every new framework or AI tool that comes out.

I'd spend time with users. I'd sit in customer support calls. I'd read every piece of feedback. I'd understand how people actually work, not how I think they should work.

The frameworks change every two years. Understanding humans compounds forever.

Product engineering isn't a nice-to-have anymore. In the AI era, it's how you stay relevant.

The future belongs to engineers who can think like builders, not just coders. AI will handle the coding part. The building part still needs humans. ✨

Originally published on March 30, 2026 at souravdey.space.

7 Years as a Software Engineer: What Actually Changed 💼

Sourav Dey — Wed, 25 Mar 2026 14:10:14 +0000

Green build. Staging fine. I still walked away feeling off 💻

The code did what we agreed on. The agreement was the broken part. That week stuck with me more than any refactor I have shipped since.

Seven years in, I still write code. I also still Google things I have looked up a hundred times, and I am fine admitting that. The job stopped being mostly syntax ages ago. It moved into requirements nobody wrote down, roadmaps that pretend six things are one thing, and the gap between what product imagines and what the system can honestly do. You feel that gap in your calendar before you feel it in the compiler.

I am not going to give you a promotion timeline or a framework bingo card.

Here is what moved in how I work, and what I would say to the version of me who was scared of sounding dumb in standup 🙈

🧭 The first shift: when “it runs” is not the win

Early on I treated success like a checklist. Tests pass ✅ PR merged. Done. That bar matters. You cannot skip it.

The first time it failed me was ordinary. Everything behaved in staging, users were still unhappy, and the bug was the assumption behind the feature, not a null pointer.

These days I slow down before I type. Who is this actually for? What happens at 10x traffic? What is the cheapest way to prove we are wrong? I used to think those questions were someone else’s job.

They are the job 🎯

Hackathons taught me scope is the real villain 🏃 Side projects taught me demos follow their own physics. HackerRank taught me the expensive problems sit between intent and reality. Same muscle, different costumes.

🌫️ Ambiguity stopped feeling like a personal failure

Junior me assumed if I asked enough questions in one Slack thread, uncertainty would pack up and leave.

It does not work that way. Some fog only lifts after there is a real thing to poke at.

I stopped pretending I had it all figured out on day one. I try to pick a step we can undo, say the tradeoff out loud, and invite correction early. A rough prototype still beats a three-day thread. A written assumption beats a silent guess every time ✍️

I mentored at a hackathon once (notes from CentuRITon), on the other side of the table. The struggling teams were rarely lazy. They were drowning in parallel goals 🌊 Helping them kill features felt like coaching courage, not debugging. I still use that instinct when a roadmap tries to ship six epics like they are one.

⚖️ Speed, quality, and the lie of having both for free

You have heard both sermons.

Move fast and break things. Quality is non-negotiable. Real teams live in the middle and rarely say the quiet part out loud.

What helped me was naming the tradeoff in a room full of people. If we optimize for learning speed, we accept rough edges and we instrument them. If we optimize for reliability, we skip shortcuts and we staff for that choice. The painful failure mode is when leadership says one priority and the calendar and incentives say another. Then you get slow and brittle together.

No prize 💥

I still misread that alignment sometimes. I just catch it faster.

Sounds tiny. It cost a lot of Tuesday evenings to get there 🩹

💬 Communication is not fluff. It is part of the ship.

I am not the person who “only wants to code.” Not because I love calendars 📅 Because when alignment drifts, it shows up as reverts, sharp tickets, and that quiet distrust nobody puts in writing.

A decent PR description. A diagram someone can find next month. A short note on why we picked this shape. Those things feel soft until you pay for not having them.

When I built this portfolio in public, I realized people read the thinking, not only the pixels. Same thing shows up in code review and design feedback. They are judging whether they can trust your judgment.

🧠 Competence and confidence refuse to stay in sync

Call it imposter syndrome or call it a brain that loves your mistakes more than your wins.

Same glitch.

I stopped waiting for the doubt to vanish. I keep boring receipts now. What shipped. What broke. What I fixed. What someone else shipped because I unblocked them.

Loud moments under pressure helped once. They do not cure anything. They just remind you that you have done hard things before. Without the small receipts, one bad deploy on a random Tuesday eats the whole story 📉

🧰 What actually aged well

Syntax turns over. Tools churn 🔄

The skills that kept paying were unglamorous. Reading a stack trace without ego. Tracing a bug across services and saying which layer lied 🐛 Knowing when a library saves time and when it hides the learning you still need.

Any fool can write code that a computer can understand. Good programmers write code that humans can understand.

— Martin Fowler

I still enjoy a gnarly bug.

I enjoy it less when the gnarl exists because nobody wrote how the system is supposed to behave. Docs are not admin homework. They are kindness to whoever is on call at 11 PM 🌙 Future you counts.

🤝 Leadership without the title

Influence is not a level on a ladder.

It shows up in a clearer ticket, a safer rollback plan, a review comment that teaches instead of scores points. Sometimes it is saying I do not know when everyone else is improvising confidence 🤷

I have spent five years at HackerRank now 🌱 Sustained product engineering, for me, is not heroics. It is ownership. It is the quiet work of keeping a platform understandable while it grows.

✉️ What I would tell past me

Ask earlier. Ship smaller. Write down why you chose something, not only what you built.

Guard your attention the way you guard uptime, because it is the same finite resource.

Busy is not the same as useful. I am still learning that last one ⏳

🪨 What still feels hard

Saying no without becoming the villain in someone else’s story. Estimating when the information is incomplete, without faking precision. Staying curious when the backlog is shouting. Remembering the win is not owning the thread. It is leaving the system less confusing than you found it.

Seven years is not mastery 🎓

It is enough repetitions to spot the same traps: fake urgency, complexity sold as intelligence, teams confusing motion for progress. Enough time, too, to feel grateful for people who raised the bar 🙏 and a little gentler with myself when I was the bottleneck.

If you are earlier in the curve, the takeaway is smaller than everyone makes it sound.

Show up. Say the risky true thing. Make the next step obvious. Keep building.

The code is only one part of the craft ✨

Originally published on March 25, 2026 at souravdey.space.

⚡ Flexbox-Guide 🚀 Flexbox layout made simple with an Interactive tool

Sourav Dey — Wed, 14 Apr 2021 08:49:49 +0000

TLDR

An Interactive Tool for the concept of Flexbox and Responsive Design. Simply set the attributes as needed and copy the CSS code. 🎉

Website Link - http://flexbox-guide.vercel.app/

Github Repo - https://github.com/Souravdey777/flexbox-guide

Docs Link - https://souravdey777.github.io/flexbox-guide/

About `Flexbox-Guide`

Flexbox-Guide is a website developed for web developers and Coding newbies learning CSS Flexbox Layout. This website can be used for both learnings or generating the code. Simply arrange the flex items as you need and copy the CSS to your code.

Before the Flexbox Layout module, there were four layout modes:

Block, for sections in a webpage
Inline, for text
Table, for two-dimensional table data
Positioned, for the explicit position of an element

The Flexible Box Layout Module makes it easier to design a flexible responsive layout structure without using float or positioning.

For a detailed explanation please check A Complete Guide to Flexbox by Chris Coyier

Why wait? Straightaway go to the website and join the Awesomeness 😎
https://flexbox-guide.souravdey777.vercel.app

Inspiration 💡

I got the Idea while I was explaining flexbox to a few of the interns in my office. I was explaining to them with three sample cards that how to make responsive cards with flexbox. And I have seen a lot of web developers using static paddings and margins and handling it with a lot of media queries. But, why go for such a mess when we have the CSS flexbox layout.

This tool was also created with the same thought process. So that all the budding software developers can learn flexbox layout with an interactive tool, where you can set the attributes and check the layout as well as It will generate the CSS code for it.

Technologies 🔨

Built with Reactjs and Love ❤️

Hosted in Vercel Cloud.

Accomplishment 🚀

I have integrated 📈 analytics with plausible with the website recently on the 29th of Jan and here are the stats https://plausible.io/flexbox-guide.vercel.app.

It also got published in a Weekly Magzine for Designers 🎉
https://speckyboy.com/weekly-news-for-designers-577/

The greatest of all is that It will help the community.

License

📝 Distributed under the MIT License. See LICENSE for more information.

Contribution and Support

Upvote Flexbox-Guide in 🚀 Product Hunt.

Open a Pull Request or Raise an Issue.

👨‍🚀 Contributions are what make the open-source community such an amazing place to learn, inspire, and create. Any contributions you make are greatly appreciated.

Hope you Loved it! Do let me know in the comments.

Want to learn more about flexbox?? Check the below link
https://souravdey777.github.io/flexbox-guide/#learn-more-about-flexbox

Contact me

Creating your own npm package

Sourav Dey — Sun, 11 Apr 2021 12:18:17 +0000

First of all, What is npm?

npm is two things: first and foremost, it is an online repository for the publishing of open-source Node.js projects; second, it is a command-line utility for interacting with a said repository that aids in package installation, version management, and dependency management. A plethora of Node.js libraries and applications are published on npm, and many more are added every day.

☝ This is not out of my brain. 🧠

Reference to the definition
https://nodejs.org/en/knowledge/getting-started/npm/what-is-npm/

Setting the things up

What you need to start is with simple Node.js installation and yes, that is it.
Refer to the below links 👇

How to install Node.js

Download link for Node.js

Let us break this down into simple steps

1. Creating the package.json file

For publishing an npm package you don't need anything apart from package.json. But, yeah it will not be having any functionalities.

There are two ways to create the package.json file. You can simply open any code editor and go for the good old-fashioned way of editing it yourself. I will suggest trying it once. You will get to know how to and what to add as key-value pair in the JSON file.

{
    "name": "your-amazing-package",
    "version": "1.0.0",
}

This is the minimum key-value pair that is required to publish a package

But, again if you want things to be done efficiently. Create the package.json with the below command

npm init

Follow the instructions and enter the details one after another and after that just select enter after confirming the details.

This is how your Package.json is going to look after that 👇

{
  "name": "awesome-npm",
  "version": "1.0.0",
  "description": "the awesome package",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "repository": {
    "type": "git",
    "url": "git+https://github.com/YOUR_Git_USERNAME/awesome-npm.git"
  },
  "keywords": [
    "awesome"
  ],
  "author": "Sourav Dey",
  "license": "MIT",
  "bugs": {
    "url": "https://github.com/YOUR_Git_USERNAME/awesome-npm/issues"
  },
  "homepage": "https://github.com/YOUR_Git_USERNAME/awesome-npm#readme"
}

We have the package.json ready. Now, index.js comes to the picture that is defined in pacakge.json as "main": "index.js"

2. Creating the index.js file.

Let's create a simple function in the index.js file. 👇

function awesomeEmojiLog(message) {
    if (message === undefined) throw new Error("No Message Found");
    console.log("😎", message)
};

module.exports = awesomeEmojiLog

It is any day better to test your function before publishing it.
It can be easily called inside index.js as

awesomeEmojiLog("This is awesome emoji")

Test it with a simple command

node index.js

The output will be

😎 This is awesome emoji

Once done. It is now time to publish it.

3. Publish the npm package

To publish an npm package you first need to create an account in the npm registry with this link 👉 Signup for npm.

Done. Cool.

npm login

npm adduser

Enter the username, password, and email ID as asked.

After that, you are one command away from your npm package. Just type this

npm publish

Note- If your package name starts with "@Your-username/packageName"

use the below command.

npm publish --access=public

🎉🥳 The npm package is Published. You will get a mail for the same and You can check your list of packages in the npm registry if you are logged in.

4. Create the Github Repo for your package.

Create your repo awesome-npm and push the code.

Follow the command to push the code.

echo "# awesome-npm" >> README.md
git init
git add .
git commit -m "first commit"
git branch -M main
git remote add origin https://github.com/Souravdey777/awesome-npm.git
git push -u origin main

Add the Licence for your package. I have used MIT.

Write the package's basic details in the Readme file like how to use it and what it does. Now, you can Create a new release for the npm package with proper versioning.

you can check the repo for reference 👉
https://github.com/Souravdey777/awesome-npm

and the npm package 👉
https://www.npmjs.com/package/awesome-npm

😎

Your awesome npm package is ready. 🎉🎉

Hope you Loved it! Do let me know in the comments.

Forem: Sourav Dey

My Blog Syndication Strategy 📣

The workflow at a glance

What those two commands actually do

Canonical first

What the actual loop looks like

What the GitHub Actions actually do

What that conversion code is really doing

The GitHub issue checklist

Why I still syndicate

The tradeoffs are real

What I would do differently

Facebook Developer Circle 🏆 - Open Source Immersion Challenge 2020

What is Facebook Open Source Immersion Challenge?

Steps to Participate

Here is the list of Pull Requests:

Finally, Got the email

Achieved Swags from Facebook for being in the top 1000 of the Open Source Developer Immersion 2020

Contact me

Winning the HackGPT 2.0 Hackathon: 2nd Runner-up Position 🧑🏻‍💻

🎯 The Problem: Scoring Developers on a Single Axis

🗺️ Designing a Holistic Skill Profile

🏗️ The Architecture (Plus 12 Cups of Coffee)

⏪ My Contribution: Turning Keystrokes into a Time Machine

📊 What the AI Reviewer Actually Outputs

🌙 24 Hours of In-Office Hackathon Culture

🚀 From Hackathon to Product

💡 What I Learned

Why Side Projects Compound 🏗️

What side projects teach beyond your job 🧾

What compounding means for side projects 📈

Side projects are not free ⚖️

What I would do differently 🧭

LeetCode #376: Wiggle Subsequence

LeetCode Question - 376. Wiggle Subsequence 🧠

About the Series

Problem Statement

Video Explanation

Solution

Similar Questions for practice

You can find me on the web 🌍

LeetCode #1465: Maximum Area of Cake After Cuts

LeetCode Question - 1465. Maximum Area of a Piece of Cake After Horizontal and Vertical Cuts 🍰

About the Series

Problem Statement

Video Explanation

Solution

You can find me on the web 🌍

Product Engineering: The Only Skill That Survives AI 🏗️

The AI Acceleration Problem

What Product Engineering Actually Means

Why AI Makes This More Critical, Not Less

The Obsession With "Great Engineering"

My Product Engineering Principles

The AI Era Divide

What I'd Do Differently

7 Years as a Software Engineer: What Actually Changed 💼

🧭 The first shift: when “it runs” is not the win

🌫️ Ambiguity stopped feeling like a personal failure

⚖️ Speed, quality, and the lie of having both for free

💬 Communication is not fluff. It is part of the ship.

🧠 Competence and confidence refuse to stay in sync

🧰 What actually aged well

🤝 Leadership without the title

✉️ What I would tell past me

🪨 What still feels hard

⚡ Flexbox-Guide 🚀 Flexbox layout made simple with an Interactive tool

TLDR

About Flexbox-Guide

Inspiration 💡

Technologies 🔨

Accomplishment 🚀

License

Contribution and Support

Contact me

Creating your own npm package

First of all, What is npm?

Setting the things up

Let us break this down into simple steps

1. Creating the package.json file

About `Flexbox-Guide`