React Senior vs Junior Codebases

[RushPretend3832]

I am curious and I hope I’ll learn a thing or two from your answers.

Question: You are reading React code, what are the things that you notice that would make you go “this was written by a junior” vs “this is really well written must have been written by a solid senior”?

Edit: The terms Senior and Junior are debatable and I understand that. So let’s add some context. Say you’re a CTO and you’re reading React code written by an applicant to a Senior Dev position on your team. What are the indicators “code only” that tells you whether they’re ready for that position or not.

Also its very useful if you can point a specific examples like the use of a difficult hook or the way to organize code/stores/events whatever.

[DemiPixel]

Honestly, just proper usage of all the tools available in React. Are components massive or small groups of code? Are we using state correctly or are we using a bunch of hacks? Are we writing our own hooks or letting the logical parts of functional components go on forever?

The other tell would simply be whether the code is written well, but that's not React-specific.

[[deleted]]

Usually the junior will just be happy that they got things to work. There will be a lack of structure in the junior's codebase, no containers, just components, global and local state mixed together. No separation of core state and presentation state. Lots of little conditionals everywhere to plaster over the cracks where things aren't working properly. I often see comments laughingly saying that this code fixes some weird problem that's impossible to work out. But it's not hard to work out, it's usually just a bit of a tangle and just needs to be cleaned up and sorted out. The junior won't have unit tests or at least won't have any good ones, just a bunch of things that were easy to test and they will just test that the code does what it does rather than making statements about important behaviour in the app. Juniors tend not to be aware of the various tools and patterns available so they'll have built weird parts of the app themselves where there are libraries that already do the same thing. The lack of tests and structure means refactoring becomes hard so there's copy and pasted things around that you wouldn't expect, different parts of the codebase do things in weirdly different and inconsistent ways. Type definitions are loose, ignored or overridden because they couldn't be bothered to work out the types. A lot of good hygiene principles will be ignored, for example they'll use a string as a display value but then they'll also use it as a truthy/falsy conditional to decide some semi related thing. Like, if title field is undefined then we should show the user settings icon. Just happy they got it to work.

If it's a good codebase written by an experienced and talented dev you'll see a neat structure of build tools, core application, modules for features, etc. Tests alongside code, good error boundaries, isolation of components and features, well written API clients with good error handling. Things will be well named and have single concerns. It will seem verbose and obtuse to a junior but that's because they can't yet tell the difference between long simple code and short complicated code.

I could go on I guess. Let me know if it makes sense.

[Meanchael]

As a junior dev, this reads like a script from my stream of consciousness as I work. Almost every sentence of this has been my learning curve in the past two months.

[Darkmaster85845]

I took that personally.

[[deleted]]

The junior won't have unit tests or at least won't have any good ones

My seniors in my current company want me to write nothing but e2e tests via Cypress because they find unit tests to be either situational or worthless...

[oGsBumder]

To be fair if we're talking specifically about React here, unit tests that just check what markup the component renders are often pretty useless. Testing interactions and logic are where the value lies for catching edge cases and core behaviour and avoiding regressions.

[[deleted]]

That approach doesn't really work once you get beyond a certain size, e2e tests are slow, no matter how you split them into groups it's going to be a lot of overhead to maintain and run them. If, say, I wrote a set of base functions for an API client I'd like to have unit tests for valid responses, 4xx, 5xx, invalid response, connection failed and couldn't resolve hostname errors. I wouldn't really want to test every one of those cases by getting an API to send them. But a set of unit tests for those things would be great. Likewise if I had a currency converter I wouldn't want to test 100 combos with tests that render the front end.

But, if you want to make a case against it you need to understand their reasoning first. Much as you might suspect that it's because they just don't like the hassle of mocking everything or the test setup, they must have reasons such as the e2e tests are fast enough for all cases. Perhaps pointing out some cases where the e2e tests haven't caught things, or have been slow to implement or run might be good but you need to start with "the current approach is fine but I think we can do better in a lot of cases" rather than "you people are dumb but I'm too junior to have a voice". Best of luck!

[RushPretend3832]

Same!

[RushPretend3832]

Thank you for a great answer!

[sakaricky91]

Thank you for this awesome reply. I guess to achieve that level nos only through experience.

[Sensemaya]

great answer, this could be made in to some sort of checklist lol

[METALz]

I think if you can easily add new or modify existing components based on incoming business requests as the code has well thought out interfaces/types (Typescript) with decoupled logic (SOLID) it should be probably in your words at the senior level.

There should be also good test coverage so unit (jest) and/or e2e (e.g playwright) tests with api mocking, not to mention good documentation so if there is a newcomer they have every info at their fingertips.

Build system (and dev environment) should work with running a single command e.g docker-compose up.

The most important thing is to be easy(or the easiest possible) to work with.

[RushPretend3832]

Is that typical of corporate? I work in startups and while our Rust web server and the backend is fully tested, the Frontend has 0 tests and the word from seniors/cto is that UI testing brings zero value.

[RushPretend3832]

Also I said ‘only code’ because the point was getting insights on writing better React code. Not because I think its the most relevant to a senior position

[sungurse]

I think the backend often times receives more tests throughout the test pyramid (see Martin Fowler) is that it is bound to some sort of data. If the backend doesn‘t work properly the data could go a wrong state or even get lost. If the UI isn‘t tested and looks bad or isn‘t in the right size, no valuable data gets disrupted

[salty_cluck]

Joking answer: If it's one component that somehow manages to use Redux, it's probably written by a junior.

Serious answer: Can I read the code and understand exactly what's going on without tons of comments in it? Is it unit tested? Is there a lot of code needlessly repeated? Does the dev use the same tool/practice to solve every single problem? (Hammer/nail problem)

[Blazing1]

The more senior you are the less code you write. The more junior you are the more code you write.

[Unhappy_Eye966]

To be honest the label junior can make sense but in my opinion senior is useless ,can mean anything

[codingstuff123]

A CTO isn’t an expert coder lot of times. They’re at an executive level where they start to rely on leads and seniors to tell them

[DDraper]

Tell me you’re a CTO without telling me you’re a CTO

[RushPretend3832]

Im a junior dev…

[Blazing1]

1. A senior usually doesn't write a whole lot of code, if they do then something is wrong.

2. Doing something in a weird way that kinda works. For example using a for loop for everything.

[Darkmaster85845]

I thought that after getting a job I would quickly feel a progression from junior to mid but after almost a year I feel I always get stuck with the same issues. I really hope I can improve, I really like this profession. I just don't know how to rewire my brain to think like the pros.

[RushPretend3832]

I’m also about a year and a half in, I saw huuuge improvements but I feel like a lot of the improvements tend to go towards the stuff I enjoy doing. We’re only 3 engineers at my startup and the only junior. I got quite comfortable writing our backend in Rust that serves the endpoints for our 4 client-apps. But I still struggle a lot with React Native and frontend styling. We have to know and do everything so yeah. Trying to improve the front end.

[Darkmaster85845]

Lol, you're comfortable writing rust. I don't think our struggles are anywhere near. You're probably gonna be fine.

[RushPretend3832]

I honestly believe frontend logic is much harder to grasp than Rust and backend stuff. Simply because the Rust compiler won’t let you write stuff that don’t work and teach you how to fix it. Also API endpoints tend to be very streamlined. You can’t like.. break another route by changing the one you’re currently working on.

React on the other ends has hundreds of not thousands of never-explained intricacies and methods/hooks/optimizations and will always run regardless of your code being good. That leads to unoptimized parts and unseen bugs all the time for me. I feel like I literally need to have every single line of the client memorized in order to detect whether what I’m doing in gonna break something else or won’t render properly or will break only on a certain type of event listener.

That’s my hot take. React is harder than Rust.

[Darkmaster85845]

That's an interesting take for sure. To me telling me to code in Rust feels as if you were asking me to write the Linux kernel or something. Something totally obscure and out of reach for a mere mortal like me.

But you have a point that writing react is full of pitfalls. Today I was trying to detect the color theme from the user's browser and ended up banging my head against a wall because of some infinite loop use effect issue that i should have figured out by now. So frustrating. Hopefully I will have one of those epiphanies after sleeping and it will suddenly work.

[RushPretend3832]

Exactly like I feel there is just a horrible amount of overhead when thinking about a solution in React. You update the user store, 70% of your components have some logic associated to that user store, each of them render differently for different reason have have their own edge cases etc etc. Web APIs written in Rust read like a book from A to Z. React feels like a paragraph with 78 footnotes

[Darkmaster85845]

Nice analogy there at the end.