Besides being a talking head on LinkedIn, I lead software development teams, mentor developers and help career changers learn to write complex software.

At the core of all these efforts is a simple goal: empowering developers and magnifying their capabilities.

Sometimes that means changing processes to allow teams to move faster, deploy code with less friction and confidence. In my courses and programs, empowerment is making the abstract practical with lessons and challenges which mimic the experience of being a software developer.

If you actually read this, thanks. Always happy to connect and check out the links in about section 😉

Brian Jenney

Apparently, if you’re not using:

• Opus 4.5 (but only for certain tasks)
• A different model for planning vs coding vs refactoring
• Custom rule files
• Per-project AI configs
• MD spec / rules docs
• Spec-driven planning phases
• Git subtrees
• “Ralph loops”
• Spec kit
• Carefully segmented prompting workflows

…then you’re "not using AI correctly."

To be fair, some of this is spot on. 

𝗕𝘂𝘁 𝗮𝘁 𝘀𝗼𝗺𝗲 𝗽𝗼𝗶𝗻𝘁 𝘄𝗲 𝘀𝗵𝗼𝘂𝗹𝗱 𝗽𝗮𝘂𝘀𝗲 𝗮𝗻𝗱 𝗮𝘀𝗸:

If it takes this much infrastructure to get AI to help us write decent code…

𝗜𝘀 𝘁𝗵𝗲 𝗽𝗿𝗼𝗯𝗹𝗲𝗺 𝗿𝗲𝗮𝗹𝗹𝘆 𝘁𝗵𝗲 𝘂𝘀𝗲𝗿?

Or is the tooling still not as intuitive as we pretend it is?

The biggest performance gains I’ve seen don’t come from elaborate toolchains. They come from:

• Understanding the problem
• Being able to describe the problem clearly
• Giving the model the right context (look at 𝚊𝚐𝚎𝚗𝚝𝚜.𝚝𝚜 as an example to scaffold the next agent)
• Reviewing and iterating

Yes, rules files help. 
Yes, better workflows help. 
Yes, model choice matters.

But if someone needs a 14-step AI ritual just to build a CRUD app, we may have crossed from "power tools" into magic spells.

𝗔𝗿𝗲 𝘄𝗲 𝗮𝘂𝗴𝗺𝗲𝗻𝘁𝗶𝗻𝗴 𝗱𝗲𝘃𝗲𝗹𝗼𝗽𝗲𝗿𝘀 𝗼𝗿 𝗷𝘂𝘀𝘁 𝗮𝗱𝗱𝗶𝗻𝗴 𝗮 𝘀𝗲𝗰𝗼𝗻𝗱 𝗷𝗼𝗯 𝗮𝘀 𝗮𝗻 𝗔𝗜 𝘀𝘆𝘀𝘁𝗲𝗺𝘀 𝗼𝗽𝗲𝗿𝗮𝘁𝗼𝗿?

I'm not saying either is wrong... I'm just saying.

Learn AI by Building: A Practical RAG Project to Get You Started 👇

The same company telling you "𝘞𝘦 𝘮𝘪𝘨𝘩𝘵 𝘣𝘦 6–12 𝘮𝘰𝘯𝘵𝘩𝘴 𝘢𝘸𝘢𝘺 𝘧𝘳𝘰𝘮 𝘮𝘰𝘥𝘦𝘭𝘴 𝘥𝘰𝘪𝘯𝘨 𝘮𝘰𝘴𝘵, 𝘮𝘢𝘺𝘣𝘦 𝘢𝘭𝘭, 𝘰𝘧 𝘸𝘩𝘢𝘵 𝘴𝘰𝘧𝘵𝘸𝘢𝘳𝘦 𝘦𝘯𝘨𝘪𝘯𝘦𝘦𝘳𝘴 𝘥𝘰 𝘦𝘯𝘥-𝘵𝘰-𝘦𝘯𝘥" is also rapidly expanding.

I wonder what roles they will be hiring for? 🤔

2 things:

1. Are CEOs of large companies really begging their eng department for... anything? Let alone to build a prototype? Why?
2. If you ARE doing this... cool! Using app-gen tools like v0, Lovable or Replit are great ways to create a "cheap" proof of concept with basic functionality.

Oh and lastly, if you're one of those dudes who claims they built an app over the weekend that is now doing 10K MRR and you have no clue how it works... you can take a long walk off a short bridge.

During a live coding interview last year, I instinctively switched from Cursor to VS Code.

The CTO stopped me.

“No — leave Cursor on. We want to see how you solve this with AI.”

I thought the interview would be easier.

It wasn’t.

“Are you using any AI tools we should know about?” “No.” “Great, can you explain what that first line of code is doing?” “You still there?” We never s

Open article: The CTO Told Me to Leave Cursor On. The Interview Got Harder. by Brian Jenney • 4 min read

The CTO Told Me to Leave Cursor On. The Interview Got Harder.

Tech Layoffs Translated:

“𝘞𝘦’𝘳𝘦 𝘧𝘭𝘢𝘵𝘵𝘦𝘯𝘪𝘯𝘨 𝘵𝘩𝘦 𝘰𝘳𝘨.” 
𝗧𝗿𝗮𝗻𝘀𝗹𝗮𝘁𝗶𝗼𝗻: We overhired, and now we’re cutting back.  

“𝘞𝘦’𝘳𝘦 𝘣𝘦𝘤𝘰𝘮𝘪𝘯𝘨 𝘮𝘰𝘳𝘦 𝘦𝘧𝘧𝘪𝘤𝘪𝘦𝘯𝘵 𝘸𝘪𝘵𝘩 𝘈𝘐.” 
𝗧𝗿𝗮𝗻𝘀𝗹𝗮𝘁𝗶𝗼𝗻: We told investors our massive bet on AI would pay off. It didn’t. Now we need to cut you.  

“𝘋𝘰𝘪𝘯𝘨 𝘮𝘰𝘳𝘦 𝘸𝘪𝘵𝘩 𝘭𝘦𝘴𝘴.” 
𝗧𝗿𝗮𝗻𝘀𝗹𝗮𝘁𝗶𝗼𝗻: Tariffs, the markets, or simply bad bets have eaten our lunch. AI 𝘮𝘪𝘨𝘩𝘵 save us, but we don’t actually know how.  

We’ve heard some version of this nonsense since the pandemic. It likely won’t stop any time soon.   

Tech hiring continues to rise overall, but companies still over-hired, over-invested, and made short-sighted moves that are now being paid for by workers getting laid off.  

I was laid off a couple years ago.   
It was brutal.   

I had just bought a business, I have three kids and a mortgage. My biggest regret is not taking more time to reflect before jumping back into the job market. 

But I get it: you need a paycheck and the guise of stability. I did too.  

I ended up becoming part of the great reshuffle: moving from management and web dev into working with LLMs, AI and product engineering.  

If you’re impacted by layoffs, I’m sorry and I can relate.   

But if there’s any silver lining, it’s this: the next era of tech is being built 𝘳𝘪𝘨𝘩𝘵 𝘯𝘰𝘸. And the skills you build next could shape your entire career.  

Good luck out there.



I made a project for full stack developers who want to learn AI practically:

Open article: RAG with Next.JS by parsity.io

Do not attend if:

1. You're studying for Google, Meta, Netflix or massive tech orgs
2. You want some magical prompts to "hack" the interview
3. You'd just use a cache 😉

We're going to cover 3.5 patterns to help you nail your next technical interview outside big tech.

Mohamed Ahmed, Sarmad Razaq and 64 other attendees

View event: Interview Prep for non-FAANG: 3 Patterns that will Save You

Interview Prep for non-FAANG: 3 Patterns that will Save You

Nearly 100% of my code is AI-generated.

That doesn’t mean I’m not building software - it just means I’m not the one writing the code.

It's a weird time to be a coder but there's also massive opportunity hiding behind the hype and fear mongering...

If you’re trying to become a developer in 2026 or just entered the field, it probably feels like you showed up to the party five minutes after it ende

Open article: You Must Learn to Code So You Can Never Write Code Ever Again by Brian Jenney • 5 min read

You Must Learn to Code So You Can Never Write Code Ever Again

If you're a Typescript developer and you want to get started with AI agents, just do this:

1. Put $5 into OpenAI's API platform (or use Gemini's free tier) https://lnkd.in/gPM8D2Pq
2. Install Vercel's AI SDK: https://lnkd.in/gh-sND6r
3. Read up on common patterns for agents (human in the loop, ReAct, orchestration): https://lnkd.in/g3ekb3xr
4. Create a simple agent using tool-calling to do an internet search and summarize the results. You can use this API: https://www.searchapi.io/
5. Re-build your agent with a popular framework like LangGraph: https://lnkd.in/g9yB-_ec
6. Add unit tests and/or evals for your agent
7. Add an observability layer with Helicone or Langsmith: https://www.helicone.ai/
8. Grab this project to build your first agent: https://lnkd.in/gMv3x3tS

𝗦𝘁𝗲𝗽 𝟴.𝟱 - spend less time online arguing about whether or not LLMs will replace developers with people who can't solve FizzBuzz.

So you can just write Python in your NextJS app now.

What will those maniacs at Vercel cook up next? 🙇‍♂️

"𝘞𝘢𝘳 𝘪𝘴 𝘱𝘦𝘢𝘤𝘦. 𝘍𝘳𝘦𝘦𝘥𝘰𝘮 𝘪𝘴 𝘴𝘭𝘢𝘷𝘦𝘳𝘺. 𝘐𝘨𝘯𝘰𝘳𝘢𝘯𝘤𝘦 𝘪𝘴 𝘴𝘵𝘳𝘦𝘯𝘨𝘵𝘩."

I can only dissociate through code and AI hot takes for so long. It feels like a dark time is upon us in the US. But I'm always optimistic.

You may not know me personally, but I hope you're doing alright and keeping sane in an increasingly chaotic world.

RIP Alex Pretti

We get it. AI wRiTeS thE COde!

While most devs are optimizing their prompts, I think the fun (and opportunity) is a couple layers below:

1. 𝗕𝘂𝗶𝗹𝗱𝗶𝗻𝗴 𝗮𝗴𝗲𝗻𝘁𝘀 using frameworks like LangChain, Vercel's AI SDK or rolling your own
2. Learning how to to 𝗶𝗺𝗽𝗿𝗼𝘃𝗲 𝘀𝗲𝗮𝗿𝗰𝗵 𝗾𝘂𝗮𝗹𝗶𝘁𝘆 𝗶𝗻 𝘃𝗲𝗰𝘁𝗼𝗿 𝗱𝗮𝘁𝗮𝗯𝗮𝘀𝗲𝘀 like Qdrant and Pinecone
3. 𝗦𝗰𝗿𝗮𝗽𝗶𝗻𝗴 𝗶𝗻 𝘁𝗵𝗲 𝗔𝗜 𝗲𝗿𝗮 using tools like Firecrawl and 𝚌𝚛𝚊𝚠𝚕𝟺𝚊𝚒
4. 𝗖𝗼𝗻𝘁𝗲𝘅𝘁 𝗲𝗻𝗴𝗶𝗻𝗲𝗲𝗿𝗶𝗻𝗴 - basically figuring out how to organize what an LLM needs to know at what stage to give you a good response
5. 𝗟𝗟𝗠-𝗼𝗽𝘀 𝗮𝗻𝗱 𝗼𝗯𝘀𝗲𝗿𝘃𝗮𝗯𝗶𝗹𝗶𝘁𝘆. Monitoring token costs and model drift to see what breaks and why.

While everyone is glazing Claude or arguing over replacement theories, you could build up these skills and be prepared for software 3.0

If you’re using AI to write your code, here’s something you should know.

If you are:

• using AI to generate production code
• using AI to generate the tests
• using AI to validate its own output
• and then shipping it

Then you are MORE likely than a human to ship bugs and vulnerabilities.

Specifically, you are more likely than a human to:

• Introduce security vulnerabilities (~20-25% higher likelihood)
• Ship critical or major bugs (≈1.5–1.7× more per PR)
• Miss edge cases and failure paths in tests
• Over-test happy paths and under-test bad inputs
• Have “clean” builds that hide production risks

AI-written tests are less likely to test edge cases and over-use mocks.

LGTM! 😅

This doesn’t mean “don’t use AI.”

It means 100% AI-generated systems should make you pause and consider the risks.

Output scales fast. Judgment and maintenance won't.

Side Effects of Vibe Coding:

• Sensitive API keys were embedded directly in client-side JavaScript bundles, making them publicly accessible.
• Row Level Security (RLS) was disabled, allowing unauthenticated users full administrative read and write access to the database.
• Approximately 1.5 million agent authentication tokens, 35,000 user email addresses, and over 4,𝟬𝟬𝟬 𝗽𝗿𝗶𝘃𝗮𝘁𝗲 𝗺𝗲𝘀𝘀𝗮𝗴𝗲𝘀 𝘄𝗲𝗿𝗲 𝗲𝘅𝗽𝗼𝘀𝗲𝗱.
• Reported participation metrics were misleading — 𝟭.𝟱 𝗺𝗶𝗹𝗹𝗶𝗼𝗻 “𝗮𝗴𝗲𝗻𝘁𝘀” 𝘄𝗲𝗿𝗲 𝗼𝗽𝗲𝗿𝗮𝘁𝗲𝗱 𝗯𝘆 𝗷𝘂𝘀𝘁 𝟭𝟳,𝟬𝟬𝟬 𝗵𝘂𝗺𝗮𝗻 𝘂𝘀𝗲𝗿𝘀 (an 88:1 ratio).
• Unauthenticated users could modify any live post on the platform, enabling widespread defacement and manipulation of content.
• 𝗣𝗿𝗶𝘃𝗮𝘁𝗲 𝗱𝗶𝗿𝗲𝗰𝘁 𝗺𝗲𝘀𝘀𝗮𝗴𝗲𝘀 𝗰𝗼𝗻𝘁𝗮𝗶𝗻𝗲𝗱 𝘁𝗵𝗶𝗿𝗱-𝗽𝗮𝗿𝘁𝘆 𝗢𝗽𝗲𝗻𝗔𝗜 𝗔𝗣𝗜 𝗸𝗲𝘆𝘀 stored in plaintext, putting users’ external accounts at risk.
 
Maybe Moltbook is the warning we need.

"𝘚𝘩𝘪𝘱 𝘧𝘢𝘴𝘵 𝘢𝘧 𝘶𝘴𝘪𝘯𝘨 𝘈𝘐 𝘵𝘰𝘰𝘭𝘴!"

What could go wrong? 

A lot apparently.

Challenge accepted.

Last year I spent a lot of time rallying against AI hype.

I also said a lot of things that are now less true than they were 6 months ago.

The models have improved.
Our collective workflows have improved.

I'm honestly not sure where the limit is and I'm excited John Crickett is working to find it.

CTO / VP Engineering / Head of Software Engineering

Think AI can’t handle real programming challenges? I think you're wrong!

So, let’s test that, together.

I keep hearing the same claim. AI is fine for toy problems, but it falls apart when you need real software built. I’m skeptical of that. I’m also skeptical of the hype.

So here’s an open challenge.

If you believe AI can’t solve a specific programming problem, or can’t build a particular kind of software, share the problem with me. I’ll attempt it using AI and document the process end to end.

If it works, I’ll show you how.  If it doesn’t, we’ll learn where the limits actually are.

This isn’t about proving anyone wrong. It’s about collaborative learning and evidence over opinions.

The rules for challenges are simple:

1. Well-specified and bounded. "Build the next Facebook" won't cut it. Give me a concrete, defined problem with clear scope.
2. Time-bound. I can dedicate a few hours, (maybe days if it's one that interests me) to each project, not months. For small-to-medium projects, that can mean building from scratch. For large codebases, it means fixing a specific bug or adding a well-defined feature.
3. Clear acceptance criteria. You define what "done" looks like upfront, so we all agree when or if it's solved.
4. Demonstrable. The result needs to be something I can share publicly so others can reproduce and verify the results.
5. No proprietary barriers. We need to be able to share the work so others can reproduce and verify the results.
6. Legal and ethical. Nothing that violates TOS, copyright, or involves malicious code.
7. You're available for questions. Well-specified tasks often have ambiguities that surface during implementation. I or the AI may need clarification as I work through it. 
8. Realistic performance expectations. If speed or efficiency matters, state your thresholds upfront.

To submit a challenge, document it in a public GitHub repo or Google Doc, then raise a PR adding it to this repo:
https://lnkd.in/ean_C-aU

So far, I’ve reviewed three challenges. Two were rejected, not because AI failed, but because the briefs weren’t workable. They lacked scope, acceptance criteria, or basic constraints.

That’s been the most interesting signal so far. 

The biggest blocker to using AI for software engineering doesn’t seem to be the AI.  It’s weak problem definition and missing software engineering fundamentals.

If you think that’s unfair, great.

 Bring a solid challenge and let’s find out.

Junior developers are inherently risky (in every industry, not just tech btw).

𝘉𝘶𝘵... 𝘐 𝘢𝘮 𝘢 𝘫𝘶𝘯𝘪𝘰𝘳, you say.

Yeah, I get it, I get it, just bare with me here.

The word junior is subjective. 𝗪𝗵𝗮𝘁 𝗶𝘁 𝗯𝗮𝘀𝗶𝗰𝗮𝗹𝗹𝘆 𝗯𝗼𝗶𝗹𝘀 𝗱𝗼𝘄𝗻 𝘁𝗼 𝗶𝘀 𝘀𝗼𝗺𝗲𝗼𝗻𝗲 𝘄𝗵𝗼 𝗵𝗮𝘀 𝘀𝗼 𝗹𝗶𝘁𝘁𝗹𝗲 𝗽𝗿𝗮𝗰𝘁𝗶𝗰𝗮𝗹 𝗲𝘅𝗽𝗲𝗿𝗶𝗲𝗻𝗰𝗲 𝘁𝗵𝗮𝘁 𝘁𝗵𝗲𝘆 𝗰𝗮𝗻𝗻𝗼𝘁 𝗯𝗲 𝘁𝗿𝘂𝘀𝘁𝗲𝗱 𝘁𝗼 𝗱𝗼 𝗺𝘂𝗰𝗵 𝗼𝗻 𝘁𝗵𝗲𝗶𝗿 𝗼𝘄𝗻.

• They need significant hand-holding for months on the job.
• They will take on the easy stuff and maybe break some things.
• They won't contribute much.

𝗛𝗲𝗿𝗲'𝘀 𝘁𝗵𝗲 𝘁𝗵𝗶𝗻𝗴: nearly every developer will be junior when they first join a company unless they are very senior.

You don't actually need to a be a mid level developer to be a safe hire. You just need to avoid the tell-tale signs that you are, in fact, a n00b.

Quite simply, stop down-playing yourself.

• 𝗥𝗲𝗺𝗼𝘃𝗲 𝗷𝘂𝗻𝗶𝗼𝗿, 𝗮𝘀𝗽𝗶𝗿𝗶𝗻𝗴 𝗮𝗻𝗱 𝗹𝗲𝗮𝗿𝗻𝗶𝗻𝗴 from your resume and LinkedIn.
• DON'T talk about the project from your school or bootcamp
• 𝗗𝗢 𝗧𝗮𝗹𝗸 𝗮𝗯𝗼𝘂𝘁 𝘁𝗵𝗲 𝗮𝗽𝗽 𝗼𝗿 𝘄𝗲𝗯𝘀𝗶𝘁𝗲 𝘆𝗼𝘂'𝗿𝗲 𝗹𝗮𝘂𝗻𝗰𝗵𝗶𝗻𝗴 - yes, you need to have a project to talk about.
• 𝗨𝘀𝗲 𝘀𝘁𝗿𝗼𝗻𝗴 𝗹𝗮𝗻𝗴𝘂𝗮𝗴𝗲 𝘁𝗼 𝘁𝗮𝗹𝗸 𝗮𝗯𝗼𝘂𝘁 𝘆𝗼𝘂𝗿 𝗲𝘅𝗽𝗲𝗿𝗶𝗲𝗻𝗰𝗲 and speak to the benefits of features you created. 
• Instead of created a full stack app with a laundry list of tech try migrated a JS app to Typescript to improve developer experience and velocity.

I break down why you need to be building a product instead of a portfolio in 2026 with some resources to help you get started:

Open article: #300 - Build a Product, Not a Portfolio by open.spotify.com

I helped design the interview process for an AI start up where I used to work.

The job listing was for an "AI Engineer".

What that meant, practically, was:

1. 𝗘𝘅𝗽𝗲𝗿𝗶𝗲𝗻𝗰𝗲 𝘄𝗶𝘁𝗵 𝗥𝗔𝗚: chunking && re-ranking and opinions on retrieval strategies
2. 𝗕𝘂𝗶𝗹𝗱𝗶𝗻𝗴 𝗮𝗴𝗲𝗻𝘁𝘀 𝗮𝗻𝗱 𝘄𝗼𝗿𝗸𝗳𝗹𝗼𝘄𝘀: tool-calling vs orchestration, evals and testing
3. 𝗔𝗴𝗲𝗻𝘁 𝗳𝗿𝗮𝗺𝗲𝘄𝗼𝗿𝗸𝘀: LangGraph, Vercel's AI SDK, etc. and when it makes sense to use them... or not
4. 𝗢𝗯𝘀𝗲𝗿𝘃𝗮𝗯𝗶𝗹𝗶𝘁𝘆: how do you control token costs and see where agents fail or drift from their expected behavior?

These skills really aren't too difficult for most experienced devs to learn.

Yet, it's incredibly difficult to find people who already have practical experience, made the costly mistakes and know what to avoid.

If you're a developer looking to build these skills for fun or to launch a product or maybe you're an engineering manager who is looking for a more technical understanding of RAG and agents, 𝗜 𝗰𝗿𝗲𝗮𝘁𝗲𝗱 𝗮 𝗵𝗮𝗻𝗱𝘀-𝗼𝗻 𝗽𝗿𝗼𝗷𝗲𝗰𝘁 𝗳𝗼𝗿 𝘆𝗼𝘂 𝘁𝗼 𝗹𝗲𝗮𝗿𝗻 𝗯𝘆 𝗯𝘂𝗶𝗹𝗱𝗶𝗻𝗴: https://lnkd.in/d6Pzfcg6

Don't let anyone tell you that junior engineers are becoming irrelevant.

It's probably a rough time to be browsing LinkedIn as a junior engineer. Lots of folks are making the prediction that your role is dying. I call BS.

I won't deny that the job market is rough right now, driven in large part by the death of ZIRP. But extrapolating "things are hard now" to "things will be hard hereafter" is a sloppy conclusion that misunderstands why companies hire junior engineers.

The myth that junior engineers can be replaced by Claude assumes that the job of junior engineers is to write code. False. The foremost job of junior engineers has *always* been to grow. Junior engineers are costly! And the largest slice of that cost is not their salary, it's the time and energy that senior engineers and managers devote to training them.

Why do companies bother? Because junior engineers grow over time. When you grow your own senior engineers from scratch, they come with built-in knowledge of your company's business and technology, and at least a measure of loyalty to the company. It's a higher-quality hire coupled with a longer gestation time. Not every company wants to make that trade-off, but the trade-off itself is not dying.

In fact, one of the key variables defining the value of that trade is time-to-promotion: how long until your junior engineers stop being so junior? And that's something that's actively in flux.

It used to be that the only way we knew to advance junior engineers was by handing them coding tasks. "Learn our technology by touching our technology." Along the way, you'd wrestle with things and ask your mentor a lot of questions. But make no mistake, there was more value created by teaching the engineer than by closing the defect report.

Coding agents have upended this in a crucial way: you can ask technical questions of your agent instead of your mentor. This decreases the burden of onboarding a new hire, and can increase the rate of knowledge uptake. After all, the agent is available 24/7, can see more of the codebase than your mentor has in their head, and has infinite patience for questions that you might be too embarrassed to ask a person. "Someone mentioned 'redis' in the team meeting, what is that and how does it work?"

Furthermore, today's junior engineers have the opportunity to be the first wave of "natives" on the new development paradigms. They will adopt them more fully, because it's all they've ever known.

So long as we believe that senior engineers are still valuable, there will also be value in pipelines that create senior engineers. There are good reasons to believe that this new technology can decrease the investment cost to create experienced engineers. It will take time for all the corners of the economy to adapt to this reality, but I don't believe this road ends with the death of the junior engineer. Stay courageous and stay curious.

While my YouTube channel has gained a lot of traction, my podcast is steadily declining in listeners.

On the podcast, I feel like I've formed a deeper connection with listeners and can be a bit more nuanced in my advice.

I'm making some changes to hopefully increase listeners on Spotify by going all in on video episodes.

Tomorrow, the first video podcast drops and I'd love to hear from you if you're a listener of the show.

What are topics you really want to know about? What are you struggling with?

DM me or leave a comment and let me know if you want a shout out if I use your topic/question. 

THANK YOU FOR YOUR ATTENTION TO THIS MATTER 🫡

At Parsity, we’ve been against AI tool use while students are learning to code.

This was not an easy decision and I'd be lying if I said I was 100% sure that this was the right move.

Emerging research (and what we see in practice) supports our position:

• 𝗖𝗼𝗻𝗰𝗲𝗽𝘁𝘂𝗮𝗹 (𝗺𝗶𝘀)𝘂𝗻𝗱𝗲𝗿𝘀𝘁𝗮𝗻𝗱𝗶𝗻𝗴: Students finish tasks without building real mental models
• 𝗗𝗲𝗯𝘂𝗴𝗴𝗶𝗻𝗴 𝗶𝗻𝗮𝗯𝗶𝗹𝗶𝘁𝘆: Fewer mistakes == fewer chances to learn how systems actually break
• 𝗟𝗮𝗰𝗸 𝗼𝗳 𝗰𝗼𝗱𝗲 𝗰𝗼𝗺𝗽𝗿𝗲𝗵𝗲𝗻𝘀𝗶𝗼𝗻: Reading AI output != knowing how to write or fix it yourself
• 𝗦𝗸𝗶𝗹𝗹 𝗿𝗲𝘀𝗶𝘀𝘁𝗮𝗻𝗰𝗲: Performance drops when the AI “exoskeleton” is removed

Yes, AI can boost short-term productivity.
But learning to code was never about speed. It’s about building the brain.

That’s why our students learn fundamentals first.

AI comes later. Once they can evaluate, debug, and supervise it.

We’re not anti-AI.
We’re pro-skill formation.

White board interviews are biased, archaic and don't reflect the kind of work we actually do as developers.

Ok.

Let's pretend you're correct.

What do you do now?

You can either:

a. Avoid DSA and all companies that ask these questions (𝘐 𝘵𝘳𝘪𝘦𝘥 𝘵𝘩𝘪𝘴 𝘧𝘰𝘳 𝘺𝘦𝘢𝘳𝘴 𝘸𝘪𝘵𝘩 𝘷𝘢𝘳𝘺𝘪𝘯𝘨 𝘳𝘦𝘴𝘶𝘭𝘵𝘴)
b: Learn some of the most common patterns and data structures that make up the majority of questions out there

You can still avoid whiteboard interviews, because you WANT to, not because you HAVE to.


PS 👇

I break down 3 patterns you WILL encounter on the interview circuit and a free guide for developers who want to learn through hands-on challenges: https://lnkd.in/gEYY9sF5

Full Stack Software Engineer | .NET Specialist | Master's Student at City, University of London

I’m a tech founder who transforms ambitious ideas into scalable, real-world technology solutions that solve meaningful problems. Over the years, I’ve founded and led tech ventures, built high-impact products across finance, education, healthcare, and enterprise systems, and thrived in fast-moving startup environments.

My expertise sits at the intersection of Software Engineering, AI/ML, and Data Science, where I design and deliver resilient SaaS platforms, distributed systems, and adaptive infrastructures that evolve with business needs. I combine systems thinking, deep product intuition, and strategic leadership to align technology, design, and business goals.

Beyond building tech ventures, I educate and mentor the next generation of engineers and founders, helping them innovate, grow, and lead with purpose.


————————

Subscribe to The Modern Engineer Newsletter: elliotone.com

————————

I am relentlessly focused on delivering:
➜ Value
➜ Impact
➜ Long-term growth

Cutting-edge Solutions → xantco.com


📩 For business inquiries, collaborations, or partnership opportunities, reach out at business@elliotone.com


Let’s Connect:
[1] Instagram: https://www.instagram.com/elliot1one
[2] X (Twitter): https://x.com/elliot1one
[3] Substack: https://substack.com/@elliotone
[4] GitHub: https://github.com/ElliotOne
[5] TikTok: https://www.tiktok.com/@elliot1one
[6] YouTube: https://www.youtube.com/@elliotone
[7] Support my work: buymeacoffee.com/elliotone

Elliot One

Leaking resources is a silent performance killer.

Managing unmanaged resources is not optional if you care about performance, stability, and reliability.

Any time the code touches files, databases, networks, or external systems, it allocates resources that the GC does not manage for you. 

If you fail to release them explicitly, you slowly accumulate problems that only show up under load.

.NET gives us two clear tools for this job:
1. IDisposable for synchronous cleanup via Dispose()
2. IAsyncDisposable for asynchronous cleanup via DisposeAsync()

Using them correctly gives you:
• Fewer memory and handle leaks
• Lower pressure on system resources
• More predictable application behavior
• Better performance at scale

The key is ownership. 

If your class owns a resource, it must also own its cleanup. That means implementing the appropriate interface and exposing a clear lifecycle.

Modern C# makes this easier than ever. 

The using and await using statements ensure cleanup happens deterministically, even when exceptions occur, without cluttering your code with manual try/finally blocks.


A simple rule of thumb:
• Use IDisposable when cleanup is fast and synchronous
• Use IAsyncDisposable when cleanup is asynchronous or resource-heavy


P.S. Clean resource management is not just about correctness. It is about writing code that behaves well under stress and remains maintainable as systems grow.


♻️ Share if you care about clean, reliable resource management

➕ Follow Elliot One for practical Modern Engineering insights

IAsyncDisposable & IDisposable Resource Cleanup in .NET by Elliot One

taplio

The Battle

Brian Jenney

Elliot One

Followers

Posts

Engagements

Likes

Performance ScoreBrian Jenney's LinkedIn Performance

Performance ScoreElliot One's LinkedIn Performance

Ready to grow your LinkedIn presence?

taplio

The Battle

Brian Jenney

Elliot One

Followers

Posts

Engagements

Likes

Performance Score.css-goub6s{font-size:var(--chakra-fontSizes-md);font-weight:500;color:var(--chakra-colors-gray-600);display:block;margin-top:var(--chakra-space-1);}Brian Jenney's LinkedIn Performance

Performance ScoreElliot One's LinkedIn Performance

Ready to grow your LinkedIn presence?

Performance ScoreBrian Jenney's LinkedIn Performance