DEV Community: Major League Hacking (MLH)

GitHub, Demystified

MLH Team — Fri, 05 Jun 2026 19:32:48 +0000

TL;DR -
GitHub is a place to store code and keep track of every change made to it. That is the core of it. Because so much open source software lives there, it is also where a builder can find and reuse other people's tools, including a lot of the AI ecosystem. Its reputation as an intimidating community space is real, but that layer sits on top of a tool that does something fairly simple. A newcomer does not need to earn their way in. They need a project and an account.

GitHub has a way of making new developers, and now software creators or anyone who is creating code, feel like they walked into a party everyone else was invited to years ago. The profile photos, the rows of green contribution squares, the open source projects with thousands of stars. It reads like a club, and the entrance exam feels both invisible and already failed.

Plenty of people first hear about GitHub in its community form. They’re told it’s a place where strangers read your code and form opinions about it, long before anyone explains what it actually does. As a result, they may think GitHub is just a place where developers collaborate. In reality, it’s so much more. The collaboration is real. It is just not the only way in.

Consider this reframe: GitHub is a tool first. The community is something that grew on top of the tool, and a beginner can get real value out of the tool for months without touching the community at all.

What GitHub Actually Is

Strip away the reputation and GitHub does one job. It stores code and remembers every version of it.

That second half matters more than it sounds. The technical name is version control, like your history in Google docs. When anyone changes their code, GitHub keeps a record of what it looked like before. When you save a new version, the old one is still sitting there as a reference for the future. Break something badly at midnight, and there is a working version from that afternoon you can restore in the morning. Nothing a person saves to GitHub is ever truly lost, which is a quietly enormous relief for anyone who has overwritten a file and felt their stomach drop.

That same change-tracking is what makes building with other people possible. When two developers edit the same project, GitHub keeps both sets of changes straight and flags the spots where they collide, so the work can be combined instead of one person accidentally erasing the other. The collaborative nature of GitHub – the reputation it has built up over the years – is really just this one feature, pointed at more than one person.

The Mental Model: Google Docs for Code

Anyone who has opened the version history on a Google Doc already understands the heart of it. Every edit is recorded. Earlier drafts are recoverable. More than one person can work in the same place without chaos…there’s even color coded changes to keep things clear. GitHub does that for code instead of documents, with a few more tools for combining everyone’s changes cleanly. A learner who keeps that picture in mind has most of what they need to get started.

Getting Your First Project onto GitHub

Three things get a first project up, and none of them require permission from anyone.

First, an account. It is free at github.com, and that is the entire barrier to entry. No invitation, no wait time, no portfolio, no minimum experience.

Then a repository, repo for short. A repository is just the home for one project: its files, and the full history of how they got that way. Most new developers make one repo per thing they build.

Then commits. A commit is a saved snapshot of the project at a moment in time, with a short note describing what changed (added contact form, fixed the broken link). Committing often is the habit that turns GitHub from a backup into a timeline a person can actually read later.

The part that scares a lot of beginners, the black terminal window, is increasingly optional. Modern code editors and AI agents connect to GitHub directly, so someone who built a project by talking to an AI tool can often push it up through a few buttons without ever typing a command. The terminal is one door in. It is no longer the only one.

The Community Layer

This might be where GitHub’s reputation comes from, and it is worth understanding so it stops being intimidating. Because so many projects already live on GitHub, it has become the default place for open source: software whose code is public, so anyone can read it, learn from it, and suggest improvements.

When a project is public and popular, it attracts a lot of eyes. Someone spots a bug and offers a fix. Someone else improves the documentation. The original developer reviews the suggestion and decides whether to fold it in. That back-and-forth is genuinely powerful, and it is the thing people picture when they think GitHub is only for experts.

A useful way to think about it: GitHub is community-driven in the way Wikipedia is community-driven. Wikipedia is, at its core, a place to store information, and a community gathered around that core idea because the information was worth gathering around. GitHub is a place to store code, and a community gathered around it for the same reason. The storage comes first. The community is what has grown on top over many projects and many years. A beginner can use the storage for a long time before the community is ever relevant, and there is nothing wrong with that.

Using GitHub to Find and Reuse AI Tools

The community layer does something else worth knowing about. It turns GitHub into a place to get tools, not only a place to keep them. For a vibe coder, or anyone building without a traditional background, the most valuable thing on GitHub is often someone else’s work, sitting in the open and free to build on.

A large share of the AI ecosystem is developed and shared as open source. Agent setups, prompt libraries, automation workflows, and starter projects that already connect to a model or an API are all out there, posted by people who solved a problem once and left the solution where others could find it. A learner who wants to add image generation to a project, wire up a chatbot, or automate a repetitive task can often find a working starting point instead of beginning from a blank file if they know where to look.

Finding one can be as simple as searching GitHub for what the project needs to do and reading a few signals.

The star count is a rough measure of how many people have found a project useful.
The README, the page that greets a visitor on the repository, is the front door, and it usually explains what the tool does and how to set it up.
The date of the most recent activity says whether the project is still alive or was abandoned two years ago. A tool with recent updates and a clear README is a safer bet than one with neither.

A non-traditional developer does not have to read every line to put a tool to work, especially if they are vibe coding with the help of an AI agent. They can point their agent at the repository, ask it to read the README and the code, and have it explain in plain language what the tool does. From there the same conversation can cover how to bring the tool into the current project, what needs to be installed, and where the learner’s own details, an API key or a file path, have to go. Bringing a copy into their own workspace (forking or cloning, in GitHub’s terms) is usually a step the agent can walk through as well. The skill here is less about understanding the code on sight and more about knowing what to ask.

An important note on security: Code written by a stranger runs on the learner’s machine and sometimes reaches into their files, their accounts, or the keys that pay for an API. Before running something unfamiliar, it is worth knowing what it actually does, and an AI agent is good at exactly this kind of review. Asking your vibe coding partner what a tool accesses, what it sends out, and whether anything looks unusual takes a minute and catches the rare project that does more than it advertises. This is the same build-then-audit instinct to cultivate.

It is also worth a glance at the project’s license, usually linked on the repository’s main page, since that is what spells out how the code is allowed to be reused. Most widely used tools carry permissive licenses that allow this kind of borrowing, but a quick look avoids surprises later.

Git, GitHub, and the Alternatives

One last source of confusion worth clearing up.
Git is the version control system itself, the underlying technology that does the change-tracking.
GitHub is one popular place to host projects that use Git, and it is not the only one.
GitLab and Bitbucket do much the same job.
A beginner does not need to evaluate all three. Picking the one a tutorial or a friend already uses is a fine way to start because the core ideas carry over to the others.

The tool is far simpler than its reputation suggests. Accounts are free, your first repository takes a few minutes, and the community is there whenever you are ready for it. Until then, it can be pretty invisible. The only thing standing between a beginner and the version of GitHub that actually helps them is a project worth saving.

FAQ

Do I need to know how to code before using GitHub?
No. GitHub does not care how the code got written, whether by hand, in a bootcamp, or through a conversation with an AI tool. If a person has a project and an account, they can use it.

Is my code public by default?
Not unless a developer chooses to make it so. Repositories can be private, visible only to their owner and anyone explicitly invited. Public repositories are how open source works, but going public is always a choice.

What is the difference between Git and GitHub?
Git is the version control technology that tracks changes to code. GitHub is a service for hosting projects that use Git, with extra tools layered on for collaboration. People often say one when they mean the other, and for a beginner the distinction rarely gets in the way.

Do I have to use the terminal?
No longer. The terminal is one way to work with GitHub, and many developers like it, but code editors and AI agents now connect to GitHub through a visual interface. A new developer can put a project up without typing a single command.

Can I just upload my files directly instead of using Git?
Yes. GitHub lets a person drag files straight into a repository through the website, which is a perfectly reasonable way to start. Doing it through Git is considered best practice because it captures the full history of changes, but nobody has to begin there.

Is it okay to use someone else’s code in my own project?
Usually yes, when the project is open source, though the specifics depend on its license. Open source means the code is public and meant to be built on, and the license attached to a project spells out the terms, including whether credit is required. Most popular tools use permissive licenses that allow free reuse. The license is normally linked on the repository’s main page, and an AI agent can read it and summarize what it permits.

How do I know if a tool I find on GitHub is safe to use?
A few signals help. Recent activity, a clear README, and a healthy star count point to a project that real people rely on. Beyond that, code from a stranger runs on the learner’s own machine, so it is worth understanding what a tool does before running it. Asking an AI agent to read through the project and flag anything that touches files, accounts, or API keys is a quick way to check, and it catches the rare project that does more than it claims.

Do I have to pay to use tools I find on GitHub?
The open source code itself is almost always free to use. Costs usually come from somewhere else, such as a tool that connects to an AI model or another paid service, where the usage is billed by that provider rather than by GitHub. Reading the README, or asking an AI agent to, will usually surface whether a project depends on anything that costs money to run.

DevRelCon NYC 2026: Where Developer Relations, DevX, & Developer Marketing Come Together

MLH Team — Fri, 29 May 2026 17:34:01 +0000

TL;DR -DevRelCon NYC returns to Industry City in Brooklyn on July 22–23, 2026. It's the flagship conference for developer relations, DevX, and developer marketing professionals — about 300 people, intentionally tight-knit, with a DIY indie feel that sets it apart from larger corporate events. This year's programming focuses heavily on what AI is changing about DevRel: how to write docs for human and agent users alike, what developer experience means when AI handles the boilerplate, and how to measure and scale adoption in a shifting landscape. The week starts Tuesday night with a mini hackathon. Tickets are at nyc.devrelcon.dev, scholarships are available, and there's a "Convince Your Boss" script if you need it.

There's a conference that's been running for more than a decade, quietly becoming the place where the people who build for developers go to figure things out together. No keynote theater (but plenty of excellent speakers). No lanyard maze (but good happy hours and the occasional magic show). Just a few hundred practitioners in a converted Brooklyn warehouse, having the conversations that actually move the work of developer relations forward.

That's DevRelCon. And this year, it's coming home to Industry City on July 22 & 23, 2026. We’ve been active partners in the DevRelCon space since the beginning and now head up the flagship conference here in New York. Here’s a look at what we have planned this year.

What DevRelCon Actually Is

DevRelCon isn't a general tech conference. It's built specifically for people who work to grow developer adoption: developer relations professionals, developer experience teams, product marketers, platform PMs, and anyone whose job involves getting developers more deeply engaged with their work.

The community is intentionally tight-knit. Each year we have about 300 attendees. People who've been coming for years show up knowing they'll run into the colleagues, collaborators, and honest sounding boards they only see once a year. At the same time, each year we get new people who show up and find out immediately that the community is one of the friendlier ones in tech.

What This Year Is Focused On

The developer relations world is navigating something genuinely new right now: the increasing adoption and sophistication of AI models across an industry that sees opportunity in the tech.

When the end user of your API might be a person or an AI agent, how do you write documentation? When everyone is using AI to generate boilerplate, what does "developer experience" even mean anymore? These are the questions DevRelCon 2026 is designed to dig into.

Sessions this year are organized around the challenges that matter most to the community right now:

AI Developer Tooling And Platform Strategy
Developer-First Go-To-Market Methods
Measuring Developer Adoption And Activation
Documentation As Product
Building And Scaling Developer Ecosystems
Content Strategy And Career Paths

Our format stays true to the conference's DNA: 25-minute talks, 50-minute hands-on workshops (real ones where attendees leave with something tangible…not just slides and handouts), and lightning talk sessions for the short-form ideas that still deserve airtime.

DevRelCon Is More Than It’s Daily Sessions

The conference runs Wednesday and Thursday, but the experience starts Tuesday night with a mini hackathon for early arrivals. Consider it a low-stakes place to build something, get dinner, and shake off the travel before the main event.

Industry City itself is part of what makes this work. The converted warehouse complex in Sunset Park, Brooklyn is surrounded by art studios, coffee shops, and the kind of industrial-creative energy that makes a conference feel like an adventure rather than an obligation. MLH rents out the co-working space for an un-conference track that runs parallel to the main programming: attendees vote on topics, self-organize, and lead peer discussions without a deck in sight. Some of the best conversations at DevRelCon happen there.

And yes, of course, there's a happy hour at the end of day one. And after that? There's usually karaoke.

Who Should Come to DevRelCon?

The honest answer is that, if your work touches developers in any way, there's something here for you. That includes people at large platforms, startups, open source projects, and companies that aren't developer-focused but work alongside a lot of developers internally. DevRelCon has always been better at including people across that full spectrum than most conferences in its category.

Scholarships are available for students and people currently in career transition.

Apply for a Scholarship

If you need to make the case to your organization for attending, there's a ready-made script at the "Convince Your Boss" page on the DevRelCon site.

The Part That's New This Year

MLH has been running the New York edition of DevRelCon for several years. This year, with DEV now part of the MLH organization, the conference has a more direct connection to one of the largest developer communities on the internet. That means more paths to find your people before you arrive, more ways to keep the conversation going after you leave, and more infrastructure to make DevRelCon the year-round presence it's always had the potential to be.

The lab and the library, finally in the same building.

Tickets are available at nyc.devrelcon.dev. See you at Industry City in just a few weeks!

FAQ

When and where is DevRelCon NYC 2026?

July 22–23, 2026, at Industry City, 220 36th St, Brooklyn, NY. The full experience kicks off Tuesday night, July 21, with a mini hackathon.

Who is this conference for?

Anyone whose work involves developers: DevRel professionals, developer experience teams, product marketers, platform PMs, and go-to-market strategists. It's also a strong fit for people at companies that aren't developer-first but work alongside a lot of developers internally.

What does the programming look like?

Multi-track sessions across two full days, including 25-minute talks, 50-minute hands-on workshops, and lightning talks. An un-conference track runs in parallel in the co-working space at Industry City, where attendees self-organize and lead peer discussions on topics they vote on the day of.

What's the vibe?

Casual and intentionally indie. About 300 attendees, a community that's been building for 10+ years, and a venue that leans into that energy. Expect good conversations in the hallway as much as in the sessions, a happy hour at the end of day one, and, historically, karaoke.
Are there scholarships available? Yes — for students and people currently in career transition. Applications are open on the DevRelCon site.

What if I need help getting my company to cover attendance?

There's a ready-made "Convince Your Boss" script on the DevRelCon site.

What's new this year?

With DEV now part of MLH, DevRelCon has a direct connection to one of the largest developer communities on the internet — more ways to connect with attendees before and after the event, and more infrastructure to make the community year-round.

Inside #100DaysofSolana: A Guided Path into Web3

MLH Team — Thu, 21 May 2026 19:14:12 +0000

TL;DR - 100 Days of Solana is a four-epoch program from MLH and Solana that walks hackers from curiosity about Web3 to building applications on a real blockchain. As of this week:

Where it is now: 29 days in, starting Epoch 2.
What Epoch 1 covered: Reading data from Solana, finding your way around the ecosystem, the fundamentals.
What's coming: Epoch 2 moves into writing data on-chain (token economics, digital assets, NFTs). Epoch 3 covers writing programs. Epoch 4 is shipping and exploring.
How it works: A flexible weekly rhythm – Try, Build, Stretch, Document, Amplify – designed so participants don't need to hit every day to benefit.

Just over a month ago, we kicked off #100DaysofSolana, a program designed to walk hackers from “I’ve heard of blockchain” to “I built something on it.” As an introduction to Solana, we spent Epoch 1 working through the basics and giving all of our participants the chance to get comfortable with concepts that, for most developers, have always lived behind a wall of jargon.

As we get ready for Epoch 2, we invite you to learn about the opportunity and consider joining us: The beauty of #100DaysofSolana is that you can do just that. Start today. Walk away in another 70 days with a new set of skills, a new understanding of web3, and an understanding of how to build on Solana’s blockchain.

What is Solana?

Solana is a blockchain platform – part of the broader web3 ecosystem that also includes Bitcoin and Ethereum. (If you’re not familiar, a quick explanation on web3 can be found here, and you can explore more in DEV’s web3 tag. And here’s a blockchain explanation too.)

What makes Solana different is speed and cost. Blockchain platforms have struggled with both; at one point, Bitcoin’s annual electricity consumption was higher than the country of Switzerland. Solana was built to make everyday transactions practical rather than purely theoretical – which is what makes it a useful place to actually build.

The platform also supports small programs that run on-chain when a transaction calls for them. They are the building blocks for some of the most interesting work happening on the chain.

Why #100DaysofSolana Right Now?

Web3 is still in its youth as a concept and a practice. And we often get the question from next gen developers who are still learning, “How can I learn more?” The honest answer is that the path to learning in this one case is a bit more challenging than most: A lot of the available material – including Solana’s own documentation – is written for people who already understand it, and the existing community has a vernacular all its own, where familiar words can mean unfamiliar things. A developer who is curious about web3 can spend a long time bouncing off resources that assume they already “get it” to a certain extent.

We wanted to close that gap and #100DaysofSolana was developed to help do just that.

The program assumes a participant already knows the world of web and mobile development, and can bridge from there into Solana. For instance, we started off our program by aligning the idea of Solana with the idea of a global database. And then we worked through accessing and reading data from it as you would learn how to find and read data in a database you are familiar with navigating.

Solana is exactly the right partner for this kind of program.

Compared with earlier blockchains, it is faster and more affordable to use, which makes it practical for real applications rather than purely theoretical ones.
It hosts a meaningful share of stablecoins – digital currencies pegged to traditional ones – and the things people are building on it span payments, digital assets, loyalty and incentive systems, and ownership models with no obvious Web2 parallel.
The platform is still early enough that developers working with it now have a real chance of being part of figuring out what works.

And 100 days, rather than a weekend or a month, is deliberate. Learning Solana isn’t just learning a new library…it is a different mental model so you need more than a few days to really wrap your mind around it and let it sink in. Smart contracts, on-chain data, token economics, and digital assets don’t map cleanly onto anything most developers have built before, so that shift takes time. The career math lines up too: as AI reshapes entry-level software work, picking up a specialization is one of the most useful things an early-career developer can do, and a hundred days of hands-on Solana experience is something concrete to point to.

What #100DaysofSolana Looks Like for Participants

We built #100DaysofSolana with our participants in mind, and the belief that a little bit every day goes a long way to learning new skills. Every week follows a pattern that’s designed to be flexible (with even more flexibility on the weekend because we know you need rest).

Monday – Try: A new topic gets introduced.
Tuesday – Build: Participants put hands on the keyboard and put the idea into practice.
Thursday – Stretch: A deeper challenge that pushes the week’s concept further.
Saturday – Document: Participants write about what they’ve learned on DEV.
Sunday – Amplify: Engage with other participants on DEV or social platforms and see what everyone else is learning and trying out.

The structure is built so no participant has to complete all 100 days perfectly to benefit. A developer who does just Try and Build in a given week still walks away with enough to understand the topic and move on. The Saturday and Sunday rhythm – write it down, share it – borrows from the way working developers actually build expertise: in public, with feedback.

We just finished Epoch 1 where we focused on the fundamentals: where Solana data lives, how to read it, and how to get oriented in the ecosystem. The goal was less about writing code and more about building familiarity – making the platform feel less like a black box and more like something a developer can actually navigate.

We’re just getting started with Epoch 2.

What’s Next for #100DaysofSolana in Epoch 2

Next we are going to move from reading to writing. Participants start manipulating data on Solana, beginning with concepts like token economics, incentives, and digital assets. The first challenge asks a deliberately concrete question: What would it look like to build a tokenized reward system on Solana, like a supermarket loyalty card? Or a Reddit-style karma system?

Those questions are also the door into the concept of NFTs, which, despite their reputation, aren’t limited to expensive jpegs of memes and monkeys. An NFT is a unique token recorded on a blockchain, usually with metadata that points to or describes a specific digital or real-world item, and the range of practical uses is much wider than the headlines suggest. This is the point in the program where the learning starts to feel applied. Participants are no longer just reading from the chain. They’re putting things on it.

Where #100DaysofSolana Goes Next

Epoch 3 moves into writing programs on Solana directly. This is where the foundational concepts from the first two epochs become tools, and participants start building software that runs on-chain.

Epoch 4 is shipping and exploring. The structure loosens, the projects get more independent, and participants get the chance to combine everything they’ve learned into something of their own design.

By the end of the 100 days, the goal is to have moved a hacker from curiosity about Web3 to confidence in actually building on it.

There is no shortage of opinions about Web3. But there is a need for patient, sequenced learning material that gets a working developer from the outside of the conversation to the inside without asking them to take anything on faith. #100DaysofSolana is built to be that material: a guided path, paced for someone learning from scratch, designed around the assumption that the best way to understand any new technology is to spend enough time with it to form an actual opinion.

Hackers can follow along, join in late, or come back at any epoch. The program is built to accommodate all of those. More information, and signup, is available at https://mlh.link/solana-100. You can also explore our DEV content for the program here: https://dev.to/100daysofsolana

FAQ

Do I need to know anything about Solana or Web3 to join 100 Days of Solana?
No. The program is built for developers who already know web or mobile development but have never worked on a blockchain. Epoch 1 covers the fundamentals from scratch – what Solana is, where its data lives, and how to read from it.

Can I join now that the program is already underway?
Yes. The weekly structure is designed to accommodate people joining late, taking breaks, or moving at their own pace. A developer who picks it up partway through can still go back and work through earlier epoch material on their own time.

How much time does 100 Days of Solana take per week?
The week has five themed days (Try, Build, Stretch, Document, Amplify), but no participant is expected to do all five every week. Completing just Try and Build is enough to walk away with the week's concept and move on to the next one.

What do I need to participate?
A computer, a code editor, and a Solana wallet for the on-chain challenges. The program guides participants through wallet setup as part of Epoch 1.

Is 100 Days of Solana free?

Yes.

Do I need to buy SOL to participate?
No, you don’t need to buy SOL. Just like Web2 development, Solana gives you the equivalent of a dev environment where you can practice. It’s called devnet and you can request free devnet SOL from a system called the faucet.

Why Solana, and not Ethereum or Bitcoin?
Solana was built to be faster and cheaper to operate than earlier blockchains, which makes it practical for everyday transactions rather than purely theoretical ones. The program is specifically Solana-focused, but most of the underlying concepts – smart contracts, on-chain data, token economics – apply broadly across Web3.

What happens after the 100 days?
Epoch 4 is shipping and exploring – the structure loosens and participants are given room to combine what they've learned into independent projects. The work and writing produced during the program become portfolio pieces showing real, hands-on Solana experience.

Vibe Coding, Demystified

MLH Team — Thu, 14 May 2026 20:04:04 +0000

TL;DR -Vibe coding is the practice of building real software by talking to an AI, in plain English, instead of writing every line by hand. The whole stack a beginner needs fits into four roles: a conversational AI tool for the rough draft, an AI-powered editor for the real work, a version control service to save progress, and a deployment service to put the project online. The human still picks what to build, judges whether the result is any good, and decides when it ships. The on-ramp is shorter than it has ever been.

Vibe coding has become the shorthand for a way of building software that did not really exist three years ago. A person opens a conversation with an AI tool, describes what they want, gets working code back, and ends the session with something live on the internet. No bootcamp. No three-hour Homebrew install. No semicolon hunt at 2am.

This piece is for the software creator: the person who wants to build something useful, not someone trying to become a senior engineer at a megacorp. The advice differs depending on which path a learner is on, and the previous piece in this series sketched both. What follows is the practical shape of the software creator path, the tools that show up in it, and the moments where the human in the loop still really matters.

What an Actual Session Looks Like

The best way to understand vibe coding is to walk through a real one. Let’s examine a site revamp: An experienced developer helped their partner, a cinematographer, replace his Squarespace portfolio with something built from scratch. He had no developer background.

The flow looked something like this:

She pointed him to Google AI Studio and told him to prompt whatever he wanted. He typed something close to “build me a portfolio website for a cinematographer.” A first mockup came back. He kept iterating in conversation until the layout felt right.
Then he downloaded the code. He opened it in an AI-powered editor, which lets a user see the actual project files alongside a chat window. Then an AI assistant inside the editor handled the next round of work: pulling his real bio and project list out of the old Squarespace, making styling changes, and answering his questions along the way.
When he was ready to make it live on the internet, he connected the project to GitHub for version control, then used a hosting service to make it live. He already owned the domain. He asked the assistant which fields to update at his domain registrar, and it walked him through them.

The whole project took him a few weekends of conversation to get to a real website. No tutorial completed start to finish.

When a vibe coding session goes well, it looks just like this. The human is making decisions about taste, structure, and intent. The AI is handling the parts that used to take three hours of YouTube and a sympathetic friend.

The Tool Stack, by Role

The tool landscape can feel overwhelming when seen all at once, partly because the same task can be done in five different products. The simpler way to navigate it is by job. A vibe coding workflow generally pulls one tool from each of these four categories:

Conversational Sketchpad: This is a general AI tool where the first version of an idea gets generated. Google AI Studio, Claude, and ChatGPT all work for this. Some people stay here for the whole project. Others use it just for the rough draft.
AI-powered Editor: This is where the code gets edited with help from an assistant that can see all the files at once. Cursor and Google’s Antigravity are two examples. VS Code with the Copilot extension is another widely used option. These editors are friendlier than dropping straight into a terminal, because the user can see the files and the changes happening in real time rather than typing blind into a black window.
Version Control: We’ve discussed this before. GitHub is the default for most people, and it deserves its own piece in this series. GitLab and Bitbucket exist as alternatives. The function is the same across all three: it tracks every change to the project, so nothing is ever truly lost and rolling back to a working version is always one click away. Think of it as Google Docs history for code.
Deployment Service: This is where the finished thing actually lives on the internet. Cloudflare Pages and Render show up often. Vercel and Netlify are also widely used. Most of these connect to GitHub directly and update the live site automatically whenever the code there changes.

A workflow can use one tool per row, four total. That is really all the infrastructure that your first project needs.

A Note: The differences between the leaders in each tool category are small enough that a beginner will not feel them. Familiarity, free tiers, and whatever a friend already uses are reasonable tiebreakers. The right tool is mostly the one that actually gets used.

Where the Human Still Matters

Vibe coding sometimes gets caricatured as the user typing “build it” and the AI building it. The reality is more collaborative, and the moments that require human judgment tend to cluster in three places.

To begin with, the AI cannot read your mind, so the quality of the first prompt shapes everything that follows. “Build me a portfolio site” is a workable starting point. “Build me a portfolio site for a cinematographer with a dark theme, full-bleed video on the landing page, a project grid that filters by year, and a contact form that emails me directly” gives the AI much more to work with and produces a much more useful first draft. Specificity is the entire skill.

Next is at the breakage point. AI assistants are very good at writing code that works on the first try most of the time. They are less reliable at catching when something subtly does not work. Examples include: A login that lets anyone in; a database connection visible to the public; a form that quietly fails on phone keyboards. These failures look like working code…until they don’t. Asking the AI to audit its own work, after the fact, with prompts like “what would a senior developer change about this?” or “walk me through the security of this database connection,” catches a good portion of these issues before they hit anything real.

Finally, AI can only offer you options – it can’t make decisions for you. What gets built next? What stays in scope? What is good enough to ship? You have to decide what matters.

A Real First Step

Here’s your next move: Open a free account at any of the conversational AI tools mentioned. Ask it to build a simple version of something small and personal: a one-page site, a photo renamer, a tracker for whatever the reader is currently tracking on paper. Talk to it the same way one would talk to a patient friend. Ask follow-up questions when the response does not make sense. Save the project to GitHub when it works. Push it to the internet when it feels real.

The shape of software development has changed. The on-ramp is dramatically shorter, and the number of people who can credibly call themselves builders is about to grow by an order of magnitude. For someone just starting out, the question worth dwelling on now is what to build. The other questions sort themselves out from there.

MLH hackathons are a good place to bring that first project into a room of people doing the same thing. DEV is a good place to write about what got built once it ships. The build happens privately. The learning happens in public.

Frequently Asked Questions

Is vibe coding actually coding?
Depends on the definition. The person doing it ends the day with working software that runs on real infrastructure, which is the part most people care about. The activity looks more like directing than typing. Many working developers now describe their own day-to-day this way.

Do I need to know any code before I start?
No. The cinematographer in the example above did not. What helps is being specific about what is wanted and patient about asking follow-up questions when the AI does something unexpected. Knowing a little code makes it easier to audit the output later, which matters more for anything handling real user data.

Is the code any good?
It is usually functional. It is sometimes great. It is occasionally subtly wrong in ways that matter. Code that handles passwords, payments, or personal information deserves a second look from someone who knows what to look for. Code that renames files in a folder probably does not.

What happens when I get stuck?
Most beginners stall in one of two places: a feature that will not work no matter how it gets reprompted, or a deployment step that throws an error message in unfamiliar language. The fix for the first is usually to restart that part of the conversation with a more specific prompt. The fix for the second is to paste the exact error message back into the AI and ask what it means. Search engines, the DEV community, and an MLH event are also genuinely useful at this point.

Is this how real developers work now?
Many of them, yes, at least for parts of the job. Senior engineers tend to use AI as a collaborator for unfamiliar territory and a multiplier for familiar territory. The skill that distinguishes them from beginners is knowing when to trust the output and when to dig deeper. That skill is learnable, and it develops through practice.

How much does vibe coding cost?
Most of the conversational AI tools have generous free tiers that are enough for a first project. GitHub is free for public repositories and most personal use. Cloudflare Pages, Render, Vercel, and Netlify all have free tiers that cover small sites. A custom domain costs roughly ten to fifteen dollars per year. A learner can ship a real first project for the price of a domain name and nothing else.

Should I still learn to code the traditional way?
That depends on the goal. Someone aiming for a software engineering career will benefit from foundations: a real language, the basics of how computers actually run code, some experience reading code written by other people. Someone who just wants to build a thing that solves a problem in their own life can probably skip that, at least at first. The previous piece in this series breaks out both paths in more detail.

How a Hackathon Weekend Produces What a Hiring Manager Actually Wants to See

MLH Team — Fri, 08 May 2026 20:40:02 +0000

TL;DR: Self-taught developers who can build do not always look hireable on paper, and the gap is rarely about skill. Hiring managers screen for four signals that tutorials and personal projects almost never produce: code with another person’s name on it, a project that lives at a real URL, a Git history that reads like a working developer’s, and a reference who has watched the candidate ship under pressure. A hackathon weekend produces all four at once. That is why an MLH event tends to do more for a job search than another month of solo study, and why the participants who walk out on Sunday afternoon often look meaningfully more hireable than they did on Friday night. According toMLH, 91% of community members pick up something at events and programs that classrooms and workplaces miss.Stack Overflow’s 2025 Developer Survey reports that 44% of new coders now learn alongside AI tools, and 82% of developers built their skills primarily through online resources rather than in school.

A specific kind of frustration shows up a few months into self-taught coding. The learner has shipped a few projects. They can read most of the code in the open-source libraries they use. They are no longer afraid of the terminal. By every internal measure, they have become a developer. And the rejection emails keep arriving anyway, sometimes without an interview, often without a human eye on the application at all.

The frustration is reasonable, and the cause is usually not skill – it’s legibility. A hiring manager scanning hundreds of candidates is reading for specific signals, and most self-taught portfolios send almost none of them. A solo project, however well-built, looks indistinguishable from a thousand other solo projects. A polished GitHub profile with five tutorials reproduced cleanly is, to a recruiter’s eye, evidence of nothing in particular. The candidate is not failing the technical bar. The candidate is failing the legibility bar.

A hackathon is the fastest way over that bar. Two days at a real one produces the exact four things a hiring manager is actually scanning for, in a form almost nothing else in the self-taught path can match.

What a Hiring Manager Is Actually Looking For

Strip the hiring process down to its bones, and four signals do most of the work. Every one of them is hard to fake, hard to manufacture alone, and easy to recognize when it shows up.

The first is collaborative code. Real software almost never gets built by one person, and a candidate who has only ever shipped solo projects is a candidate who has not yet been tested on the part of the job that fills the actual workday. A hiring manager wants evidence that the candidate has read someone else’s code, written code that someone else then read, and survived the negotiation between the two.

The second is something that lives at a real URL. The leap from “it works on my laptop” to “anyone can click this link” is wider than most beginners realize, and crossing it is a meaningful credential on its own. A live deployment proves the candidate has thought about hosting, environment variables, and the long list of small operational details that solo tutorials almost never cover.

The third is a Git history that looks like a working developer’s. Not a single commit labeled “initial commit” with five thousand lines of code attached. A real history of branches, merges, fixes, and small atomic changes — the texture of how software actually evolves when more than one person is touching it. Recruiters and engineers can read a git log the way a literary critic reads an early draft. They can tell the difference between a portfolio assembled in one sitting and a project that was actually built.

The fourth is a reference who has watched the candidate work. Not a former employer in an unrelated field. Not a bootcamp instructor who graded a final project. Someone who has seen the candidate make decisions under time pressure, debug something that mattered, hand off a half-finished piece of code to a teammate, and recover when something broke. That reference is the single hardest credential for a self-taught developer to acquire, and almost the only reliable way to acquire it outside a workplace is through a hackathon.

Solo learning, no matter how diligent, produces zero of these signals. A hackathon weekend produces all four.

How a Weekend Produces Each One

The way a hackathon manufactures these credentials is mechanical, not magical. The format itself does the work.

Collaborative code happens because there is no other option. A team of four sharing a single repository for forty-eight hours generates more genuine collaboration than most beginners experience in their first year of solo building. Branches get pushed and pulled. Merge conflicts get resolved out loud, with a teammate at the next table. By Sunday afternoon, the participant has worked inside a shared codebase the same way working developers do every day, and the artifact lives on GitHub afterward as proof.

Live deployment happens because the project has to be visible to judges. Nobody is going to walk a panel through code on a personal laptop. The team picks a hosting platform, wrestles with environment variables for an hour, breaks something, fixes something, and lands at a working URL. That URL goes onto the resume. The hiring manager clicks it.

The Git history takes care of itself, almost as a side effect. Forty-eight hours of small commits from multiple authors produces exactly the kind of git log a senior engineer recognizes as real. There is no way to fake this and no need to. The format generates the history naturally, and the history is the credential.

The reference is the part that surprises people. Mentors at MLH events are working developers, and the good ones genuinely remember the participants they helped. A participant who asked sharp questions, came back with progress, and shipped something that ran is exactly the kind of person a mentor is willing to vouch for later. The same is true for teammates. Two days of building together, with everything that happens in those two days, produces the kind of professional context that lets one developer write a real recommendation for another. A hackathon team is, functionally, a small temporary workplace. Workplaces produce references.

We see this happen at our events constantly. The participant arrives Friday night with a portfolio that looks like every other self-taught portfolio. By Sunday afternoon, the same portfolio has a collaborative repo on it, a live link, a real commit history, and the basis for at least one genuine reference. Nothing else on the calendar produces all four in a weekend.

Why the Format Beats the Alternatives

It is worth comparing this to the things a job-searching beginner typically does instead, because the comparison is what makes the case.

Another solo portfolio project produces more code, but no collaborative signal, no reference, and a Git history that still reads as solo work. The candidate looks marginally more accomplished and exactly as illegible to a hiring manager.

Open-source contribution, done well, produces a real collaborative signal and can produce a reference over time. The catch is the time. A meaningful open-source contribution usually takes weeks of context-building before the first pull request lands, and the reference takes longer than that. The path is real and worth walking, but it is much slower than a weekend.

Bootcamps produce references and structured projects, but the projects often look like every other graduate’s projects, and the reference is from an instructor who graded the work rather than a peer who built alongside it. The hireability lift is real but expensive, and the projects rarely carry the texture of real-world constraint that a hackathon project carries by default.

A hackathon, by contrast, costs a weekend, produces all four signals, and produces them in a form that is hard to fake and easy to point to in an interview.

There is also a piece of the experience that no amount of solo polish can substitute for. Working with other people on a deadline teaches a candidate how to make decisions under constraint, cut features they were attached to, and ship something imperfect on time. AI has become a remarkably patient tutor, and the chat-style interface has lowered the bar for asking the questions that used to feel embarrassing. But AI does not sit shoulder-to-shoulder. It does not push back on a feature the team should probably cut, even when the team’s pride is bound up in keeping it. AI will agree with almost anyone. A teammate, in the politest possible way, will not. The ability to ship under that kind of pressure is what hiring managers are reading the four signals for in the first place.

What to Do With the Weekend in a Job Search

The weekend ends. Now you have to figure out how to use it.

The repository goes onto the resume with a one-line description that names the team, the timeframe, and the live link. Not “hackathon project,” which reads as decorative. The actual format hiring managers respond to looks closer to: Built a collaborative finance dashboard in 48 hours with a team of four at [Specific Hackathon]. Live at [URL]. Shipped a working OAuth flow, a real-time data feed, and a deploy pipeline on Render. The specifics are what makes the line legible.

The mentor relationship gets maintained, deliberately. A short thank-you message on Sunday night, a follow-up a week later with a question about something they mentioned, a link to the finished project once it’s polished. Mentors who get treated as actual professional contacts will respond as actual professional contacts. The reference materializes from there.

The teammates get added on LinkedIn before anyone leaves the venue. The strongest professional network a self-taught developer can build in their first year of looking for work is the network of people who watched them ship something. A hackathon manufactures a small piece of that network in a weekend.

The DEV writeup is the move that ties it all together. A post that walks through what got built, what broke, what the participant learned, and what they would do differently turns the weekend into a public artifact that hiring managers can read before they ever open the resume. It is, in effect, the cover letter the candidate did not have to write.

The Door Stays Open

A self-taught developer can do almost everything alone in their first year of learning, but they cannot manufacture the four signals a hiring manager is reading for. Nobody can, alone. Those signals come from working with other people on something real, and the cheapest, fastest, most reliable way to do that outside a job is a hackathon.

We run them year-round, with beginner tracks baked in. The weekend is the move.

Frequently Asked Questions

Do hackathon projects actually count on a resume?

Yes, when they are described specifically. A line that names the event, the team size, the timeframe, the live link, and one or two technical specifics reads to a hiring manager as evidence of shipping under constraint. A line that just says “hackathon project” reads as decorative and often gets skipped. The artifact is real; the description has to match.

Will a hiring manager actually click the live link?

For a junior or self-taught candidate, often yes. The live link is one of the highest-signal items on the resume because it proves the candidate has crossed the gap between local development and real deployment. A working URL with a clear, functional project behind it can do more for a candidate than a polished resume bullet.

Is a hackathon better than another solo portfolio project for getting hired?

For most self-taught developers, yes. A solo project demonstrates skill but not collaboration, deployment under pressure, or the texture of working with other people. A hackathon project demonstrates all of those and produces the artifacts that prove it. A candidate who has both is stronger than a candidate with only one, but the hackathon is the higher-leverage weekend.

Do I need to win or place to put a hackathon on my resume?

No. Winning is a nice line, but the real credential is the artifact: the repo, the link, the team, the deploy. Most hiring managers care far more about what got built than about which prize it took home, and many candidates put hackathon projects on their resumes without ever placing.

How does a hackathon compare to open-source contribution for hiring purposes?

Both are valuable, and they produce different signals on different timelines. Open-source contribution is slower but builds a deep, ongoing track record over months or years. A hackathon produces the same kinds of signals in a single weekend, faster but shallower. The strongest self-taught candidates often have both, with the hackathon as the entry point and open-source contribution as the long-term play.

What if I’m not technically advanced enough to be useful on a hackathon team?

The premise of the question is wrong, but the worry is common. Hackathon teams routinely include complete beginners, and the beginner often ends up doing real work — writing copy, building the landing page, handling part of the front end, demoing the project to judges. Showing up at a level below the rest of the team is the norm, not the exception, and it produces the same four credentials regardless.

What should the resume bullet for a hackathon project actually say?

Something close to: Built [specific project] in [timeframe] with a team of [N] at [event name]. Live at [URL]. [One specific technical achievement, e.g., shipped an OAuth flow / built a real-time data feed / deployed on Render with environment-based config]. The specificity is the credential.

The post How a Hackathon Weekend Produces What a Hiring Manager Actually Wants to See appeared first on Major League Hacking News.

How a Hackathon Will Teach a New Developer What a Year of Tutorials Can't

MLH Team — Thu, 07 May 2026 16:57:37 +0000

TL;DR- A hackathon compresses what would take months of solo learning into a single weekend. Beginners use Git, APIs, deployment, team collaboration, and mentor relationships in earnest, not in tutorial form. According to MLH, 91% of community members learn something at events and programs that they are not learning in the classroom or at work. Stack Overflow's 2025 Developer Survey puts AI tool use among new learners at 44% and finds that 82% of developers learn primarily through online resources rather than in school. Neither AI nor online tutorials replicate what 48 hours in a room with mentors and a deadline can do. For a beginner who has been experimenting alone, a hackathon is the highest-ROI weekend on the calendar.

There is a stage in every new developer's journey where experimenting alone starts to feel circular. The same beginner who once felt powerful asking an AI to help them build a weather widget starts to notice they can’t quite see how or why the widget works, can’t quite explain it to someone else, and wouldn't know how to fix it should something break. It’s not a sign of failure. It’s simply telling you that solo learning has done what it can and now it’s time to do more. The next move is somewhere with other people in it.

That somewhere is a hackathon. A weekend hackathon does more for a beginner's understanding of how software actually gets built than any tutorial, course, or conversation with an AI agent ever will. The reason is simple: those things teach the moves in isolation, much like a language learning app like Duolingo can teach someone vocabulary and grammar. Like a conversation in your new language on the streets of a foreign city, a hackathon makes a beginner use all of them at once, in front of other people, on a deadline.

This is an important step in the developer's learning journey – a bridge that gets you from experimenter to project builder phase. Skipping it is possible. Doing it is faster.

What a Hackathon Actually Is (and What It Isn't)

A few misconceptions tend to keep beginners from signing up.

A hackathon is not Shark Tank with laptops.
It is not a 48-hour bro-coding endurance test.
It is not a job interview, not only for computer science majors, and not the place where a beginner gets exposed for not knowing enough.

What a hackathon actually is: a short, structured event, typically a weekend, where small teams build a working project together, with mentors and organizers on hand. Most teams are small, and cap at roughly four people. Most events run on university campuses, in corporate event spaces, or as fully virtual conferences. The atmosphere is closer to a creative residency than a competition.

Showing up does not require packing a research lab. For our MLH-supported events, we partner with organizers to provide the space, the food, the mentors, and the sponsor APIs and credits a team will inevitably reach for. A participant brings a laptop, a charger, and a willingness to be confused and then hopefully unconfused for a few hours. For the hour-by-hour breakdown of how the weekend runs, our What to Expect at a Hackathon summary handles the logistics; the packing guide handles the rest. Let’s discuss why this format is so effective.

Who Actually Shows Up At A Hackathon

A stubborn myth about hackathons is that they are for people who already know what they are doing. The opposite is true. Beginner tracks are now standard at MLH events specifically because the median attendee is closer to "wrote their first line of code last month" than "five years in industry." The mix is the feature. A team of four can contain a complete novice, a hobbyist with a year of side projects, a CS sophomore, and someone who has been working professionally for a while, or any mix of these profiles. Each one teaches and learns from the others in different directions.

The version of this that experienced developers know, and that beginners often miss, is that asking the questions a person would be embarrassed to ask in a classroom is the hackathon's hidden curriculum. Everyone in the room is mid-build, mid-stuck, or mid-figuring-it-out. Nobody has the bandwidth to judge a stranger for not knowing how to push to a remote branch. They are too busy with their own remote branches.

The numbers underwrite the point. Stack Overflow's 2025 Developer Survey found that 44% of people learning to code in the past year used AI tools to help them, up from 37% the year before. The same survey found that 82% of developers learn primarily through online resources, compared to just 49% who learned in school. The new developer is not an outlier; the new developer is the average. A hackathon room is the most concentrated possible version of that community.

What a Hackathon Participant Touches in 48 Hours That Solo Learning Takes Months to Reach

This is the core of why hackathons work. A solo learner can spend half a year doing everything right.

They’re finishing tutorials.
They’re building little projects.
They’re watching the videos, and they’re still never use most of the tools a working developer touches every day.

A hackathon participant uses them all in a weekend, often for the first time, and uses them for real.

Version control as an actual workflow. Not a tutorial about Git. A real branch, a real merge, the first merge conflict resolved with a teammate sitting two feet away.
APIs as a means to an end. The team needs payments, or maps, or weather data, and the API is how they get it. The abstract concept becomes concrete in the time it takes to read a docs page.
Public deployment. Somebody has to put the thing at a URL before judging starts. The leap from "it runs on my laptop" to "anyone can visit this link" is one a lot of solo learners never make.
Team collaboration. Splitting work, reading someone else's code, agreeing on scope, cutting a feature when the clock runs out. These are the skills the industry actually hires for, and the ones tutorials never teach.
Mentor relationships. The single most compressed learning channel a beginner can access. A working developer one or two stages ahead can answer in five minutes what a beginner would otherwise spend a weekend Googling and trying to unpack – or Googling and giving up.

Our own numbers make this concrete. 91% of MLH community members report learning something at events and programs that they are not learning in the classroom or at work. The hackathon does not duplicate formal education. It teaches the things formal education routinely skips.

Why Hackathons Work as a Learning Shortcut

The mechanism is worth naming directly, because it explains why nothing else replicates it.
Solo learners optimize for completeness. They want to understand things before they use them. The instinct is reasonable but also slow. A hackathon flips the priority: the team optimizes for shipping. The deadline forces decisions a solo learner can defer for weeks, like picking a stack, scoping a project down, cutting a feature, or calling something "done." Each of those decisions is a learning event. Made under pressure, with a team, in front of mentors, they happen at roughly ten times the pace of solo study.

The mentor effect compounds the rest. A working developer two stages ahead of the beginner can collapse a trial-and-error loop from months into minutes. The beginner who would have spent a Saturday wrestling with an environment variable gets a one-line answer and moves on. Multiply that across a weekend and the pace of skill acquisition genuinely changes.

There is also a piece that AI cannot simulate. AI has become a very good coach for someone learning alone. The conversational nature of modern tools has made asking dumb questions safer than it has ever been. But AI does not stand next to anyone, does not hand off code mid-project, does not have to be convinced that a feature should be cut. AI will not kill their darlings. Your teammates might. The texture of working with other humans on a deadline is the part of the craft that no current tool reproduces. A hackathon is the cheapest, fastest way to get that texture.

The Monday After Your Hackathon

The project that gets built over the weekend is rarely the most important thing the participant takes home. Most first hackathon projects are functional, ugly, and a little embarrassing, and that is the correct outcome.

The actual take-homes are different. A working mental model of how the modern toolchain fits together. A GitHub repository with real commits and at least one collaborator's name on it. Contact information for one or two mentors who would now recognize the participant in their inbox. The lived texture of what shipping software under pressure actually feels like. None of those show up on a resume, and all of them show up the next time the participant sits down to build something alone.

That next solo project is the next step after this for most developer’s learning journeys, and it is much more achievable on the Monday after a hackathon than it was the Friday before. The DEV writeup of the weekend — what got built, what broke, what the participant learned — is the move that bridges gaps. The portfolio, the public record, the body of evidence that turns a beginner into a hireable developer all start with a single post about a single weekend.

The Open Door

A new developer can do almost everything in their first year of learning alone. They cannot, alone, manufacture a deadline, a team of strangers willing to build with them, or a room full of mentors who answer questions for free. A hackathon is the single weekend on the calendar where all three exist at once.

MLH runs them year-round, with beginner tracks built in. Showing up is the move.

Frequently Asked Questions

What is a hackathon, in plain English?

A hackathon is a short event, usually a weekend, where small teams of developers and would-be developers build a working software project together, with mentors and organizers on hand. Teams typically cap at four people. The point is not competition. The point is structured immersion in how software actually gets built.

Do I need to know how to code before going to a hackathon?

No. MLH events run beginner tracks specifically because the median attendee is closer to "wrote their first line of code last month" than "five years in industry." A team of four routinely contains a complete novice alongside a more experienced builder, and the mix is a feature. Stack Overflow's 2025 Developer Survey reports that 82% of developers learn primarily through online resources rather than in school, which means the hackathon room is the most concentrated possible version of the average new developer's learning environment.

Are hackathons worth it for new developers?

More than almost any other single weekend a new developer can spend. According to MLH, 91% of community members learn something at events and programs that they are not learning in the classroom or at work. The format compresses Git, APIs, deployment, team collaboration, and mentor access into 48 hours. A solo learner can spend months without touching all five.

How long does a hackathon last?

Most hackathons run between 24 and 36 hours of building, spread across a weekend. Some run a full week; some run an afternoon. MLH events typically follow the weekend format, with team formation on Friday night, building Saturday into Sunday morning, and judging on Sunday afternoon.

Do I need a team before I show up?

No. Most hackathons run team-formation activities at the start of the event specifically for solo arrivals. Showing up alone is the norm, not the exception.

What's the difference between an MLH hackathon and a hackathon found anywhere else?

MLH events are run with explicit beginner support: tracks, workshops, mentors, and a code of conduct that is enforced. Some independently run hackathons offer the same; many do not. The MLH name is essentially a guarantee that a beginner will be welcomed, mentored, and not embarrassed for not knowing things.

What should a beginner expect to walk away with?

A working mental model of how software gets built, a GitHub repository with real commits, at least one mentor or teammate who would now recognize them, and the texture of what shipping under pressure feels like. The project itself is rarely the most valuable take-home. The model is.

The Next-Generation Developer Path: From First Line of Code to First Job

MLH Team — Fri, 01 May 2026 17:01:27 +0000

TL;DR — Five stages turn a software creator into a job-ready developer: experimenting with AI, attending a beginner-friendly MLH hackathon for structured immersion, building solo projects, curating a portfolio (pinned GitHub repos, READMEs as case studies, DEV writeups, and open source contributions through programs like the MLH Fellowship), and entering the job market with a public body of work. The U.S. Bureau of Labor Statistics projects software developer employment to grow 17% from 2023 to 2033 with roughly 129,000 annual openings, but entry-level postings have dropped 40% from their 2022 peak, and Big Tech has reduced new graduate hiring by around 25% since 2023. The takeaway: the door to a developer career is still open, but the doorway is narrower — and the people who make it through treat their public work, their community participation, and their AI fluency as the second half of the strategy.

There is a moment in every new developer's journey where the early excitement of building something runs into a harder question – not how to write the code, and not how to ship a first project. What comes next is a different kind of work. The question shifts from "can I build something?" to "can I turn this into a career?"

That question matters more than it used to. The U.S. Bureau of Labor Statistics projects software developer employment to grow 17% from 2023 to 2033, with around 129,000 annual openings. It’s a market that genuinely exists and has plenty of room. But entry-level postings have dropped roughly 40% from their 2022 peak, and what employers expect a "ready" candidate to look like has shifted sharply. The door is open. The doorway is narrower than it used to be. The pipeline below is structured around making it through.

Five stages. Each one earns the next.

Stage One: The Experimenter

The first stage is the one most thoroughly covered before now. A software creator at this stage might be having conversations with AI, generating small things, watching them run, changing values, asking why. It is genuinely creation, even if the experimenter does not yet feel like a "real" developer. Calling someone in this state a software creator from day one is not generous – it is accurate.

The job of this stage is to feel the loop, build curiosity, and notice when AI alone stops being enough. The signal that it has stopped: the experimenter can make things work, but cannot quite see how the things work. That gap is a cue to move on to a new way of learning.

Stage Two: The Hackathon Participant

The conventional advice after experimenting is "start your own project." That advice misses a step. Going from chatting with an AI to opening a blank file solo is a leap that loses a lot of would-be developers. A better intermediate move is to spend a weekend at a beginner-friendly hackathon. (We have a lot to choose from.)

Beginner-focused MLH events run with workshops, mentors, beginner tracks, and explicit invitations for people who have never built anything before. The point is not competition; it is structured immersion in compressed, social form. In a single weekend, a participant typically gets exposed to version control, working with APIs, public deployment, real team collaboration, and most importantly, mentors who can answer questions in real time.

That last piece matters more than the others combined. A mentor one or two stages ahead (sometimes only six months ahead tbh) compresses what might be months of solo trial and error into a few hours of "oh, that's how you do that." The output of a first hackathon is supposed to be rough. The point is the mental model the participant takes home: a working sense of how the pieces fit together. That sense is what makes everything that comes after possible.

Stage Three: The Project Builder

With hackathon scaffolding behind them, a solo project finally makes sense. The new project builder has watched real developers work, used Git in a live setting, and seen how a team scopes an idea down to something achievable. The blank file is no longer a void. It’s a starting point.

The shift at this stage is less about what gets built and more about how. Experimenters let AI generate code. Project builders ask AI to teach them while it generates. They keep building the public record on GitHub. They start to recognize their own taste, like what kinds of problems they enjoy, what they want to get better at, and what they want to avoid.

This stage is also where the question of a "first language" stops being a research project and starts being a byproduct. The hackathon usually decides it. Whatever the team used over the weekend, a project builder likely continues using.

Stage Four: The Portfolio Developer

This is where the journey changes from learning to positioning. By this point, the software creator has built things, broken things, and shipped things. They likely have at least one hackathon project, a few personal ones, and a growing GitHub history. The next move is to make all of it findable, legible, and persuasive to someone who has thirty seconds to decide whether to keep reading.

A coding portfolio in 2026 is not a personal website with a "Hire Me" button, though it can include one. It is a curated public record. The pieces that matter most:

A GitHub profile pinned with three to five projects that show range, ideally one hackathon project, one solo project the developer is proud of, and one contribution to something larger than themselves. Quantity of repos matters less than coherence. Five thoughtful projects beat fifty abandoned ones.
A README for each pinned project that reads like a short case study. What problem the project solves, what got built, what was hard, what the developer learned, what they would do differently. Hiring managers often read READMEs more carefully than people expect, partly because they double as samples of technical writing. It’s a skill that is rapidly becoming non-negotiable.
A handful of writeups on DEV that document specific moments in the journey: a bug that took a day to find, a concept that finally clicked, a tool the developer has opinions about. These show how the developer thinks which a static portfolio can’t really do on its own. Posts also tend to attract feedback, draw connections, and surface job leads in ways resumes don't.
Open source contributions, even tiny ones. A merged pull request to a real project like a documentation fix, a clearer error message, a small bug. These all prove the developer can read someone else's code, work within a community's conventions, and ship something that meets an actual standard. In other words: They understand team work. Programs like the MLH Fellowship make this stage substantially easier by placing aspiring developers on open source projects with mentorship attached and a stipend that makes focused work possible.

The portfolio developer is, in effect, building a body of evidence. Every project, README, post, and pull request is a small piece of proof. Stage Five is when that proof goes to work.

Stage Five: The Job Seeker

The job market for entry-level developers in 2026 does not look the way it did three years ago, and pretending otherwise sets a job seeker up to misread what is happening to them.

AI has automated a chunk of the boilerplate work that used to be where junior developers could get their starts. Major tech companies have reportedly reduced junior hiring by around 25% in direct response. Some entry-level roles that existed in 2022 like manual QA, basic data entry pipelines, simple CRUD-app maintenance, are not coming back in their old form. That is the bad news, and ignoring it does not make a job search go better.

The good news is that the work has not disappeared. It has shifted. What employers want from junior hires now is harder to specify on a resume but easier to demonstrate in a portfolio: judgment about what to build, taste about whether the output is any good, and the kind of communication skills that let a developer explain their reasoning to humans and prompt their reasoning to AI. A well-curated GitHub profile, a hackathon record, and a few thoughtful DEV posts signal these skills more directly than a degree does. That weighs in favor of self-taught and non-traditional candidates in a way the previous era of tech hiring did not.

A few things tend to actually move the needle at this stage:

Apply broadly, including up-stretch. Entry-level requirements are often aspirational. A strong portfolio routinely beats a year of generic experience, and the only way to find out which postings are negotiable is to send the application.
Be ready to talk about AI fluently. Interviewers in 2026 are asking how candidates use AI tools, where they don't trust them, and what they do when AI gets something subtly wrong. "I use it for everything" is a weak answer. So is "I never use it." The strong answer is specific: here is what I delegate, here is what I verify, here is a time I caught it being wrong.
Reach out directly. A short, specific message to someone whose work the candidate admires – "I built this thing inspired by your project, here's what I learned" – works far more often than people expect. The hiring funnel still favors warm introductions, and warm introductions are made of small, sincere gestures.
Lean on your community. First jobs in the 2026 market are increasingly coming from places resumes don't reach: a project posted on DEV that a recruiter happened to read, a hackathon collaborator who refers the candidate when their company opens a role, a Fellowship cohort whose members hire each other for years afterward. The portfolio gets a person noticed. The network gets them hired. Showing up consistently in community spaces is not optional; it is the second half of the strategy.

What the Pipeline Actually Produces

A developer who comes through these five stages does not arrive at a first job by luck. They arrive with a public body of work, a network of people who have seen them in action, a working understanding of how the modern toolchain fits together, and the increasingly rare ability to think clearly about what AI can and cannot do for them. None of those things are taught in a classroom in any reliable way. All of them are forged in a pipeline like the one we’ve outlined here.

The first developer job, when it comes, is rarely glamorous. It is often a small company nobody has heard of, a role with a vague title, a team of three or four people who all wear several hats. That is fine. That is, in fact, the point. The job is the proving ground for everything the pipeline taught, and the next role (and the one after that) is built on the work that gets done there.
The market is real. The path is real. The next generation of software creators is already walking through it, and the ones who keep walking are the ones who get to the other side.

Frequently Asked Questions

What's the fastest path from absolute beginner to first developer job in 2026?
Five stages, in order: experimenting with AI to learn the loop of building, attending a beginner-friendly hackathon for structured immersion, transitioning to solo projects, curating a portfolio of public work, and applying with that portfolio in hand. Each stage builds skills the previous one couldn't — a hackathon teaches the toolchain that solo learning skips, a portfolio surfaces the judgment that resumes can't show. The pipeline isn't fast, but it's more reliable than picking any one stage in isolation.
Do I need a computer science degree to become a developer?
No. Self-taught and non-traditional candidates are increasingly competitive in the 2026 market, especially when their work is publicly findable. A well-curated GitHub profile, hackathon projects, open source contributions, and writeups on DEV signal taste and judgment in ways a degree can't. Employers now expect candidates to demonstrate skill rather than credential it, which weighs in favor of people who built in public and can show it.
What's a beginner-friendly hackathon and why should I do one?
Major League Hacking and similar organizers run weekend events specifically for first-timers, with workshops, mentors, beginner tracks, and explicit invitations for people who have never built anything before. The point isn't competition — it's structured immersion in compressed, social form. In a single weekend, a participant typically gets exposed to version control, APIs, public deployment, real team collaboration, and mentors who answer questions in real time. A first hackathon is the fastest way to build a working mental model of how real development actually fits together.
What should be in a coding portfolio that actually gets me hired?
A curated public record, not a personal website with a "Hire Me" button. Pin three to five GitHub projects that show range — ideally one hackathon project, one solo project, and one contribution to something larger than the developer themselves. Each pinned project needs a README that reads like a short case study (the problem, what got built, what was hard, what was learned). Add a handful of writeups on DEV and any open source contributions, even tiny ones. Programs like the MLH Fellowship make those contributions substantially easier. Coherence matters more than quantity — five thoughtful projects beat fifty abandoned ones.
How is the entry-level developer job market actually doing in 2026?
Narrower but real. The U.S. Bureau of Labor Statistics projects 17% growth in software developer employment from 2023 to 2033 with around 129,000 annual openings, so the market exists. But entry-level postings have dropped roughly 40% from their 2022 peak, and Big Tech has reduced new graduate hiring by around 25% since 2023. Some entry-level roles that existed in 2022 — manual QA, basic CRUD maintenance — aren't coming back in their old form. The roles that remain demand judgment, taste, and AI fluency, all of which a portfolio can demonstrate more directly than a resume can.
How do I talk about AI in a developer job interview?
Specifically. Interviewers in 2026 are asking how candidates use AI tools, where they don't trust them, and what they do when AI gets something subtly wrong. "I use it for everything" is a weak answer. So is "I never use it." The strong answer names a concrete delegation pattern: here is what I have AI generate, here is what I verify by hand, here is a time I caught it producing something subtly broken and what tipped me off. That kind of answer signals judgment, and judgment is what the role actually requires.
I'm self-teaching alone — how do I find a developer community?
Three places to start: a beginner-friendly MLH hackathon, DEV, and a Discord server in a stack the learner is already using. The hackathon provides intensive in-person or virtual interaction with people one or two steps ahead. DEV provides asynchronous community with feedback and visibility — posts there have a way of finding the right readers. Discord provides daily, low-stakes conversation. Showing up consistently is what matters; the network that gets a person hired is built one small interaction at a time.

A Map for the First-Time Software Creator

MLH Team — Fri, 24 Apr 2026 19:29:01 +0000

TL;DR — Five stages turn a first-time software creator's idea into a deployed product: wireframing (Figma, Balsamiq, Excalidraw), choosing a platform (web, mobile, or no-code via Replit, Bubble, or Webflow), working with APIs, version control on GitHub, and free-tier deployment (Vercel, Netlify, Cloudflare Pages, GitHub Pages). GitHub's 2025 Octoverse report counts 36M+ new developers in the past year, Stack Overflow's 2025 Developer Survey finds 84% of developers use or plan to use AI tools, and Gartner projects 70% of new enterprise apps will run on low-code or no-code platforms by 2026. The takeaway: first-time coders are not behind the curve — they are the curve, and a first project should aim for "ugly and working" over "beautiful and half-done."

Anyone trying to build their first piece of software runs into the same walls. Wireframes. APIs. GitHub. Deployment. No-code platforms that promise everything, mobile apps that demand developer accounts, necessary hosting services that seem to appear out of thin air. Seventeen browser tabs open and no idea why you opened half of them in the first place except that a how-to told you that you should.

What you need is a map, and we have put one together for you.

A Beginner Developer Is Not Behind

Before anything else, a new coder should know they are not alone. According to GitHub's 2025 Octoverse report, more than 180 million developers now work on the platform, and over 36 million new software creators have joined in the past year alone. That’s an average of more than one new account every second. Likewise the 2025 Stack Overflow Developer Survey puts AI tool use or planned use at 84% of developers, up from 76% a year earlier, and reports that 44% of people learning to code in the past year used AI tools to help them do it, up from 37% the year before. Some of these AI users are experienced developers who are learning how to use new tools, but a lot of the newest coders in the development space are average everyday people who have never created software before they gave AI or vibe coding a try.

In other words, the entire field is in motion. Professionals are relearning their own craft. Career-changers are showing up every day. A new coder is not behind the curve. They are the curve.

The First Fork in the Road: Web, Mobile, or No-Code

The earliest meaningful decision is not which language to pick. It is where the thing is going to live. There are three realistic answers, and they lead to different toolboxes.

The web has the most forgiving front door. A website opens in a browser, which means no app store approval and no download step. When a beginner shares the link, it just works. Tools they will hear about include:

Replit: A cloud-based, AI-powered integrated development environment (IDE) that runs code inside a browser tab with nothing to install
Vercel & Netlify: Hosting services that take a finished project and put it at a real address on the internet.

The underlying ingredients are usually HTML for structure, CSS for appearance, and a dash of JavaScript to make things move. Stack Overflow's 2025 survey still places JavaScript and HTML/CSS among the three most-used languages in the world, which is to say the web is both a beginner-friendly path and one with a huge library of free tutorials behind it.

Mobile is a shinier but more challenging entryway. A lot of first time software developers have a first instinct to build something "like the apps on my phone," but iOS and Android apps come with a heavier starter kit. You need to have developer accounts with Apple and Google, to be prepared for review queues that can take valuable time before anything goes live, and to know mobile native languages like Swift or Kotlin that are less forgiving than JavaScript. A common compromise for beginners is a progressive web app, which is really a website dressed up to look and feel like a mobile app. It installs on a phone's home screen, but it skips most of the bureaucracy.

No-code is the fastest way to get something in front of real people. Platforms like Webflow, Bubble, Glide, and Softr let a person drag, drop, and publish an actual working product without typing a line of code. This is no longer a fringe route. Gartner projects that 70% of new enterprise applications will be built on low-code or no-code platforms by 2026, per Hostinger's 2025 low-code trends summary, and that same summary points to non-professional developers or software creators. These non-engineers are building real software, and they are one of the fastest-growing groups in the industry.

None of these paths is better than the others. They are three distinct neighborhoods with their own pathways, cul-de-sacs, and ways of working. The most useful question a beginner can ask themselves is not "which tool is best," but "who is going to use this, and where will they be when they do?"

Sketching Before Building: Wireframes

The cheapest mistake to fix is the one made in pencil, not software.

Professional developers rarely start in code. They start by sketching what the thing is supposed to look like and how a person will move through it. That sketch is called a wireframe, and it does not need to be pretty. It needs to answer small, boring questions before a single line of code gets written. Where does this button go? What happens when someone taps it? What does the empty version of this page look like before there is any data in it?

Modern AI tools can generate a first-pass mockup from a plain-English description, which is a genuine shortcut. The beginner just has to look at it and decide whether it matches what they actually imagined.

You don’t literally need to start with a pencil and paper, though you can. There are online tools and programs that can help you bring your idea to life on a screen:

Figma is the most widely used sketching tool in the industry and has a generous free tier.
Balsamiq is famously, deliberately low-fidelity. Everything looks like a napkin drawing, which is the point, because nobody argues about font choices when the mockup is gray boxes.
Excalidraw is free and feels like drawing with a fat marker.

But don’t let this turn you off of old reliable. A paper notebook also works. Plenty of products started that way.

The Invisible Helpers: APIs

API is a word that intimidates the most beginners, and it almost always stops doing so after one honest sentence: An API is how one piece of software asks another piece of software for help.

Example: When a little weather widget on a webpage shows today's forecast, it did not generate that data natively. It asked a weather service for it through an API. The webpage is the kitchen, the API is the delivery driver, and the data is the groceries. The beginner running the kitchen does not have to grow the vegetables.

This matters because most of the impressive things a first app does are powered by APIs the developer did not have to build. Maps, payments, "Sign In with Google" authentication, AI responses, stock prices, song lyrics, sports scores, and more. This is the quiet leverage of the modern era – a first project can pull in capabilities that entire companies have spent years perfecting. Friendly places to start playing are OpenWeatherMap (weather data), the Pokémon API (exactly what it sounds like, and a legitimately popular learning sandbox), and Spotify's developer docs. And they’re all free.

Where the Code Lives: GitHub

GitHub has a reputation as an intimidating professionals-only clubhouse. It is neither.

As mentioned last week, at its core, GitHub is version history for code. It is the "see edit history" feature in Google Docs, but for an entire project, with the bonus that other people can look at the work and suggest changes. Nothing more complex than that. The community layer, things like stars, pull requests, and collaborations, sits on top of the version history tool. It is not the price of admission.

A beginner does not need to "earn" a GitHub account. They just need to sign up for one. An empty repository is not embarrassing. It is a starting line. The 2025 Stack Overflow Developer Survey names GitHub the single most popular code documentation and collaboration tool, used by 81% of developers surveyed, which means signing up puts a software creator in the same room as roughly four out of every five working developers on the planet.

The Ribbon-Cutting: Deployment

Deployment is the moment a project stops living on one laptop and starts living at a URL anyone can visit, and it is less of a technical hurdle than a ceremony. The software goes from private experiment to something a friend can actually click.

The free-tier options for a first deployment are genuinely generous. Vercel, Netlify, Cloudflare Pages, and Render all host small personal projects at no cost. GitHub Pages will publish a static site for free directly from a GitHub repository, which means the last two sections of this essay can neatly become the same action: push the code to GitHub, and it is live.

The Map Folded Up

Sketch it first. Pick a place for the thing to live that feels right for you, web, mobile, no-code, whatever fits the idea. Ask questions. A lot of AI agents now are great at providing how-tos that can be explained step-by-step so you know what to do next. Ask APIs for help with the hard parts. Let GitHub keep receipts. Deploy when it is ready-ish, not perfect.

Your first project does not need you to master every tool discussed on this tour. It just needs you to see it through to the finish, and it needs to land somewhere a friend can click on it. Ugly and working beats beautiful and half-done, every single time. Every tool mentioned here was built by people who were beginners once, who drew their first wireframe on the back of a receipt and pushed their first repository up with a commit message that probably just said "test."

The neighborhood is open. The map is folded in a back pocket now. Time to go build something…even if it’s a little ugly the first time around.

Frequently Asked Questions

Am I behind if I'm just learning to code now?
No. GitHub's 2025 Octoverse report shows more than 36 million new developers joined the platform in the past year alone — an average of more than one new account every second. Stack Overflow's 2025 Developer Survey found that 44% of people learning to code in the past year used AI tools to help them, up from 37% the year before. Professionals are relearning their craft alongside newcomers, which means a new coder is not behind the curve — they are the curve.

Should I build a website, a mobile app, or use no-code for my first project?
Websites are the most forgiving start: no app store approval, shareable by link, built with HTML, CSS, and JavaScript. Mobile apps are a heavier lift, requiring developer accounts with Apple and Google, review queues, and languages like Swift or Kotlin; a progressive web app is a common middle path. No-code platforms like Webflow, Bubble, Glide, and Softr let you drag, drop, and publish without writing code — Gartner projects that 70% of new enterprise applications will be built on low-code or no-code platforms by 2026. The better question is not which tool is best, but who will use the product and where they will be when they do.

What is a wireframe and do I actually need one?
A wireframe is a sketch of what your software looks like and how a person moves through it. It answers small, boring questions before a single line of code is written: where does this button go, what happens when someone taps it, what does the empty version of this page look like. Popular tools include Figma (widely used with a generous free tier), Balsamiq (deliberately low-fidelity so nobody argues about fonts), and Excalidraw (free and feels like drawing with a fat marker). A paper notebook works too — plenty of products started that way.

What is an API, in plain English?
An API is how one piece of software asks another piece of software for help. When a weather widget on a webpage shows today's forecast, it asked a weather service for that data through an API. The webpage is the kitchen, the API is the delivery driver, and the data is the groceries — the beginner running the kitchen does not have to grow the vegetables. Most of the impressive things a first app can do, like maps, payments, sign-in, and AI responses, are powered by APIs the developer never had to write. Friendly free starter APIs include OpenWeatherMap, the Pokémon API, and Spotify's developer docs.

Do I need to "earn" a GitHub account before signing up?
No. At its core, GitHub is version history for code — the "see edit history" feature in Google Docs, but for an entire project. A beginner does not need to earn a GitHub account; they just need to sign up for one. An empty repository is not embarrassing, it is a starting line. The 2025 Stack Overflow Developer Survey names GitHub the single most popular code collaboration tool, used by 81% of developers surveyed.

Where can I deploy my first project for free?
Vercel, Netlify, Cloudflare Pages, and Render all host small personal projects at no cost on their free tiers. GitHub Pages will publish a static site for free directly from a GitHub repository, which means pushing your code to GitHub and making it live can become the same action. Deployment is less of a technical hurdle than a ceremony — the moment your project stops living on one laptop and starts living at a URL anyone can visit.

What should my first software project actually look like?
Your first project does not need to master every tool. It needs to see it through to the finish and land somewhere a friend can click. Sketch it first, pick a place for the thing to live (web, mobile, or no-code), use APIs for the hard parts, let GitHub keep receipts, and deploy when it is ready-ish, not perfect. Ugly and working beats beautiful and half-done, every single time.

Learning to Code: A Beginner's Guide for the AI Era

MLH Team — Fri, 17 Apr 2026 19:51:58 +0000

Most people remember the first time they opened a terminal. Maybe it was a Tuesday night, on a laptop at a kitchen table somewhere. The window was black. The cursor blinked. And the person sitting there was completely convinced that every other human on earth had been handed some secret manual they'd never seen.

The feeling that everyone else already knows this and I'm the only idiot in the room is the real reason many quit before they start. The work isn't too hard, and they're plenty smart enough. The trouble is that nobody ever hands them a map. They're just dropped into a forest and told the exit is somewhere to the north.

So here's a map. Something that experienced developers are only now starting to say out loud: The path in has changed over the last few years, and a lot of the old advice is out of date.

Don't Learn to Code. Learn to Build Things.

This is the single most important reframe for anyone starting out in 2026. The senior developers and design technologists who've been thinking hardest about the learning path keep landing on the same point: coding and making things are genuinely different activities, and conflating them is what sinks most beginners.

When we say "coding," we mean it in the traditional sense: memorizing syntax, learning paradigms, wrestling with package managers, and debugging a missing semicolon at 2am are just a few examples. It's what you do when migrating a database from one system to another. It's grunt work. No one wants to do grunt work. What people actually want when they "learn to code" is to make something – a website, a tool, a little app that solves an annoying problem in their own life. For Major League Hacking, it's often why someone comes to their first hackathon. Curiosity and a drive to try to build something new.

Those two goals used to be inseparable. If a person wanted to make a website, they had to spend three hours installing Homebrew, then three more installing Postgres, then three more configuring their development environment, before they ever typed a single line of the actual thing they wanted to build. Many beginners quit somewhere in those nine hours, convinced they just aren't cut out for it. The truth is they are – they're just being asked to build the entire toolbox before they get to put a hammer to a nail.

AI has broken that chain. The setup work, the boilerplate, the hunting through Stack Overflow for the right command – the stuff that used to eat the first two months of a beginner's life – can now be handled in a conversation. The craft hasn't disappeared. It's evolved.

The skill today is less about typing the code and more about knowing what to build, knowing whether what got built is any good, and knowing how to ask the right questions to get it there.

A New Coder Is Not Behind. They Are Normal.

More than one in three developers in Stack Overflow's 2024 survey had been coding for four years or less, and about a quarter of working professionals report just one to four years of experience. The industry is much younger than anyone would have you believe. And 82% of developers are learning with online resources, compared to 49% who learned in school – so the self-taught path is the real way in for most working developers today.

Software development as an industry is full of people who taught themselves the parts that mattered most, often while working other jobs, raising kids, or switching careers later in life. Changing careers at 35, parenting a toddler while learning, coming in from a liberal arts background — none of these are disadvantages. They're the everyday profiles of a new coder's future colleagues. And in the AI era, when the entire industry is learning a new way of working at the same time, everyone is a beginner at something.

What "First Language" Even Means Now

Often experienced developers get the same questions. One is "which language should I learn first?" Beginners can turn this into a weeks-long research project. They read comparison articles. They watch YouTube debates. They ask on Reddit and then argue with the replies. Months pass. They still haven't built anything.

Here's the updated answer, and it splits into two paths depending on where the learner wants to end up.

Path One: The Software Creator

Someone who wants to make a personal website, automate an annoying task, build a tool for their own life, or just prove to themselves they can make something new that works. This person should probably not spend months picking a language. They already have one: it's English or the language they grew up speaking. They can open a conversational AI tool – Claude, ChatGPT, Google's AI Studio – and describe what they want to build colloquially.

"Build me a portfolio website for a photographer."
"Write me a script that renames all the photos in this folder."

The AI can generate the code, explain what it did, and walk the learner through deploying it. This is vibe coding, and it has opened the door for an enormous number of people who would have quit during the Homebrew-install step five years ago. For this path, the "first language" question basically disappears. The first language is the one they have spoken all their life.

Path Two: The Aspiring Professional Developer

Someone who wants to work in software, whether that's engineering, DevOps, security, or any role where they'll need to audit, debug, and extend code written by other people (including AI). This person still benefits from learning a foundational language the old-fashioned way, and two of the most popular options are:

Python: The friendliest syntax in the business, reads almost like English, sitting at the top of the TIOBE Index since late 2022. Great for data, automation, and AI adjacency.
JavaScript: The language of the web, used by 62% of all developers in the past year, the most widely used language on the planet. Best for anything that lives in a browser.

For these learners, the advice is consistent: pick one language, don't agonize, and actually finish learning it. Your first language does something very important. It teaches you how to think like a programmer, and that thinking is what helps you audit output later. If an AI agent writes something subtly broken – an insecure database connection, a login form that leaks user data – the beginner who skipped foundations might ship the bug because they don't see it. The one who learned foundations has a real shot at catching it.

Many working developers recommend a hybrid approach to these two paths: Build the first thing with AI to catch the excitement and the momentum, then go back and ask the AI to teach instead of type. Prompts can look like:
"Explain why you structured it this way."
"What would happen if I changed this line?"
"Can I try writing this next part myself?"

Using AI as a coach rather than a grunt worker is a legitimate and increasingly common way to learn.

The Trap Called Tutorial Hell

Here's the part nobody warns new coders about. They'll find a great course. They'll finish it and feel incredible. Then they'll find another course, because the first one was so satisfying. Then another. They'll nod along to every video, understand every line the instructor types, and still freeze the moment they open a blank file on their own.

This is tutorial hell, and it can get almost anyone.

Why does it happen? Because watching someone code is like watching someone swim. A person can follow every stroke, memorize the breathing pattern, understand the biomechanics, and still sink the second they jump in. Think about watching the Olympics with your family. Every mistake elicits loud groans. Hopefully you're also turning and laughing together with the understanding that you can sit on a couch and critique, but landing that quadruple axel would be impossible without Ilia Malinin's years of experience, particular brand of confidence, and whatever brain chemicals send him launching himself into the air with blades on his feet.

Reading about a skill and performing a skill use different parts of the brain. The tutorials feel like progress because the brain is genuinely learning something – it's learning to recognize code. But recognizing code and writing code are miles apart. Nobody fully learns a new language on Duolingo. They learn it in conversation with native speakers, fumbling accents and verb conjugation, and generally looking a little bit silly. Then next time they pay at the bodega, they're a little bit better.

The rule experienced developers learn the hard way: finish one short tutorial, then immediately build something with it – even if that thing breaks.

What matters is that it's the learner's own, right away, even if it's tiny and ugly and barely works. Break it on purpose. Change things. Delete things. Google every error message that pops up. Or better, paste the error into an AI and ask what it means and why. That last part isn't cheating. 61% of all developers spend more than 30 minutes a day searching for answers, and most of them have been doing this for years. Looking things up is the skill. The professionals aren't the ones who have memorized everything – they're the ones who've gotten very good at finding the answer in the next 45 seconds.

AI as a Learning Tool

Now, 37% of developers use AI to help them learn, and it has quietly become one of the most powerful tutors ever invented. It's patient, available at 2am, willing to explain the same concept ten different ways until one of them clicks. The conversational nature has been a real breakthrough. A new coder can ask the questions they're embarrassed to ask in a bootcamp classroom, and get the answer in seconds instead of searching for it 500 different ways. That alone has reshaped what beginner education looks like. But the line between coach and crutch is real.

Asking AI to explain an error, unpack a concept, or walk through why code works the way it does is learning. Letting it write the project while the learner nods along is tutorial hell with a chatbot.

Build the Ugly Thing First

A new coder's first real project should be useful to exactly one person on earth: themselves. That's it. They are both the developer and the entire customer base. This is liberating, because it means nobody else has to like it, understand it, or ever see it.

Some projects that work beautifully for beginners:

A script that renames a folder full of photos from IMG_4823.jpg to something a person can actually search for.
A little webpage that shows today's weather in the learner's city.
A to-do list they actually use.
A tracker for how much they're spending on coffee this month.
A program that picks a random restaurant so nobody has to argue about dinner.
A tiny game like tic-tac-toe, hangman, rock-paper-scissors.
A portfolio site that replaces their ancient, and heavily templated, Squarespace.

These work because they share three traits. They're finishable. They solve something real for the creator. And when they break – and they will – the learner will actually care enough to fix them.

Please, resist the urge to build the next Instagram as a first project. A finished ugly thing beats an unfinished beautiful thing every single time.

When it's done, put it on GitHub, even if the code is embarrassing. GitHub is a source of real intimidation for many beginners, so it's worth demystifying: despite its reputation as a community space, it is fundamentally a version control tool. Think of it as Google Docs for code. It tracks every change the learner (or their AI assistant) makes, so nothing is ever truly lost. The community layer sits on top of that, not underneath it. A learner does not need to "earn" the right to be on GitHub. They just need a project and an account.

You can also bring it to DEV. Post about your project. Ask people for feedback. Read and respond to the comments. While MLH hackathons are incredible labs where you can build these first projects (or your 100th) with others over a few days, DEV is available 24/7. We think of ourselves as both the Lab (MLH), and the Library (DEV), where you can learn all the time.

The Disappearing Middle, and How to Not Be It

Here's the uncomfortable thing experienced developers might be quietly worrying about, and every new learner should know it too. AI has made the distance between absolute beginner and productive builder smaller than it has ever been. But it has also, at least for now, eroded the middle layer of expertise – the years a new developer used to spend wrestling with real problems on a team, learning what "good" actually looks like, absorbing the multi-point pre-flight checklist every senior engineer builds over a career.

That erosion is a problem, and the beginner who doesn't plan for it will get stuck.

A vibe-coded app can ship fast. It can also leak every user's data the moment it goes live – there are news stories about exactly this happening, more than once, in the last year. The beginner who built it with AI and never learned the underlying concepts may not know what went wrong, may not know how to find the thing that needs fixing, and may not know what questions to ask next time. The beginner who used AI as a coach – who built, then went back and examined the code, who asked why and what if – has a much better chance of being able to do these things.

The practical advice: build first, then audit. Ship the ugly thing, then open the code and ask the AI to walk through it line by line. Ask what it would do differently for a real product. Ask what security practices it skipped. Ask what a senior developer would change.

Over time, that accumulated questioning becomes the expertise the middle layer used to provide. The learners who will thrive in this era are the ones who use AI to build fast and then stay curious enough to learn what just happened.

How To Stick With It

There's a stretch, usually somewhere between month two and month six, where a new coder will feel dumber than they did the day they started. The tutorials got easy and then the real projects got hard, and everything in between feels like fog. This is not a sign the learner is failing. It's the sign they've left the shallow end.

Three things keep people in the chair through that stretch.

Shrink the goal: Thirty focused minutes a day will take a learner further than a six-hour Saturday binge, every single time. Consistency compounds. Burnout erases. Plenty of career switchers have made it through on forty-five minutes a day before work, for a year or more. It's a whole strategy.
Find a room: Other beginners are the difference between a hard month and a lonely one. An MLH hackathon, a Discord community, a DEV conversation, a local meetup, a coworker a few steps ahead, a friend who's also learning.
Keep a "done" list, not just a to-do list: Every week, write down what got built, learned, fixed, or figured out. "Got my first API call to work." "Finally understood what a for loop actually does." "Deployed my first site." On the weeks when everything feels stuck, the only thing that reliably works is scrolling back through that list and remembering the learner couldn't do any of it six months ago.

That list is proof. On the bad days, proof is the only thing that keeps a person typing.

Major League Hacking (MLH) Partners with Backboard.io to Bring AI Memory and Persistent State to Global Student Developers

MLH Team — Thu, 09 Apr 2026 15:55:50 +0000

Major League Hacking (MLH), the world’s largest developer community, is excited to announce a 12-month promotional partnership with Backboard.io, the #1 ranked AI memory platform. Launching ahead of Global Hack Week (GHW), this collaboration establishes Backboard.io as the primary AI memory layer for the next generation of builders, making “memory-first” development the new standard for the AI stack.

Building Persistent AI: Memory First, Stateful by Default

At MLH, the mission has always been to help developers learn by doing. As AI applications shift from simple chat interfaces to complex, long-running agents, the need for persistent state has become critical. Backboard.io provides the stateful API necessary to ensure AI applications stay consistent across prompts, sessions, and users. Backboard.io is model agnostic across 17,000+ models with built-in model routing, so developers can use any model, coordinate agents, and build AI apps that stay consistent across prompts and sessions without piecing together their stack.

Through this partnership, MLH will introduce a “Best Use of Backboard.io” category across 50 hackathon events worldwide, 3 Global Hack Weeks, and a DEV Challenge. This category challenges participants to move beyond “stateless” prototypes and build production-ready applications that remember user context and maintain state across the entire development lifecycle.

Benefits to the Global Developer Community

The MLH community, spanning over 135 countries, will receive direct access to Backboard.io’s cutting-edge technology through several key initiatives:

Free State Management for Life: Powered by MLH, students can maintain the state of their projects indefinitely without cost. With Backboard.io’s bring-your-own-API-key support, any model or existing API they’re already using becomes instantly stateful.
Software Credits: Participants at MLH events will receive free credits to access Backboard.io’s premium AI memory features.
Exclusive Rewards: Hackers building with Backboard.io will be eligible for specialized swag and high-value prizes.

A Word from Leadership

“MLH is where the most ambitious developers, hackers, and software creators go to learn fast and build the future of technology,” said Mike Swift, CEO and Cofounder of MLH. “By integrating Backboard.io into our global hackathon league, we are giving student developers the foundation they need to build more sophisticated, context-aware AI. Backboard.io’s ability to handle persistent state and model routing through a single API allows our community to focus on what they do best: innovating and shipping real-world solutions.”

Jonathan Murray, CSO and Cofounder of Backboard.io , added: “We believe the next wave of world-changing tools will come from this community. We’re making Backboard.io the starting point of the AI stack for MLH builders, ensuring they can scale from weekend tinkering to enterprise-ready deployments without reworking their foundation.”

Get Involved

Developers can start building with Backboard.io at upcoming MLH events. To find a hackathon near you or to join Global Hack Week, visitmlh.io/events. Learn more about the stateful AI stack at Backboard.io.io.

About Major League Hacking: Major League Hacking (MLH) is the largest developer programs platform in the world reaching over 1 million developers through hackathons, fellowships, open source programs, and mentorship. MLH helps technical talent gain real-world experience through global hackathons, online fellowship programs, and open-source projects. Each year, MLH supports thousands of in-person and digital learning experiences across nearly 100 countries, alongside fellowship programs that help developers gain real-world experience and build lasting professional skills. Through these programs, MLH develops a deep, data-informed understanding of how developers learn and build in real-world settings, shaping long-term partnerships with companies like Meta, GitHub, and Google. For more information, visit mlh.io.

About Backboard.io: Backboard.io is the memory-first, stateful API platform for building AI applications that stay consistent across prompts, sessions, and users. Ranked #1 on both LoCoMo and LongMemEval, Backboard.io supports 17,000+ models and lets developers bring their own API key — making any model instantly stateful. It handles persistent state, RAG workflows, multi-agent coordination, and tool calls through a single integration, enabling teams to go from prototype to enterprise-ready deployment without reworking their foundation. Learn more at Backboard.io.

The post Major League Hacking (MLH) Partners with Backboard.io to Bring AI Memory and Persistent State to Global Student Developers appeared first on Major League Hacking News.

The "Stateless" AI Era is a Massive Engineering Tax

MLH Team — Thu, 09 Apr 2026 15:42:13 +0000

We have spent a decade watching hackers grind through the same 48-hour cycle at MLH: build something brilliant, realize it has the memory of a goldfish, and then watch it break the second a user tries to do something complex. It is a mess. We keep pretending that stateless prompts are enough. They aren't.

We are tired of seeing great projects die because the "plumbing"—the session logic, the vector database, the state management—swallows 80% of the weekend. It is an engineering tax that student developers should not have to pay.

State Management and AI Memory for Developers

Did you know the "stateless" AI era is actually a huge bottleneck? Most builders are just stitching together fragments of history and hoping the LLM doesn't lose the thread. It is fragile. We have realized that to move past simple chat wrappers, you have to start with the memory. You should not have to rebuild your entire logic layer just because you want to switch from GPT-4o to Claude.

Integrating Backboard.io: The Stateful API for AI Applications

MLH is bringing Backboard.io into our ecosystem for the next 12 months. Backboard.io is a stateful API and the #1 ranked platform for AI memory on LoCoMo and LongMemEval. It acts as the persistent brain for your application, handling RAG workflows and tool calls through one integration — with support for 17,000+ models, built-in model routing, and bring-your-own-API-key so your entire existing stack becomes instantly stateful. This lets you scale a prototype into a production-ready agent without a complete rewrite of your foundation.

MLH x Backboard.io Partnership Benefits and Hackathon Access

We are making this a new standard for the MLH community. Starting April 10th at Global Hack Week, and across 50 events this year, we are giving every MLH builder free state management for life and the dev credits needed to actually ship.

We want to see what happens when you stop worrying about how your app will remember a user and start focusing on what the app actually does. If you are building at an MLH event this year, look for the "Best Use of Backboard.io" category.

Don't build another forgetful app. It is a waste of your time.

Major League Hacking (MLH) Acquires Developer Community Platform DEV to Build the Largest Community for Software Professionals

MLH Team — Wed, 18 Feb 2026 15:00:00 +0000

Acquisition connects MLH’s events and experiential learning programs with DEV’s technical knowledge & community platform to solve the problem of fragmented learning in the AI era

Major League Hacking (MLH), the largest developer programs platform in the world reaching 1M+ developers through hackathons, meetups fellowships, open source programs, and mentorship, today announced the acquisition of DEV, the 3M-strong digital community for software creators. By combining MLH’s experiential developer programs with DEV’s daily technical publishing platform and media site, the acquisition creates a centralized home for developers that supports a technologist’s entire journey from their first “Hello World” to their first senior engineering role.

Creating The Core Community Infrastructure for Learning and Skills Development

MLH’s acquisition of DEV reflects its evolution from the college hackathon league into the leading professional development and skills lab for software creators. By pairing MLH’s decade of experience running hackathons and hands-on training programs with DEV’s daily publishing and peer-driven learning, the two are creating a clearer path for how developers learn, build, and grow their careers.

“MLH is where you build and break things in person. DEV is where those lessons live on. Whether you’re shipping your first project or you’re a senior engineer picking up AI skills for the first time, you’re welcome here. In the AI era, everyone is a beginner again at some point, and we want to be the place where that’s not just okay, but encouraged.” said Mike Swift, Co-Founder and CEO of Major League Hacking.

The Partner of Choice for the AI Era

This acquisition also consolidates MLH and DEV as the primary distribution channel for the world’s most significant AI and infrastructure companies. Leaders such as Google Gemini, GitHub, ElevenLabs, Snowflake, and DigitalOcean have already established partnerships within this ecosystem to bridge the gap between AI potential and actual developer adoption. 51% of MLH alumni have introduced a technology they learned from MLH into production at their job.

As AI lowers the barrier to entry for software creation, these companies are doubling down on community engagement. By putting tools directly into the hands of millions of software engineers and creators, MLH and DEV provide the real-world proving ground where the next generation of technical standards is established.

A Shared Vision for Independence and Scale

DEV will continue to be the community its members know and trust. The culture its founders built is why MLH wanted to do this, and the focus of the acquisition is on investing in DEV and helping it grow, not changing what makes it special.

“If DEV is the library, MLH is the lab. One is where knowledge gets shared, organized, and preserved. The other is where you get your hands dirty and prove you can actually build. Together, we’re building the core community infrastructure of the next era of technology.” said Jon Gottfried, Co-Founder of MLH.

Strategic Impact: Scaling the Impact of Experiential Learning

Massive Combined Reach: By joining forces, we now reach 5 million developers, which is 10% of all software engineers globally. Our combined community offers unparalleled scale for collaboration. This acquisition exponentially expands the peer network available to every developer in our ecosystem.
Enhanced Developer Journey: The acquisition of DEV positions MLH to capture the entire technical learning lifecycle, expanding the original event-based engagement to add daily content distribution and planned professional training expansions.
Sustainability and Forem: MLH and DEV will serve as stewards for Forem, the open-source project powering DEV. Both companies are committed to finding an arrangement that allows the Forem mission to thrive independently and serve the broader open-source community.

“As more people create software, the technical content surrounding that work is becoming increasingly important,” said Peter Frank, Co-Founder and CEO of DEV. “Joining MLH lets DEV remain that everyday gathering space for developer knowledge while benefiting from MLH’s deep roots in the global developer community.”

About Major League Hacking (MLH)

Major League Hacking (MLH) is the largest developer programs platform in the world reaching 1M+ developers through hackathons, fellowships, open source programs, and mentorship. MLH helps technical talent gain real-world experience through global hackathons, online fellowship programs, and open-source projects. Each year, MLH supports thousands of in-person and digital learning experiences across nearly 100 countries, alongside fellowship programs that help developers gain real-world experience and build lasting professional skills. Through these programs, MLH develops a deep, data-informed understanding of how developers learn and build in real-world settings, shaping long-term partnerships with companies like Meta, GitHub, and Google. For more information, visit mlh.com.

About DEV

DEV is a professional network of over three million registered software developers. As a blogging-first platform, it allows members to connect, discuss trends, and exchange advice. Leading companies like Google, Microsoft, and AWS maintain an official presence on the site. As AI reshapes code creation, DEV serves as a critical hub for collaborative learning and career advancement. For more information, visit dev.to.

The post Major League Hacking (MLH) Acquires Developer Community Platform DEV to Build the Largest Community for Software Professionals appeared first on Major League Hacking News.