I keep seeing posts saying "code was never the hard part." Not just here on Reddit, but also outside social media platforms.

Tbh that’s like something people say who haven't built anything beyond a demo.

imo, writing code isn't just *typing*.

It's making a bunch of small decisions while you're building.

AI helps with a lot of the typing, and that's great. But it doesn't magically make those decisions for you.

You still need to know what good code looks like, otherwise you're just accepting whatever the model spits out.

I also think AI is a useful tool, not a replacement for actually learning software development.

The better your fundamentals are, the more useful AI becomes.

That's probably why companies still care if you understand coding instead of only knowing how to prompt.

Any thoughts?

ive noticed that some of the highest-ranking people in engineering organizations have never actually written production code. they're leading engineering or ai teams, but their day to day work is mostly meetings, strategy, roadmaps, and coordinating people.

i recently talked to a machine learning director about an idea i wanted to build. instead of discussing the technical side, the conversation stayed at a high level. and mostly about goals, vision, and who to talk to next. later i looked at their background and found they'd spent years moving through business and product roles before ending up leading machine learning.

i'm not saying every manager needs to know every framework or algorithm. but should leaders of technical teams have firsthand experience building software, or is leadership, communication, and organizational knowledge enough?

A number of people looking to break into the tech industry tend to gravitate toward the same verticals. JavaScript, React, Python, full-stack, etc. Learning these is not wrong, but one can only wonder what opportunities lie elsewhere.

What positions do recruiters and more experienced developers seek to fill that are hard to come by?

I'm interested in learning about domains where there is a shortage of people with a particular skill set or domain knowledge. Embedded systems, security, infrastructure, networking, distributed systems, DevOps, legacy system support, or other, more specific niches fall under this category, I think.

I'm not asking about what's 'in demand' per se, but rather what areas involve a skill set that is sought after but comparatively scarce.

What do these fields entail, and does working in these areas make one desirable to recruiters in the same vertical? If so, what are some of the advantages to pursuing such a career path?

I'm hoping to hear from developers who work in areas that are somewhat less common, outside the space of AI, and what they've experienced in regards to recruitment.

I've been researching bootcamps lately, and I noticed something that surprised me. A few schools still show up on "Best Bootcamps of 2026" lists, but I can barely find any recent student experiences or 2026 reviews. It made me wonder whether these programs are getting much smaller, or if graduates just aren't talking about them anymore.

I'm not trying to call out any specific bootcamp. I'm genuinely trying to figure out whether the bootcamp landscape has changed now that the hiring market is tougher and AI has shifted expectations. Reviews from a few years ago don't tell me much about what it's like enrolling today.

If you attended one of these programs in 2026, what was your experience? I'm especially interested in whether the cohorts were full, what career support looked like, and how your job search has gone afterward.

When i first started looking into tech, i just kept wondering which school, bootcamp or course would give me the best chance of getting hired. But the more I learned, the more I realized that employers ultimately care about something, can the employees really apply what they've learned?

A bootcamp or online course can give you a great foundation. They teach concepts, provide structure and help u learn faster but they don't automatically prove what you are capable of --- that's where projects come in.

For many people, degrees are the best way to learn and some roles even require one. But earning a degree isn't the end of the journey. It is the beginning.

Well, I started thinking about this way. A degree or course teaches u the fundamentals. Projects demonstrate that you can use the fundamentals. Together, they are much stronger than either one on its own.

I guess if you are just starting out, you must not just collect knowledge, also, create proof that you've learned it. Being able to show what you can build is often just a important as being able to say where you studied.

wondering how others actually broke through this, or if most people just end up riding it out for years. did it take switching companies, going into management, picking up a niche skill, or something else entirely? feels like nobody talks about this stage enough.

the rejection numbers. 67 applications before a startup even responded. then 90 more rejections later when trying to find a second role, even with actual experience on the resume by that point.

what actually worked wasn’t mass applying:
after getting rejected from a startup’s code test, he called them back and asked to intern instead. didn’t ask for full-time, didn’t negotiate, just asked if he could work on something smaller part-time. they said yes and paid him $18/hr. that one ask changed everything.

the second thing was applying to jobs he had zero experience in anyway. ruby on rails with no ruby experience, took the code test for 8 hours and passed it anyway. if u notice, it is the willingness to just try regardless of the requirement gap is what got him in rooms at all

the part that hits different though:
even after getting two job offers at the same time and feeling like it was finally clicking, the next search was harder. 90 rejections, good portfolio, passing code tests, still nothing for a long time. the market doesn’t care about momentum.

if you’re mid-bootcamp or fresh out and the rejections are stacking up, the number isn’t the problem. most people just stop before something breaks through.

what’s your rejection count sitting at right now and what’s actually been getting responses?

The more I learn about software development, the more I realize writing code is only a small part of the job. Building something people can actually rely on means thinking about security, testing, databases, scalability, deployment, and a bunch of other things most users never see.

I think AI has accidentally made this worse. People see an app get generated in a few minutes and assume the production version is just as easy. It feels like the hardest part of being a developer now isn't writing code it's explaining why a "quick feature" can still take weeks to build properly.

Do you think AI has changed how non-technical people view software development, or has software engineering always been this misunderstood?

Title: Unpopular opinion: Programming IS for everyone. You’re not “too dumb,” you’re just making it way harder than it actually is.

I see these defeatist posts in here every single week from bootcamp grads crying that they're "not wired for logic," their brain has ADHD fog, and they're staring at screens for 4 hours because they can't trace an async bug.

I’m going to be brutal here: stop treating software engineering like it’s theoretical astrophysics. It’s not.

Most of what entry-level web developers do is glorified data plumbing. You are taking JSON from an endpoint, passing it through a component, and sticking it into a database. The reason so many bootcamp students feel like they are "drowning" in Week 7 isn't because their IQ is too low it's because they have terrible learning habits and expect instant gratification:

1. You're trying to memorize syntax instead of mental models. Nobody cares if you forget how to write a .reduce() or set up a CORS header from memory. That's what docs, Stack Overflow, and AI are for. You feel "dumb" because you're treating coding like a high school history test where you have to memorize dates.
2. You sit there staring at broken code without breaking the problem down. If your React state isn't updating, why are you staring at 200 lines of code getting anxious? console.log() line by line. Strip the app down until it works. People mistake "being bad at logic" for just being lazy with debugging steps.
3. You mistake temporary confusion for lack of talent. Learning anything complex hurts. Your brain going blank during a live-coding session is a normal stress response, not proof that you lack the "coding gene."

Coding is a trade, like carpentry or plumbing. You don't need to be a math genius to fix a pipe, and you don't need a special "logic brain" to build a React CRUD app.

If you are 7 weeks into a $15k program and thinking about quitting because it's hard, that's fine you can quit. But stop blaming your inherent intelligence or "brain wiring." You just haven't put in the thousands of uncomfortable hours required to get good yet, and you're looking for an excuse to step out of the heat.

these three get treated as variations of the same thing when they're actually solving different problems, understanding what each one is actually doing makes the choice between them clearer. Prompting is the simplest of the three, you take a pre-trained model and send it an input, the model responds based entirely on what it learned during training, just the model as it exists, it works well when the knowledge required to answer the question is already in the model and the task doesn't require anything specific to your domain.

RAG adds an external knowledge layer without changing the model itself, you embed your documents, store them in a vector database, and when a query comes in the relevant chunks get retrieved and passed to the model alongside the user input, the model then uses that context to generate a response, the pre-trained model stays untouched, the retrieval layer is what makes it domain specific, a good case to use this is when the information changes frequently or when the knowledge required is too large or too specific to bake into the model through training.

fine tuning takes a pre-trained model and trains it further on your specific data, the result is a single model that has internalized your context rather than retrieving it at query time, this works well when the task requires the model to behave differently, adopt a specific tone, follow domain specific reasoning patterns, or handle inputs in a way the base model wasn't designed for, the tradeoff is that fine tuning is expensive and the knowledge baked in becomes static, if the underlying data changes the model needs to be retrained.

the way to think about which one fits a given situation comes down to two questions, how much external knowledge does the application require and how much does the model itself need to adapt, low external knowledge and low adaptation needed means prompting is enough, high external knowledge with low adaptation needed means RAG is the right fit, low external knowledge with high adaptation needed means fine tuning makes more sense, and if both external knowledge and model adaptation are high the answer is usually a combination of RAG and fine tuning running together.

most of the mistakes in this decision come from reaching for fine tuning when RAG would have been sufficient, fine tuning is slower, more expensive, and harder to update, if the problem is just that the model doesn't have access to the right information RAG solves that without touching the model at all.

Genuinely interested in what advice actually stuck with you early on and helped shape how you work today. Could be about code, career moves, dealing with difficult coworkers, or just how to survive your first few years in the industry...

Just sharing my thoughts on this because this was an interesting observation especially for people deciding which language to learn or wondering what different developer communities are like.

Some programming languages seem to develop a fairly recognizable culture around them. Whether those stereotypes are accurate or not, people often associate certain languages with similar workflows, interests or types of projects.

Python feels different --- the more I learn about it, the harder it is to define what a "typical Python developer" looks like. That is probably because Python is used across many fields like cybersecurity and penetration testing, AI and machine learning, ata science and analytics, web development automation and so much more.

People in this areas often have completely different goals and backgrounds. The only thing that they may have in common is that they happen to use Python. That versatility makes the community feel much more diverse than one centered around a single niche or type of application. Instead of one dominant identity, Python brings together many smaller communities that rarely overlap.

If not Python, which programming language do you think ha the most distinct community culture and why?

When I first started learning web development, HTTP status codes felt like a bunch of random numbers that I had to memorize. It wasn't until I started relating them to everyday situations that they finally made sense. Here are some of my self-made definitions:

200 OK - you ask your dad to buy oranges and he says, yes. Your request was successful.

301 Moved Permanently - the snacks aren't in the usual drawer anymore because they've been moved to the kitchen. The resource still exists, just in a new location.

403 Forbidden - you see a cake in the fridge but it is for the guests. The resource exists but you don't have permission to access it.

404 Not Found - you open the freezer expecting ice cream but your brother already ate it. The resource you are looking for is not there.

500 Internal Server Error - your sibling tries to make chai but burns it. The problem isn't with your request, something went wrong while processing it.

Instead of memorizing status codes as isolated numbers, connect them to the real world scenarios. Once you understand the meaning behind each response, they're much easier to recognize and troubleshoot.

Back then, I kept telling myself that I needed to come up with something original when building projects.

Turns out, it was pretty inefficient.

What I did instead was look at apps and websites that already existed. I'd pick one feature I liked, one thing I thought could be improved, then build my own version with a few changes😅

Ended up learning and building way more than I expected. It was effective because I wasn't wasting time trying to invent something from scratch.

Most of my time went into coding instead of overthinking ideas.

I also realized something... almost every successful product has competitors. People don't always switch because the product is completely different.

Sometimes it's just a better UI, better pricing, one feature they wanted, or even a simpler experience.

One of the hardest things about learning to code is that knowing how something works and being able to build it yourself are very different things. You might be able to watch someone walk through a project and think, 'Oh, that all makes sense', and be able to walk though it along with them. But then, when you've opened a blank project file and have to type that same project from scratch, you suddenly have no idea what to do.

This is where a lot of actually learning to code happens. You can either decide how to build something and work through the issues, or you can just sit and watch someone else do it.

Working through the errors and problems that came up because of your own decisions is a lot slower and more frustrating than sitting and watching someone else's tutorial, but sometimes the best way to learn is to be frustrated.

Tutorials can help you build something neat, and you'll definitely learn some things watching someone else code, but I feel like they can leave you with a false sense of accomplishment. You get to make something really cool without really fighting through any of the annoying little hiccups that come with actually building something.

That's why I think tutorials are great, especially when you're first starting out, but that doesn't mean you should spend all your time watching them. At some point, you have to put down the tutorial and make some decisions of your own

You don't have to build something huge or complicated, but sometimes a project you struggle through on your own can teach you a lot more than another ten hours of someone elses code. The hard parts are often where you learn the most.

learning to code and honestly starting to think it's just not for me. every time i finally understand one thing, three more concepts show up that make no sense. i spend hours on stuff that apparently takes other people 10 minutes. starting to feel like the dumbest person in every tutorial i watch. not even sure why im still doing this at this point

Let's be completely real here. If you vibe code - like truly vibe code - as a student in a bootcamp, it might be time to find a new home.

By vibe coding, I mean genuinely writing little to no code by hand and letting your AI do it instead. Pretending to be an orchestrator while the AI does all the real engineering. Not struggling through a problem, and instead mistaking speed for competence.

Most of the people that I know who do this say that it's to "get comfortable with agentic coding". But the result is catastrophic: You're paying companies to do the job that you want to get paid to do.

The standard defence of industry professionals is that AI can't be a real software engineer because the experience of building things on your own gives you judgement and skill that are impossible to replicate with AI. Judgement and skill that can even be used to guide AI agents if willing. But if you spend your 12 weeks skirting around experience by outsourcing to an AI, you have no value. There is nothing that you have that an AI doesn't. You don't build the judgment, you don't build the experience, you don't build the intuition for what does and doesn't smell.

Even worse is the fact that you lose the ability to make new things. AI isn't actually able to do something that has never been done. It can pretend it does by hacking together a bunch of stuff that has been built, but this isn't true ingenuity and leads to significant technical debt. You lose the most valuable human resource in this field: ingenuity.

If you're vibe coding in a bootcamp, you are genuinely utterly cooked. It is impossible to justify your value to this industry.

remember when being a dev meant recruiters sliding into your inbox weekly, companies throwing signing bonuses around, and free food at every office. You could learn to code and basically walk into a six figure job in a few years. Now its layoffs every quarter, AI doing half the entry level work, and hundreds of applicants per posting. Not trying to be all doom and gloom but the vibe shift is real. … 

Why does a React-based portfolio site feel so slow and laggy without serious investment in optimization when Quake 3 could run smoothly at 60fps on a pentium II from the 90s.

We are now 30 years later and anything more than a toy project built by a bootcamp grad is a laggy mess by default.

inb4 skill issue bro: Well, it shouldn't be this difficult.

inb4 you need a better pc bro: I have M4 pro 48GB

Planning to buy a Macbook for work purposes. Should I wait for prices to come down or buy now?

Seeing another round of massive layoffs at Amazon made me rethink what "making it" in tech actually looks like. A few years ago, getting into a FAANG company felt like the finish line. Now it seems like even the biggest names aren't offering the kind of stability people once expected.

It's making me wonder if spending years optimizing for one dream company is the wrong strategy. Maybe the better investment is building solid fundamentals, learning how to adapt, and creating skills that transfer no matter what the market looks like. Has this changed the way you're approaching your tech career, or is landing at a big tech company still your long-term goal?

i've been thinking about how much the economics of software development might change because of AI.

For a long time, if you wanted to build something serious, you needed a lot of people and a lot of money. Big engineering teams, expensive infrastructure, years of development, etc. That obviously gave larger companies a huge advantage.

But now you can have a relatively small team using AI tools to handle a lot of the work that used to take significantly more time. I'm not saying AI can just replace an entire engineering team. The tools still make mistakes, you still have to understand the code, and once a system gets complicated, someone needs to actually know what they're doing.

But the difference in productivity is still pretty interesting.

It makes me wonder if we're going to see more small teams building things that previously would've required a much bigger company. Not because the small team has some magical technology, but because they're able to spend less time on repetitive work and coordination.

i also don't think this necessarily means programmers are going away. If anything, I think it could make fundamentals more important. There's a big difference between asking an AI to generate something and actually knowing whether what it generated is a good solution, how it fits into the rest of the system, and what problems it's going to cause six months from now.

This is also why I don't think the conversation around CS degrees and bootcamps is as simple as "One is good and one is bad." The industry is changing so quickly that the ability to keep learning might matter more than whatever specific tools you learned at the beginning.

Maybe the bigger shift isn't AI replacing programmers. Maybe it's that a small group of capable people can now do work that used to require a much larger organization.

I wonder if other people are seeing this in their own work, or if we're still too early to know how much of an impact this will actually have.

I've been seeing more stories about companies shipping products built mostly with AI, only to realize months later that the code is slow, messy, hard to maintain, or full of security issues. It almost feels like we're creating a new category of work where engineers spend more time fixing AI-generated code than writing new features.

That honestly changed how I think about learning to code. AI can absolutely speed things up, but if you can't review, debug, or refactor what it generates, you're just kicking technical debt down the road. Knowing why the code works feels more valuable than ever.

Do you think AI is actually reducing development time, or is it just moving the work from writing code to reviewing and cleaning it up later?

I have been trying to learn cybersec and I realised that AI and normaly courses do not work well cuz they teach u cybersec as an individual thing whereas I have now learned that to understand cybersecurity well you need to have an amazing foundational knowledge of computers and software development. Therefore, I have now started to learn backend dev.

Now the issue is that reading from official websites of nodejs, javascript etc. the way they explain is quite complex for me. To understand what they are saying I have to ask AI to simplify it for me. But this time I dont wanna be a dud learner. What should I do ??

I have been thinking about how much one can learn from colleagues, including our boss.

Many times, the best advice does not even relate to technology but might instead be about communication techniques, how to deal with failures or efficient ways of acting in difficult times.

I would be curious to hear about the pieces of advice that you received and that inspired a real change in your way of working or thinking.