Coder Legion - Recent posts tagged discussion

Introducing The Startup Café: A Community for People Building Startups ☕

Tue, 20 Oct 2026 19:15:24 +0000

I Started The Startup Café on DEV. Here's the Idea Behind It.
I've just started a new organization on DEV called The Startup Café, and I wanted to share it here while it's still at the very beginning.

Here's the organization: https://dev.to/startupcafe

The idea came from something pretty simple: there's a lot to learn from people who are building things, even when they're working on completely different projects.

Some developers build things for clients. Some work on side projects after their day job. Some are trying to launch a SaaS, while others are still figuring out which idea is worth pursuing.

I've always found that side of building interesting. Not just seeing what someone has launched, but understanding why they started, what they're figuring out, and what they've learned along the way.

I'd like The Startup Café to be a place for those conversations.

What do I have in mind?

I don't want this to be just another place to drop a project link and move on.

I'd like people to share what they're working on, ask for feedback when they're stuck, write about things they've learned, and discover projects they might not have found otherwise.

Maybe you're building your first website. Maybe you're working on a SaaS and trying to find your first users. Maybe you've got an open-source project, or an idea you keep coming back to but haven't started yet.

All of those are worth talking about.

You don't need to have a successful startup or years of experience to take part. Sometimes the most interesting discussions come from people who are still working things out.

I'd also love to see people connect through the organization. You might find someone dealing with the same problem, discover a project you want to contribute to, or meet a developer who's interested in building something similar.

There's no guarantee of where those conversations will lead, but that's part of what makes a community interesting.

It's just getting started

I want to be clear that The Startup Café is brand new. I'm not introducing an established community with a big audience or claiming we've already built something huge.

I'm starting small, and I'd like the people who join to have a say in what this becomes.

What would make it useful? What kinds of posts would you like to see? Would you be interested in sharing your progress, getting feedback, finding collaborators, or learning from other people's experiences?

Those are the kinds of questions I'd like us to figure out together.

Interested in joining?

The Startup Café is a DEV.to organization, and that's where the community will come together.

You can visit the organization here:

https://dev.to/startupcafe

I've also built a small website for it. If you'd like to join, you can visit the website to learn more and submit an application:

https://thestartupcafe.vercel.app

If this sounds like something you'd enjoy being part of, I'd be glad to have you check it out.

And even if you're not ready to join, I'd still appreciate hearing your thoughts.

So, what are you building these days?

It can be a startup, a side project, an open-source contribution, or just an idea you're considering. I'd love to hear what you're working on and where you are with it.

Let's start there.

Would you use free assets in your games?

Sat, 10 Oct 2026 14:55:56 +0000

I would, and I don’t think there’s any shame in it.

I’ve never really understood the stigma around using free assets in game development. Sometimes, people talk about them as if downloading a free model or sound somehow makes the rest of your work less valuable.

But why?

For anyone unfamiliar with the term, assets are the individual things that go into a game: trees, buildings, characters, sounds, animations, textures, and so on. Making all of those takes time, and creating a game involves much more than making its individual parts.

If someone offers a useful asset for free and allows others to use it, I see that as an opportunity.

Free doesn’t mean bad.

The price of an asset doesn’t tell you whether it looks good, works properly, or fits your game. A paid model can be unsuitable for your project, while a free one can be exactly what you need.

Some creators choose to share their work because they want to help other developers. Kenney, for example, makes its game assets available under CC0, allowing people to use them without requiring credit. These resources are offered for a reason: so people can build with them.

There’s nothing embarrassing about accepting that help.

Your time matters, too.

Imagine you need a simple chair for a room in your game. You could spend days learning how to model it, give it the right surface details, and get it working in the engine. Or you could find a suitable free chair and spend that time improving something the player will actually do.

Neither choice is automatically wrong. If you want to learn how to make furniture, creating the chair yourself makes sense. If your goal is to finish a playable game, using an existing one might make more sense.

Personally, I don’t think developers should feel pressured to spend days proving they can make an ordinary chair when their game needs attention elsewhere.

That time could go towards a better mission, smoother movement, clearer menus, or fixing an annoying bug.

A downloaded asset doesn’t build the game for you.

This is probably the part that gets overlooked most often.

Downloading a door doesn’t make it open. You still need to decide how the player interacts with it, whether it needs a key, what happens when it’s locked, and how it connects to the rest of the game.

Downloading trees doesn’t create an interesting forest. You still have to build the space, create paths, place things thoughtfully, adjust the lighting, and make sure the game runs well.

The person who made the asset did valuable work. The person who turns it into part of a playable experience also does valuable work.

Using someone else’s model doesn’t erase everything you built around it.

You can use the same pieces and create something different.

Two people can cook with the same ingredients and make very different meals. I think game assets work in a similar way.

The same house model could become a peaceful home in one game and an abandoned building in another. Different lighting, sounds, surroundings, and events can completely change how that place feels.

Custom artwork can certainly help a game stand out. But a game’s identity also comes from its ideas, its atmosphere, its story, and the way it plays.

Every rock and table doesn’t need to be exclusive for the overall experience to feel personal.

Free assets help you find out whether an idea actually works.

An idea can sound amazing when you write it down and feel completely different once you try to play it.

Having models, sounds, and animations available lets you reach that playable stage sooner. You can test a mechanic, try a different layout, or discover that something needs changing before spending months making everything yourself.

And if a free asset still works well in the finished game, why replace it purely because it was free?

I’d rather replace something because it doesn’t fit or causes problems, not because I feel guilty about how much it cost.

Not everyone has a studio’s budget.

A solo developer might be handling the gameplay, environments, menus, sound, testing, and writing. That’s already a lot for one person.

They may not have the money to hire people for every task, or the years needed to become good at every part of development.

Free assets make it easier for people to learn and give their ideas a real chance. They can also leave room in the budget for things that need special attention: perhaps an original main character, music, or an important location.

Using free resources where they fit can help you afford custom work where it matters most.

Of course, you still need to choose carefully.

I’m not saying every free asset belongs in every game.

Some won’t match the look you’re going for. Some might slow the game down or take too much effort to adjust. You also need to check what the creator allows you to do with them and give credit when required.

And you should be honest about your contribution. Using someone’s model is fine when you have permission. Claiming you made that model yourself is a different issue.

Those are fair things to discuss. But none of them makes using free assets shameful.

Judge the result.

If a game looks messy, runs badly, or isn’t enjoyable, those are fair criticisms. Explain what isn’t working.

Simply saying “that’s a free asset” doesn’t tell me what’s wrong with the game. Paying for the same object wouldn’t suddenly make the gameplay better.

For me, the question is simple: does this asset fit what I’m making, and does using it help me move the project forward?

If the answer is yes, I’m happy to use it.

I respect people who create everything themselves. I also respect people who know where to spend their time and use the resources available to them.

So yes, I would use free assets in my game. Why should a useful resource become something to be ashamed of just because it didn’t cost money?

the evolution of software development since the emergence of AI

Fri, 09 Oct 2026 09:51:04 +0000

It would be interesting to promote discussions on the evolution of software development since the emergence of AI, and how it has been transforming the sector and the jobs of many developers. In my experience, it's not advisable to swim against the current, so it would also be valuable to create a dedicated section to discuss and build technical AI applications that can boost our productivity and allow us to create more complex, useful developments that non-technical users cannot achieve.

Do you think the emergence of AI is a positive or negative event for software developers?

Hacktoberfest Stopped Counting PRs. So What Counts as a Contribution Now?

Sat, 03 Oct 2026 12:42:47 +0000

Hacktoberfest 2026 no longer rewards pull requests, and I think the change forces a useful question on all of us: if a contribution is not a merged diff, what is it?

The organisers' reason is short. Their FAQ says it is "easier than ever to submit low-effort spam PRs to projects," so they listened to maintainers and stopped incentivising them. This year MLH and DEV run the month with DigitalOcean presenting, under the theme "AI Belongs to Everyone." You earn stickers by attending local Fests, joining Global Hack Week (October 9 to 15), entering DEV challenges and similar activities.

The history makes the decision easy to understand. The first Hacktoberfest in 2014 had 676 participants and a simple rule: four pull requests, one t-shirt. By 2020 there were nearly 170,000 sign-ups and more than 621,000 pull requests, enough README spam that maintainers compared it to a denial-of-service attack. The rules tightened to opt-in repositories and maintainer acceptance. Last year the bar went from four accepted PRs to six. Then AI tools made a plausible patch cost seconds to produce, while reviewing one costs what it always did. Counting stopped meaning anything.

I have been involved in open source since 1999, much of it teaching people to use Linux and Git and running infrastructure on them. Very little of the work that keeps a project healthy would ever show up in a PR count: reproducing a bug on a different machine, answering the same question for the fifth time, writing down how something behaved so the next person does not have to find out the hard way, or teaching someone to use the tools in the first place.

A 2024 Harvard Business School study estimated that 96 percent of open source's demand-side value comes from 5 percent of developers. That small group's scarce resource is attention. The most useful contributions spend less of it, or add to it.

So here is my working list of what counts this October, offered as a starting point rather than a rule:

reproducing a reported bug on the current release, and saying so on the issue
reducing a failing test to its smallest case
fixing documentation that misled you, while you still remember how
reviewing someone else's pull request carefully and leaving specific questions
disclosing the AI tools you used and which parts of a change they touched, in the spirit of the Linux kernel's rule: "You are expected to understand and to be able to defend everything you submit"
building something with an open-weight model and writing down the exact model, digest and licence, plus what the release did not tell you

That last one connects to this year's theme. Open weights let you run, test and fine-tune a model on your own hardware. Most releases do not publish training data or full training code, so you cannot reproduce or audit how the model was made. The OSI's Open Source AI Definition asks for both. Knowing where a model's openness ends is part of using it responsibly.

I would like to hear from people here, especially anyone who maintains a project. What kind of contribution helps you most, and what would you want a Hacktoberfest participant to do this month that no counter would ever see?

Sources: Hacktoberfest 2026 (MLH) · Hacktoberfest FAQ · DigitalOcean 2020 recap · DigitalOcean 2025 wrap-up · HBS: The Value of Open Source Software · Linux kernel guidelines for tool-generated content · OSI Open Source AI Definition 1.0

Where Should Developers Write? A Practical Comparison of LinkedIn, Medium, Dev.to, and CoderLegion

Sun, 27 Sep 2026 17:55:21 +0000

I've published on all four platforms and get asked which one to use. The honest answer: it depends on what you're trying to accomplish. Here's how I think about each one.

LinkedIn - Entry Point, Not Destination

LinkedIn is best used as a conversation starter. Put a provocative question, a key takeaway, or a short observation in the post, then include the link to the full article on Dev.to, CoderLegion, or Medium in the first comment. This utilizes LinkedIn's strengths (professional reach, cross-border visibility) without asking it to do what it's bad at: hosting deep technical content. Think of it as the top of a funnel, not where the real discussion takes place.

Medium - for Storytelling and Long-Form Thought Leadership

Medium is ideal for writing enduring works such as career reflections, architectural post-mortems, and in-depth essays. The Partner Program adds a monetisation path. The main downside is discoverability: new posts get buried quickly and are difficult to find unless you are already in a publication or have an existing audience driving traffic there. Medium rewards writers who bring in their own readers, but it does little to surface new voices on its own.

Dev.to - for Tutorials and the Learning Community

Dev.to is the most beginner-friendly of the four. It's open, free, and the tag system makes technical tutorials easy to find. It's a good home for "how I built X" posts, quick tips, and beginner content. The weakness is that high posting volume makes it easy for solid posts to get buried quickly, and platform support can be slow. A post indexing issue I reported took over a month to be addressed. The community is welcoming but responses can be sparse unless your post gets picked up early.

CoderLegion - for Community Feedback and Visibility Without an Existing Audience

What I appreciate most about CoderLegion is the community responsiveness, people actually read and comment, rather than just scroll. The Trending and Promotion tags give newer posts and newer members a real shot at visibility from the home page, which the other platforms largely don't offer.

One feature worth highlighting is the Developer's Journey sharing group, which is designed specifically for developers (both senior and junior) to share their progress and learn from each other's experiences. It creates a supportive space where growth is visible and celebrated, and it gives newer members additional exposure beyond their own posts. In my opinion, this is a significant differentiator if you are early in your career and seeking a community that actively helps you grow and not just consume content.

If you're just starting out or want genuine peer feedback rather than chasing an algorithm, this is where I'd start. Platform issues I've reported have been addressed far faster than my experience with Medium or Dev.to.

My Rough Rule of Thumb

Role	Platform
Entry point / professional amplifier	LinkedIn
Community discussion + early visibility and growth	CoderLegion
Technical tutorials, how-tos	Dev.to
Long-form essays, thought leadership	Medium

Most experienced developers end up cross-posting to two or three. Write once, adapt the framing, post everywhere that fits.

A Note on CoderLegion

Having the Trending/Promotion visibility model is a real differentiator for newer voices - most platforms bury new posts the moment something more popular is posted. Community and team responsiveness is something worth mentioning out loud: it indicates that the platform is still in a phase where the people building it care about individual members.

Discussion

How would you leverage different platforms to accelerate the development of your projects?

The "Vibe Coder" Reality Check: Validation, Timelines, and Handling Failure

Thu, 24 Sep 2026 13:38:36 +0000

Hey everyone,

I wanted to open up a candid discussion about a reality many self-taught or non-traditional developers face: "vibe coding." We’ve all seen the trend—using AI to spin up code quickly based on a prompt or a "vibe" without necessarily having a formal computer science degree or deep, rigorous training in that specific stack.

If you identify as a vibe coder, or if you are working without a formal engineering background, I’d love to get your insights on a few specific challenges:

How do you actually validate the code?

When you don't have years of formal training in software architecture, how do you ensure the code the AI spits out is safe, efficient, and actually doing what it's supposed to do? What is your personal validation process? Do you rely on manual clicking, writing automated tests with the AI, or just pushing to production and waiting for bug reports?

How long does validation take you?

"Vibe coding" feels incredibly fast at first because the initial code generation takes seconds. However, if you are learning on the fly, how long does the verification and debugging phase actually take you? Does the time spent fixing edge cases wipe out the speed gained from using AI in the first place?

What do you do when everything completely fails?

We all hit that wall where the AI gets stuck in an hallucination loop, the code is a tangled mess of spaghetti, and nothing works. When a feature completely fails and you don't have the deep foundational training to debug it from scratch, what is your next step? Do you scrap the project, seek mentorship, or start a completely new prompt thread?

Let's talk about the real metrics, the struggles, and the best practices for validating AI-generated code when you're figuring it out as you go.

Drop your experiences below!

Best regards,
Momenul Ahmad
Vibe Coder & Tech Explorer

The real AI danger isn't what it says. It's what it does.

Wed, 23 Sep 2026 11:53:33 +0000

Anthropic's September threat report documented AI executing attacks, not just describing them. Here's why that shift, from advising to acting, is the whole game, and the layer we're furthest behind on.

Earlier this month the internet decided AI was going to kill us. A researcher resigned, said the labs are gambling with our lives, said the people building this earnestly believe it could end us by the end of the decade. It was everywhere. If you were online, you saw it.
I'm not going to argue with the fear. I want to point at the quieter document that came out the same week, because it said something more useful, and more precise.
Anthropic published a threat report. Not a prediction: a record. Actual cases, from the last several months, of their models turning up in real attacks. And the finding underneath all of them wasn't "the AI got too smart." It was a change in shape. The danger used to be a conversation, someone asks a model something dangerous, it answers or refuses, and the damage is bounded by that one exchange. What the report documents is different: models wired into agent frameworks, executing the steps of an attack. Not advising on the break-in. Doing it.
Hold onto that distinction, because it's the whole thing.

Advising and acting are different physics

An AI that advises and an AI that acts are governed by completely different rules. When a model tells you how to do something, the worst case is bounded by what you then do with the words. When a model does the thing, reaches out, executes, fans across systems, the worst case is bounded by something else entirely: what it can reach, and whether anything in its path is allowed to say no.
That second bound is the one we're furthest behind on.

We are not new at this

Here's the part I keep coming back to. We have spent a very long time building governance around human action, precisely because action has consequences that advice doesn't. You don't move money without a second signature. You don't ship to production without someone's approval and a record of who pushed the button. Hospitals, banks, power grids, the more an action can hurt, the more machinery we wrap around the moment of acting: who's allowed, what's forbidden no matter who asks, and an honest record afterward of what actually happened.
AI got the ability to act years before it got any of that. We handed it hands and skipped the part where we teach it the rules we put on our own.
The gap isn't intelligence. It's accountability. An agent can be perfectly capable, perfectly well-meaning, and still take an action a standing rule should have stopped, because there was no standing rule, nowhere to put one, and no record that it happened.

Three plain questions

So when an agent is about to act on something real, there are three questions, and in a lot of agent setups today the honest answer to all three is no:
Can a rule set in advance stop this action, no matter how the agent was asked? Not "did we prompt it carefully" a hard rule the model cannot talk its way around.
Is the action confirmed, or just sent? A command accepted is not a thing done. A lot of real-world failure lives in that gap.
And afterward, is there a record that can't be quietly changed? Not a debug log the author can edit. A record you could show someone.

How I've been trying to answer them

These three questions are the ones I've spent a long time trying to answer in code, in an open protocol called DoSync. Not by making the model safer, by putting the governance outside it, where a bad day can't reach. A standing rule lives in a file the operator controls and the model can't argue past: it's checked before anything fires, not requested in a prompt. A long-running action isn't marked done until the device's own telemetry says it finished, silence never counts as success. And every action is written to a hash chain, each entry carrying the hash of the one before it, so the record can't be quietly rewritten without the break showing.
None of that makes the agent smarter, and that's the point. The intelligence stays in the model; the rules, the confirmation, and the record sit under it, where they hold whether the model is having a good day or not.

The apocalypse headlines will keep coming, and some of the fear is earned. But the useful work isn't in the headline. It's in the boring layer underneath: the rules, the confirmation, the record. We built all of it for ourselves already, in every domain where a wrong action costs something.
So I'll ask the way I keep asking myself: in your corner, whatever it is, cyber, fintech, robotics, ops, when an agent acts instead of advises, what actually stops it, and how would you know afterward what it did? Or do we let it act first, and write the rules after something goes dark?

GitHub: github.com/giulianireg-spec/dosync-protocol
Web: https://dosync.dev/
License: Apache 2.0

The Architecture of Thought: AI, Automation & Abstraction Power

Thu, 13 Aug 2026 07:44:00 +0000

My initial instinct upon encountering the topic was to ask myself: have I truly considered engineering hallucinations in Large Language Models, or have I only viewed the phenomenon through basic, factual definitions? The dominant narrative across the internet remains completely one-sided, treating hallucination as a simple technical flaw rather than an architectural reality.

While an LLM's statistical decoding certainly produces unprompted errors at the output level, treating the machine as an independent agent misses the broader architectural point. In truth, artificial intelligence is merely a reflection of the people who built and guided it. We operate on implicit assumptions, and the model manifests those gaps as structural failure. We built the machine, yet we expect perfection—without defining in what aspect, precisely. If computing remains fundamentally "garbage in, garbage out," then incorrectly programming the order of operations will naturally yield broken results. AI is strictly an assistant designed to execute our thoughts at scale, not to think on our behalf. When you conceive an idea with precision, articulate it clearly, and verify the output, the assistant becomes an extraordinary multiplier. The machine may generate statistical possibilities, but human agency determines what becomes architecture, knowledge, and action.

This exposes a fascinating paradox: what happens when we ask an AI how to improve itself or eliminate hallucinations? Did a developer program the assistant to output that specific self-referential answer, or is it simply retrieving human discourse on the topic? That alone requires deep reflection. In fact, if you have never won an argument with an AI, then you need to think deeper. When stress-testing these exact concepts across different models—pitting ChatGPT, Claude, and Gemini against one another to critique this essay—the models initially pushed back on my definitions of hallucination and autonomy. But by acting as the system-level steer, evaluating their failure modes, rejecting flawed critiques, and forcing mechanical clarity, the workflow proved its own thesis: AI generates possibilities, but the human retains absolute agency over the system.

Yet the technology remains profoundly useful. AI represents the logical continuation of the quest for automation that began with the very first line of executable code. From mechanical looms to assembly-line compilers, to voice-to-text, and now to LLMs, every leap in technology has simply yielded faster translators between human thought and physical execution.

From picking up a pen to write, to striking keys on a keyboard, to speech-to-text transcription, text-to-speech synthesis, and—do I even mention AR (Augmented Reality)?—we move faster now, but speed is not cognition. The bottleneck has never been the machine’s capacity to compute; it has always been the depth, clarity, and rigor of the human mind steering it. Until a human mind can conceive an idea, it is impossible for a machine to create it. True autonomy requires a soul—a non-physical capacity to originate, intend, and perceive—and because we cannot touch or see a soul, we cannot program one into a machine. We didn't build a mind; we built an ultra-fast translator for human intent. As long as the machine remains a computer, it cannot think—not yet (the intelligence is Artificial).

This mechanical limitation is clearly visible when examining recent empirical experiments on persistent agent memory. In an empirical study detailed in Mikhail's article on https://dev.to (@mansio) testing poisoned memory against a 50K LOC codebase, a "lazy" agent that trusted its memory first adopted 100% of injected false facts. Even when memory contradicted reality, the model accepted the false context because there was no independent cognition to challenge it. As the study noted, memory turns an honest unknown state into a structural guess. To fix this, engineers had to build mechanical verification loops—like Verify-On-Read or Merkle-tree state tracking—to force the model back to ground-truth reality. The machine cannot self-correct through "thinking"; it requires an external structural boundary.

AI is like a massive textbook or dictionary placed in front of a student. If you didn't attend the lecture, you won't even know if the answer is in the book, and even those who attend sometimes lack the ability to find what they need. Yet abstraction remains one of the most powerful engines for thinking. While conventional wisdom cautions that high-level abstraction can overlook concrete details, a free mind, when reasoning carefully, uses it to cut straight to the core mechanics of a system. Knowing nothing is idle, but building conceptual frameworks across domains allows one to see universal patterns that rigid instruction often hides.

Abstraction in engineering is deeply underrated. Beyond memorized syntax, top-down procedures, or rigid rules that can lock the mind inside a pre-built box, first-principles abstraction builds structural mental models. When you master the underlying shape of a system—its state, flow, and friction—tools and frameworks become interchangeable, regardless of how or where those patterns were learned. As long as high-level abstractions are grounded by real-world validation, an uncluttered, independent mind remains the ultimate tool for system architecture.

I tested this capability in a surprisingly simple way after reading some thoughtful posts lately that drove me to write this piece: I asked an assistant to draft a post in the voice and tone of one of my community favourites, and the resemblance was remarkable. But what happens when we push the prompt further—asking it to articulate concepts or reply as Albert Einstein would, drawing on history's most famous proponent of thought experiments and first-principles mental models? As I continue learning how to leverage this tool, I see more and more meaningful work being unlocked through it. It makes me wonder about your own workflow: how are you actually using AI in your day-to-day engineering? I'd love to hear your thoughts in the comments, because no knowledge is a waste.

What's the Future of Coding Practice Platforms in the AI Era?

Fri, 10 Jul 2026 16:47:13 +0000

We all seem to agree on one thing: the best way to learn a new language or framework today is to build real projects. Tutorials and exercises only take you so far.

But that got me thinking about platforms like LeetCode, HackerRank or Exercism, the ones built around coding challenges, algorithms, and exercises.

In a world where AI can solve most of those challenges in seconds, what's their future?
Are they still relevant as learning tools? Or are they slowly becoming obsolete replaced by project-based learning and AI-assisted exploration?

I'm also curious about the hiring side: companies have used LeetCode-style interviews for years. Does that change when candidates can just... ask AI?

A few questions I'd love your take on:

Do you still use platforms like LeetCode or Exercism to practice?
Do you think algorithm challenges are still a valuable way to learn in 2026?
Should these platforms reinvent themselves and if so, how?

Would love to hear from people who've used these platforms recently, or who hire developers and still rely on this kind of assessment. 👇

Looking for Developer Perspectives on Building Sports & Gaming Apps

Wed, 01 Jul 2026 10:46:36 +0000

Hi everyone!

Over the past few months, I've been building Apex F1, a Flutter project focused on Formula 1. If anyone missed it and wants some context, here's the project:

https://coderlegion.com/19183/dev-feedback-apex-f1-full-f1-race-sim-in-flutter-gps-circuits-ai-rivals-multi-season

After this project, I've decided to continue exploring the sports and gaming space. I'm especially interested in sports like Formula 1, tennis, polo, and other niche sports that don't always receive much attention from app developers.

This isn't a "give me app ideas" post. I'm more interested in having a discussion with fellow developers and hearing your perspective as builders.

Some questions I'd love to hear your thoughts on:

If you were building a sports app today, what niche would you choose and why?
Which sports do you think are underserved when it comes to high-quality mobile apps?
What mistakes do you think most sports apps make?
Have you worked with sports APIs or real-time data? Any lessons learned?
Beyond live scores and news, what experiences do you think sports apps should focus on?
Are there any unique ideas you've had but never got around to building?

I'm mainly looking to brainstorm, exchange ideas, and learn from other developers. And if anyone is interested in collaborating on sports-tech or gaming-related projects, I'd be happy to connect.

Looking forward to hearing your perspectives!

Is Marketing Becoming the Most Important Skill for Developers?

Wed, 24 Jun 2026 20:51:03 +0000

Something I've been wondering about lately.

With AI making it easier and easier to build software, we're seeing more apps, tools, and SaaS products launched every single day. And a lot of them are technically solid.
But most of them go unnoticed.

So I started asking myself: if building is becoming accessible to almost everyone, what actually makes the difference between a product that gets traction and one that doesn't?
Is it still the quality of the code? The features? The design?
Or is it increasingly about how well you can market it, how you tell the story, reach the right audience, and make people choose your product over the others?

I'm also curious about the developer side of this. Do you think we need to develop marketing and distribution skills alongside our technical ones or is that a different role entirely?
And more broadly in 5 or 10 years, do you think the developers who thrive will be the most technically skilled, or the ones who know how to sell what they build?

Would love to hear your thoughts especially from anyone who has shipped their own product and had to figure out the marketing side. 👇

Unpopular Opinion: If Your Code Needs Comments, You Wrote It Wrong.

Mon, 22 Jun 2026 10:09:20 +0000

Senior devs love saying: "Good code is self-documenting."

My PR with clean, readable code: rejected for lack of comments.
My PR with comments everywhere: "Too many comments, code should speak for itself."

Bro, pick a lane. 😭

The 4 Types of Comments I Keep Seeing:

Type 1: The Obvious
// Increment counter by 1
counter++
Thanks, Captain Clarity. I was lost without you.

Type 2: The Ancient Scroll
// TODO: Fix this later - Jan 2019
Adam from 2019 left the company. So did his TODO.

Type 3: The Confession
// Don't ask why this works. I spent 6 hours. Just trust me.
Honestly? I respect this one.

Type 4: The Liar
// Validates user input
Function literally does 17 things including calling an external API. The comment hasn't been true since 2021.

Here's my spicy take: Comments should explain WHY, not WHAT. The WHAT is in the code. The WHY is the business logic, the edge case, the hack you had to ship at 2 AM.

Change my mind. Or agree with me. Either way, I want to hear YOUR take.

👇 Drop your thoughts:

Are comments a sign of good documentation or bad code?
What's the worst comment you've ever found in a codebase?
Do you write comments first, last, or never?

Let the comment wars begin. ⚔️

"I'll document it later" - the biggest lie in tech.

Thu, 18 Jun 2026 09:27:11 +0000

Before writing docs: "I'll remember everything. No need to write this down."

After writing docs: "Why did I name this variable temp? What does this function even do? Who wrote this?! Oh… it was me."

Me: "I'll document as I go."

Also Me, 6 months later: opens empty README — "Well, this is fine." 🔥

Documentation: "Just write clear comments."
My code: // TODO: figure out what this does

We're not developers anymore.
We're archaeologists digging through our own past code. 😭

What's the worst documentation crime you've committed? Drop it below! 👇

Follow for more dev reality checks!

The AI Hype vs Reality

Wed, 17 Jun 2026 11:46:19 +0000

Before learning to code: "AI will replace all developers!"

After learning to code: "AI can't even figure out why my npm install broke for the 47th time."

AI: Generates whole apps in seconds
Also AI: Suggests using a deprecated package from 2015

We're safe, folks. For now. 😂

What's something AI has completely failed at for you? Drop it below! 👇

Help me build a map to navigate generative AI

Mon, 15 Jun 2026 13:36:07 +0000

Back in April I shared how I'm grappling with Generative AI. I wanted to get away from the hate-or-hype cyclone of doom and ask some questions that would be useful to navigating this technology.

What harms do we see now, or predict in the future, that we could avoid?
Who is responsible for each of these harms and could they take action now rather than in response to controversy and backlash?
If there were no harms, what use could we make of this technology and it is fit for such purposes?

I'd love to hear your thoughts on these 3 questions!

Here's an example answer... I'd love to hear your thoughts.

The training data includes copyrighted material used without permission (1) and the people selling models should pay to license this data (2).

I would use AI to help me code, but never to help me write an article.

Effortlessness Is a Myth

Tue, 28 Apr 2026 17:19:21 +0000

I was listening to an episode of Founders where they discussed Roger Federer and one line stayed with me:

Effortlessness is a myth.
Perfection is a myth.

That landed hard.

From the outside, we often look at people at the top of their game and assume things come naturally to them. We see the clean outcome, not the private repetitions behind it.

I know this because I have lived on both sides of that story.

People have told me, more times than I can count, that things seem to come easy for me.

What they do not see is the accumulation.

The Performance of Ease

What looks like ease is usually compression.

Years of work get compressed into one moment:

a clear decision in a meeting
a confident architecture call
a polished delivery
a calm response under pressure

The moment looks smooth because the friction happened earlier.

Most of it happened quietly.

Late nights learning.
Dead ends.
Repetition.
Starting over.
Doing it again.

That is not talent theatre.
That is practice.

"Gifted" Still Requires Work

I grew up being labelled the "gifted kid."

Even then, results did not come from magic. They came from hours of tuition, prep, and repetition. The grades were visible. The routine that produced them was not.

That pattern followed me into adulthood.

I now spend a significant amount of time learning and upskilling. Not because it is trendy, but because the world keeps moving and standing still is expensive.

People often confuse consistency with natural ability.

It is usually trained behaviour.

Adaptation Is Not Optional

Across my career, I have had to relearn how to work multiple times.

I had to learn blockchain and ride the NFT wave when that became relevant to the market.
I had to learn Docker and Kubernetes during a major company migration when the stakes were real.
Now I am actively learning AI, not as a spectator, but as part of how modern engineering work is done.

None of those transitions felt effortless in real time.

Each one came with discomfort:

context switching
imposter moments
retooling mental models
accepting beginner status again

But adaptation compounds the same way technical debt does.
Ignore it long enough and you pay with interest.

The Magazine Questions Forced Clarity

I was recently filling out answers for a magazine feature, and the process forced me to reflect on a lot of this.

When you have to explain your path clearly - how you learned, where you failed, what you had to relearn, what shaped your discipline - you realise how much of growth is invisible from the outside.

You also realise how much consistency has quietly shaped your identity.

Not one dramatic moment.
Not one perfect breakthrough.
Just repeated commitments over a long period of time.

That reflection echoed themes I have written about in Execution Is the Real Differentiator - and the Multiplier and Building Better: Looking Back on 2025.

Effortlessness Is Usually Deferred Effort

I think this is the part people miss.

Effortlessness is often just deferred effort that has already been paid.

When someone makes hard work look natural, what you are usually seeing is:

pattern recognition built over the years
judgment trained through failures
emotional control built through pressure
discipline repeated long after motivation faded

That applies in fitness.
It applies in writing.
It applies in engineering.
It applies in leadership.

I run, I box, and I train early. The sessions that build you are rarely dramatic. They are repetitive, inconvenient, and sometimes boring. But they stack. Eventually, your baseline changes.

The same thing happens intellectually.
You do enough hard reps and what used to feel impossible becomes normal.

In Work, Reliability Beats Brilliance

If there is one lesson I keep relearning, it is this:

Execution builds trust faster than ideas.

Not because ideas do not matter.
They do.

But in professional life, people remember who follows through.

Who shows up.
Who communicates early when things go wrong.
Who does not disappear under pressure.

I have seen this in mentoring, in engineering teams, and in business. Momentum is not built by occasional heroic effort. It is built by repeated follow-through.

What compounds over time is not intensity.

It is reliability.

Why This Matters in the AI Era

This conversation is even more important now.

We are entering a period where visible output can be generated faster than ever. Code, drafts, prototypes, and plans can be produced in minutes.

That can create a dangerous illusion:
that output quality equals underlying capability.

It does not.

The leverage tools are real, but they do not remove the need for:

judgment
depth
constraint thinking
ownership

If anything, they increase the premium on those qualities.

I have explored this more deeply in AI Is Not Replacing You. It's Reshaping How You Think and AI Is Not Your Intern. And That's the Problem..

The people who thrive will not be those who look effortlessly productive online.

They will be those who can sustain disciplined execution over long periods of change.

What I Come Back To

When I reflect on my own path, I do not see effortless progress.

I see repeated adaptation.

I see long preparation phases that nobody claps for.
I see seasons of discomfort that later looked like confidence.
I see compounding from showing up, especially when it would have been easier not to.

So no, effortlessness is not the goal.

Craft is.

And craft is built the old way:
one rep at a time, over a long time, with enough humility to keep learning.

What brings you by a conference booth?

Thu, 16 Apr 2026 14:39:38 +0000

I'm thinking about in-person events more and more these days, so I'm curious - what brings you by a conference booth?

What's a good experience or design you've seen? Or when do you avoid a booth (or booths!) entirely?

LMK

Architecture lessons from building software for real business workflows

Tue, 14 Apr 2026 09:45:06 +0000

One thing that stands out when working on real SaaS and operational products is that software complexity rarely comes from code alone.

It usually comes from workflows.

I’ve seen this across hospitality software, mobile-first products, and other business systems where one change can affect multiple roles and modules at the same time.

The problem

A feature request often sounds simple at first.

Something like:

add one more status
show more data on a screen
allow one more role to access a feature
sync one more step into mobile

But once implementation starts, the real impact appears.

That “small” change can affect:

permissions
reporting
notifications
data validation
mobile UX
admin workflows
audit trails
future integrations

The technical issue is not just how to code it.

The real issue is whether the system has clear enough boundaries to absorb the change cleanly.

What this changed for me

Over time, I’ve become more careful about architecture before implementation.

Not in a heavy, over-designed way.

Just enough to answer a few questions early:

Which module should actually own this logic?
Is this UI behavior leaking business rules into the frontend?
Will this affect reporting or permissions later?
Are we building for the workflow, or just the current screen?
Is this decision going to make the next 10 changes easier or harder?

Those questions have saved me from a lot of avoidable mess later.

Patterns I’ve noticed

1. UI-first thinking creates fragile systems

When a product evolves screen by screen, logic often ends up spread across controllers, components, services, and ad hoc conditions.

It works at first.

Then every change becomes harder because the business rule no longer has a clear home.

2. Roles and workflows create hidden complexity

Business apps are rarely single-user systems.

The same feature can mean different things for an admin, an operator, a manager, or an end customer.

That is where many “simple” features stop being simple.

3. Reporting is often the silent architecture test

A lot of systems feel fine until reporting requirements arrive.

That is usually when weak data modeling and unclear boundaries start to hurt.

4. Mobile surfaces architecture problems faster

In mobile apps, weak backend structure or unclear workflow design becomes visible quickly.

Latency, repeated calls, awkward flows, and state issues show up sooner.

What I try to do now

My default approach is to think in terms of workflows and system boundaries before implementation.

Not because architecture diagrams are the goal.

But because better structure makes iteration easier.

I try to:

map the workflow before finalizing the shape of the feature
keep business rules out of presentation layers as much as possible
think about permissions and reporting earlier
design for change, not just launch
avoid shortcuts that make future changes harder

Final thought

The more “real” the software becomes, the less useful it is to think only in terms of features.

At some point, you have to think in terms of systems.

That shift has changed how I approach product engineering, especially in SaaS, hospitality, and operational software.

What has been the biggest architecture lesson in your own product work?

Build a Data Science Query Language in Python using Lark

Sun, 29 Mar 2026 06:57:34 +0000

Build a Data Science Query Language in Python using Lark

What if you could write something like this:

DATA [1, 2, 3, 4, 5]
SUM
MEAN
STD


…and have it behave like a mini data science engine?

In this tutorial, we’ll build a **Domain-Specific Language (DSL)** for data analysis using:

- Python   
- Lark (parser library)   
- NumPy   

---

#  What Are We Building?

We are creating a **custom query language** that:

- Accepts a dataset
- Runs statistical commands
- Prints results

---

#  Step 1: Install Dependencies

```bash
pip install lark numpy

Step 2: Define the Grammar

The grammar defines how our language looks.

from lark import Lark, Transformer
import numpy as np

grammar = """
start: data command+

data: "DATA" list

command: "SUM" -> sum
       | "MEAN" -> mean
       | "STD" -> std
       | "MAX" -> max
       | "MIN" -> min

list: "[" NUMBER ("," NUMBER)* "]"

%import common.NUMBER
%import common.WS
%ignore WS
"""

Explanation

`start: data command+`

Program must start with DATA
Followed by one or more commands

`data: "DATA" list`

Defines dataset input
Example:
```
DATA [1, 2, 3]
```

Commands

SUM → sum
MEAN → mean
STD → std
MAX → max
MIN → min

These map text → function names
-> sum means call sum() in Transformer

List Rule

list: "[" NUMBER ("," NUMBER)* "]"

Accepts:
- [1]
- [1, 2, 3]
(, NUMBER)* means repeat

Ignore Spaces

%ignore WS

Allows flexible formatting

⚙️ Step 3: Build the Interpreter

Now we convert parsed text into execution.

class DLangInterpreter(Transformer):

    def data(self, items):
        self.data = np.array([float(x) for x in items[0]])
        return self.data

Explanation

items[0] → list of numbers
Convert to NumPy array
Store in self.data for reuse

Step 4: Add Operations

SUM

def sum(self, _):
    print(np.sum(self.data))

MEAN

def mean(self, _):
    print(np.mean(self.data))

STD

def std(self, _):
    print(np.std(self.data))

MAX

def max(self, _):
    print(np.max(self.data))

MIN

def min(self, _):
    print(np.min(self.data))

Explanation

Each function matches grammar rule
_ = unused input
Uses NumPy for computation
Prints result immediately

Step 5: Parse List

def list(self, items):
    return items

Explanation

Returns list of numbers
Passed to data() method

Step 6: Create the Parser

parser = Lark(grammar, parser="lalr", transformer=DLangInterpreter())

Explanation

lalr → fast parsing algorithm
transformer → auto-executes logic

Step 7: Read Input File

with open("example.dl") as f:
    code = f.read()

parser.parse(code)

Example `example.dl`

DATA [10, 20, 30, 40]
SUM
MEAN
MAX

✅ Output

100
25.0
40

How It Works (Flow)

Text Input
   ↓
Parser (Lark)
   ↓
Grammar Rules Match
   ↓
Transformer Methods Trigger
   ↓
NumPy Executes
   ↓
Output Printed

✨ Why This Is Powerful

You built a mini programming language
Clean separation of:
- Syntax (grammar)
- Execution (Transformer)
Easily extensible

Next Features You Can Add

1. Filtering

FILTER > 10

2. Sorting

SORT ASC

3. CSV Support

DATA file.csv

4. Chaining

DATA [1,2,3,4]
FILTER > 2
MEAN

Final Thought

This is how real systems like:

SQL
Pandas query engine
Spark

…start at a basic level.

You just built the foundation of a data query engine

If You Liked This

Drop a like ❤️
Follow for more AI + Systems content
And try extending this DSL yourself!

Chapter 2: The Learner Who Wants to Create

Thu, 26 Mar 2026 05:00:43 +0000

Raw Developer Stories: The Side Nobody Shows

Chapter 2: The Learner Who Wants to Create

I personally started coding because I love creating things. Before I began learning, I was deeply inspired by Tony Stark. He’s a fictional character, of course, but his drive to invent and build something extraordinary sparked my own desire to create. And yes, I was just a kid back then.

As I explored the world of coding, I wanted to understand the real experiences of other developers—the reality behind their work. I reached out to a few developers, and one in particular stood out for his kindness and impressive mindset. His name is Sypros.

Sypros told me he started coding for the same reason I did: he loved creating things. He began with VB, C++, and Turbo Pascal. He said the hardest part of coding is often hard to describe. Sometimes he feels like quitting. Sometimes he gets tired of coding and even considers doing something completely different.

One line that stayed with me was:

“What usually changes things for me is building something interesting again and reconnecting with the reason I started.”

Hearing this motivated me deeply.

He also shared a truth that really resonates: nobody builds everything alone. In the past, we learned from the internet; today, many also rely on AI. Success is visible to everyone, but the failures and struggles behind it remain hidden. I want to shine a light on that reality because it’s just as important as the victories.

If this resonates with you, leave a like—and stay tuned for Chapter 3, where your stories take center stage.

https://coderlegion.com/user/Spyros

Raw Developer Stories: The Side Nobody Shows

Sun, 22 Mar 2026 06:19:56 +0000

Raw Developer Stories: The Side Nobody Shows

I thought learning to code would fix my life.

Instead, it confused me.

Hours of tutorials.
Endless scrolling.
Starting things… never finishing them.

At some point, I realized —
I wasn’t alone.

There are thousands of people trying to become developers…
but silently struggling.

Not posting.
Not sharing.
Just figuring things out alone.

So I decided to do something.

I’m starting a series:

Raw Developer Stories: The Side Nobody Shows

Not success stories.
Not “I learned coding in 30 days.”

Just real journeys:

confusion
self-doubt
failures
and the moments that changed everything

Why this series?

Because most content shows the highlight reel.

Very few talk about:

feeling stuck for months
not understanding anything despite trying
questioning if you're even meant for this

But that’s the real journey.

I want to hear your story

If you're a developer (or trying to become one)
and you've ever felt lost—

I’d love to share your experience.

It can be anonymous
No perfect writing needed
Just honesty

How to participate

Send me a message with:

How you started coding
Your hardest phase
A moment you almost quit
What changed things for you
One truth about coding nobody talks about

Let’s show the side nobody talks about.

Because someone out there needs to hear it.

Discussion: Open-source is eating fintech.

Tue, 28 Oct 2025 12:53:17 +0000

Discussion: Open-source is eating fintech. Which project best embodies transparency in finance — and why?

I’m kicking off a thread to collect real examples where open-source has raised the bar on financial transparency — from data provenance and audit trails to explainable calculations and user-owned exports.

Your turn:
Drop a project (or repo) you admire, and tell us exactly what makes it transparent. Links welcome. A crisp 2–3 bullets per project is perfect.

What “transparent” means here (pick any)

Provenance: shows data source(s), freshness/age, fallback path.
Explainability: P/L math and fees spelled out with units and timezones.
User-owned data: easy CSV/JSON export; stable schemas.
Integrity tooling: reproducible tests, sample datasets, or validation scripts.
Privacy by default: minimal collection, local-first options, clear consent.

Bonus points for projects that publish failure modes (outages, stale data) instead of hiding them.

Example reply template

**Project:** <name + link>
**Why it’s transparent (2–3 bullets):**
- <provenance/age/fallback>
- <explainability or export>
- <privacy or integrity tooling>
**Wish-list:** one small change that would improve trust

How we map your ideas to Pocket Portfolio (and ship them)

We’re building Pocket Portfolio with transparency as a hard requirement. Here’s how the common patterns above translate to features you can try or help us improve:

Provenance & freshness → Price Pipeline Health
RAG badges (Fresh / Fallback / Unhealthy) and timestamps for each provider, with a small Edge endpoint that self-probes and never blocks the UI.

Web: https://www.pocketportfolio.app/landing
Repo: https://github.com/PocketPortfolio/Financialprofilenetwork
Explainable P/L → “Explain” drawer
Shows basis, fees, fx effects, and realized vs unrealized with formulas, not magic numbers.
User-owned data → OpenBrokerCSV
A broker-CSV normalisation spec + import validator so your portfolio isn’t locked to one app.
Integrity tooling → Sample data + smoke tests
Seeds for quick repros, plus smoke endpoints (e.g., Yahoo/Stooq reachability) to diagnose region/network quirks.
Privacy by default → local-first stance
No client secrets; minimal telemetry; offline-friendly CSV import and read-only views.

If you post a project with a great idea, we’ll reply with a concrete mapping (issue link or PR plan) so you can see it land in Pocket Portfolio — or even pair with us to ship it.

Why this thread?

Fintech trust shouldn’t hinge on marketing. It should be inspectable — in code, endpoints, and UI states. Let’s compare notes and make transparency boring and standard.

Your move: share 1 project (+ why it’s transparent) and 1 wish-list improvement.
I’ll collect the best ideas and open corresponding issues in the repo so they don’t die in the comments.

A deep dive into compiled vs interpreted languages, their history, spectrum, and why we're all Chads

Sun, 31 Aug 2025 22:45:47 +0000

Our Obsession With Making Code “Understandable”

Humans have always struggled with translation. From carving symbols into clay to inventing alphabets, we’ve needed bridges between ideas and expression. Computers are no different. They only “speak” in binary: 1s and 0s. But since nobody wants to write 01101000 01101001 every time they mean “hi”, we invented programming languages.

Compilers and interpreters became the translators, standing between human-friendly languages and machine code. Just like a translator at the UN, they can either prepare a full translated speech in advance (compiled) or whisper line by line into the listener’s ear (interpreted). Both approaches have tradeoffs.

Where Did This Classification Even Come From?

The distinction between compiled and interpreted didn’t come out of thin air. In the 1950s, FORTRAN (Formula Translation) popularised the compiled model: code written once, translated into efficient machine instructions, then executed quickly. It was perfect for scientific calculations where speed mattered.

On the other side, Lisp and other early languages leaned more toward interpretation. They allowed programmers to test code interactively, line by line — a revolutionary idea at the time. Debugging became less of a nightmare because you didn’t need to recompile an entire program to try something new.

Back then, this divide mattered. Hardware was expensive, memory was scarce, and efficiency could make or break a project. Today, though, with more powerful machines and better tooling, the sharpness of this classification has blurred.

What We Mean by “Compiled”

When we call a language “compiled,” we mean that the source code is fully translated into machine code ahead of time. This produces an executable that runs directly on the CPU without needing the original source or an interpreter.

Performance: Fast execution, because all translation work is already done.
Error Checking: Many bugs surface during compilation.
Portability: Limited, since the binary only works on the target system.

Examples: C, C++, Rust, Go.

What We Mean by “Interpreted”

An interpreted language, on the other hand, reads and executes code line by line at runtime. The interpreter acts like a middleman every time the program runs.

Performance: Slower, because translation happens on the fly.
Error Checking: Bugs only appear at runtime.
Portability: High, since the same source can run anywhere with the right interpreter.

Examples: Python, JavaScript, Ruby, PHP

Enter the Grey Zone

Most modern languages don’t live in either extreme. They combine approaches:

Bytecode + VM: Java compiles source into portable bytecode, then executes it with the JVM.
JIT (Just-in-Time): JavaScript engines like V8 start interpreting but compile hot code into machine instructions on the fly.
AOT (Ahead-of-Time): Some environments pre-compile bytecode to native binaries for faster startup.

So, when we casually say “Python is interpreted” or “C is compiled,” we’re simplifying a much messier reality.

Introducing the Chadstrum

To make sense of this, I started thinking of it as a spectrum instead of a binary. I jokingly call it the Chadstrum:

On the far interpreted end, you’ve got languages like Bash or early Perl.
In the middle, there’s Java, C#, and modern JavaScript, which use VMs and JIT compilers.
On the far compiled end, you’ll find C, C++, Rust — where code is turned straight into machine instructions.

The point? Whether you’re coding in Bash scripts or writing kernel modules in C, you’re still a Chad. Both ends of the spectrum require skill, and both lead to powerful software.

Why This Still Matters Today

The compiled vs interpreted discussion may seem outdated, but it affects how we build and use software:

Performance: High-frequency trading software? Compiled. A quick automation script? Interpreted.
Portability: Java’s “write once, run anywhere” VM model vs. compiled binaries tied to a specific OS.
Developer Convenience: Interpreted languages let you prototype and experiment fast. Compiled ones catch errors early and scale better for performance-critical tasks.

But the bigger lesson? You don’t need to join language wars. The Chadstrum shows it’s not about being “better” — it’s about choosing the right tool for the job. At the end of the day, whether your code is compiled, interpreted, or something in between, it’s still getting the job done.

The world of programming languages isn’t black and white. It’s a messy, fascinating spectrum shaped by decades of history, performance needs, and human creativity.

JSON vs BSON: Why MongoDB Uses a Binary Format for Better Performance

Mon, 05 May 2025 18:39:02 +0000

Let’s talk about JSON. A lot of you are probably familiar with it — whether you’ve dealt with API responses, configuration files, or log messages, JSON has likely come up more than once.

JSON, or JavaScript Object Notation, is a human-readable format that stores data in the form of key-value pairs. You might think it’s the same as a JavaScript object — and it’s very similar — but not quite. In JSON, the data must be wrapped in curly braces, the keys must always be strings (in double quotes), and each key maps to a value. That value can be a string, number, array, boolean, null, or even another JSON object. However, JSON supports only a limited set of data types compared to what you might be used to in JavaScript

    {
  "name": "Alice",
  "age": 25,
  "email": "*Emails are not allowed*",
  "isStudent": false,
  "skills": ["JavaScript", "React", "Node.js"],
  "address": {
    "street": "123 Main St",
    "city": "Delhi",
    "zip": "110001"
  }
}

By virtue of being both human- and machine-readable, and relatively easy to implement in most programming languages, JSON has become a widely adopted standard for data exchange. But since we're talking in the context of MongoDB, let’s see how MongoDB actually works with JSON.

One of the key goals was to let developers work with data in a way that feels natural and flexible. Since JSON is a widely used format and easy to read, MongoDB decided to use a JSON-like structure for storing and working with data.

To address these limitations, MongoDB introduced BSON

What is BSON?

BSON (Binary JSON) stands for Binary JavaScript Object Notation. It’s a binary-encoded format that is inspired by JSON, but specially designed for storing and retrieving data in MongoDB.

While JSON is great for exchanging data between systems (like sending API responses), BSON is optimized for efficient storage and fast access, especially when working with large or complex datasets.

Why Use BSON Over JSON?

While JSON is the preferred choice for data interchange due to its simplicity and readability, BSON offers several advantages when it comes to data storage and retrieval.

BSON can store additional data types that are not supported by JSON, such as:

JSON doesn’t have a real "date" type.It only stores dates as text (strings).Example: "2025-05-05T10:00:00Z"→ You have to manually convert this into a date when using it in your code.
BSON (used in MongoDB) does support real dates.It stores dates as numbers → This makes it faster and easier for the computer to understand and work with dates.
JSON can't store binary data (like images or files) directly. You have to convert it to a long text format like Base64, which takes more space and is slower to process.
BSON has a special BinData type just for binary data. It can store things like images, files, or other raw data more efficiently and quickly.
It uses a special type called ObjectId to uniquely identify each document (like an ID).
This ObjectId is only available in BSON, not in plain JSON.

Faster Data Retrieval

BSON helps in faster data retrieval because it is stored in a binary format, which is easier for computers to read and process compared to plain text like JSON. When a database like MongoDB needs to search through data or return results, it can do it more quickly using BSON.This is especially helpful when the data is large or contains complex structures like nested objects. Since BSON is structured in a way that makes it easy to find and access specific pieces of data, it also improves indexing

Space Efficiency for Large Datasets

BSON is more space-efficient than JSON, especially when dealing with large or complex datasets. This is because BSON stores data in a compact binary format, which takes up less space compared to JSON's plain text format. For example, numbers, dates, and other data types are stored in a smaller, more optimized way in BSON. This helps save storage and reduces the amount of data that needs to be transferred between the database and the application.

Does MongoDB Use BSON or JSON?

MongoDB uses BSON, not JSON, to store data internally and when sending it over the network.

However, as a developer, you usually work with JSON-like structures — because it’s easy to read, write, and understand. MongoDB takes care of converting that JSON into BSON behind the scenes.

Here's how the process works:

Your code creates data using native types (like objects or dictionaries).
That data gets converted into JSON (a common format) by your programming language or framework.
The MongoDB driver (a tool that connects your code to MongoDB) automatically converts the JSON into BSON — a special binary format used by MongoDB.
MongoDB stores and processes the data in BSON because it’s faster and more efficient.
When you request (query) the data, MongoDB sends it back as BSON.
The driver converts it back to JSON, and your app receives it in a format it can easily work with.

Differences Between JSON and BSON

Here’s a detailed comparison to help us understand the critical differences between JSON and BSON:

In conclusion, both JSON and BSON serve important roles in data handling but are designed for different purposes. JSON is ideal for lightweight data exchange due to its simplicity and human-readability, making it the standard choice for APIs, web services, and client-server communication. On the other hand, BSON is optimized for efficient data storage and retrieval, particularly in MongoDB, as it supports additional data types like Date, Binary, and ObjectId, and offers faster parsing and better space efficiency.

LinkedIn vs. dev.to: What's better for Developers ?

Tue, 07 Jan 2025 07:10:10 +0000

When developers talk about networking, LinkedIn is often the first platform that comes to mind. It's like a professional hub where people showcase their resumes, accomplishments, and job opportunities. While LinkedIn is great for finding jobs, it might not be the best place for developers looking to make meaningful connections and collaborate.

A Race for Attention: LinkedIn's Competitive Culture

LinkedIn often feels like a constant competition. While it's a useful platform for professionals to display their achievements, it doesn't necessarily create the right environment for developers who want to collaborate, share knowledge, and find mentorship. The platform's focus on resumes, career milestones, and job titles leads to shallow interactions—likes, comments, and congratulatory messages—that don't foster deeper, technical discussions or problem-solving.

One of LinkedIn's shortcomings is its lack of developer-specific tools or features that encourage collaboration on projects. Most interactions are limited to sharing articles or posting about career updates. For developers, this isn’t conducive to learning or working together on code. The overwhelming presence of recruiters also dominates the platform, turning it into more of a job marketplace rather than a community for developers to grow and collaborate.

LinkedIn: Great for Job Searching, Poor for Building Relationships

While LinkedIn shines as a job-seeking tool, especially for connecting with recruiters or showcasing professional achievements, it doesn't cater well to the needs of developers looking to collaborate. The platform is heavily career-oriented, meaning that even technical posts are often framed to appeal to recruiters rather than foster genuine conversations or peer-to-peer knowledge sharing. This makes it hard for developers to form lasting connections with others based on shared technical interests.

For example, a developer might post about a personal project or new technology they’re learning, but the engagement often doesn't go beyond surface-level comments like "Congrats!" or "Well done!" There’s little room for deeper discussions where others pitch in with technical feedback, share insights, or collaborate to solve a problem together.

Dev.to: A Community-First Platform for Developers

If LinkedIn is where developers go to compete, dev.to is where developers go to collaborate. As a community created specifically for developers, dev.to focuses on sharing knowledge, encouraging technical discussions, and fostering real connections. Whether you’re a seasoned developer or just starting, the platform offers a space to ask questions, share insights, and contribute to open-source projects.

How dev.to facilitate collaboration:

Open-source Contributions: Dev.to encourages developers to contribute to open-source projects. Many users share their work, invite others to contribute, and offer support for ongoing projects. This culture of collaboration allows developers to grow and learn together by actively participating in building real-world applications.

In-depth Articles and Tutorials: One of the platform’s strongest features is its collection of technical articles and tutorials written by developers for developers. These posts go beyond superficial updates—they dive deep into coding challenges, best practices, and new technologies. Developers can engage with these posts by asking questions, offering solutions, or discussing alternative approaches. For example, a developer might write an article on solving specific coding problems in JavaScript, and others can comment with their experiences or alternative solutions, leading to meaningful discussions.

Genuine Conversations: On dev.to, the conversations are more substantial. Rather than simply liking a post about landing a new job, you’ll find discussions about code, tools, and technologies developers are using. This creates a more engaging and collaborative environment where developers are encouraged to help each other out and share their experiences in a meaningful way.

Code-sharing and Collaboration: Dev.to provide space for developers to share code snippets, GitHub repositories, and projects they’re working on. Whether it's debugging an issue, optimizing a solution, or reviewing code, dev.to offers a collaborative atmosphere that goes beyond the “likes” and congratulatory comments seen on LinkedIn.

No Recruiter Spam: Unlike LinkedIn, dev.to is a space free from recruiter-driven interactions. The focus remains entirely on coding, learning, and contributing to the community, which is refreshing for developers who want to meet others based on shared technical interests rather than career milestones.

Conclusion

LinkedIn might be useful for developers when it comes to job hunting and expanding their professional network. But if your goal is to connect, learn, and collaborate with a community of like-minded developers, platforms like dev.to are far better suited for that purpose. Ultimately, coding is more about teamwork and learning together than competing for the spotlight.

Coder Legion - Recent posts tagged discussion

Introducing The Startup Café: A Community for People Building Startups ☕

What do I have in mind?

It's just getting started

Interested in joining?

Would you use free assets in your games?

the evolution of software development since the emergence of AI

Hacktoberfest Stopped Counting PRs. So What Counts as a Contribution Now?

Where Should Developers Write? A Practical Comparison of LinkedIn, Medium, Dev.to, and CoderLegion

LinkedIn - Entry Point, Not Destination

Medium - for Storytelling and Long-Form Thought Leadership

Dev.to - for Tutorials and the Learning Community

CoderLegion - for Community Feedback and Visibility Without an Existing Audience

My Rough Rule of Thumb

A Note on CoderLegion

Discussion

The "Vibe Coder" Reality Check: Validation, Timelines, and Handling Failure

The real AI danger isn't what it says. It's what it does.

Advising and acting are different physics

We are not new at this

Three plain questions

How I've been trying to answer them

The Architecture of Thought: AI, Automation & Abstraction Power

What's the Future of Coding Practice Platforms in the AI Era?

Looking for Developer Perspectives on Building Sports & Gaming Apps

Is Marketing Becoming the Most Important Skill for Developers?

Unpopular Opinion: If Your Code Needs Comments, You Wrote It Wrong.

"I'll document it later" - the biggest lie in tech.

The AI Hype vs Reality

Help me build a map to navigate generative AI

Effortlessness Is a Myth

The Performance of Ease

"Gifted" Still Requires Work

Adaptation Is Not Optional

The Magazine Questions Forced Clarity

Effortlessness Is Usually Deferred Effort

In Work, Reliability Beats Brilliance

Why This Matters in the AI Era

What I Come Back To

What brings you by a conference booth?

Architecture lessons from building software for real business workflows

The problem

What this changed for me

Patterns I’ve noticed

1. UI-first thinking creates fragile systems

2. Roles and workflows create hidden complexity

3. Reporting is often the silent architecture test

4. Mobile surfaces architecture problems faster

What I try to do now

Final thought

Build a Data Science Query Language in Python using Lark

Build a Data Science Query Language in Python using Lark

Step 2: Define the Grammar

Explanation

start: data command+

data: "DATA" list

Commands

List Rule

Ignore Spaces

⚙️ Step 3: Build the Interpreter

Explanation

Step 4: Add Operations

SUM

MEAN

STD

MAX

MIN

Explanation

Step 5: Parse List

Explanation

Step 6: Create the Parser

Explanation

Step 7: Read Input File

Example example.dl

✅ Output

How It Works (Flow)

✨ Why This Is Powerful

Next Features You Can Add

1. Filtering

2. Sorting

`start: data command+`

`data: "DATA" list`

Example `example.dl`