T[] data = new T[capacity];   // does not compile

It feels like it should work. You can write new String[capacity] and new int[capacity], so why not new T[capacity]? The answer is a single design decision Java made back in 2004, and once you understand it, a whole cluster of generic "gotchas" stops being mysterious. That decision is called type erasure. Let's work up to it.

The generic array problem

Say we're building a small generic container, the kind of thing you write once and use with any element type:

public class Box<T> {
  private T[] data;

  public Box(int capacity) {
    data = new T[capacity];   // we'd love to write this
  }
}

The compiler stops us cold on that new T[capacity]. The usual fix is to allocate an array of Object and cast it to T[]:

@SuppressWarnings("unchecked")
public Box(int capacity) {
  data = (T[]) new Object[capacity];
}

The cast is unchecked, the compiler can't verify it, so it warns us, and we suppress the warning because data is private and we control every value that goes into it. From the outside, the box behaves exactly as if it held a real T[].

This is the standard idiom. Java's own ArrayList does exactly this: it stores its elements in an Object[] and casts on the way out. But it raises an obvious question. Why can't we just write new T[capacity] and skip the dance?

Type erasure

Here's the rule that explains it. Type erasure means generic type parameters exist only at compile time. The compiler uses them to check your code, and then it throws them away before your program runs.

So when you write this:

Box<String> b = new Box<String>(10);

the compiler checks every use of b against String, and then erases the type argument. At runtime, what's left behaves as if you'd written:

Box b = new Box(10);

The angle brackets are gone. The running program has no idea that b was ever a "box of String." And that is precisely why new T[capacity] is illegal: building an array requires knowing its component type at runtime, and by the time the program runs, T has been erased. There's no concrete type left for the array creation to use, so the language disallows the syntax outright rather than let you create something unsound.

What else erasure explains

The array restriction is the one people hit first, but it's not alone. Several of Java's generic limitations are the same fact wearing different hats:

• All instantiations share one class. Box<String> and Box<Integer> compile to the same bytecode. There is only one Box class at runtime, not one per type argument.
• instanceof can't ask about a type parameter. You can't write x instanceof T, and you can't write b instanceof Box<String>. The type argument isn't there at runtime to test against, so the check is meaningless and the compiler rejects it.
• You can't do new T() either, for the same reason new T[] fails: there's no concrete type to construct.

None of these are arbitrary rules someone added to make your life harder. They all fall out of one decision: the type argument is not around at runtime to act on.

Why Java erases

Other languages made different choices. C# keeps generic type information at runtime; C++ templates generate a separate concrete class for each type you use. So why did Java erase?

Because of history. Generics arrived in Java 5, in 2004, nearly a decade after the language shipped. By then there was already an enormous body of pre-generic code in the wild, code full of raw types like List and ArrayList with no angle brackets at all. The language designers wanted new generic code and old raw code to keep working together, in the same program, without a painful migration. Erasure made that possible: because Box<String> and a raw Box are the same type underneath, the new and the old interoperate seamlessly.

The limitations we walked through, the array problem, the missing runtime type, the broken instanceof, are the price Java paid for that backward compatibility. Whether it was the right call is a fun thing to argue about. But knowing that it was the call, and why, turns a pile of confusing compiler errors into a single idea you can reason about.

So the next time new T[capacity] won't compile, you'll know it isn't the compiler being difficult. It's just type erasure, doing exactly what it was designed to do.

How important is full stack development given that AI coding tools can now generate full stack applications fairly reliably? If it's still worth pursuing, which stack would you recommend learning?

It's a fair question. I teach a course called Full-Stack JavaScript, and I'd be concerned too if I were a student watching AI agents generate complete applications. Let me give you an honest answer, even if it's not entirely reassuring.

The short version: Yes, I still think learning full-stack development is valuable. But the landscape is changing in ways that are uncomfortable to acknowledge.

Why This Course Exists

First, let's be clear about something. I didn't create Full-Stack JavaScript out of love for JavaScript or passion for full-stack development. I created it to help students be job ready. That was my sole intention—to give you the skills needed to work as software developers, particularly building applications that businesses actually need.

The question is whether that preparation still makes sense when AI can do much of what we teach in that course.

The Complexity Spectrum

To understand where AI fits, think about software projects along multiple axes of difficulty:

• Problem familiarity: conventional → novel
• Algorithmic complexity: low → high
• Specification clarity: precise → ambiguous
• Architectural scope: localized → distributed
• External integrations: none → many
• Environment complexity: simple → complex (setup, build, deployment)
• State and data complexity: stateless → heavy state management
• Concurrency requirements: single-threaded → highly concurrent
• Non-functional constraints: minimal → strict (performance, security, compliance)
• Robustness requirements: basic → mission-critical
• Tool/API volatility: stable → rapidly changing
• UI/UX complexity: simple forms → complex flows
• Backward compatibility: greenfield → legacy integration
• And more...

The simpler a project is on each axis, the better AI coding agents do. As complexity rises along any of these dimensions, they struggle more, the same way a human developer would.

Where AI Stands Today

The hard part to admit is this: AI coding agents are excellent at the simpler-to-moderate levels of this spectrum. They can do very well what a junior software developer can do. Everything I teach in Full-Stack JavaScript—setting up servers, creating REST APIs, building React frontends, connecting to databases, deploying applications—AI can do with flying colors, much better than students just learning these skills. (And these tools keep getting better, with no sign of slowing down.)

But it hasn't bridged the gap to become completely autonomous. It's not yet at the "build me X and it shall be" stage. You still need a human co-pilot to guide it, validate its decisions, catch its mistakes, and handle the ambiguous parts.

Current evidence suggests that AI copilots work best with senior developers. Senior + AI is more productive than Senior + Junior. This creates an obvious incentive: replace junior developers with AI.

The Market Reality

This isn't speculation. The data (see [1] and [2]) is already showing the shift:

Junior roles are shrinking. Studies across 250,000 firms show that headcount for early-career software developers (ages 22-25) has been dropping steadily, right as AI coding tools spread.

Senior roles are growing. Headcount for developers aged 31 and up keeps expanding, and companies struggle to find enough senior engineers, poaching talent or buying whole companies just to secure capable developers.

And firms are cutting junior hiring on purpose. They're reducing the roles they expect to automate, because they see it as cheaper than future layoffs: cut the hiring now rather than lay people off later.

The Paradox

Here's the problem: you can't create a course that directly turns someone into a senior developer. Senior developers are made through years of experience, starting as juniors and growing through mistakes, projects, and mentorship.

This creates two possible futures:

Scenario 1: You start learning now, but before you develop senior-level skills, AI closes the gap. It becomes fully autonomous, handles complex projects, and junior-to-mid-level developers are no longer needed. You're out of luck.

Scenario 2: You start learning now, but AI fails to close the gap. The industry suffers from its reduction in junior roles. As current seniors retire, there aren't enough people to replace them because we stopped training juniors. You become extremely valuable.

I hope the second scenario happens. Unfortunately, major companies seem to be betting on the first.

So Should You Take the Course?

Despite all this, my answer is still yes—but with clear eyes about what you're getting into.

You need to understand the fundamentals. Even if AI is writing the code, someone has to know whether that code makes sense, whether the architecture is sound, whether the security implications have been considered. You can't guide an AI copilot well if you don't understand what you're asking it to build.

The complexity spectrum matters here. The full-stack development we teach sits at the simpler end on purpose, but you need those fundamentals before you can tackle the complex problems AI still can't handle on its own. You have to crawl before you walk.

Speed matters. If you're going to beat the AI gap, you can't take the leisurely four-year path. Learn intensively, build real projects, contribute to meaningful work, and move from junior to mid-level as fast as you can. The clock is ticking.

Depth still beats breadth. Don't try to learn every framework and stack. Pick one, learn it deeply, understand the principles, and get good at solving real problems. The ability to think through hard technical challenges is what will set you apart from AI. (Think about that the next time you're signing up for another humanities course!)

What About Which Stack?

You might be tempted by another angle: since AI coding agents are better at popular stacks (trained on more data, better documentation, more Stack Overflow answers), maybe you should learn something esoteric to gain an edge. This is a mistake. You're trying to compete with AI, and you can't win that game. AI will eventually cover the esoteric stacks too, and you'll have spent your time learning technologies with smaller job markets and fewer resources. You'll have optimized for being different from AI rather than being good at building software.

Put AI aside. Don't make your technology choices based on what AI can or can't do. Make them based on what you need to learn to build real applications and get real jobs. If you want to build web applications, learn JavaScript and its popular frameworks and libraries—that's where the jobs are. If you want to work on machine learning or data science, learn Python and its ecosystem. Pick something practical with real market demand, go deep, and build things that matter.

Whatever stack or domain you choose, learn to use AI well within it. The future isn't about competing with AI; it's about working alongside it. Learn the fundamentals deeply enough that you can guide AI tools, validate their output, and catch their mistakes. Use AI to accelerate your development, not to replace your understanding. The developers who thrive won't be the ones who avoid AI or try to outrun it; they'll be the ones who understand their craft well enough to make AI a force multiplier.

There's a catch, though: using AI while you're still learning can get in the way of that learning if you're not careful. There's a real tension between learning to use AI and using AI to learn. I'll write more about how to navigate this in a future post, but for now, be mindful of the difference between using AI as a tutor and using it as a ghost writer.

The Honest Bottom Line

I can't promise that learning full-stack development will help you get a job in five years. The industry is changing too rapidly, and the AI capabilities are advancing too quickly for anyone to make that promise honestly.

What I can say is this: understanding how to build software systems, even if AI is doing the typing, remains valuable. The question is whether that value translates to employment opportunities at the junior level, or whether you'll need to accelerate past that tier before the market for junior developers disappears entirely.

It's a gamble. But it's a more informed gamble than going in blind.

If you're going to make this bet, make it count. Don't just complete the assignments. Build real things. Contribute to open source. Work on projects that challenge you. Aim to be mid-level capable by the time you graduate, not entry-level.

The industry is changing. How you adapt to that change will matter more than which stack you choose to learn.

References:

• [1] Hosseini Maasoum, Seyed Mahdi and Hosseini Maasoum, Seyed Mahdi and Lichtinger, Guy, Generative AI as Seniority-Biased Technological Change: Evidence from U.S. Résumé and Job Posting Data (August 31, 2025). Available at SSRN: https://ssrn.com/abstract=5425555 or http://dx.doi.org/10.2139/ssrn.5425555
• [2] Brynjolfsson, Erik, Bharat Chandar, and Ruyu Chen. "Canaries in the coal mine? six facts about the recent employment effects of artificial intelligence." Stanford Digital Economy Lab. Published August (2025). Available at: https://digitaleconomy.stanford.edu/wp-content/uploads/2025/08/Canaries_BrynjolfssonChandarChen.pdf

My advice is simple: take fewer courses. Focus on depth over breadth. Choose challenge over convenience. For most undergraduates, fewer courses done thoroughly is the wiser default.

Graduating early: Taking more courses can let you finish in three years and save on tuition and housing. If you face serious financial constraints, consider this path. For most students who can afford the standard four years, the depth and time for advanced work outweigh the cost savings; graduating early often means sacrificing depth of learning—the real value of your undergraduate education.

If you can afford the full four years (for example, because you're on a full scholarship), you may still feel pressure to overload on courses and extracurriculars. There is a pervasive belief that more is better—that piling on courses, majors, and activities will lead to a richer experience and more opportunities after graduation. After all, whether you take 12 credits or 21+ credits, you still pay the same tuition. Why not get the most out of it? Course registration can start to resemble an all‑you‑can‑eat buffet. That's where the logic falters. Here's the case for less being more.

The Math Doesn't Work

Let's start with basic arithmetic. The federal definition of a credit hour is this: one hour of classroom instruction plus a minimum of two hours of out-of-class work per week equals one credit hour. That's three hours total per credit, per week (in a typical semester), as a minimum. So, for example, if you're taking a 3-credit course, you should expect to spend at least 9 hours per week on that course (3 hours in class + 6 hours studying at home). There are exceptions, of course! For example, a lab course may require much less outside work, while a project-based course may require much more. But as a general rule of thumb, this is the standard.

A full-time student is one whose primary occupation is studying. Full-time employment is typically considered to be around 40 hours per week. Therefore, a full-time student should be dedicating approximately 40 hours per week to their studies. At 12 credits (the minimum for full-time status at Hopkins), that's 36 hours per week. At 15 credits (a typical course load of 3–4 courses), you're at 45 hours—already above the 40-hour mark.

If you take 18–21 credits, that's 54–63 hours per week just for coursework. Now add in extracurriculars (research projects, student clubs, applying for internships, etc.), personal responsibilities, and perhaps a part-time job. It becomes unsustainable. Something has to give, and what gives is depth of learning.

While it's true that some courses require less work, that's usually at the expense of rigor and depth. An easy or superficial course can help you check a box, satisfy a requirement, or boost your GPA, but it won't grow you intellectually the way a hard one will. And that growth is the point of an undergraduate education, especially in engineering. Paying tuition for an easy A that amounts to busywork, while skipping the advanced courses that demand real effort (the ones you're unlikely to study on your own, outside the scaffolding of a class), is a poor trade when time is zero-sum. I'd take the B+ in a rigorous course over the easy A.

The credit-hour math is a minimum. In practice, most technical courses routinely exceed it, so you'll likely spend more time than that. And even if you push well past 50–60 hours a week, there's a ceiling on how much a person can absorb: the brain has finite attention and processing capacity, and piling on more courses past that point just lowers the quality of what you learn.

The Multiple Major Trap

It's common to see students major in two or more fields, often adding a minor or two for good measure. In principle, in fields with shared cores (e.g., CS + Applied Math), a second major or minor can formalize complementary depth and perhaps open doors for interdisciplinary work. In practice, however, when you commit to multiple majors within a fixed timeframe (typically four years and within a fixed credit cap), each additional major forces you to optimize for breadth over depth. Your learning becomes a series of requirements to satisfy rather than a coherent intellectual journey. You take the courses you must take, not necessarily the ones you should take.

What's worse is that many programs have adjusted their requirements to make double majors feasible. As multiple majors become common, the marginal signaling value of an additional major declines. What stands out beyond credential inflation is actual evidence of mastery: a thesis, research paper, open-source contributions, or performance in advanced electives—outcomes that require slack in the schedule.

The Extracurricular Paradox

On top of an overloaded course schedule or multiple majors, you may try to maintain research positions in labs, participate in independent studies, lead clubs, and engage in various other activities—all simultaneously. The intent is admirable. The execution is often superficial.

When you spread yourself this thin, you can't give any single activity the attention it deserves. You do the bare minimum to put a checkmark next to each item on your resume. You're present, but you're not really engaged. You're participating, but you're not making meaningful contributions. Concentrated effort on fewer, harder things yields artifacts, references, and real competence.

A Better Path

Here's what I recommend instead.

Take three or four courses a semester, and make them count. This fits both the federal credit-hour definition and the reality of deep learning. It gives you time to actually understand the material, to struggle with hard concepts, to go past the minimum.

Commit to a single major. Take the advanced courses. Take the ones that scare you a little. Build real expertise in your field. You can always take electives outside your major to explore other interests, without the pressure of satisfying a second major's requirements. No one ever got hired because they had two majors; they got hired because they were good at what they did.

Use summers for extracurriculars. If you want to do research, an independent study, or anything else, do it over the summer when you're not taking courses. Give each one the attention it deserves instead of spreading yourself thin. Take on one or two meaningful things across your whole degree, and stick with them rather than dabbling in many.

Choose challenge over convenience. Take the courses you wouldn't study on your own, where you'll learn from the professor's expertise and your classmates' perspectives. Take the ones that matter for the field you care about and genuinely challenge you. Avoid the "easy A" that doesn't stretch you. The goal is to grow, not to collect a good grade.

Plan for four years. Unless you have serious financial constraints, there's no prize for finishing early, especially if finishing early means you learned less. Many students who rush through in three years end up adding a master's year anyway. Slow down, take your time, and make it count.

The Real Value

The value of higher education isn't in the number of degrees you collect, the majors and minors you accumulate, the courses you cram into each semester, or the activities you juggle. It's in the transformation that happens when you engage deeply with challenging material—when you have time to think, question, and connect ideas across domains. That transformation, not the transcript, is what will serve you for the next forty years of your career.

That's what I want for my students. Not more courses, more majors, more activities—but deeper learning, genuine challenge, and the time and space to become truly competent in your field.

Sometimes less really is more.

If you want a feed, here it is.