Stop Being A JR Software Engineer | Prime Reacts

Recorded live on twitch, GET IN

MY MAIN YT CHANNEL: Has well edited engineering videos

Discord

[daniel]

According to the thumbnail, the only difference between a junior and a senior developer are glasses

[EdwinMartin]

I'm a senior developer and I'm constantly learning new things. I know most seniors do. Some might not, but so are some juniors who don't like to learn new things 😉 I also think that Impostor Syndrome (it's real, look it up) is a blocker for many juniors. The most important take away from this article is: never stay longer than two years at your first company. I've seen it many times. A "junior" jumps to another company and they stopped being seen as a junior, get a nice pay rise and they're feeling more confident.

[needsloomis]

3:49 I think the real phenomenon the author is trying to articulate is that people new to a skill will cover a lot of ground learning the basics, while the senior is learning the finer points that take more time and experience to discover and understand. This learning curve creates a sort of "catch-up" effect, where a newbie may only take 2 years to cover half of the knowledge discrepancy of a 10 year senior employee.

[georgehelyar]

At my work the role profiles are clearly defined, but the gist of it is when you're a junior you need help to complete most tasks, when you're an (intermediate) engineer you can complete most tasks on your own, when you're a senior you can complete your own tasks while also helping others with theirs.

Anyone is free to pick up any task, and people are encouraged to go slightly out of their comfort zone. They might need help this time, but they will be able to do it independently next time.

I also remind juniors that experience comes from learning from failures/mistakes, and more experienced engineers got that way by making mistakes and learning from them

[FrederikSchumacher]

5:15 is where it's at for me. Wholesale agreement. Senior devs have started projects with naive assumptions, have dropped such projects and called it a learning experience, have struggled to maintain doomed and flawed projects, but also have started successful ones, experienced successful ones. Most importantly in all of this, they gathered this experience and express it in some way through idioms, prose, references, intuition, adapting(!) best practices. You don't just stop being junior after N years, or N projects. You transition to senior when the reality and consequences of your trade, tools, work have shaped you and express as general purpose competence.

[pesterenan]

I'm having a much more upfront attitude since I started watching your videos, whenever someone asks if I can do something, even if I don't know how in the moment I'll gladly accept the task and work my ass off, just get the experience. If I have problems in the way, I'll ask for help, but at least I'm trying new things, and that's what makes me love software development right now. Well, that and learning Vim motions, I use neovim, btw...

[kasper_]

Aside from the problem of determining exactly what counts as seniority, it's important to consider this distinction: There's a difference between the title "Senior Whatever" and the concept seniority. You can BS your way through a career and speedrun yourself to a title, but achieving seniority in practice cannot be cheated and will require you learn and experience the right things.

Now, I know what you're thinking. Gatekeeping seniority? Nice. No, that's not my point. I just think titles are bullshit, and the sooner you forget about them and focus on improving yourself, the better. Sure, ask around what people consider seniority and use that as a guideline on what to improve on, but don't get too caught up on getting some title.

[Psychobellic]

Yea I left my Jr position once my Sr started to "You wrote it, you manage it", also at the same time saying "Just do what I told you to, don't step outside of the guidelines I drew", fun times

[mfpears]

21:10 It's also a practice in humility. Being able to drop preconceptions and just adapt to incoming information quickly. That is a skill that all software engineering teaches.

[andrewdddo]

dude totally resonated with this - i'd consider myself a junior developer from industry standard since just starting out. I feel there's still so much more to learn through experience that I'mma work on every day!

[adriankal]

This mainly about how to look like a senior not to become one.

There are three things that matter: coding skill, environment proficiency, and communication skill. You become senior when you can use those three to solve problems. Tip: code rarely solves problems, removing code more often solves problems. Using right tools, writing a good documentation, figuring out and implementing procedures etc solves 90% of problems.

[thecyberyak]

This is encouraging. I always thought that "Seniors" were based on years experience but this sheds light on the mentality that is truly different.

[jfbarbosaboro]

Someone told me once "10 years of experience is not the same as 1 year of experience 10 times".

[GuitarWithBrett]

Great stuff. As engineering manager for over 5 years, I’ve had to train a lot of jrs how to become more sr quickly, as well as talking to srs about mentoring. I’ve realized it’s mostly about promoting exposure, challenging them with work outside their comfort zone, and pairing with Srs. The speed people do this is partly due to personality, but a lot is just showing people how to learn and gain experience faster. “apply what you learn” is great advice. I totally agree Experience is key, expertise is important but requires experience to apply it. Also, many problems aren’t solved by expertise but instead from experience. For example, how decide when and why need to roll a custom vs use a library ? How keep hard code maintainable ? .. expertise doesn’t solve these.

[thingsiplay]

Prime is not a genius. He learned and earned everything by hard work.

[Voidstroyer]

In my first job I went from a "webservices and content junior" to "webdevelopment specialist" within 1 year. I got 3 promotions "junior -> medior", "medior -> allround-ICT", and finally "allround-ICT -> webdevelopment specialist" in that year. (note that I said "in my first job" so that means I had no prior work experience at all).

I think that the title "junior developer" is more applicable to measure how long you've been in the role in that specific company. It's usually the first few months when you change jobs that you will feel like a junior. Once you know (almost) everything about the software and infrastructure that your company uses you could consider yourself intermediate. And once you start contributing in big ways you can call yourself a senior.

[im_cloudy]

Just the beginning of the video encourages people to finally start doing shit in their life.
When I was young, I've been making games, lot of games, never really finished any, but still had lot of ideas and passion to do them. Never gave up on idea. I think this is actually the best way how to become really good developer, by creating something in your free time and enjoy the fuck out of it.

[foswa]

Prime this was a great video. Thanks for this!

[peppybocan]

I would say there is a line we should consider calling people senior and when we should not. Consider Alice, Bob, Clide and David. Alice went to work for Google for 3 years, and then she went onto working for Microsoft. Bob, graduating the same uni, took a different route, Bob went the startup route, spent the same amount of time at a small startup led by people who worked at Google and Microsoft. Clide, graduated the same uni, but went to a small, established company, that was not really trying to become the next Google, money was good, and Clide had more opportunity to work on his personal projects, travelling and so on. Clide was never truly challenged and got the senior position, because he stuck around for long enough. David, the same uni, went into a hedge fund as a quant dev. raking money with big bonuses. Brilliant guy, very smart, but never got to lead a team, delivering big projects, never really dug into the software architecture.

They all have 5 years of experience. But they are all different, and they might be "senior" in their own field, e.g. Alice has a knowledge in the "web-scale" projects, Bob has a startup knowledge with amazing tutors behind him, Clide has a deep domain knowledge about the product (and its implementation) his company is selling and David has made the hedge fund tens of millions dollars, and knows how to make it rain. They are all senior enough in their own domain. Yet, they lack knowledge in one or more areas and they are not necessarily interchangeable.

Some people don't get to become senior engineers for the things they have experienced and seen, but because they were long enough at some place. This inflates the ranks of "senior" engineering. Not everybody gets to work for the top companies, and work on the hardest problems (webscale, low latency, etc) and that's why I think sometimes we have to be careful when interviewing, whether the candidate is truly senior enough. What does the company expect from a "senior" engineer differs vastly.

[doomguy]

"Experienced developers are also likely to miss important new features in languages and tools because they're just used to doing things a certain way".

I totally agree with this. This is normal human behaviour and this is to be expected. Once we establish "how things are", we become less flexable to what is possible. Which is why it is important to always challenge the facts that we know and our views on things.

An exmaple in the software development could be, for instance, that every time we learn a new language, we are bringing our experience from the previouse one and try to do things the way we already familiar with. Such as moving from Java to Python, trying to minic irreleveant patterns, or trying to make OOP in Rust