Why You Need to Build Projects in Coding

I had bookmarked over 100 tutorials on automation. Never opened a single one. Then in one week, I learned Make, Typeform, Carrd, Airtable, and Softr—and tied them all together. What changed?  I had a project to build. Most of us try to learn tools in isolation. We watch courses. We follow tutorials. We bookmark resources we’ll never revisit. But tools don't make sense in a vacuum. You can't learn how to connect five different platforms by studying them one at a time. That's where project-based learning changes everything. When you have something real to build, the tools stop being abstract concepts. They become solutions to specific problems you need to solve right now. Here's why project-based learning is the fastest way to master new tools, or indeed, new subjects: 1: Projects give you a clear finish line. - Without a project, you'll wander down every rabbit hole. - With a project, you learn exactly what you need—nothing more. - The goal pulls you forward when curiosity tries to pull you sideways. Clarity comes from constraints, not endless possibilities. 2: Projects force you to connect the dots between tools. This is where the real learning happens. Make handles automation. Typeform captures input. Airtable organizes data. Softr turns it into an app. Carrd builds the landing page. Alone, each tool is interesting. Together, they solve a problem you couldn't solve before. Project-based learning doesn't just teach you tools. It teaches you how to tie them together into something that works. 3: Projects compress your learning curve dramatically. - I bookmarked 100+ tutorials and learned nothing. - One real project taught me five tools in seven days. - Theory builds confidence. Projects build competence. You don't learn to swim by reading about water. 4: Projects teach you what theory never will. Courses teach you features. Projects teach you decisions. Should you automate this step or do it manually? Which tool fits best here? How do you troubleshoot when two platforms won't talk to each other? These are questions you only encounter when you're building something real. I finished 80% of my project in one all-nighter. Then I spent four days stuck on the last 20%. That struggle taught me more than any tutorial ever could. 5: The best learning project is one you care about. - Pick something you want to exist. - Make it small enough to finish in a week. - Make it real enough to push through when it gets hard. Passion combined with quick, small wins is the antidote to quitting. #life #upskilling #business

"People hiring don't care about your projects." False. In fact, some job posts ask for them. When I used to look at dev applications, I would occasionally come across resumes that included a list of projects. When I saw projects that had similar, or identical, tech stacks, I dug in to know more about them. Specifically, what problems candidates solved, and how. I saw how projects were created. I looked at documentation, code quality, and so on. It gave me a glimpse at someone's ability to do the things they'd do at work. I also made sure my team leads reviewed those projects to make sure I didn't miss anything. When everything looked good, I'd move that person on to a phone screen.  Sometimes I'd look at resumes that were unimpressive and got impressed by the projects in their portfolio, typically a GitHub profile. If you can't create projects because you don't have time, open source contributions are a great alternative. If you include projects on your resume, it will only help. Especially for early career engineers, recent grads, and bootcampers. The people that need to see your projects, will. -- 👋 Hi, I'm Jonathan. I help job seekers in the tech industry land interviews and offers. #techjobs #jobseekers #portfolio #projects #protips

Copy a project from GitHub or YouTube to land a job… That’s not how it works anymore. “What project should I add to my resume?” That’s one of the most common questions I get from juniors. And honestly, I’ve asked the same thing in the past. Back then, the default answer was simple: “Build an e-commerce website.” “Make a full-stack MERN app.” “Do something with ML “ So we did. Copied projects from GitHub. Followed 3-hour YouTube tutorials. Changed a few colors. Added our name to the footer. Done. It worked… kind of. But here’s what I’ve realised now, especially with how fast AI is evolving: Your resume doesn’t need another “portfolio project.” It needs a “problem solver.” These days, anyone can use Cursor or bolt to build a full-stack app in a few hours. What makes your project different? Not the tech. The problem it solves. Let me give you an example: You want to send 100+ personalized emails to students. Mail Merge? Already exists. But your emails are landing in spam. So you build a small Python script that sends emails like a human would. Slowly. With better delivery. Tiny project. Few lines of code. But real value. That’s what recruiters remember. Not how many lines of code you wrote. But how many problems you solved. You can use AI. You should use AI. But don’t be just a copy-paster. Understand what you’re building. Learn the stack. Because your project should say one thing.. “I don’t just code. I solve.”

Coding Portfolios are like resumes. Most of them look the same and it’s very hard to tell if the candidate is any good from a “vanilla” portfolio. However, a half finished project that is trying to solve a real problem is far more interesting and persuasive than another front end “about me” project with fancy CSS. So if you want to become a professional coder, stop focusing on ‘filling up the portfolio’. That is “window dressing”. Instead focus on building usable things that address a real-life use case.  You don’t need many.  One or two “real” projects is enough to showcase how you think, and how you build solutions to ambiguous problems. I know there’s lots of suggestions on HOW to find projects.  And most suffer from one problem – they look at other examples and copy them.  Consequence?  Everything starts to look the same and you dont stand out in the job market. And again, your focus shifts to window dressing rather than learning how to use the tool (code) to solve real life problems. Here’s how I learn a new technology. I start with Why. Learn WHY I’d use it, not just WHAT it does.  Why helps us understand WHEN we should choose to use it. Then I zoom out and find real life things that can be represented by that “tool”. Learning for loops? Why would you ever need to loop over something? Oh…when you want to go through a list of things.  WHY would you want to do that?  Maybe to find one or more things in that list. To extract. To validate. To check. To update. Ok what lists do I encounter everyday that ARE NOT the obvious ones. ( Yeah - no shopping lists and TODO lists) How about lists of: 🗓 Birthdays? 💹 Investments? 💼 Jobs you would like? 🌴 Trees in the park? 🎼 Songs that last only 1 week on the charts? 💻 APIs that return other lists? As you start to think like this you will start to think about how you’d define these objects and what data you would need to store and retrieve and process. Now you’re starting to think like a coder. You’re starting to understand all the times you would want to loop over a list. This way, as you dig deeper you will learn the tools, but most importantly you will learn HOW to use them. And each little micro project from your real life becomes a project for your portfolio that is different, unique to your experience and which you are PERSONALLY connected to. That will help a lot more than just building the same portfolio projects everyone does. 👉 One tip: don’t think of projects as “products” or “startup ideas”. That’s too grandiose and overwhelming.  Small micro projects are better to learn a new technology, because each technology was designed and created to solve a specific class of problems.  Understand those classes of problems … not just the tech. Learn how the tool solves that class of problems. Repeat. #careerchange #softwarengineer

For folks who use GitHub and are in early stage careers and hope to add GitHub as a value add to your profile - here is a note. If interviewing for an SDE role, GitHub projects that don't solve a problem and are just a coding exercise are not very helpful. This may sound perplexing but it needs to be said. : Hiring managers and tech leads (like me) look for problem-solvers. A repository full of practice exercises might show you can write code, but it doesn’t demonstrate that you can build impactful solutions. ► How to Make Your Projects Stand Out 1. Frame Them as Solutions: Instead of presenting your project as "just another app," position it as a business solution or a tool that solves a real-world problem. For example: - Instead of “Expense Tracker App,” say, “A tool for freelancers to manage and categorize expenses for tax season.” - Instead of “Weather App,” frame it as, “A weather app optimized for agricultural planning with location-based crop suggestions.” 2. Highlight the Problem It Solves: Every great project starts with a problem. Make it clear what problem you identified and how your project addresses it. - Example: “This tool was designed for small business owners who struggle with automating their daily sales tracking.” 3. Show Quantifiable Value: Numbers tell a story. Include metrics like: - How much time/money the solution saves. - How many users it could potentially impact. - Any test data or feedback you’ve collected. - Example: “This app reduced invoice processing time by 35% in a real-world test case.” 4. Document It Well: A project is only as good as its README. Include: - A brief description of the problem it solves. - Key features. - Instructions on how to run/test it. - Screenshots, GIFs, or a demo link to bring it to life. Having a GitHub full of clone apps or unfinished side projects sends the wrong signal. It doesn’t show creativity, ownership, or impact, it shows you can follow tutorials, and that’s not what companies hire for. Instead, invest your time into one or two high-impact projects that: - Solve real-world problems. - Show off your ability to understand user needs. - Demonstrate your thought process, design skills, and technical execution. So, take a step back, revisit your GitHub, and think: - Does this project solve a problem? - Can I explain its value to someone outside of tech? - Would I hire someone based on this work? If the answer isn’t “yes,” it’s time to rethink how you approach your projects. Remember: One impactful project > 100 clones. Focus on impact, not just output.

💡 𝗘𝘃𝗲𝗿𝘆 𝘀𝗼𝗳𝘁𝘄𝗮𝗿𝗲 𝗲𝗻𝗴𝗶𝗻𝗲𝗲𝗿 𝘀𝗵𝗼𝘂𝗹𝗱 𝗱𝗼 𝘁𝗵𝗶𝘀 𝗼𝗻𝗰𝗲 𝗶𝗻 𝘁𝗵𝗲𝗶𝗿 𝗰𝗮𝗿𝗲𝗲𝗿 -- 𝗶𝘁 𝘄𝗶𝗹𝗹 𝗰𝗵𝗮𝗻𝗴𝗲 𝗵𝗼𝘄 𝘆𝗼𝘂 𝘀𝗲𝗲 𝘆𝗼𝘂𝗿 𝘄𝗼𝗿𝗸 𝗳𝗼𝗿𝗲𝘃𝗲𝗿! 🚀 The one career-defining experience every developer should have: 𝗯𝘂𝗶𝗹𝗱𝗶𝗻𝗴 𝘀𝗼𝗺𝗲𝘁𝗵𝗶𝗻𝗴 𝗳𝗿𝗼𝗺 𝗮𝗯𝘀𝗼𝗹𝘂𝘁𝗲 𝘇𝗲𝗿𝗼. Not maintaining an existing system. Not adding features to a mature product. Not inheriting code, pipelines, and databases. But starting with nothing --a blank canvas -- opening a blank editor, staring at that empty repo, laying the first brick yourself, and turning an idea into a living, working piece of software. It’s a challenge that pushes you out of your comfort zone and reshapes the way you think about engineering, ownership, and impact. --- 𝗪𝗵𝘆 𝗱𝗼𝗲𝘀 𝗶𝘁 𝗺𝗮𝘁𝘁𝗲𝗿? Because nothing humbles you more -- and nothing grows you faster -- than realizing how many moving parts come together before the first feature even sees the light of day. --- 𝗛𝗲𝗿𝗲’𝘀 𝗮 𝗾𝘂𝗶𝗰𝗸 𝗰𝗵𝗲𝗰𝗸𝗹𝗶𝘀𝘁 𝗼𝗳 𝘄𝗵𝗮𝘁 𝘆𝗼𝘂’𝗹𝗹 𝗳𝗮𝗰𝗲: 🔐 Authentication (JWT, OAuth, sessions) 🗄️ Database schema, migrations & permissions 🌱 Environments: dev, staging, prod - with secrets 🛠️ Unit, integration & end-to-end tests ⚡ CI/CD for automated deployments 📜 API design with clean docs (Swagger / OpenAPI) 🛡️ Security basics: validation, HTTPS, rate limits, CORS 📦 Docker & deployment to cloud (AWS / GCP / Azure) 📊 Logging, error monitoring & caching (Redis / Memcached) 🧹 Code quality with linters, formatters & static analysis 📖 A README your future self will thank you for --- 💡 𝗬𝗼𝘂 𝗱𝗼𝗻’𝘁 𝗻𝗲𝗲𝗱 𝘁𝗼 𝗺𝗮𝘀𝘁𝗲𝗿 𝗮𝗹𝗹 𝗼𝗳 𝘁𝗵𝗲𝘀𝗲 -- 𝗷𝘂𝘀𝘁 𝘁𝗼𝘂𝗰𝗵 𝘁𝗵𝗲𝗺. The goal is to understand what it really takes to move an idea from nothing to “it’s live.” Once you’ve gone through this journey, you’ll never see your daily work the same way again. You’ll respect the invisible layers holding projects together. And you’ll know what it truly takes to ship end-to-end. --- 🔥 𝗜𝗳 𝘆𝗼𝘂 𝗵𝗮𝘃𝗲𝗻’𝘁 𝗱𝗼𝗻𝗲 𝘁𝗵𝗶𝘀 𝘆𝗲𝘁, 𝘀𝗲𝘁 𝗶𝘁 𝗮𝘀 𝗮 𝗽𝗲𝗿𝘀𝗼𝗻𝗮𝗹 𝗺𝗶𝗹𝗲𝘀𝘁𝗼𝗻𝗲. It might just be the most eye-opening project of your career.

I started learning to code when I was 22. And no, I wasn’t a computer science student; so the transition was anything but smooth. I struggled with syntax. I struggled with logic. I struggled with simply believing I could write a clean function and call it… without seeing those warnings and errors. And today, it’s even more confusing because people say coding isn’t “necessary” anymore. But it is ~ and you know why? A data scientist still writes. An SDE still builds. A DevOps engineer still automates. A cloud engineer still scripts and deploys. Every role touches code in some form. They all require coding. And yes, “vibe coding” makes things look easy. AI fills half the gaps. Fixing issues in code feels magical. But you still need to understand the logic behind why the model is suggesting a certain block, what it’s doing behind the curtains. So if I were starting to learn coding today, I’d follow one framework: CLIMB. C → Choose your path Pick your direction first: Web, Data, AI, Cloud, DevOps, Systems. Your language depends on where you’re going ~ not the other way around. L → Look at real-world use cases See what developers actually build: APIs, cloud automations, dashboards, AI models, pipelines. It shows you the purpose behind every concept. I → Identify the fundamentals Syntax. Variables. Loops. Functions. Data structures. Don’t skip this. These basics stay with you for life. M → Master the small stuff Mini labs. LeetCode. HackerRank. Playgrounds. Small repetitions build big confidence. B → Build real projects Start with scripts and tiny apps (automation, apis). Then move to full-stack projects, cloud infra, AI workflows, data pipelines. Projects validate your skills more than anything else. Because learning to code isn’t hard… it’s just overwhelming. Structure makes it doable. If you’re starting today… CLIMB. One step at a time.

4 years ago, I didn't struggle to land data science roles because I lacked skills. I struggled because I had notebooks and no proof I could ship. So I rebuilt my portfolio approach around one principle: build like you're already on the job. And I've gone from: • Having "projects" that were just Kaggle notebooks with default parameters → a deployed ML system with a real API, dashboard, and CI/CD pipeline • Spending weeks on portfolio projects that never got finished → shipping a production-grade project in 7 days • Watching hiring managers glaze over at "I did a project on Titanic survival" → hearing "walk me through how you built this" A friend asked me what changed. I stopped building projects that proved I could learn and started building projects that proved I could ship. And that fixed the exact problem more Kaggle competitions never could. So I built the 7-Day AI-Powered Data Project Challenge to show you exactly how to do the same. It includes: • A day-by-day build guide from Day 0 (setup) to Day 7 (deployed on GitHub) • How to use Claude Code as your AI coding agent, directing it like a senior engineer • A data quality gate that catches garbage before it touches your model • Feature engineering, model training, and experiment tracking that logs what you tried and why • API + dashboard build, something a hiring manager can actually click on • Docker and CI/CD so your repo looks like you've done this before • A README strategy that tells the story of your project and the decisions behind it Even if you're not actively job hunting right now, this is how you build the kind of project that compounds in value every time someone lands on your GitHub. ➡️ Just comment "build" and I'll send you the link. PS — It's completely free. Just the exact system I used to go from bombing portfolio reviews to getting asked "walk me through how you built this."

Stop Building Another Titanic Project! 🤦♂️ I have reviewed 133+ Data Science portfolios, and what I found was shocking: 90% had the same projects 80% never deployed them 50% couldn't explain their own code Let me be brutally honest - your Titanic survival prediction isn't going to land you that dream job. Here's what ACTUALLY impresses recruiters: 1. Real-World Impact Build products that solve actual problems. Forget academic datasets - create something people can use. 2. End-to-End Solutions Don't just stop at model building. Deploy your projects, create APIs, build user interfaces. Show you can deliver a complete solution. 3. Original Ideas House price prediction? Been there, done that. Think unique - maybe a tool that helps local businesses, or an app that solves a community problem. 4. Documentation Skills Clean code with clear documentation shows you can work in a team. If you can't explain your code, how will you collaborate with others? 5. Problem-Solving Approach Showcase your thinking process. The "why" behind your decisions matters more than the code itself. Want to stand out? I'm starting a cohort where we'll build real products together. No more cliché projects - let's create something meaningful. Comment your email 👇 and I'll notify you once the next cohort is open!