Coder Legion - Recent posts tagged devjournal

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?

What I Thought DevRel Was vs. What It Actually Is (A Mentee's Honest Take)

Tue, 09 Jun 2026 08:15:03 +0000

A few weeks ago, if you'd asked me what "DevRel" stood for, I would've squinted, smiled, and given you a confident-sounding non-answer. Today I'm in a DevRel mentorship program so let me close that knowledge gap for you the way it got closed for me

The "Before": What I Thought DevRel Was

When I first heard the term Developer Relations (DevRel), my brain did what most people's brains do; it grabbed the two words and built a half-decent guess.
"Oh, so… you relate to developers? Like, customer support for developers?"

Not quite.

I also assumed it was basically being a tech influencer. Someone who posts on Twitter/X, shows up at events with a branded hoodie, and tells everyone how amazing their company's product is. Half marketing, half cheerleader.
Also not quite.

The "During": What DevRel Actually Is

Here's the cleanest definition I can give you:
DevRel is the bridge between a company that builds tools for developers and the developers who actually use those tools.

Think of it like this: imagine a company builds a really powerful kitchen appliance, but only professional chefs can figure out how to use it. That appliance will flop; not because it's bad, but because nobody knows how to get value out of it. DevRel is the team that writes the cookbook, hosts the cooking class, listens to chefs complain about the buttons, and then walks back to the engineers and says, "Hey, can we move this button?"

In tech, that "appliance" is usually an API, an SDK, or a developer tool. The "chefs" are software developers around the world. And DevRel is the function that makes sure the two actually connect.

One thing my mentor said in our first session that stuck with me:
"You should be a developer(Even at beginner level) before you become a developer advocate."

This is the part that demolished my "tech influencer" theory. You can't honestly bridge two worlds if you only live in one of them. If you've never written code, you don't know which parts of a product are confusing, broken, or magical. You can talk to developers, but you can't speak with them.

The Three Cs of DevRel
The work itself breaks down into three pillars what folks in the field call the 3 Cs:
‍ Code — DevRel folks build things. They use the product themselves, ship demo apps, write sample code, and feel the same friction real developers feel. This is how they earn the right to speak.
✍ Content — They turn the product into something learnable. Documentation, tutorials, blog posts, videos, livestreams, conference talks. If you've ever Googled "how to do X with [some tool]" and landed on a guide that actually made sense; that was probably DevRel's work.
Community — They show up where developers gather. Hackathons, meetups, conferences like DevFest Lagos, Discord servers, Twitter/X spaces. They're not there to sell; they're there to listen, teach, and build genuine relationships.
A DevRel person who only does one of the three? good but can be better. A DevRel person who weaves all three together? That's the real job.

The "After": How I'm Actually Getting Started

I won't pretend I've figured this out. I'm at the very beginning; accepted into a mentorship program. But here's what "getting started" looks like in practice:

Becoming a developer first. Not optional. Before I can advocate for developers, I need to be one, even at a beginner level. Code is the foundation that everything else stands on.
Learning from people already doing it. A few I'm watching closely:
Tejas Kumar — chief developer advocate, podcast host, and one of the clearest voices on what DevRel actually is and isn't. His ConTejas Code podcast has a whole episode dedicated to a deep dive into DevRel.
Sodiq Akinjobi — Developer Ecosystem Community Manager at Google and one of the organisers behind GDG Lagos and DevFest. If you want to see community-building done well in Africa, watch what he ships.
Joshua Omobola — a true polymath whose work cuts across engineering, writing, and community from Supertokens to Web3Afrika. The kind of multidisciplinary profile that DevRel rewards.
Timonwa Akintokun — DevRel Engineer at IQ AI, working on ADK-TS (the Agent Development Kit for TypeScript). She literally sums up the job on her site as "Code, content, and community that's what I do." Iconic. Also, a reminder that this field has space for women doing absolutely cracked work, and the more visible that is, the better.
Putting myself out there. Which is what this blog post actually is. Writing in public is one of the best things you can do, you're practising content, learning to explain, and inviting feedback at the same time. (This is me practising.)

A Quick Word on Career Paths

DevRel isn't one job; it's a family of jobs. You can specialise as a Developer Advocate, a Technical Writer, a Community Manager, a Developer Experience (DX) Engineer, or a DevRel Engineer. Some lean more toward code, some toward content, some toward people. There's no single ladder, which is intimidating at first but freeing once you accept it.

So… What Do You Take From This?

If you're a fellow developer wondering whether DevRel could be a fit, it is if you like teaching and you don't mind being visible.
If you're non-tech and you've read this far, congratulations! You now understand a corner of tech that even a lot of tech people don't fully get. The next time someone says they work in DevRel, you'll know they're not doing tech support, and they're not just an influencer. They're the bridge.
And if you're somewhere in between, welcome to the club. I'll see you out there!

This post is part of my journey through the DX mentorship program. I'll be writing more as I learn. Feel free to follow along, or share your thoughts in the comments on what you thought DevRel was before reading this. I'm collecting answers!

Your RAG isn't broken. Your chunks are.

Thu, 14 May 2026 14:44:24 +0000

Everyone wants to blame the model. "GPT-4 is hallucinating." "Claude isn't following instructions." "The embeddings are bad."Nine times out of ten, it's the chunks.I've been auditing RAG pipelines lately and the same patterns keep showing up:Fixed-size chunking that splits sentences in half. The model gets a fragment that starts with "...and therefore the policy applies only when" and you wonder why the answer is confidently wrong.No overlap between chunks. Context that spans a paragraph boundary is gone. The model sees the question but not the answer, because the answer lives in the chunk after the one that matched.Chunking before cleaning. Headers, nav menus, footer junk, and "Click here to subscribe" all get embedded as if they're content. Then they show up in retrieval and pollute the context window.Embedding the wrong thing. People embed the raw chunk but the user query is phrased completely differently. No wonder cosine similarity is low — they're not semantically close, they just happen to be about the same topic.Before you blame the model, look at what you're actually retrieving. Log the top 5 chunks for 10 real user queries and read them like a human. If you can't answer the question from those chunks, the model can't either.The model is a mirror. It reflects the quality of what you feed it.

Why I Started Taking Web Development More Seriously

Sat, 25 Apr 2026 07:07:30 +0000

My interest in web development didn’t start with code; it started with curiosity.

I used to look at different websites and wonder how everything worked behind the scenes. From simple layouts to complex features, it made me realize that there’s more than what we see as users. That curiosity slowly turned into a desire to understand and eventually create something on my own.

As I learned more, I began to see how important websites are today. Almost every business, personal brand, or community relies on an online presence. That made me realize that web development is not just a technical skill, but something practical and valuable in the real world.

What makes it even more interesting is the creative freedom. Building a website is not only about writing code, but it’s also about turning ideas into something real. Whether it’s a blog, a portfolio, or a simple web app, every project is an opportunity to experiment and improve.

At the same time, I also discovered that this field is full of challenges. From understanding logic and algorithms to solving unexpected bugs, there’s always something to figure out. But instead of being frustrating, it became something I enjoy. The process of solving problems and learning from them is what keeps me going.

In the end, learning web development is more than just a technical journey. It’s about curiosity, creativity, and continuous growth.

If you’re curious about what led me to take this path more seriously, I shared the full story here: Why I Started Taking Web Development More Seriously

Beyond Code: Lessons from My Website Experience

Wed, 22 Apr 2026 03:33:00 +0000

A website hiccup made me rethink how I approach projects, habits, and priorities. It's a reminder that growth isn’t just technical, it's personal too.
Read the full reflection: Beyond Code: Lessons from My Website Experience

Technical Writing for Beginners: A Simple Guide with Examples

Tue, 21 Apr 2026 21:07:57 +0000

Have you ever tried to follow instructions in a software program, only to end up more confused than when you started?

This often happens when instructions are not written clearly or when too many technical terms are used without explanation. Good technical writing helps solve this problem by making complex information easier to understand.

In this guide, you will learn what technical writing is, see practical examples, and discover a few simple tips to help you get started as a beginner technical writer.

What is Technical Writing?

Technical writing is the process of writing complex information into easy-to-understand content. However, the goal is not to sound complicated, but make things simple for the readers to understand.

Example

Instead of saying:

The application facilitates communication between users.

A technical writer will write:

The app allows users to send messages to each other.

In this example, the second sentence replaces the complex and formal terms (facilitates, communication) in sentence one, with direct verbs (allows, send). This makes the information easier for readers to understand.

The main goal of a technical writer is to turn complicated ideas into clear instructions that users can quickly follow.

Other Examples

Topic 1: How to Install a Mobile App

Complex Example

After downloading the application, execute the installation procedure and configure the settings appropriately.

This sounds too complex and unclear.

Simple Technical Writing Example

How to Install the App

Open the Google Play Store
Search for the app name
Tap Install
Wait for the download to finish
Open the app and follow the setup instructions

This version works for three reasons:

It uses numbered steps so readers can track their progress
It uses plain, active verbs (tap, search, open) instead of vague ones (execute, configure)
It speaks directly to the reader using "you"

These three habits: numbered steps, active verbs, second person voice are cornerstones of good technical writing.

Topic 2: Connecting to Wi-Fi

Complex Example

Establish a wireless network connection by opening the device network configuration interface, selecting the desired SSID and providing the correct security credentials.

Simple Technical Writing Example

Open Settings → Wi-Fi, select your network, enter the password and tap Connect.

The other example is preferable because it changed the technical jargon (establish, configuration, desired SSID) used to relatable verbs (open, select, enter). This process compressed the first example into simple instructions, which is the purpose of technical writing.

Where Technical Writing Is Used

Technical writing is used in many areas of technology, such as:

Software Documentation
These are guides that explain how software works and how to use it.
Example: A guide explaining how to use Microsoft Word or Zoom features.
Product Manuals
Step-by-step instructions for setting up or using a product.
Example: A phone or blender manual.
Tutorials and Guides
Instructions that teach users how to complete a task.
Example: How to create a Gmail account.
Instructions for Developers
Instructions on how to use software tools, apps, or services.
Example: Using an API.
Help Center Articles
Short articles that answer common questions or solve problems.
Technical Blog Posts
Articles that explain technical topics in a simple way.

Tools Used for Technical Writing

When starting technical writing, some tools can make the process easier.

Markdown
A simple formatting language used for writing structured documents.
Google Docs
Useful for drafting articles, editing content and collaborating.
Grammarly
Helps check grammar, spelling and clarity.
Notion
Helpful for organizing notes and writing ideas.
Hashnode
A platform for writing and publishing technical blogs.
Confluence
Used by companies for internal documentation.

If you're just starting out, begin with Google Docs and Grammarly. You can learn the others as you grow.

Tips for Beginners

1. Audience Awareness

Before you write a single sentence, ask yourself:

Who will read this?
What do they already know?
What do they need to be able to do after reading this?
What is the simplest way to explain this?

Knowing your audience is what separates useful technical writing from writing that just sounds technical.

2. Start with Easy Topics

Begin by picking simple tasks like:

How to reset a password
How to send an email

3. Avoid Hard Words

Use simple words everyone can understand.

Instead of:

Authenticate your credentials

Write:

Enter your username and password

4. Use Headings and Lists

Break your content into headings and lists.

Example: How to Take a Screenshot

Press the Power and Volume Down buttons together
Wait for the screen to flash
Open your gallery to view the screenshot

5. Give Examples

Show how things work with short examples. Use step-by-step instructions or screenshots to improve understanding.

6. Practice Writing

Write short, simple guides regularly.

Create a mini-guide like:

How to share a file online

Try publishing it on a blog.

Conclusion

Practicing technical writing helps you communicate clearly, think logically, and solve problems step by step. It also builds a portfolio that shows your skills to potential employers or collaborators.

Start small. Pick any app or tool you use daily and write a step-by-step guide explaining how to use it.

Share it on dev.to and tag it #technicalwriting. The feedback you receive will accelerate your growth faster than writing in private.

The more you practice explaining technical topics clearly and simply, the better you will become.