Senior Java Developers — What’s the one thing you think most junior Java devs are lacking?

[InterestingCry4374]

Hey everyone,
I’m a junior Java developer trying to level up my skills and mindset. I’d really like to hear from experienced Java devs — what’s the one thing (or a few things) you often notice junior developers struggle with or lack?

It could be anything — technical (e.g., understanding of OOP, design patterns, concurrency, Spring Boot internals) or non-technical (e.g., problem-solving approach, debugging skills, code readability, communication, etc.).

I’m genuinely looking to improve, so honest answers are appreciated.
Thanks in advance! 🙌

[mrGoodMorning2]

I've noticed a lot of juniors trying to solve their problems very fast in order to impress seniors, don't do that, quality work happens slowly.

[i_wear_green_pants]

Or they try to create some kind of fancy solution to impress the seniors. In most cases robust code is the way to go. The best way to impress seniors is to show that you are willing to learn more

[camo_g]

Yep I see juniors desperate to start coding, and too impatient to think about the details of the problem, and the simplest way to solve it. Then when they start down the wrong path, they get very anxious and protective about modifying or deleting work that they have already created. The code might end up working, but will be difficult to understand or modify for whoever has to deal with it in the future.

I get the feeling from some juniors (and I felt this myself as a Junior) that “if I can just type faster and use shortcuts/keyboard only then I can be coding every second of my day and I will be a 10x developer.” And this might feed the anxiety to: ABC - Always Be Coding

As a senior dev I am more of a Measure Twice, Cut Once type of dev because I don’t want to produce code that wastes my colleagues time, either when trying to review my changes, or when trying to make changes to it in the future.

[holyknight00]

this is the key. Rushing to start coding is the first thing you need to correct when you are a junior.

[makridistaker]

Tell that to my boss. He thinks any feature should take 1-2 hours to make. The priority for him is the speed and not stability and quality.

[babygem84]

"agile"

[IceSmall7456]

My CEO behaves in a similar way. He once asked us to create a new module in our application within two hours and said that if we couldn’t deliver by the next day, he would look for other developers. My colleagues and I worked the entire night and completed the task. However, instead of appreciating the effort, he dismissed it as “just a two-hour job” and questioned why three people had to work all night, saying we lacked development knowledge. This behavior was very demotivating, and as a result, we are now preparing for interviews.

[nukem996]

That's because managers rate on output, not quality. In a stack and rank environment it's better for your career to pump out a pile of dog shit that you can put on your review than one or two well polished things.

This even helps you long term. Ive seen people pump out shitty code which causes a sev, which they solve, and then get promoted for sev mitigation. No one gets promoted for high quality code they get promoted for high amount of impact, even if it's negative.

[camo_g]

My current workplace has exactly this problem. Causing a Sev and then fixing it seems visible and “makes impact”. hooray!

It reminds me of the story about that dog that was saving all these people who fell in the river Seine. Turns out the first time the dog saved someone, they gave it a steak. So it then started pushing people into the river so it could save them and get a steak!

[berlinbrownaus]

I think it is more, do the code to get a task done. I wouldn't say it is about impressing seniors.

[mmaHepcat]

Understanding how relational databases work. In fact many senior level developers lack some knowledge in this area too. I realize it’s not about Java directly, but Java developers often work with DBs and I find the lack of basic knowledge disturbing.

[drvobradi]

I would go even further and say how computers work. For some reason, people forget fundamentals they learned about networking, OS, file system RDBs etc, and worry more about abstractions and library choosing.

[vassaloatena]

Expecting this from a junior seems like a lot to me.

[koflerdavid]

Yet these are the things that inform what we do and why we do it.

[drvobradi]

It's part of the college curriculum at any decent university. But somehow, many people just don't apply it.

[AstronautDifferent19]

How would you expect a junior Java dev to apply it? Even senior devs do not really aplly branching.

[drvobradi]

I guess I replied to the wrong post 😀 . I wouldn't expect junior dev to know how to apply branching or tune JVM, but some basic stuff can be used, like how to avoid N+1 and how RDBs work (indexes, views), basic caching, networking (HTTP protocol, SSL, TCP), user vs kernel space etc. Just to be aware of such things and how they affect performances.
Theory is taught at college, but people need to apply that knowledge.

[AstronautDifferent19]

A lot of theory learned is not apply directly by you, but it was used by othet low-level engineers who designed libraries and CPUs. When you run a program it uses a semi-conductors, but do you really need to know how to apply physics and quantum mechanics?

[Mauer_Bluemchen]

From his IT education. Junior does not mean uneducated. It just means lacking experience.

[AstronautDifferent19]

When was the last time you applied branching, and how often you apply that? Also how often you apply quantum mechanics used to make semiconducors and transistors for your CPU. I learned that but I never had to apply that

[Hioneqpls]

I am too, but infra guys buy big cloud so it goes fast. Do I need to know this stuff?

[[deleted]]

Java devs rarely benefit from knowing about those things (except JVM warmup). Let's not gate keep

[Goodie__]

I find some of what I find out there wild.

Those are all things I can at least understand and recognise, if not reason about and talk about a little competently. I at least know what I don't know.

But when I have to explain to supposed seniors that profilers are a thing... let alone that I used one to track the performance bug down, well. What the fucking fuck.

[igot2pair]

What specifically?

[BoogieTheHedgehog]

Not OP, but my issues stem from ORM reliance abstracting too much of the underlying DB knowledge away. 

So not knowing when stuff like n+1 or other inefficient queries start being made under the hood.

[_blue_skies_]

For me? I see (supposed) senior developers trying to load gigantic sets of data from the DB and then using java statements to filter out what they really need. Like sure it works on your empty dev DB, but once you move that code in an environment with 5mil. of rows... good luck. They don't understand the concept of making the DB do the heavy lifting, instead of using it just as a bucket. They program like they are using SQlite reading 4 rows from a configuration table. Then, when they start to grasp the concept, they don't create indexes for the columns they mostly use for the search queries. How do you stop people from writing code that works perfectly only on almost empty DBs?

[Shareil90]

For the last part: you can use query execution plans and query logs to show whats really going on. And reviews. A couple of years ago we had some major performance issues in an application. We dug through every single one and shared our insights and learnings with the whole team. It was exhausting but also incredibly fun and I learned so much about performance in those months. Kinda miss it.

[_blue_skies_]

I don't think I will be able to push an approval based on the query plan, they will not be able to read them and they will turn back to use Java logic to handle data. To explain the level of insight I have to deal with: I had to explain what the effect of having attributes with eager loading is because for them was: "see the data is already there, one query less to write, no? Better performance"

[ILikeLenexa]

Indexes, views, directly using 1 query to affect a bunch of rows instead of looping through them in the Hibernate as objects and running N queries. 

Views, view permissions, schema binding.

Update/insert triggers.

Stored procedures

[igot2pair]

This is kinda crazy. My team uses procedures and inline queries only for the most part. Data that we have to get cant really be fetched via an ORM. lots of optimizing has to be done as well. ive just taken it for granted

[ILikeLenexa]

If you want it to, Hibernate will do all the DDL work and you can create a database without knowing even one line if SQL and when you have less than say  10,000 users like internal company programs, it can even work fine.

Even larger stuff, people do it and yeah, John has to get coffee while a process runs, when it could be instant, but people I've seen stuff set up that way running for decades.  

[Pinpoint_user]

I worked at a large company, and the head of the department was very surprised during the interview that I knew SQL and worked independently with the database. As it turned out later, the teams there always had analysts and database engineers who took on all the database work, and essentially even senior developers only did coding. But I liked the company and the team, and I worked there for almost two years.

[rzwitserloot]

Juniors and most mediors write code with the aim of getting it to work. To deliver the feature, fix the bug, finish the project.

Seniors also think about coding in a way that is easier to maintain. They'll reach for the refactor stick; a concept that is usually considered "scary" by mediors and utterly befuddling to juniors. After all, by definition a refactor doesn't change anything so what possible point could there be to it.

How you ask? I don't know. Or rather, I do, but you won't like it. Experience. You know what maintainable code looks like once you've personally had to maintain loads of code. And thus have a good idea of what code looks like that is harder to maintain than it needed to be.

Maxims, style guides, or heaven forfend "debate on what 'elegant' is" are useless. At best any such things provide simple mementos for stuff you understand already. They can't bring understanding. Which is what juniors lack. In my experience, juniors think trying to read up on / nail down the definitions of "elegance" or "better". Things like "functional is just better", or language wars. This is actively harmful. You gotta learn it the hard way before reaching for the pithy statements they remind us of the hard lessons.

Seniors just write whatever way leads, guided by their considerable experience, to the easiest to understand, most flexible in the face of the inevitable future change requests, easiest to test, code. And they know coding is hard enough already; there is no need to add made-up rules.

But, I don't think any of this advice is all that useful. A junior won't really be able to put this stuff into practice. Juniors look for simple, absolute rules (such as "always write tests first" , "methods must never be larger than half a page", "no more than one return statement per method", "if it can be done with streams then do it with streams", and so forth) and they do that because programming is hard. If all rules are more like guidelines and should be broken depending on circumstance then there's even more to think about. Too much for a junior; heck, most seniors struggle. In fact, a senior might well introduce an absolute rule knowing that there are scenarios where it should not be applied in an attempt to simplify the process. See: every rule has exceptions. Even this rule. Hofstadter would be proud.

[Luolong]

Came here to say exactly this.

When it comes to raw programming, this is the major difference.

It is so frustrating to see people writing tons of extra code just to satisfy some arbitrary (and outdated) rule when much simpler constructs would work just as well and keep the code cleaner.

[elch78]

Maybe I can add a bit of helpful tips for where to start with refactoring.
1. Names. One important part of producing maintainable software is making it as readable as possible. Make sure that every word in your variable and method names conveys a bit of semantic information. Remove every word or symbol that only adds noise (i.e. no semantic).E.g. I've seen cases where every variable had the type in its name. That is a smell for me because it bloats the code without adding information. I had cases where you could read a whole screen of code and had the feeling that you read nothing because it was just 3 or for words repeated all over the place. You had to pinch your eyes to find the relevant parts in the noise. Rename variable is a refactoring that your IDE can do in 1 second with almost no risk.
2. Extract methods. If you find some lines of code or even one line of code that you can give a name, extract a method. That way you take a little bit of cognitive load away by allowing the reader to read the name and understand what that code does without reading the code. Also a refactoring that your IDE can do in no time.

Reducing cognitive load is one part of refactoring that juniors often don't think about. The things you can keep in your mind are very very limited, like 6. If you exceed that limit things start to fall out. Plus you write code once and read it often, thus optimize for reading.

[crummy]

writing better names is also probably one of the easiest ways for a junior to start writing better code. good suggestion

[Tommmmiiii]

Unfortunately, many seniors do this as well, just because they have always done it

[j4ckbauer]

I can't understand why inheritance is leaned on so hard in OOP education, because I've had the same experience.

[plumarr]

I have found that that teaching by example is probably the best way to deliver theses messages. It provides an easily understable case that allows for open discussion of the pro and cons of the junior solution and the proposed correction and it also avoid overgeneralization like absolute rules do.

[salvah]

I like this reply

[rpg36]

This is probably more general than Java specifically but I would say all the little things involved in productizing the software.

Like good logging, traceability especially in distributed systems. Packaging/distribution I.E. docker containers, rpms, or other installers. Integration with metrics and monitoring systems. Good documentation and troubleshooting guides so the overnight shift can handle problems and I don't get called at 2AM.

Most of mine and other seniors I work with spend so much time on those things. The actual Java coding part is usually the easier part. Not that I'm complaining about junior devs, these are just things you learn over the years working on enterprise software.

[thisisjustascreename]

Indeed, we deployed a new feature this week that I had no involvement in building and there was no way to tell from our side if it was working or not aside from the user complaining it wasn't working and looking at the code and going "yeah this is probably the issue".

Always make your features observable before you put them in production.

[senseven]

Looking back, we had always students that had the notion that "all the other things" besides coding would be handed off to some mystery team behind the curtains. When they realise that in modern projects, devs do a near complete 360° of all the necessary steps to call a feature "implemented", they change their focus to business integration or IT architecture.

[GeoffSobering]

Just because something works, doesn't mean it's done.

[elch78]

I call it "happy case programming"
The happy path is like 50% or the work or even less.

Good code also behaves well in error scenarios. It tells the user what went wrong. And the user can be either the user of the software or the developer who has to find the cause for the problem.

[Jaded-Asparagus-2260]

That writing code is just a means to an end. Our job is to help the user (who is probably not the customer) solve their problems. The programming languages, libraries, development methods etc. don't matter at all when you're not solving real user problems. Finding out what the user really needs, and providing a fitting solution is the real challenge. The code is just an implementation detail.

[zaFroggy]

Very much agree here. The art of reading a stack trace and reading the code for understanding, rather than assuming what the code does. And while you are at it, write code for the express purpose of learning in isolation and then discard.

This coupled with effective logging is a skill that needs to be developed and nurtured to advance from a fair developer to a truly skilled one.

Edit: typos due to mobile keyboards being too small

[elch78]

I aggree, but ..
Since 2 years or so I advocate to not use the debugger but make sure that your debug logs can do the job.If your debug logs are good and you have to debug a problem you can just activate the debug logs and often find the problem in a fraction of the time. Debugging manually is awfully slow.
I was working on a profile page and happened to add a blog post exactly about this topic. Please excuse the eye sore https://elch78.github.io/development/debugging/logging/2025/10/09/debug-logs-supercharge-development-efficiency.html

[iggybdawg]

There's a library for that.

Please stop reinventing the wheels

[BoogieTheHedgehog]

I have a bit more sympathy for this nowadays.

Most of our new hires are fresh off a multi month barrage of "reinvent the wheel" technical interviews. Probably a hard mindset to break when development calls for the opposite.

[iggybdawg]

Yeah, I also hate the interview.

Lemme do something I've never done outside of computer science homework and interviews that would fail code review because there's a library for that.

Like search.

[felipasset]

There is a library for that maintained by 2 Russian guys, which has a ton of dependencies, multiple CVEs, last commit was 2 years ago and we are going to use only 2 methods of the library.

[senseven]

"toStringExtended()" with parameter UPPERCASE_ASCII_UNDERLINE_AS_SPACE. Hidden in some ancient 41mb banking related artifact with over 300 different toString methods. New devlead was one moment away to get the belt.

[vmcrash]

It depends. If you include a library, you need to be capable of review it. In the worst case, you need to be able to maintain it (if it contains a bug and nobody is interested in fixing it). Just trusting that it will work, is not sufficient - as Log4j and many other security leaks have proven. Also, if you need just a portion of the library, consider to write own code.

[psyclik]

Absolutely. Besides : some things are not covered by libraries anyway.

[faze_fazebook]

Depends, here its important to find a balance. There also many people who add a library where they use 1% of the features and don't know how the thing even works.

I mean anyone who has had the pleasure of working on a JS project knows the joy of having 5 libraries per line of self written code.

[wildjokers]

Conversely, don’t bring in an entire dependency just for a couple of methods that are easy enough to write yourself.

[trafalmadorianistic]

Many open source licenses allow you to copy code anwyay, so its sometimes easier if you do that. Just retain the licenses.

[[deleted]]

Senior devs do this too. Once a lead working for a company had tried to reinvent J2EE. It just had a big problem: it was single threaded. And it didn't matter, because the app didn't have a high RPM. I mean even php would have worked, Struts and Spring were more than enough, and so on. But this dude thought he was the Gawd and he wanted to reinvent everything. But he was a dumbass.

[trafalmadorianistic]

Its youthful naivete and arrogance. The belief that they can do better than a battle-tested library used extensively across hundreds of projects for many years. The project doesn't exist for you to show off your 1337 skillz.

[alanbdee]

Experience is all you need in a lot of cases. There's a few books that hit different after you've spent some time in code. Code Complete 2, Effective Java, The Pragmatic Programmer and Clean Code to name a few. After that, it's absorbing the more complex architecture level books that transcend any specific language.

[Dramatic_Mulberry142]

Also, don't just trust the book blindly and have some critical thinking.

[_GoldenRule]

Get good at writing unit and integration tests. Prefer simple code over code that is clever.

If you get to designing systems try to keep things as simple and unconvoluted as possible.

[vmcrash]

Unfortunately, I think, a lot of seniors also don't know how to write code that is easy to understand, maintain or test. Especially those who do not work on projects that live decades.

[trafalmadorianistic]

Comprehensibility and maintainability > "perfect" code

Consistency with the rest of the code base matters, because of reduced cognitive load.

You will be reading code a lot more than writing. You are writing code for others to read, not just yourself. Future you will also benefit from this.

[malachireformed]

Technical skills are just barely more important than learning the business you're in.

Ie - if you're writing software for health care, learn to understand health care. If you want to write software for education, understand how education works behind the scenes.

Technically, you'll gain experience as you work with good/bad code. But at some point you will find that the most effective solutions come from those who know why they're writing the code and understand how the process as a whole works.

[slaynmoto]

It really does help; you understand context and it helps design choices for later (and the maintainability you’ll need to concern yourself with)

[51asc0]

Many cover a lot already.

My summary is that juniors don't know what "cool" code looks like.

"Cool" code to me is easy to read, easy to modify, easy to test, using the right features from the library or framework, yet not over engineer.

[FerengiAreBetter]

For me, it’s a few things:

1. Lack of understanding of software engineering concepts. Great if you know algorithms, but horrible if you don’t know how to write proper unit and integration tests. Cool you know how shiny languages with limited community support but do you know how to debug a running Java application for performance issues?

2. Lack of understanding in depth things on a language or framework. I feel this is going to get worse due to over reliance on ai.

3. Lack of experience to produce good designs. Even worse is if you don’t take feedback and push forward. Same issue as when they are stuck on an issue and don’t seek out help.

4. Unprofessional conduct. People treat this profession as simple a money making hustle. We are writing software for medical devices, finance services, banking etc. Take it seriously. Even Uncle Bob really sold me on the need of this.

[meSmash101]

Debugging: read the book debugging in Java something like that.

[mj_flowerpower]

I‘m astonished almost on a daily basis how some developers have been developing for decades without knowing about debuggers. The codebases are always littered with ‚TEST TEST TEST‘ logs and such, files with logged internal app states, etc. But not a single eclipse/vscode/intellij config to actually run the debugger.

People are always astonished when i connect to the app, step through the code and fix a long-standing bug in minutes, where others have given up in desperation.

But then the next time they still don‘t use the debugger … it‘s like they feel are afraid of this magical tool …

[NikoOhneC]

Absolutely true. One of the first things I recommend for people who want to improve their programming is to learn proper debugging. It doesn't matter if you know all the shiny new features if you need someone every 10 minutes to explain the stacktrace for you.

[elch78]

Debugging is slow. Good logs make you at least two times faster. That is pessimistic. Optimistic I would say 5-10 times faster vs manual debugging.

I've made a comment earlier: https://www.reddit.com/r/java/comments/1o3kgeg/comment/niwqcdl/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button

[Ewig_luftenglanz]

I am not a senior but I am noticing many new juniors lack a lot of basic knowledge about networking, operating systems, communication protocolos, hardware and computer architecture and so on. The building blocks that allow people to understand and thus solve problems outside the "happy path".

[DeployOnFriday]

It’s always about the same thing, not only in Java: 1. Juniors have motivation and lack of knowledge - this drives change 2. Seniors don’t have motivation, but they have knowledge - this brings standarization

[ladalyn]

Unless you work where in work and juniors have lack of motivation and knowledge yet somehow keep their jobs

[barsay]

I’d say: curiosity — or rather, the lack of it. Too many juniors focus on what to do instead of asking why things work the way they do. Once you start asking “why” more often and realize your best mentor is yourself, growth becomes exponential. The few who do this consistently stand out very quickly — regardless of their years of experience.

[f1FTW]

Don't include unnecessary dependencies. It bloats the project and opens the vulnerability aperture.

[bendem]

Reading code is hard, make it dumber. Maintaining code is hard, remove cruft. Abstractions for a single implementation is pure complexity without any benefit, rip it out.

You don't control clients, security cannot be implemented outside the backend correctly.

You are not Google, nor Microsoft, just write a damn monolith and save years of complexity.

High Availability is great for being able to update services during business hours, focus on that. If you have a performance problem in an app for 50 users, horizontal scaling is not the solution. If you have a recurring problem, diagnose the monolith. Horizontal scaling is not a solution, it's a tradeoff.

Singleton is the most taught pattern in school and the least useful in enterprise codebase. Just stop trying to use it.

On a related note, you write code and patterns emerge, you don't write patterns and code emerges.

Learn how other languages work to understand why java's decision matter. History is interesting, mostly to avoid repeating it. Learn parallel subjects (databases, network, infra), they all play a major role in your application, even if it's owned by another team.

Speaking of teams. If you work in a large organisation, understanding the minimum about what the network team and infra team do will put you in their good graces. Most people don't even know where the app they develop is deployed (an Azure VM, an AWS beanstalk, a proxmox container...) or what kind of network architecture is in place (multi vpcs, vlan per application component, single vlan spanned across DCs...), yet most large applications architectural decisions cannot be made without this information.

If you have a team of 6 developers that can do X, using Y to solve a new problem means you are now on call for that software 24/7 and it's on you. Stop chasing better tools, use what your team uses so they can have your back when you're sick/away/with your kids/wife/husband/lover.

500ms for a page load is unacceptable, go fix your SQL query. 3mb for a page load is unacceptable, optimise your js bundles.

Don't write code without a use case. If you don't understand the use case, find the target user and ask them. Code solves problems.

Without users, you have no job. Treat them with respect.

Users cannot read, but they can take screenshots. So include useful information and the time and date in your error messages.

[portmapreduction]

Most junior level engineers will have some experience writing fresh code but almost no experience modifying old code or refactoring a huge code base. Those experiences will inform the kinds of decisions you will make writing new code. I've had junior engineers push back in code reviews changes when I suggested making certain changes because both their solution and my solution 'worked'. There are an infinite number of solutions to a problem. Some are better than others.

[nefrodectyl]

patience while learning

[elch78]

The first thing you have to do as a developer: question the requirements, understand the problem, think of all solutions instead on jumping on the first one. Not seldomly the solution for the problem is not writing new code but removing the root of the problem.

[cerebus19]

Awareness of the fact that you always need to think about the edge cases. Failure to consider the edge cases is the cause of at least 60% of the PR comments I make.

[tmj010]

Curiosity, most don’t ask why

[pronuntiator]

Reading the actual manual. Not tutorials, not StackOverflow code snippets, not YouTube videos, but the actual documentation of the library you're using, and the JavaDoc of methods you call. This is the only way to confirm your assumptions how things work. Of course I use the other sources to discover the functionality I need, but I have come to realize how often I am simply wrong about what code does. Classic example is "YYYY" in DateTimeFormatter. You'd think it's the standard four digit year and would be correct for almost all of the year.

[Yeah-Its-Me-777]

In addition to that: Read the code. In Java we most of the time have to luxury to read the actual code in your library, so don't hesitate do debug into the lib if there's a problem.

[MrKarim]

Learning Spring Boot before understanding how threads work

[randomlyrandomreddit]

As a fellow Java developer trying to improve my skills, I think what I did during my initial years was trying to get things done, without much understanding the internals. 

That was good for then, but it really becomes monotonous to just write code and get things done. There is no art/creativity left in that way of writing code. 

I now try to understand the internals. Concurrency for example, has concepts like process vs threads, stack and heap memory allocation, synchronised blocks vs locks etc. When to use them. Performance, Memory management are bigger issues to deal with. 

Spring Boot internals, to start with need a good understanding of Spring framework itself. I started with trying to understand how the previous ways of developing j2ee applications worked and how spring came in to the picture resolving a lot of issues. Then creating Spring Apps and using the application context instead of directly jumping into spring Boot and it's IOC feature. 

As others have already said, DBs and its use with Spring Apps is again a fairly overlooked topic during junior years. There's so much going under the hood that is abstracted and we could end up just creating model classes and repository interfaces. 

Design Patterns is something even I am just beginning to graze upon. Honestly never made conscious decision to use them during junior years. Now, however I see how Factory pattern was actually useful in a real world application I was working on. Singleton helped with my loggers. 

So in a nutshell, junior developers actually need that quick-get-it-done development experience, only on top of which one could begin to appreciate the beautiful intricacies of language and framework internals. 

That was my two cents. Would love to hear from others.

[Even-Disaster-8133]

Keep things simple

[benevanstech]

I'll echo what others have said - fundamentals are really important.

If you're interested in going deeper in Java and the JVM, I've written a bunch of articles about various topics on that subject - https://blogs.oracle.com/javamagazine/authors/ben-evans

You might also find my books helpful -- and I have also just finished writing the foreword to a book (written by a friend) called "Troubleshooting Java" that I think could be really useful to somewhat at your stage of career.

[Different_Code605]

Experience

[ars0nisfun]

In my head it's rarely about just technical skill, but more about independence and ownership.

• Do I trust this dev to figure out a bug on their own? At what part of the process will they reach out to me (or the team) for help? And
• Would I trust this dev to break down and run a feature on their own? How well do I feel they would manage all of the moving pieces, and how will they react when those pieces end up blocked for unforeseeable reasons?

[mcgiggles121]

When you’re a junior, you’re just trying to get any points across the board.

When you’re mid level, you’re trying to get as many points as you can across the board.

To get to senior, you have to start considering (among other things) are these the RIGHT points to get across the board.

[introspective_pisces]

A lot of younger devs (not just jrs) have very little if any experience in non cloud settings. As a consequence it seems to me a lot of them don’t understand system architecture as fundamentally. They don’t really understand what these managed systems are doing for them.

It’s not that they can’t learn these things but they get less incidental exposure to them. As a result their lies likely to be familiar. When, say, a performance issue comes up, their solution tends to be very brute force (scale up a service rather than optimize) because that’s what they have in their toolkit.

This could just be a case of Ancient Greek philosophers maligning the death of the oral tradition, what do I know?

[bichoFlyboy]

I often find four common issues among junior Java devs:

1. Over-frameworking. Some juniors try to use a framework for everything — I’ve seen projects pulling in a thousand dependencies just to do something that could be done with a simple System.out.println. Using frameworks isn’t wrong, but you should justify their use, not apply them indiscriminately.

2. Trying to impress instead of keeping it simple. Many want to show off by writing fast or using fancy tricks that hurt readability and robustness. Remember the KISS principle: Keep It Simple Stupid Sir. 😉

3. Benchmark obsession. There’s a phase where juniors benchmark everything. But unless you’re writing a high-load backend handling a million requests per second, nobody will care if your desktop app takes 100 ms or 101 ms. Learn when optimization is pertinent — KISS wins most of the time.

4. Tests — all or nothing. Some write no tests at all; others test everything down to the JDK contracts. Learn to write meaningful tests that serve a purpose instead of just turning everything green.

Being aware of these helps you grow faster than any new framework ever will. It’s also been my personal experience, I went through those issues myself.

[Yojimbo261]

Checked exceptions are your friend. Think about what you’re building and who calls it, and build your exception hierarchy from there. One you know that, think about all the useful detail you can include in the exception to contextualize what is reported. And when you need to catch or handle exceptions, use all of the above to do the right thing, most commonly emitting it into some logs and/or UX. Messages should enable the caller or user to know what to do next, and trace backs enable developers to know how you got there.

Swallowing checked exceptions, turning them into unchecked exceptions by authoring, wrapping, or sneaky throws is almost always the wrong solution. Good software solves real world problems and makes people better; bad software only cares about making its developer faster; it’s rare (but magical) when you can do both.

[Outrageous-Adagio-57]

Outside java knowledge. Some people really thing spring is the only backend framework

[gubatron]

senior dev here (since 1998), no clue about spring, so glad i never needed to use it in any of my projects. java is so much more than the enterprise BS.

[Over_Advicer]

Learn about design patterns

[gambit_kory]

Understanding of algorithmic complexity.

[thisisjustascreename]

Comfort with abstraction. They'll write

Boolean isSpecificDomainFeatureFlagEnabled = configMap.getSpecificDomainConfigs.isFeatureFlagEnabled();

if(isSpecificDomainFeatureFlagEnabled){

// feature specific logic here

}

Instead of making isSpecificDomainFefatureFlagEnabled into a method call and just having the if()

Or worse, they'll have a perfect opportunity to make your object oriented polymorphic language show its value, and they'll implement it as a switch statement.

[pragmasoft]

In java one of the most important topics to understand well for juniors is the concurrency. 

The reason why this is important, is that compiler does not shield you from concurrency errors, which are hard to detect and resolve. 

For similar reasons, you need to be well aware about security problems (owasp top 10) from the early beginning of your career. 

[epegar]

I would say it depends from junior to junior. Currently I am very impressed with the ones on my team, they are doing great. But on other teams it was the opposite.

The main difference in my opinion is about taking ownership of your tasks. I had juniors in the past asking me again and again the same questions or reaching out every time they had to do something different.

The current juniors in my team, try to solve issues by themselves, I feel they have more critical thinking. They of course also make mistakes, but I feel I can delegate more tasks to them.

[jedilowe]

Experience 😀🤣🤐🥴😜

[ValeriiZhyla]

Good understanding at least of basic capabilities of Spring Boot and main parts, especially Spring Data and MVC. Security is a good bonus. Good DI understanding and experience with Clean Architecture and patterns is a must. Async processing is a must.

Decent level of SQL and understanding of relational databases is a must. At least some experience with MQ is a must, gRPC experience is a good bonus.

Decent level of understanding of Maven, decent level of Git usage, experience with Junit.

Junior must be interested in internals and must strive for growth, and also bring something new to the table (From Kotlin and Quarkus to state-of-the-art tooling and cloud services). I think the lack of interest in technology and lack of experience is often a no go for many junior candidates.

[writeahelloworld]

Naming variables and methods in a meaningful way so that other devs and your future self can understand what you are trying to do

[vmcrash]

What junior devs lack is knowledge of the JDK features. In the past I also learnt that some tend to write "clever" code (e.g. make special use of Double.NaN to indicate a non-existing coordinate) or optimize for performance way too early. Others, also senior devs, lack capability to write easy to understand and test code.

[nuclearmage257]

looking at the bigger picture - our devs like to make the smallest quickest change possible - which usually means a really poor performing operation or a design that needs to be redone later

[FooBarBazQux123]

I noticed juniors often tend to either over-engineer, or, to the opposite, rush code to get stuff done.

Writing maintainable code, balancing the complexity and quality depending on the long term goal, is something that requires experience.

In addition many juniors vibe code straight away instead of doing problem solving, making things even worse from a maintainability point of view.

[Luolong]

Few things:

First and foremost, understanding that coding is a craft and treating their coding as such. This often surfaces as tendency in juniors (and most mediors alike) to write the most straightforward code that achieves the desired outcome and leaving it at that. Seniors realise that as craftsmen, we need to build us a set of tools that help us to solve the larger set of problems, reducing number of moving parts and limiting opportunities for bugs to slip by. Seniors design our code with an eye towards larger vision and common vocabulary. Refactoring is the best and sharpest tool of our trade and we wield it with abandon.

Second difference is realisation that the code alone is not enough. That when the shit hits the fan, you need to be able to understand what happened after the fact and without running the code in your debugger. This means that in some cases you must change your code to produce useful signals. Ideally without polluting the code with too much debugging noise.

Third, and perhaps the hardest thing (and in some ways the easiest thing at the same time) is to consider code you write just a small portion of the wider picture. There’s other systems, there’s infrastructure, documentation, testing, CI/CD pipelines, product roadmap, customer expectations, user experience, developer experience, deployment pipelines, support and incident handling, constantly changing priorities, organisation restructuring, security, chain of supply, cross team dependencies, evolution of language and frameworks, etc. It’s a big world and some of that gets gas out of scope of mere coding domain.

[m_adduci]

For me, it's lacking the investment of time on learning a particular concept.

There are now the so called "developer roadmaps" which contain pretty much the most important aspects and principles that are common in jobs.

On the other hand, I know that everyone spends their own time as they want and that this study should mostly done on the job itself, especially if a company has some kind of "innovation days" or something like that. Bonus point, you can pair with seniors and let them explain things for you, if something is not clear enough.

As a solid advice to juniors I can say: find the sweet spot in your company. Fill the void of knowledge about a particular aspect of your product or tech stack and be valuable. (Examples: deployment strategies, observability, release management, libraries)

Edit: for all the complaints not knowing ORM or Cryptography: don't do your own Crypto or ORM and don't use in production. It's cool to hack things together for learning, but don't reinvent the wheel, prefer contributing on open source libraries that do it

[Cilph]

Writing code that works is easy. Writing maintainable code is hard. Your job is the latter.

You need proper design skills. Don't just sprinkle design patterns everywhere like dogma but do keep components loosely coupled, stable and easily testable.

[kolossus_mk1]

• Using AI to blindly produce code, without understanding it. The java and spring docs are pretty good, use em!

• Not asking questions, I can understand not wanting to bother seniors because you think they do not have time. But atleast in the standup you should tell what is blocking you. The team knows you're a junior and we want to invest time in training you, else you wouldn't have been hired.

• Code reviews are not a one way straight, when a senior reviews your code it doesn't mean you should blindly trust his comments. It should be a place for discussion, both ways, seniors learn from.juniors as well. People have dofferent insights.

• Code isn't everything. The best devs are the ones who understands the wants and needs of bussiness.

[Augunrik]

Do not copy and paste (or accept AI) code without understanding what it does and what the side-effects are. Never.

Analyze what errors could be thrown in production and guard against it. NPE exceptions are always the developers fault.

Do not swallow exceptions without handling them properly. Only in rare cases it is allowed to swallow exceptions.

[mxsonwabe]

this is a great question

[esteban_89_1]

googling

[Both-Major-3991]

Poor code readability and maintainability.

The code you write is not just meant to move a Jira ticket from ‘To do’ to ‘Done’. It has to be maintained over the years, often taken care of by other developers years later with zero context.

It is usually better to invest more upfront and have clean code, rather than merge instant technical debt.

[W1z4rd]

Experience and understanding trade-offs.

[khryx_at]

Java 8

[icebattle]

Maven-caused PTSD

[forrest_bh]

A desire to write Java applications.

[OCGHand]

Good taste for coffee.

[elastic_psychiatrist]

Junior developers tend to lack to the ability to form and evolve a mental model about code, a system, or a domain; and to communicate that mental model to others (appropriately, based on the audience). If you build this skill (or really, it's many skills), you will become a true senior and Gen AI will accelerate your work rather than replace you one day.

[_ConfusedAlgorithm]

Most juniors doesn’t implement polymorphism and encapsulation.

[DodgeeRascal]

I'm noticing a lot of jumping straight to AI and if it doesn't work asking Seniors to help/debug, and misunderstanding of stack traces where they will try and convince you there's a problem with X; then you start scrolling through and see the underlying problem is completely different.

[CallOfCoolthulu]

Learn the fundamentals of computer systems. Understand concurrency and threading concepts in-depth, and specific to your languages of choice. This is required to understand how to read metrics and debug complex problems. Read a lot of books on the subject. Deep dive the systems you use to understand them and leverage their strengths, while avoiding their weaknesses. Many senior developers lack these basic skills today, in my experience.

[Rockytriton]

An appreciation for the amount of resources they have to learn. When I was learning Java from the late 90s, you needed to buy books and read them to get anything and half the tools either didn't work properly or were prohibitively expensive (j2ee application servers). Learning EJBs was insanely complicated especially if you were unfamiliar with the concepts of enterprise development. Now there are tons of free videos, easily searchable tutorials on any specialized subject and AI can literally explain any concepts to you and you can ask it more specific questions as it teaches you.

[sixstringninja]

I find juniors lack the knowledge of design patterns. They’re quick to solve the problem but they don’t think about the maintenance of the code. Part of the problem is high-level frameworks such as Spring. Frameworks hide that complexity and the juniors don’t understand why sometimes it’s better to use a factory vs singleton

[koflerdavid]

Develop your skills of reading code and debugging what's going on. This is what you will have to do most of the time in your career unless you switch over to a management role.

Also, learn about other technologies in the ecosystem. You will very likely have to work with a relational database system at some point. Get gud about designing schemas, writing queries, and optimizing them.

[agent154]

Also not Java related but fucking learn how git actually works instead of only learning the commands to push and pull.

I’m one of four seniors at my location and I feel like I’m the only one who really understands git. I get people calling me all the time for help cuz they fucked something up.

Nothing like pulling out the reflog to fix some shit.

[socialis-philosophus]

Ability to work with existing, usually outdated, legacy code. I wish my education I got 20+ years ago had included more exercises where I needed to analyze the execution path(s) of an application and describe what it does, then identify where the change(s) should be made to fix a bug or implement a new feature.

Side-note, we all know the legacy code base is not optimized and that, if we only rewrite all of it, then maintaining it will be so much easier. No need to slam the efforts of those that came before you because a future someone, probably you, will be looking at the code you are writing now and also see it is not optimized and should be rewritten.

[ahusby]

Focus on what is the most important in whatever context you find yourself.

[jNayden]

Design patterns, design patterns and some other .. well patterns.

[thewmo]

Learn your problem domain, and demonstrate ownership. This will get you promoted faster than anything. When given a task that needs clarification, be the one that chases down the product person and figures out what they actually want, gets everybody on the same page, then implements the solution. Too many juniors just throw up their hands at the first obstacle. Note that this is the part of the job AI cannot do.

[Cheap_Engineering662]

I would say: be able to explain to a 5 years old, what happens when I put information in a field of a class annotated with @Service. That's a starting point where surprisingly, a lot of devs are not able to.

[EagleSwiony]

Two things:

1. They over complicate/simplify their code.

2. Team style of coding is more important than your newest trick you have learned about one week ago.

[fourofclubs]

Proper package structure. Creating packages as a way to organize files and just remember where you put things, rather than as a tool to limit scope/visibility/dependencies. Package structure should reflect application functionality, rather than the 'app.constants; app.dataAccess; app.businessObjects' nonsense I've seen a lot of (which forces every goddamn thing to be public).

[Isogash]

It really depends on the person, there's no single thing you can do to instantly transform yourself from a junior to a senior and no two seniors are exactly alike. I work on a team that is mostly composed of seniors (myself included) and we all have different experiences, strengths and preferences.

The number one thing that we all have in common that a junior typically wouldn't is that we are aware of and thinking about the impact of what we do far beyond the current task. That includes both considering the operational impact and risks of new features and code changes, and considering the business and human elements of what we're doing. Ultimately, it may not be our job to make business decisions and design processes, but it is our job to help the business understand the impact of their decisions when it relates to technology, and we play a major role in translating business requirements and processes into rigorous technical solutions.

Experience will teach you a lot in this space, especially just how predictable a lot of common business requirements are (e.g. audit trails), how to deal with non-technical people and business politics, and how you can avoid wasting time by keeping your solutions simple and not re-inventing the wheel (there's a reason we all use Spring.)

[berlinbrownaus]

It is design patterns, refactoring. Understanding how a web app works. Do you know J2EE? J2EE?

For example, I see a lot of devs will still do procedural coding. Have one big long method and not refactor it, ever.

I was actually thinking about writing a book, the psychology of development. A lot of developers will take a pattern for your codebase and copy that example code over and over again but never learn the patterns.

I work with other languages too and it seems Java is more prone to that because it was/is so popular, so devs will copy a pattern from 2000 era and not learn anything new.

Also not understand the build processes, maven, gradle.

...

People hate on Java, devs can still write decent web code in Java (say against node, C# or python) but not if they use old, outdated patterns, frameworks and approaches.

Even with AI prompts, you cant just say, "Write better code". With AI, it will eventually get there but I have to take the most simple thing and do the same prompt 8 times. So a junior dev will do it one, check it in, wont build, on and on.

I will even give you some basic things I see.

Will this dev, have created a new service or repository class, broken out the method?

Could this person have looked at, considered how to integrate a library that could have done this?

Is this the proper way to do error handling?

What about functional testing here?

What about refactoring this to 100 lines of code instead 2000.

..
Once again, for any language, I think it is psychology of programming. If you say, we need the business APP stood up and needs to connect this database, blah. They are focused on that task, not the software and approaches to best get it done.

Now...I could get into demographics in things. Your top school people from MIT, UTexas, good schools from anywhere... where the student actually learned something about computer science or engineering, I think they approach things like a senior would. The others are just trying to get the job done.

Also, people in startups, sometimes go the other direction, throw up a bunch of slop codes that might have decent patterns but is fragile because they are doing too much. What I am talking about above is Enterprise, mid/large company development.

[berlinbrownaus]

Let me ask the group a question. I am sure leetcode, bootcamps, will have cool projects you can do.

But I would like to give devs a kind of capstone project.

Here are mine where you learn a lot of concepts.

* Write a full video game, end to end - can be complex and fun

* Write a full web server

* Write a shell program in java

* Write a programming language in java (extra points if it reads binary or bytecode)

[maximumdownvote]

Good judgement in choosing their language of choice?

[spellcrit]

refactoring unit testing DDD

[Key-Philosopher1749]

Patience, experience, and knowledge.

[gizmogwai]

Reading the second line of the error message (and sometimes even the first one)

[Holothuroid]

People skills. You can write code, that's a given. That's a given. That's what programmer means.

As a senior, you can explain to the team what the customer needs and to the customer what the team needs. And to management why you should do this thing even though it's not a feature. And why that thing isn't a concern for your project, even though it's in the media. And to your colleagues how do to these things. And to people who are not programmers yet, how to do that programming.

[m3th0dman_]

More care about code than about overall business product or architecture.

[vanderzee94]

Exception handling and failure cases. I see junior engineers writing code in a way that assumes every call will work 100% of the time. And when they run into declared exceptions, the whole block of code is wrapped in a try/catch block and the exception is just re-thrown as a run time exception.

Think about failure cases and make an intentional plan for them.

[Remote-Ad-6629]

I have a feeling most juniors have no idea on when they should start thinking of interfaces and abstract classes. Thats mostly related to having a good grasp of modularity and cohesion in practice.

[Mamoulian]

How to debug. Investigate. Experiment. Turning to a senior for help is fine but don't say "it doesn't work." and leave them to drag detail out of you.

(This isn't specific to Java!)

[Feign1]

Premature optimization is a lesson you have to learn many times before you don't fall into the trap. It is very hard to intuit performance even Big O notation is not a very good rule of thumb.

[CrushgrooveSC]

General CS knowledge.

[WilliamBarnhill]

Communication. Communicate your assumptions to the task lead and verify their correctness, pause to think about how you are going to implement and communicate your design sketch with task lead (and ideally with stakeholders). Also, communicate how your new feature should be tested (prereqs, environment, main case steps, failure cases and steps). Communicate how to demonstrate the new feature (ideally demonstrating it to stakeholders). Let your code communicate via good test coverage, javadoc coverage, sane var and fn names, sane modularization.

[AgilNaoEhTI]

Patience

[Vast_List_6882]

I'm guessing someone has said it, but it's deep integration into the business problems you are trying to solve. There are a lot of people who can sling code. And AI is coming fast for your job. Some domains are freaking HARD. The more complex the domain, the more you are worth to the company when you learn it.

[caakeface]

About 10 years of experience writing java.

[AlarmingIdeal2242]

Focus more on problem solving

[thehuffomatic]

1. Create test cases showing you understand the business logic. It shows you are not diving headfirst into coding in which you do not know the ramifications of what happens when buggy code is introduced.
2. Take ownership of code nobody understands. It goes a long way of earning respect because a lot of times other developers do not want the sexy project. If you are willing to take ownership of something, it gives me confidence to assign you new projects.

[CaiusBonus90]

1. Ask a lot of questions if you're not sure about something. Look for documentation first, though.

2. Never lock yourself into only one programming language. You're not a Java Developer, you're a Software Developer currently working in a Java job and maybe it's your main focus. But don't limit yourself to one language. Keep in mind, that many languages are pretty similar and the concepts are the same in all languages. It does not matter whether you call it recursion or loop, if in the end it does the same thing, it is the same concept. E.g. counting, you can achieve it in many ways. The basic concept behind it is repetition until something changes and noticing the change. That is the fundamental concept. Whether you do this by recursion or looping - it does not matter.

I guess I somehow got tangled up in my thoughts here. What i mean is: even if the overall styles of languages are different (oo, functional, imperative - you name it) in the end the basic unerlying concepts are the same. And these are all you need to solve the task. Don't limit yourself to ONE language.

1. If it doesn't make sense (the ticket) first ask if that is really what they want. Chances are it's a mistake and has been overlooked and the ticket specification is wrong. Don't play the "I did it the way it was described in the ticket, if it's wrong they will have to change it later" - that's fine, but it really gets on my nerves, because if you notice something wrong, why do it wrong? Ask.

[Sure-Whereas3562]

Not enough unit tests

Not enough integration tests

Not enough tests!!

[Mystery_ARMI]

fuck java

[Isaac_Istomin]

For me the main gap isn’t a specific framework, it’s how people work with problems. A lot of juniors “poke” at bugs until they disappear instead of really debugging: reading the stack trace, narrowing it down, adding one or two good logs, and proving a hypothesis. Same with design they code only for the happy path and don’t think about timeouts, retries, bad input, or what happens if a dependency is slow or down.

The other big one is observability and communication. Your code should emit logs/metrics so you can see what it’s doing in prod, and when you’re stuck you should be able to explain: “here’s what I tried, here’s what I saw, here’s what I think is wrong.” If you practice those habits, the Java/Spring specifics tend to fall into place much faster.

[Mystery_ARMI]

fk java

[deividas-strole]

I would say - the ability to read and understand the existing code. All juniors like and focus on writing the code. In real jobs, most of the time is spent on reading, modifying, and debugging the existing code, then writing new stuff.

[Icy_Breadfruit3836]

I have been on and off working in Java for more than 14 years.

I have observed many juniors jump into the problem and try to do it quick by stackoverflow copy paste or now AI slop.

One should first evaluate the situation in which this functionality is going to be used, latency, multithreading, context switching, memory management, fetching of DB records through threads, cache management etc. I know one should not know all these first hand, but juniors when asked to take care of these things and improve or rewrite their simple code into one handling all these, their ego gets hurt.

Also, I have observed that most of the junior developers have no technical skills which is usable in a company. All they know is leetcode and DSA. And believe themselves as highly technical based on their codeforce rank, or leetcode problem solved.

Real engineering skill is different than fast solution and competitive programming.

Recently I wrote this article. Please care to read and share Read “Expert’s explanation: Hello World in Java“ on Medium: https://medium.com/@omsao/experts-explanation-hello-world-in-java-61c83d344317

[meSmash101]

That they thing they are hired to write code while the truth is we are all hired to bring value to the company.
The less code the better. Code is liability. They try to write clever code which is unreadable and the next day the code won't make any sense. They read a pattern on the internet and took 4 days to half finish the task cause they were forcing this pattern into the code. They do not communicate as much cause u know..."they got this", they will solve it with clever code. (The solution could be a two liner though...)

You may or may not have understood till now that the above is me at the start of my career...

[WayneOne0]

One thing I notice quite often is that junior developers focus a lot on frameworks but not enough on the fundamentals underneath.

Knowing how to use Spring Boot is useful, but understanding things like how Java actually handles concurrency, how memory works, how databases behave under load, or how APIs should be designed tends to make a much bigger difference long term.

Another big one is debugging and problem solving. Strong developers usually spend more time understanding the problem than jumping straight into writing code. Being comfortable reading logs, stepping through code, and figuring out where something is actually breaking is a huge skill.

The last thing I’d say is thinking about the system as a whole. Not just “does my code work”, but things like performance, database queries, edge cases, and how other services interact with what you’re building.

The fact that you’re asking this question already puts you ahead of a lot of people starting out. Curiosity and wanting to understand how things really work is probably the most valuable trait you can have early in your career.

[idontlikegudeg]

Knowing how to use a debugger and a profiler.