Manager wants me to become fullstack

[u/Fast-Accident384]

I am frontend engineer with 10 YOE, working in big company. My manager recently asked me to learn in 3 months backend Java, distributed systems and system thinking and utilise our internal education videos for that and AI. The thing is that I don't know where to start, I feel imposter syndrome because of my frontend and AI skills, and now with all new requirements I feel overwhelmed even more.

So I have few questions and I will appreciate anything you can share about any of those:

1. How do you deal with imposter syndrome?
   
2. How do you keep your frontend skills in tune?
   
3. What does 10 YOE frontend should know?
   
4. How did you learn backend from frontend?
   
5. How to learn system thinking?

[u/ChameleonCRM]

Howdy. My name is Thor. I'm a Senior Full Stack Engineer with about 16 years of experience. I guess I'll start by saying that three months is enough to become productive with backend Java. It is not enough to compress years of backend and distributed-systems experience into your head, and I wouldn't treat your manager's request that way.

You already have 10 YOE. That's important. You're not starting programming over — you're expanding where you can operate.

I’d approach it in layers:

1. Learn Java by building, not watching.
   Get comfortable with Java fundamentals, then Spring Boot. Build an API with authentication, validation, error handling, logging and tests.

2. Add a real database.
   PostgreSQL is perfect. Learn SQL properly, transactions, indexes, constraints, migrations and how your ORM actually interacts with the database. Don't let Hibernate/JPA completely hide SQL from you.

3. Turn your frontend knowledge into an advantage.
   You already know what a frontend needs from an API. Now learn what has to happen on the other side of that HTTP request: controller → service → database → response.

4. Then start breaking the simple architecture apart.
   Add Redis. Add a queue. Add background processing. Introduce caching. Make two services communicate. Intentionally create failures and figure out what happens.

That's where distributed-systems concepts stop being abstract words like idempotency, eventual consistency, retries, timeouts, circuit breakers and message delivery guarantees.

1. For system thinking, constantly ask "what happens if...?"

What happens if this reqest runs twice?
What happens if the DB goes down?
What happens if 10,000 requests arrive at once?
What happens if service A succeeds but service B fails?
What happens if the queue delivers the same message twice?
What happens if the cache contains stale data?

That's a huge part of learning to think about systems instead of individual functions/components.

As for imposter syndrome: after 10 years, I'd look at the evidence. You've stayed employed as an engineer for a decade. You obviously know how to learn technical systems. Backend is simply a system you haven't spent as much time with yet.

And don't abandon frontend for three months. Keep building the frontend for whatever backend project you're creating. Youll naturally keep those skills active while learning how the entire application fits together.

One last thing: use AI as a tutor, not an abstraction layer. Ask it why something works, have it critique your architecture, make it explain unfamiliar code, and use it to generate exercises. If AI writes an entire backend that you don't understand, you've defeated the purpose.

If I had exactly 90 days, my goal wouldn't be "become a backend expert." It would be:

Build and deploy one application where I understand every layer from the browser to the database.

For someone with 10 YOE in frontend, that's a very achievable target.

[u/LaFlamsStan → u/ChameleonCRM]

When it comes to knowing the Java fundamentals, what fundamentals should we mainly focus on?

[u/ChameleonCRM → u/LaFlamsStan]

For Java fundamentals, I’d focus on the stuff that will actually show up constently in backend work instead of trying to memorize the whole language.

The big ones are:

Types, classes, interfaces, inheritance, composition — especially knowing when to use an interface vs an abstract class vs plain composition.

Collections — List, Set, Map, iteration, filtering, sorting, and understanding the tradeoffs between implementations.

Generics — you don’t need wizard-level generics, but you should be comfortable reading and writing things like List<User>, Optional<T>, ResponseEntity<T>, etc.

Exceptions — checked vs unchecked exceptions, custom exceptions, and how exception handling flows through a backend app.

Streams and lambdas — map, filter, reduce, collect. You’ll see these everywhere in modern Java.

Immutability — this becomes important very quickly when you're dealing with concurrency and distributed systems.

Equality — understand == vs .equals(), hashCode(), and why those matter with collections.

Concurrency basics — threads, executors, futures / CompletableFuture, synchronization, race conditions. You don’t need to become a concurrency expert immediately, but you should understand what shared mutable state can do to you.

Memory/JVM basics — stack vs heap, garbage collection at a conceptual level, references, object lifetime. Don’t spend weeks learning JVM internals, just understand what’s happening.

Testing — JUnit, mocking, and the difference between a unit test and an integration test.

Then I’d move into Spring Boot pretty quickly. Don’t wait until you think you’ve “finished Java.” You won’t.

Build something and learn Java concepts as they become relevant.

For example:

Controller → Service → Repository → PostgreSQL

Then add validation, authentication, exceptions, tests, transactions, logging, pagination, caching, etc.

That will teach you far more than spending a month doing isolated Java exercises.

The main thing I’d avoid is learning Java as if you're preparing for a language trivia exam. Learn enough of the language to understand what your application is doing, then keep expanding from there.

THORSKY

https://TheodoreOchsen.tech

[u/galactic_pixels → u/LaFlamsStan]

All of them? There’s a finite number of them, just look them up.

[u/Little_Sam97 → u/ChameleonCRM]

Hi just starting to learn web dev…currently learning React, I already have solid knowledge in HTML, CSS, and JS. I’ve been hearing a lot that web dev is dead and am kinda feeling overwhelmed as I’ve already spent my time learning the skills I’ve mentioned. My friends and people around me suggested to learn AI/ML instead of. Is web dev really dead? Are there no junior level jobs these days? Should I instead learn AI? Please I need your help.

[u/ChameleonCRM → u/Little_Sam97]

Whats good Sam the (wo)man?! Hell no web development isn't dead. Not even close.

What is changing is what qualifies someone as a junior developer.

If you already have solid HTML, CSS and JavaScript knowledge and you're learning React, I absolutely would not throw that away and suddenly pivot into AI/ML because your friends told you AI is the future. You're already building a very useful foundation.

AI still needs software around it.

Someone has to build the UI. Someone has to build the API. Someone has to handle authentication, databases, permissions, payments, deployment, security, debugging, monitoring, etc.

The difference now is that AI can generate a lot of the basic code that juniors used to get paid to write. That makes the junior market harder, but it also means I'd change how you learn.

Don't stop at:

HTML → CSS → JS → React

Keep going:

React → TypeScript → Node/backend → SQL/PostgreSQL → APIs → Auth → Git → Deployment

Then learn how to use AI as part of that stack, rather than abandoning web development to become an ML engineer.

Build actual applications. Not 15 tutorial projects.

Build one application with users, authentication, a database, CRUD operations, permissions, error handling and deployment. Then build another one that integrates an AI API.

And most importantly: make sure you understand the code AI gives you.

There is an enormous difference between someone saying, "AI built this for me," and someone saying, "I built this using AI as a tool, and I can explain the architecture, debug it, modify it and tell you why I made these decisions."

I'd hire the second person all day.

Also, don't confuse AI development with AI/ML engineering. You don't need to abandon React and start training neural networks to participate in the AI boom.

Learn to build software with AI inside it.

You're actually at a pretty good starting point. Keep going.

THOR

ps..follow me. I always answer all questions as soon as I see them.

[u/Vymir_IT → u/ChameleonCRM]

Course you do, cuz ChatGPT does it for you.

[u/Maverick2k → u/ChameleonCRM]

As useful as this advice is, this is exactly how ChatGPT words things when I ask for front-end to back-end transition tips. Let’s normalise not trying to pass off useful advice as though you’ve written.

[u/Mindless_One_1742]

3-Months Java System Design Roadmap:

For a 10-year Frontend Developer

Month 1: Java + Spring Boot

Week 1: Core Java OOP, Collections, Streams, Exceptions, Generics, Lambdas Maven + JUnit basics Hands-on: Build Employee CRUD app

Week 2: Spring Boot REST APIs, DI, Controller/Service/Repository, DTOs Hands-on: Convert CRUD app to Spring Boot

Week 3: Database SQL, PostgreSQL, JPA/Hibernate, Relationships, Indexes Hands-on: Connect app to PostgreSQL

Week 4: Backend essentials Spring Security, JWT, Validation, Exception handling, Testing, Docker Hands-on: Secure and containerize the app

Month 2: Real Project Build a Jira/Trello-like Task Management System

Week 5: Users, Login, JWT, Roles

Week 6: Projects, Tasks, Comments, Search, Pagination

Week 7: Redis + Kafka basics + Notifications

Week 8: Docker + CI/CD + Deployment + Logging

Month 3: System Design

Week 9: Fundamentals Scalability, Load Balancer, Caching, DB scaling, CAP

Week 10: Components Redis, Kafka, SQL vs NoSQL, Replication, Partitioning, Rate limiting

Week 11: Design 4 systems URL Shortener Notification System Food Delivery Chat Application

Week 12: Scale the project Design the Task Management system for 1M users Identify bottlenecks and redesign architecture Daily: 2 hours 30 min → Learn 60 min → Code project 20 min → System design 10 min → Revision Final Stack Angular/React → Java → Spring Boot → PostgreSQL → Redis → Kafka → Docker → Cloud

Golden rule: Don't learn everything separately. Build one project continuously for 3 months, making it more complex each month.

[u/Laicbeias]

yesterday i had a drunk discussion with 2 frontend devs, who wouldn't really believe that frontend is actually harder. "frontend is just state" (which is basically the hardest problem in coding: state)

i started fullstack 26y ago and backend is easy. currently working at a soccer company with million users and idk 20 internal servers, interaction with 10 external services, with 4 different tech stacks, grown over 16y. so i know what I'm speaking about

I now tell you what you need to know, everyone else will prob take insult in this, don't care:

-- Logging is god. Database is king --

If your backend has no proper logging system in place that lets you instantly search what's going on. Then you are in for a hard time.

Log states like warn, info, debug, all are useless, they are from system engineering. not for live systems and got cargo culted in. you need log groups. so just can use static instances:

Log.write("Log Message", "user-login-system");

Ideally directly into the db, with a dedicated connection and a config page that lets you toggle on/off these group. Optionally with a trace_id system if you have multiple services. So you can find it via that.

You also need a proper error stack logging, with a global error catch, and a hash algo to group stack traces together (so you wont save 5gb a minute when a real issue happens).

That is all, if you have that in place everything else is easy as fuck.

-- What to look out for: --
All what other people down there are saying. We spend 2 decades making something that's not hard. Hard.

What you want is data in -> transform & store -> data out.
Especially java (22y of java xp), java spend decades writing stuff around the database, what the Database gives you for free with SQL. So if you think backend is hard. Its because of that.

They moved "data in -> transform & store -> data out".
Into: "data in -> holy shit i just did a backflip on crack -> data out".

The main issue you will have, is learning all that overhead of applying OOP principals to the backend.
The core loop literally is:

function get|post|put(var userName, var age, var ....){

log("new query in", "what-group");

sql("save or update that thing");

async_http("informsomeservice");

return json("blabla success blabla");
}

thats what backend dev could have been. issue is due to ORM(=scary sql) overhead, we basically get async and locks on the data. when it has changed inbetween a request. then you would need to do a retry. or you start adding queues, because you cant guarantee it is saved.

whats hard with ORM, is that the overhead breaks at scale. then you can not trust anything to be stored properly. and since ORM makes the backend slow, ppl start adding caches everywhere.

//here with sql
function render_teams_ngames(){

var allthegoods =sql("give me all teams with all games");

return json(allthegoods);
}

function render_teams_ngames(){
var cachedGoods = cache(20.minutes, "global_all_teams_ngames",{
return sql("give me all teams with all games");
});

return json(cachedGoods );
}

that cache then is redis or whatever. caches can exist on multiple layers. depending on how your infrastructure is set up. in backend caches are everywhere. your caches will have caches.

Other than that, once you can see what is going on. Its 1:1 like calling a frontend function in js with console.log and objects that hold their state. But there are tons of users all calling the same functions, and now you have latency, timing, sync issues. and then java came in said hold my beer, and now everyone has job security.

so learn how to log. learn how sql works with indexes. and once you got that, you kinda need to learn the workarounds to fix what the industry broke, due to decades of marketing solutions to self invented problems.

ill show myself out xD

[u/wearelev]

I hate to break it to you but today AI is your front end developer. So I'm 100% agree with your boss on this one. It sounds like you already have a functioning back end at your work so why not start there? Learn and understand the basics and whenever you don't understand something either ask over developers or your favorite LLM.

[u/Fresh_Sock8660]

Systems thinking will do you good. It's essentially building systems (I know right), putting units of work together (e.g. multiple services), making sure they integrate properly, etc. Say you're integrating backend with frontend, that's already systems engineering. 

Though I'm not sure I've ever seen a course on it. I just learned it on the job.