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.
@@kidmoseythat is very surprising, if this is a notable company can you name it? Such talented interns seem like they only go to notable companies. And how did you know they know more than the seasoned devs?
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.
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.
People are confusing seniority with expertise and people really shouldn't confuse the two. Often if you're senior at a company you can have picked up some expertise in the product. But being an expert is defined by merit not seniority. You've sat and worked through many iterations of this and you know a thing or two. Linus Torvalds is a Linux expert, he built the thing and kept building the thing for many years. When he says something about Linux we listen to it more than when I do. It's an expedient way to filter opinions. And yes this is explicitly an elitist opinion I hold. I struggle to understand why people think elitism is wrong. Especially in the small. I would never put some new Ubuntu user who just wrote hello world in C as a kernel maintainer.
I think this article also misses the expectation that a senior will be more mature and less likely to create a mess. They should be capable of seeing what problems and edge cases could occur before they come up, and guide things in a direction that will ensure less surprises pop up as development moves forward. This requires not just experience but also a willingness to think ahead in detail. Maturity is also about having the capability and the right attitude for figuring things out on your own in an unfamiliar area, which takes more than just expertise: I've seen people with a strong foundation of knowledge who still act like they're lost as soon as they hit a minor roadblock. And finally, there's the "soft skills" aspect of knowing when things are worth arguing for and when they aren't, and when a decision really matters and when it probably doesn't.
I have been at the company I work at for almost 7 years now. Although I would technically have seniority, someone else who only has worked for 2 + years got a managerial position. I'm not sad about it or anything. He just has the skills to be a manager more than I do. I like my position and will keep learning :). People that pull the seniority card and complain have some internal ego issues to deal with....
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...
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.
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
In my company it's different somewhat it's more about how much impact you have, you're considered a senior when you're actively involved in evangelizing and pushing new ideas throughout the company. Not just focusing on your little piece, but the whole product, across all teams. If you do that often enough then they rank you as a senior, if you're just coding in your "cog in the machine" then you're stuck permanently as an intermediate at the highest It's somewhat unfair because if you're not a very social person you kinda get shafted no matter how good you are at coding, but the logic is the most senior developers should be the ones most comfortable with debating ideas and so will make themselves known though those kinds of cross-company discussions and debates
@@liquidsnake6879 yea that's one way of doing it. The soft skills do become more important the higher up you get, no matter what. We tend to find good ways of doing things and then share them with other teams, and a senior might have to give a presentation to maybe 50 people or so. Eventually, the cross team aspect becomes more of a staff engineer thing, but how do you show that you're capable of doing that? You do it as a senior enough to get noticed.
@liquidsnake6879 I don't think it's unfair or being shafted that you never get to be a senior even if you are really good. What you describe are experts. Being senior is not only about skills. It's about mentoring/training others, take active part and contribute in meetings and decision making, think about the bigger scope, develop and spread best practice etc.
Experience doesn't stop seniors from wanting to learn new things but decades of burnout, loss of passion and golden handcuffs do. I've met plenty of seniors that are as curious and passionate as someone who is still falling in love with coding. But I've also met plenty that stopped wanting to evolve.
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.
💯 fun and passion are critical. I’m an engineering manager in my career now so don’t code much during work, but I’m still always learning all the time. Often it’s stuff not directly applicable to work. For example, lately I’ve been into learning how to make NES games. It raises so many interesting questions that I can see my work code from another angle (we use elixir, react , and a lot of other tools).
Managing your passion becomes a really easy skill to improve, but hard to catch or realize, it is something you have to improve. And managing the passion of your programmers, is also really really hard. Ideally, for a side project/personal project to work, you have to focus on small, palpable features, and keep building from it. In a videogame, I've been encountering stuff like, over-engineering my project just because I thought that would play well in the long run. Spoilers, you simply don't do any shit. So now, after learning that, I focus completely on testable features. First feature, a player that moves Later, it shoots directed towards the mouse Later, it can take damage when touching something. And so on and so forth. The easy fix, it just sounds like "avoiding over-engineering" right?, But we usually don't avoid it by accident because we don't comprehend what are the consequences. Well, the consequences are, you simply can't feel the serotonin of having your code do something. It's the same feeling with Haskell, I haven't program with Haskell just to tell you, but from experiences I've read, it seems one has to really manage Side effects in some weird way, just to finally have some functionality and receive that serotonin. But I don't know eh, maybe I'm confusing it with functional paradigm applied to another language.
@@jkf16m96 About Haskell....(we interrupt this comment section for the obligatory explanation of Haskell) All types are pure. The "main function" in other languages is an IO () Read "IO " as "An action that returns some " So you can't have: firstCharOf (readLine) (assuming firstCharOf takes a string and returns a character) Because readLine takes a string while readLine is an action returning a string... you have to do line
Agreed, debugging is the best indicator to prove (to yourself) that you know your way around the language and the tools you're using. It also shows you what you're lacking which in turn makes you better at all things involved.
Is it abnormal if a newbie fresh out of the code monkey mill (college) seems to have more of a knack for debugging than people who've been in the project you just joined (or other projects) for several years longer?
@@DefinitelyNotAMachineCultist absolutely not. Some people have better skills at figuring out patterns, some people have no sense of logic at all. Some people are able to quick maths quantum mechanics while others can't even calculate basic algebra in the head, but can still code and debug (like me). I was for example always good at everything maths that was space-related, like vectors, matrices, imaginary and complex numbers. But basic algebra and geometry I was the worst. But code and debugging, figuring out patterns, realizing what some code is doing or trying to do with executing it is where I'm the best at. The brain works in really weird ways but as far as I can tell, if you let it, it will work the way that's best for you.
@@cheebadigga4092 Makes sense. Speaking as a newbie code monkey in that position, it just seems to conflict with an idea that seems repeated often. That debugging skill seems to consistently correlate with experience. Unless fiddling with and debugging weird Linux setups for months in my college days somehow transfers over to other things. When people say experience, I guess they don't always mean experience in an official job position.
@@cheebadigga4092 A shame that experience independent of job positions or companies doesn't count for CVs where I live lol Pretty sure even freelance work counts as a red flag for some recruiters.
I've worked for one year now, and the first assignment I got (I work at a consulting company) was to join the team that took care of a 20 year old system that for the last like 5 years only been on life support. That was extremely useful because it has opened up my eyes for a bunch of problem that can emerge only years after deployment. Like production crashing because a the logging disk becomes full (it was never cleared in a decade, and no one notice because it never got full). And I've really observed how my senior colleagues work, and it's not about technology or anything like that, it's the mindset they have and what they see when they look at the same thing I look at. In meeting when we get assigned new project systems to setup, the types of questions they are immediately is the type I realise half way through coding it up. TLDR, seniors see a lot more pit falls and earlier
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.
@@sorvex9 during weekdays or weekends? This is not unusual, if you work a full time day, and the kids go to bed early, it's hard to do otherwise. If it's 1 hour on weekends too... yeah. That's a problem. :)
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.
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!
The thing is, I have no commercial experience but I’ve developed entire enterprise scale projects by myself incorporating optimal conventions, documentation, design patterns, vcs, devops, ci/cd pipeline, testing etc, so I feel slightly overqualified for junior dev jobs but I’m still gonna have to get one
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.
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.
I think it's because our field isn't as mature as other fields are, the different disciplines are only starting to be clearly defined. In the world of buildings, you would hire a senior architect that build small homes to design a dam or in medecine you wouldn't hire a senior podiatrist to be the open heart surgeon on the hospital just because he is a senior MD. I bet in a few decades there will be clearer distinctions between different jobs. there probably won't be anymore polymath software engineers that might end up doing everything.
You only view it from one perspective, meaning coding. If the only senior level problem for you is "low latency, webscale" and for example not "bring big money to company at a constant rate through investing", or "bring us a steady flow of clients for a foreseeable future" then that's a false. These are also in some sort a senior level problems but in other domains.
There is no exact definition of what a "Senior developer" exactly is. It's not possible to compare like this. Different people and different companies define it completely different.
I think Prime and Kent are talking about two different types of seniors in the intro tbh. Prime I think is talking about senior devs at places like Netflix or other tech forward companies. I started at a telecom company, and the Sr devs there were exactly like what Kent is talking about. I ran into this same mindset while interviewing at a few other places like Arris (a hardware company) and other older slower companies. That type honestly made me consider leaving the field altogether. Then I joined Meta and ran into the type of Sr devs Prime is talking about where we were constantly being challenged to try new things.
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.
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
Those arent divergent types of guidance.... One is guidance around design/architecture, another is around who is responsible for maintaining something. Every time you write something, it shouldn't whimsically become their job to maintain it for you. But as a senior resource they should be helping to determine guidelines they and team members follow...
According to some HR, Senior Developer ~ Silver Rank , they wanna find some Challenger Dev with 50 years exps and can build time machine and quantum computer in a month
It’s not about what you know. It’s not about what you’ve done before. It’s about what you do now - proactively sniffing out issues and stopping them at the design level. It’s about planning ahead to write the best code possible in your domain. And it helps to get your hand in every pie. When you’re novel to the field, get a breadth of experience across as many verticals as you can. Be able to consult on the bigger picture early, so you can build varied expertise. And voice ideas & suggestions every time. Even when you’re wrong, demonstrate you are thinking about the broader context
In my experience, there are 2 kinds of Jr Devs: people who know how to code but are never going to really get it or get good, and those who are intelligent, creative, and passionate about the work. The former should not be hired; they are all too easy to weed out in a technical interview. The latter are basically Sr Devs the day they start programming; they just don't know it yet. The labels Jr and Sr are more about a company's need to "manage a career" by promotion. Most passionate developers do not want to do anything but. They do not want to become development managers, or move into marketing, or become a director/VP. Companies do not get this. They think if you love your current position enough to reject any notion of promotion, that there is something wrong with you, and that you should be fired for having a bad attitude about your "personal growth".
I've been at my first dev job for coming up on 2 years. I'm on a tiny 3 person team, with only 1 position above me until the owner. Basically, there's no vertical movement. Because of this, I've focused almost all of my spare time on working on side projects, learning new technologies, and recently open source. I know I need a new job but it's much easier said than done. I've been applying for months now, and in the one interview I got, I built out a demo for them as an optimization for a product that they had. They loved it but decided I didn't have enough industry experience and gave me no further feedback upon inquiry. I've been applying to mostly intermediate and senior level positions, because those are where I feel I could experience the most growth, and I believe I could succeed in those positions. But I'm afraid that I may need to start applying to junior level positions instead, just to get noticed on the applications. Sorry for the rant, but advice would be appreciated.
I have this exact problem. Side projects are the only thing keeping me sane. Also thought about applying to Junior again but then thought about how many people are actually juniors vs 'mid' level and Im like 'maybe not'. Competition is super high right now, but its even higher at 'Junior' which is fucked.
I am not a web-dev. I am an educator. But I watch these ThePrimeTime videos for motivation in my career. Definitely good content that transcends the web-dev community into my field. Thanks Primeagan. LEARN, LEARN, LEARN.
I am a mid level and companies often wanted me to become senior and coworkers are asking me why I am not a senior. I am also an introvert so senior means to have more meetings, more talking, more pair programming, more human interaction... I don't want all of that. I act sometimes like a senior, but I rather stay under the radar..
Seniors are people who embrace and experiment with new things so they know when/how they work and when to use them. They level up their team through their forward thinking knowledge, and are always sharing. Seniors deeply understand the business needs and what to prioritize tasks. Seniors also are good and open to mentoring new hires and juniors so that they can excel as engineers. Seniors also are great with cross collaboration. Seniors can come into any new company, and take a few weeks to a month to understand everything and become a force at the company. It's not about knowing one particular library or framework well, it's about how well you learn and implement
just started learning programming, it is a bit overwhelming but i guess the first checkpoint is to work my a.. of to get to be a sh.. junior. thanks Prime you gave me something to aspire to become.
"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
But missing a neat little trick they could be doing is not the worst thing. There are dozens of languages and thousands of neat tricks out there. If someone doesnt learn a few of them. It's okay. Just becuase you made some cool plugin doesn't mean everyone is obligated to use it.
In a previous company, there was a senior developper who was 19. Some nerd kiddo who started coding at like 10 years old and basically when he finished high school he was already a senior programmer, he was offered a senior position out of high school, without ever being junior.
I've seen many (most?) developers never reach seniority nor expert level. They are just developers. And it's not necessarily about experience. Many (most?) people simply doesn't have the personality traits to be Senior.
Honestly... At my very first official work I already did most of the architecture work - why? Because I saw that people were annoyed by the technology needed (OSGi - and it was not a choice, because the company we integrate with needed it in their architecture that we do this way) or when someone put together project skeletons... or putting together some arcane maven stuff for a project where you feel people are exhausted from that even by seeing it. Guess what: People always like when you WORK. I also did overtime and did not care or whine, but was happy I close the gap in experience. In mid of the project I was pretty much architect on the whole bigger project, later I was training juniors and interns, later got my own team. One of the intern + later junior that I was training is also senior now there - so you can do this! What I could not really do: Become PM. I was having it as a goal and already had projects where I did huge part of that organizational roles, tender writing even, contracts, etc. Still I never got it officially and there I felt there is some "who will code if you go to management" kind of "you are too valuable as technical person" view so I feel it was more glass ceilingy for this...
A "senior" i work with got his title because he had 4 years of "coding" experience on his resume, BUT looking at the resume it was friggin medical coding for insurance! Can't program his way out of a paper bag! Titles mean nothing He's also a narcissist and the only way he hasn't been fired is because he used people. But everyone has caught on now and he's sinking quick.
I can't even get a junior job, despite designing own programming language and writing software in them. I even made a better HTML together with a rendering engine. But everyone says I need a psychiatric evaluation. I think I will write my own operating system instead.
I went from junior to senior at my company within 2 years. The advice in this article is basically exactly how i did it. Boiled down into a single sentence would be: To be moved up, move yourself up.
I couldn’t agree with the “seniority” definition more. I’ve been with my company for 5 years now and I consider myself senior because of three facets 1) general programming and infrastructure knowledge 2) business domain knowledge 3) system domain knowledge (how all of our subsystems communicate) If I entered another company, I’d drop steps 1 and 2 and just be a guy who knows how to program and understand other niches like docker and kubernetes…whilst those skills are valuable and allow you to build upon parts 2 and 3 quicker; I’d absolutely call myself a junior in a new business domain
So much depends on the person. There's a huge difference between a senior developer who entirely motivated collecting a paycheck and one who is curious about the code. What Kent is saying CAN be true of senior developers is 100% true of the senior developers who are primarily motivated by a paycheck. They won't try new things if they don't have to, because that's extra time and effort. The same can be true of junior devs who are just trying to skate by, however, most junior devs feel less secure in their jobs and are more eager to please. However, someone who is motivated by their curiosity for coding and a personal desire to learn, whether they are senior or junior, is going to experiment with new tech and new coding patterns.
Note that all these points basically carry to any job with a junior/mid/senior system. It's a bit clunky, sometimes it is used as an arbitrary way to categorize and lowball ppl on their pay or assignents, sometimes it's cleverly used to spread the work to the right people and for propper onboarding and training, ... But it all fluctuates and at the end of the day you can be in your first job and become as independent, fast, reliable and even able to teach others like a senior should in theory be able to.
Get in a team that respects you. If they don't trust you that's their problem. Some teams / CEOs / leaders / managers trust you from day one and praise your skills, and for some you're never good enough. It's possible to change someone's mind *sometimes* but not always. I don't think that seniors are afraid to learn new things. Some are, some are not. If i already found a great technique that works well for me, why change that. Not every trend is worth following. Sometimes they release new stuff and I'm the first on the hype train, because the new tool solves problems i've always had with the old one.
On the topic of new features one thing that sticks out in intermediate/junior devs is their eagerness to pull in 100 libraries to change the syntax to do some esoteric wrapping syntatic sugar nonsense because some guy on Twitter says it's the greatest thing over and it's going to change the world. Senior devs see through it and reject unnecessary crap in their bundle that unnecessarily complicates their DX for a simple syntatic sugar feature that you don't even use that often
Juniors don't realize how many companies are still doing models database first and writing their own sql queries for migrations or even running some old php madness or ajax in their code base The world is yours.
11:53 I completely agree with removing the position of architect since it leads to so many bad outcomes like lack of ownership, good theoretically but bad in practice designs and you can’t be an expert on every system.
5:56 As one of the team that has to mop up the VB6/Textfile Sync/"What the fuck is Normalization" horror that the senior "head of dev" caused (written in a time where C#, json/xml where a thing). I can tell you there are seniors that won't changes their ways unless they are forced to violently by the EOL.
i joined a company as junior dev and after about a year i got the senior title. i didn't even get a pay raise and when i asked for one, i didn't get an answer. i switched companies (to get a hefty raise) and still am a senior dev but honestly close to noone cares about your title. all they care about is what you have been able to build in the past
I’m at a company with little flexibility to get to a senior title without many years of investment. Probably won’t stay too long, but I have learned a lot. It’s an embedded role, and my day to day involves reading data sheets for our SoC, debugging our boot loader (assembly mainly), writing and debugging low-level drivers (C), etc. I’m one of 3 devs on my small team, and I’m the one most responsible for low-level changes and fixes. I found a bug in our trap table this week, which needs to be ported upstream and may be present in already shipped products. I spent a week performance testing and debugging issues with our L2 cache controller, exchanging email with our chip supplier, and prompting them to send out an updated errata sheet. Im trying to get more comfortable taking initiative on problems that I find and advocating that they are worth some investment. Does that sound like a junior embedded engineer? Probably not, but it’s fine, I’ll have some great experience and should hopefully be able to jump up to a staff or senior position next time I change jobs.
"Senior", "Junior", bah, stuff and nonsense. Back in the day my job title was "Senior Software Engineer". That after only working for two years and half that time I was involved in electronics more than the assembly language we used at the time. "Junior" = younger, "Senior" = older. These terms do no relate to how much of a software wiz you are in any particular field or in general. There is no way what you call a "senior" developer of web apps or such is going to be a senior developer of things like ship simulation or jet engine management systems. It's not all about code, languages, libraries, debugging. There is a huge amount of problem domain knowledge and experience to take into account.
In order to be seen as senior within a little over a year, there were many weekends burnt and overtime hours I put in. Mostly because there aint no one who would give you space and time to create tools you feel your platform needs. I agree that you need to do that and also pick up tasks and even ask to help with projects with more advanced features just to gain experience working through problems. But most people aren't willing to put in that much extra time. That being said, I'm pretty confident I can get someone from junior to a solid mid in 3 months. Like, enough so that given the technical direction they are mostly independent and can produce most features. You don't have to be a senior, but you most definitely should stop being a junior.
As someone with 2 months of experience it makes me happy as im really doing all this stuff! I have rhis personal project called "bunget" that's a budgeting app I'm working on, and i use it to practice things i learn on it.
You are right. There is no requirement time. But there is a flipside. Some people expect to become seniors simply because time has expired. It's like the flipside to the coin. If you can work really hard, then yeah, you could be a senior within two years. If you do the bare minimum, and ask to be made a senior because you've been a junior for two years... then no. That's not how it works.
My trick: look for things that will come up soon and preemptively find a solution, pitch it and offer to implement that for the team or even the other teams. Suddenly you find yourself in a cross-team role, responsibly for an important coming matter. Software Supply Chain Security might be one of those topics currently.
I'm a senior. Developing for over 20 years (last 15 in C# and SQL). I've used tons of languages over the years but that is my niche. In my current company my boss asked if I knew Python. I said I know about it. He asked if I'd try to fix a problem with a script than ran on the server overnight every night. I'd never seen Python code in my life I mainly was in the C type languages. Syntax confused me a little but fixed it in about 2 hours. Could have redone that as a console app in C# in about 10 minutes. Python on my hatred list made it right there beside PHP 😁
I know a "junior" dev with 30 years of experience. He knows a lot but don't care about advancing his career so he got stuck doing junior work for life.
IMO "senior" is not about development/tech skills as such but knowing the company environment (although in practice some people will get hired as seniors still). I.e. you could have a decade of experience in the tech but you don't understand the environment you can still make stupid mistakes. It's about knowing the non-documented dependencies. Practical outcome is that you can be trusted to not make a mess.
In my career, I cared a lot about quick advancement and having senior-level status as quickly as possible. It took me around 4 years despite of I didn't have any tech degree. It was a difficult time and I was fighting for more than I was able to deliver. There were even some job losses connected with this attitude. I was caring for the growth of income so, I knew what I was going into. 😁😁
The push for this kind of mindset is how companys get a senior dev while paying a junior wage. Best thing you can do as a junior dev is apply for dev roles. Once you get a dev role apply for senior dev roles. Once you get a senior dev role apply for principal dev. Doing the job of a higher rank for free is NOT a good use of your time or energy.
"If you focus on comfort you will get dispair" Because... while you are focusing on the confort YOU WANT, you are also afirming you do NOT have comfort and, therefore, emitting uncomfortable vibrations, which can lead only to more and more uncomfortable situations, which in turn begets dispair. Make sense ? The trick is thus to be aware and focus more and more on what you are ALREADY comfortable with. Enjoy it, be thankful, and the notion and feeling of comfort will grow stronger and spread into other areas of life, provided you are not qualifying them as uncomfortable anymore. Focus enhances the energy and strenghten the feelings. And absense of focus make then weaker and weaker, and in time they tend to simply vanish away. Make sense ? This is half the path. The other half I share some other time, ok ?
Minus the vibrations (may be metaphorical?), that actually makes sense. Sounds along the lines of Stoicism or Buddhism. Former seems like appreciation of the present, and latter can seem like denial of your “needs” or training yourself to better ignore them.
I am a junior developer because I am 21 and have less than 2 months experience lol. However, I'm reading DDIA and have applied that to my current full stack work. I do believe time matters, because it takes time to build meaningful experience and learn
I've never used AWS or react native before, and I've made a highly interactive mobile app for safety reporting. I'm doing cloud inference using custom docker containers in a lambda, and I'm feeding those lambdas data with an SQS. So when a report is uploaded, it is immediately uploaded in the main API lambda, and is put in the SQS for classification and embedding generation for search
I graduated and got a job. However, my coworkers are some of the smartest I’ve seen. I am working on a daemon meant for managing edge computing nodes, and I regret not taking an operating systems class in college. There is a shit ton of knowledge to learn and I think I will not escape the junior mindset until at least 2 years. On the flip side I think I’ll become a kick ass developer so I should be able to find a job easily with what I learn from this job, if I choose to leave or am fired
I was coding for a decade and then had a year and half professional experience, and yet a hiring manager still told me i was “entry level” and come back when i had 3 years of professional experience MINIMUM. Well now i have 3 years and no one will even interview me 😮💨
Imagine writing an article teaching people how to hitting mega jackpot by spouting generics advices like just believe in yourself and buy tickets constantly. You're hitting senior role in a big corp after just a short time? Good on you then.
I quit my first startup company job after 1 year to get out of the junior perception, and they for no reason, gave me the title CTO on the letter of experience
I would also advise sr not to act like jr. Doing repetitive works without thinking out of the box and automation, losing interests in learning, driven by hype instead of reason are just examples
Ambiguity around Jr./Mid/Sr./Staff/Principal seems to come down to having no growth framework with objective criteria for advancement. A Jr. Engineer may need a lot of support on small tasks. A Sr. Engineer should be able to own and drive multiple epics in their team. A Principal Engineer should be working close with Sr. Management to make systemic improvements to the organization across multiple teams (or not; depends on the organization).
Imo, seniors are more likely to consider new ideas. Juniors are more likely to follow the crowd and spend more time looking for premade solutions than just building them (leftpad), which just happens to include new things. Seniors form opinions about most new things rather quickly and don't have much interest in the majority. Most new things aren't new ideas anyway.
engineers who are set in their ways are engineers who have PTSD, and simply refuse to move on because they don't want to improve their workflow, they just want to get through the day and do something else. I wouldn't say those people are good for positions that require innovation (like new projects in big companies, or startups), they are probably good for maintenance as they are resistance to change.
Just want to ask a little question about taking job and being a junior in 2023; What is the most important knowledge a backend developer (doesn't matter is a golang or csharp or rust developer) should know? What is the most important part of the backend development every engineer always thought and including in their book? You guess it right, React. Wait what? "Why UI framework? I am backend developer/engineer. Are you talking about JavaScript or maybe Typescript?" maybe you asked for it and ıdk the answer. Go and ask to hiring managers. Spoilers: They don't know as well.
I got a degree in biotechnology because they offered me enough scholarships to turn a small profit after paying dorm rent, tuition, and fees. I took a software development course in Java one semester as an elective for fun after convincing the head of the computer science department (the professor for the class) to wave the prerequisites. There was a class project (which counted as the final exam iirc) to make a simple photo editor where you made shapes and dragged them around in layers, and we had to present our plans to the class for how we would complete the project the week after partners were assigned; as the lucky odd-one-out working solo, my presentation was the log of what I actually did + a live demo because I got the whole project done the day it was assigned. I had not used Java before that class but had a blast figuring it all out and somehow building a bug-free application that met all the requirements and bonus points without unit tests. Software engineering is a unique profession in this regard: there was no feasible way to do additional experimentation to further my knowledge and professional skills in biotech, but anyone can do any type of software development exercises/experiments they want to. (Biotech was a damnably difficult and inflexible degree to obtain -- the majority of the associates of arts degree I got in highschool did not count, and certain classes were only offered once a year rather than once a semester, so I and others in my situation ended up spending a whole 4 years getting the degree -- but there were some cool fellow honors program weirdos in that degree program, and I graduated magna cum laude before getting too burnt out, so it was on the whole not terrible.)
Addendum: out of the small handful of electives I got to take, my favorites were the biological research data analysis class where we learned to use R and the marine ecology + marine biology research methodologies classes where we went boating every other week to do real field research for the department and got to go snorkeling in the Florida Keys while staying at a research base the university had there. Those were way cooler than pipetting fluids between cell cultures and hoping to get the recipe right. Hard to screw up a semester long project of measuring fish, but it was quite easy for someone to switch out the pipettes in my lab counter space while my back was turned for a few seconds and require restarting the project we had been working on for weeks. I had to get into my senior year before I realized I strongly disliked the profession. I even tried growing plant cell cultures at home with my own makeshift protocols, but it was all wasted effort. Software is way better because you can get however much hands-on experience as you wish at your own convenience, and the stuff that works in a computer lab also works on your laptop at home.
@@Zer-ei4co the CRISPR paper came out the year we graduated. My buddy lamented that almost everything we had learned had been superceded by that one paper or would soon be obsoleted by further developments of the technology. The advent of cheap custom gene sequence printing made even more of the biotech stack we learned obsolete. Again, this compares unfavorably to software development where one can pick up a new language, framework, or paradigm in a few weeks.
@@k98killer But still very comparable to industries close to SWE like AI/ML! The world is moving at such a break neck pace, technology sweeps everything and everyone from under our feet, increasingly (seemingly exponentially) so. That means we’ll have to be even more adaptable and open to learning and open minded. But now we’re competing with AI so we’re going to have to speed up, and the collective burnout will be inevitable. Maybe everyone will stop and take a look around and realize we could be appreciating so much more and living richer by living without chasing infinite efficiency and artificial deadlines. I’m curious what’s next.
@@Zer-ei4co I went down the left-wing anarchist philosophy rabbit hole today, and they have some salient criticisms of capitalism as an ideology. "Growth for its own sake is cancer logic" is probably the most memorable quote that rings truest. It seems that the world we live in is structured based upon an unsustainable exploitation of natural resources (including people) to feed greedy egregores (they would say "the state" and "corporations", but I'm generalizing). The future seems like one in which we either restructure away from wage-slavery and growth-at-any-cost or one in which the earth dies enough to excise the cancer. We could see the emergence of library economies or a V for Vendetta type society. On the topic of AI/ML, I am currently working on an evolutionary algorithm library in Go. I have a few more kinks to work out with some basic functionality (edge cases I discovered through experimentation that were not in my unit tests), but then I will implement back propagation + quickprop, refactor to handle multiple evolutionary epochs, and make a function for evolving a neural network that applies a few rounds of quickprop/backprop before measuring fitness. The library is FOSS, but I plan to make a cross-platform desktop application and tie it into an app for fine-tuning OpenAI models.
I see a lot of people with only 2 to 3 years that feel they are senior, buy they don't contribute to projects at a senior level. Some do in as little as a year. But most I feel let off the gas or get lazy. There may not be a minimum time necessary, but I feel like many people with only a few years fall short of a senior dev contributor. I know a couple devs with just 2 or 3 years that are far more useful and insightful than devs of any tenure. But many are not.
He didn't say experienced engineers ALWAYS hesitant to try new things. You maybe not hesitant but many are. Again, normal human behaviour: being comfortable with what we have. New things start uncomfortable and one with experience needs time and enough motivation to cross that
I've worked with people who have been working in Software engineering for 10 years that I would still concider junior. No title matters. Just judge people on what you encounter in their work.
Does the concept of seniority solely apply to individuals within a professional environment, based on their professional experience? How can one achieve the status or expertise equivalent to a "senior" outside of such a setting?
Going for experience to measure "juniorism" would be a contradiction to the first statement that said no absolute time limit to when you finish being a junior, because experience is gained through time which then implies that there has to be a range where that "juniorism" happens and ends.
Senior means, you can predict your project going to fail from the beginning or if you see code from others. Senior developers have learned to avoid these train wrecks by pretending they don't understand it.
@@demonrawr4769 Not easy to explain this one. As a senior developer you have been exposed to your own projects and other teams projects that fails. Over time you learn to detect those projects that will fail so you do everything to being avoided to be assigned to it because if you do it is the end of your career. Senior developer learned to detect the golden path into a mine field. Sometimes you have to fake that you are not good enough so they choose another developer to assign to that project. How do you detect failing projects that cannot succeed from day one? Instinct.
So what do you do when the company you’re working for keeps that Senior title gated by years of experience? Im a little over 2 years in (no professional experience before this job) and I feel like I anticipate problems - and their solutions - well before many of the ‘Senior’ level devs I work with on a daily basis, in fact I end up in almost every architectural design meeting so they can get my input. But I’m essentially getting “oh it’s just a title, we already view you like one of the seniors” / “it’s been a tight year, the company just can’t afford to give out promotions right now” type response to my requests for getting that Senior promotion I feel like I’m qualified for.
I aint stoppin nothin
Hell yeah, my man 😎
Momma ain't raise no quitter
😂😂😂
Yeah, I never :q
Yeah baby lets get it
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.
@@kidmoseythat is very surprising, if this is a notable company can you name it? Such talented interns seem like they only go to notable companies. And how did you know they know more than the seasoned devs?
Well.. there is always at least one imposter among us
amongus @@doomguy6296
100 % true. 2 years in first company is maxiumum
Maybe switching up your team is enough
According to the thumbnail, the only difference between a junior and a senior developer are glasses
Wear glasses for a 50% pay rise.
CTO: wears contact lenses
also stroke color
well obv when you damage your flippin' eyes for years coding, u'll be wearing glasses when senior
Java Senior Devs wear glasses because they can't C#
*bud dum tiss*
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.
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.
People are confusing seniority with expertise and people really shouldn't confuse the two. Often if you're senior at a company you can have picked up some expertise in the product. But being an expert is defined by merit not seniority. You've sat and worked through many iterations of this and you know a thing or two.
Linus Torvalds is a Linux expert, he built the thing and kept building the thing for many years. When he says something about Linux we listen to it more than when I do. It's an expedient way to filter opinions. And yes this is explicitly an elitist opinion I hold. I struggle to understand why people think elitism is wrong. Especially in the small. I would never put some new Ubuntu user who just wrote hello world in C as a kernel maintainer.
Yep.
I think this article also misses the expectation that a senior will be more mature and less likely to create a mess. They should be capable of seeing what problems and edge cases could occur before they come up, and guide things in a direction that will ensure less surprises pop up as development moves forward. This requires not just experience but also a willingness to think ahead in detail. Maturity is also about having the capability and the right attitude for figuring things out on your own in an unfamiliar area, which takes more than just expertise: I've seen people with a strong foundation of knowledge who still act like they're lost as soon as they hit a minor roadblock. And finally, there's the "soft skills" aspect of knowing when things are worth arguing for and when they aren't, and when a decision really matters and when it probably doesn't.
I have been at the company I work at for almost 7 years now. Although I would technically have seniority, someone else who only has worked for 2 + years got a managerial position. I'm not sad about it or anything. He just has the skills to be a manager more than I do. I like my position and will keep learning :). People that pull the seniority card and complain have some internal ego issues to deal with....
yea, another difference is salary & what u actually do on the job
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...
This is the way
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.
It's the law of diminished returns.
I think there is a very wide application of the term "newbie gains" but it's only really described as a thing in muscle building. Totally agree.
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
In my company it's different somewhat it's more about how much impact you have, you're considered a senior when you're actively involved in evangelizing and pushing new ideas throughout the company. Not just focusing on your little piece, but the whole product, across all teams. If you do that often enough then they rank you as a senior, if you're just coding in your "cog in the machine" then you're stuck permanently as an intermediate at the highest
It's somewhat unfair because if you're not a very social person you kinda get shafted no matter how good you are at coding, but the logic is the most senior developers should be the ones most comfortable with debating ideas and so will make themselves known though those kinds of cross-company discussions and debates
@@liquidsnake6879 yea that's one way of doing it. The soft skills do become more important the higher up you get, no matter what. We tend to find good ways of doing things and then share them with other teams, and a senior might have to give a presentation to maybe 50 people or so. Eventually, the cross team aspect becomes more of a staff engineer thing, but how do you show that you're capable of doing that? You do it as a senior enough to get noticed.
@liquidsnake6879 I don't think it's unfair or being shafted that you never get to be a senior even if you are really good. What you describe are experts. Being senior is not only about skills. It's about mentoring/training others, take active part and contribute in meetings and decision making, think about the bigger scope, develop and spread best practice etc.
Experience doesn't stop seniors from wanting to learn new things but decades of burnout, loss of passion and golden handcuffs do. I've met plenty of seniors that are as curious and passionate as someone who is still falling in love with coding. But I've also met plenty that stopped wanting to evolve.
Someone told me once "10 years of experience is not the same as 1 year of experience 10 times".
Amen brother
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.
💯 fun and passion are critical. I’m an engineering manager in my career now so don’t code much during work, but I’m still always learning all the time. Often it’s stuff not directly applicable to work. For example, lately I’ve been into learning how to make NES games. It raises so many interesting questions that I can see my work code from another angle (we use elixir, react , and a lot of other tools).
Managing your passion becomes a really easy skill to improve, but hard to catch or realize, it is something you have to improve.
And managing the passion of your programmers, is also really really hard.
Ideally, for a side project/personal project to work, you have to focus on small, palpable features, and keep building from it.
In a videogame, I've been encountering stuff like, over-engineering my project just because I thought that would play well in the long run.
Spoilers, you simply don't do any shit.
So now, after learning that, I focus completely on testable features.
First feature, a player that moves
Later, it shoots directed towards the mouse
Later, it can take damage when touching something.
And so on and so forth.
The easy fix, it just sounds like "avoiding over-engineering" right?, But we usually don't avoid it by accident because we don't comprehend what are the consequences.
Well, the consequences are, you simply can't feel the serotonin of having your code do something.
It's the same feeling with Haskell, I haven't program with Haskell just to tell you, but from experiences I've read, it seems one has to really manage Side effects in some weird way, just to finally have some functionality and receive that serotonin.
But I don't know eh, maybe I'm confusing it with functional paradigm applied to another language.
@@jkf16m96
About Haskell....(we interrupt this comment section for the obligatory explanation of Haskell)
All types are pure.
The "main function" in other languages is an IO ()
Read "IO " as "An action that returns some "
So you can't have:
firstCharOf (readLine)
(assuming firstCharOf takes a string and returns a character)
Because readLine takes a string while readLine is an action returning a string...
you have to do
line
Agreed, debugging is the best indicator to prove (to yourself) that you know your way around the language and the tools you're using. It also shows you what you're lacking which in turn makes you better at all things involved.
Is it abnormal if a newbie fresh out of the code monkey mill (college) seems to have more of a knack for debugging than people who've been in the project you just joined (or other projects) for several years longer?
@@DefinitelyNotAMachineCultist absolutely not. Some people have better skills at figuring out patterns, some people have no sense of logic at all. Some people are able to quick maths quantum mechanics while others can't even calculate basic algebra in the head, but can still code and debug (like me). I was for example always good at everything maths that was space-related, like vectors, matrices, imaginary and complex numbers. But basic algebra and geometry I was the worst. But code and debugging, figuring out patterns, realizing what some code is doing or trying to do with executing it is where I'm the best at. The brain works in really weird ways but as far as I can tell, if you let it, it will work the way that's best for you.
@@cheebadigga4092 Makes sense. Speaking as a newbie code monkey in that position, it just seems to conflict with an idea that seems repeated often.
That debugging skill seems to consistently correlate with experience.
Unless fiddling with and debugging weird Linux setups for months in my college days somehow transfers over to other things.
When people say experience, I guess they don't always mean experience in an official job position.
@@DefinitelyNotAMachineCultist in my opinion experience should be independent of job positions or companies.
@@cheebadigga4092 A shame that experience independent of job positions or companies doesn't count for CVs where I live lol
Pretty sure even freelance work counts as a red flag for some recruiters.
I've worked for one year now, and the first assignment I got (I work at a consulting company) was to join the team that took care of a 20 year old system that for the last like 5 years only been on life support. That was extremely useful because it has opened up my eyes for a bunch of problem that can emerge only years after deployment. Like production crashing because a the logging disk becomes full (it was never cleared in a decade, and no one notice because it never got full). And I've really observed how my senior colleagues work, and it's not about technology or anything like that, it's the mindset they have and what they see when they look at the same thing I look at. In meeting when we get assigned new project systems to setup, the types of questions they are immediately is the type I realise half way through coding it up.
TLDR, seniors see a lot more pit falls and earlier
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.
Prime is not a genius. He learned and earned everything by hard work.
Through hard work, he has realized much of his potential, yes. I think he also started with greater potential than many others.
Now evaluate race and IQ.@@steamer2k319
He works too hard, in a video he said he only allocated like 1 hour to his kids every day. I don't think that's good for either.
@@sorvex9 during weekdays or weekends? This is not unusual, if you work a full time day, and the kids go to bed early, it's hard to do otherwise. If it's 1 hour on weekends too... yeah. That's a problem. :)
señor gen*
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.
Bs
This is encouraging. I always thought that "Seniors" were based on years experience but this sheds light on the mentality that is truly different.
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!
The thing is, I have no commercial experience but I’ve developed entire enterprise scale projects by myself incorporating optimal conventions, documentation, design patterns, vcs, devops, ci/cd pipeline, testing etc, so I feel slightly overqualified for junior dev jobs but I’m still gonna have to get one
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.
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.
This is it
I think it's because our field isn't as mature as other fields are, the different disciplines are only starting to be clearly defined. In the world of buildings, you would hire a senior architect that build small homes to design a dam or in medecine you wouldn't hire a senior podiatrist to be the open heart surgeon on the hospital just because he is a senior MD.
I bet in a few decades there will be clearer distinctions between different jobs. there probably won't be anymore polymath software engineers that might end up doing everything.
Good example.
You only view it from one perspective, meaning coding. If the only senior level problem for you is "low latency, webscale" and for example not "bring big money to company at a constant rate through investing", or "bring us a steady flow of clients for a foreseeable future" then that's a false. These are also in some sort a senior level problems but in other domains.
There is no exact definition of what a "Senior developer" exactly is. It's not possible to compare like this. Different people and different companies define it completely different.
I think Prime and Kent are talking about two different types of seniors in the intro tbh. Prime I think is talking about senior devs at places like Netflix or other tech forward companies. I started at a telecom company, and the Sr devs there were exactly like what Kent is talking about. I ran into this same mindset while interviewing at a few other places like Arris (a hardware company) and other older slower companies. That type honestly made me consider leaving the field altogether. Then I joined Meta and ran into the type of Sr devs Prime is talking about where we were constantly being challenged to try new things.
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.
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
Sounds like a dickface
perfect time to hop
Those arent divergent types of guidance.... One is guidance around design/architecture, another is around who is responsible for maintaining something. Every time you write something, it shouldn't whimsically become their job to maintain it for you. But as a senior resource they should be helping to determine guidelines they and team members follow...
According to some HR, Senior Developer ~ Silver Rank , they wanna find some Challenger Dev with 50 years exps and can build time machine and quantum computer in a month
It’s not about what you know. It’s not about what you’ve done before. It’s about what you do now - proactively sniffing out issues and stopping them at the design level. It’s about planning ahead to write the best code possible in your domain. And it helps to get your hand in every pie. When you’re novel to the field, get a breadth of experience across as many verticals as you can. Be able to consult on the bigger picture early, so you can build varied expertise. And voice ideas & suggestions every time. Even when you’re wrong, demonstrate you are thinking about the broader context
In my experience, there are 2 kinds of Jr Devs: people who know how to code but are never going to really get it or get good, and those who are intelligent, creative, and passionate about the work. The former should not be hired; they are all too easy to weed out in a technical interview. The latter are basically Sr Devs the day they start programming; they just don't know it yet. The labels Jr and Sr are more about a company's need to "manage a career" by promotion. Most passionate developers do not want to do anything but. They do not want to become development managers, or move into marketing, or become a director/VP. Companies do not get this. They think if you love your current position enough to reject any notion of promotion, that there is something wrong with you, and that you should be fired for having a bad attitude about your "personal growth".
I've been at my first dev job for coming up on 2 years. I'm on a tiny 3 person team, with only 1 position above me until the owner. Basically, there's no vertical movement. Because of this, I've focused almost all of my spare time on working on side projects, learning new technologies, and recently open source. I know I need a new job but it's much easier said than done. I've been applying for months now, and in the one interview I got, I built out a demo for them as an optimization for a product that they had. They loved it but decided I didn't have enough industry experience and gave me no further feedback upon inquiry. I've been applying to mostly intermediate and senior level positions, because those are where I feel I could experience the most growth, and I believe I could succeed in those positions. But I'm afraid that I may need to start applying to junior level positions instead, just to get noticed on the applications. Sorry for the rant, but advice would be appreciated.
Luck plays a role here, I had 2 years hard time to get into the profession. But at home I kept my knowledge sharp.
I have this exact problem. Side projects are the only thing keeping me sane.
Also thought about applying to Junior again but then thought about how many people are actually juniors vs 'mid' level and Im like 'maybe not'.
Competition is super high right now, but its even higher at 'Junior' which is fucked.
@@QCAlpha-212 It will become better in the next year(s). You only lose when you give up.
Network, network, network. Applying online is really tough
@colefrankenhoff1428 good point. Thanks for the advice!
I am not a web-dev. I am an educator. But I watch these ThePrimeTime videos for motivation in my career. Definitely good content that transcends the web-dev community into my field. Thanks Primeagan. LEARN, LEARN, LEARN.
I am a mid level and companies often wanted me to become senior and coworkers are asking me why I am not a senior.
I am also an introvert so senior means to have more meetings, more talking, more pair programming, more human interaction... I don't want all of that.
I act sometimes like a senior, but I rather stay under the radar..
Seniors are people who embrace and experiment with new things so they know when/how they work and when to use them. They level up their team through their forward thinking knowledge, and are always sharing. Seniors deeply understand the business needs and what to prioritize tasks. Seniors also are good and open to mentoring new hires and juniors so that they can excel as engineers. Seniors also are great with cross collaboration. Seniors can come into any new company, and take a few weeks to a month to understand everything and become a force at the company. It's not about knowing one particular library or framework well, it's about how well you learn and implement
"enteral junior situation", said by person who has been software engineer for a year and a half.
just started learning programming, it is a bit overwhelming but i guess the first checkpoint is to work my a.. of to get to be a sh.. junior. thanks Prime you gave me something to aspire to become.
"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
But missing a neat little trick they could be doing is not the worst thing. There are dozens of languages and thousands of neat tricks out there. If someone doesnt learn a few of them. It's okay. Just becuase you made some cool plugin doesn't mean everyone is obligated to use it.
In a previous company, there was a senior developper who was 19. Some nerd kiddo who started coding at like 10 years old and basically when he finished high school he was already a senior programmer, he was offered a senior position out of high school, without ever being junior.
Well he was a Junior when he was 10 lmao. No-one is born a Neovim god.
6:50 This is very common in old projects, especially in languages with terrible tooling like c/c++.
I've seen many (most?) developers never reach seniority nor expert level. They are just developers. And it's not necessarily about experience. Many (most?) people simply doesn't have the personality traits to be Senior.
Honestly... At my very first official work I already did most of the architecture work - why? Because I saw that people were annoyed by the technology needed (OSGi - and it was not a choice, because the company we integrate with needed it in their architecture that we do this way) or when someone put together project skeletons... or putting together some arcane maven stuff for a project where you feel people are exhausted from that even by seeing it.
Guess what: People always like when you WORK. I also did overtime and did not care or whine, but was happy I close the gap in experience. In mid of the project I was pretty much architect on the whole bigger project, later I was training juniors and interns, later got my own team.
One of the intern + later junior that I was training is also senior now there - so you can do this!
What I could not really do: Become PM. I was having it as a goal and already had projects where I did huge part of that organizational roles, tender writing even, contracts, etc. Still I never got it officially and there I felt there is some "who will code if you go to management" kind of "you are too valuable as technical person" view so I feel it was more glass ceilingy for this...
A "senior" i work with got his title because he had 4 years of "coding" experience on his resume, BUT looking at the resume it was friggin medical coding for insurance! Can't program his way out of a paper bag! Titles mean nothing
He's also a narcissist and the only way he hasn't been fired is because he used people. But everyone has caught on now and he's sinking quick.
I am at a company where the seniors are so bad that I had to steer the ship as a junior software developer.
Don't consider that myself anymore.
I can't even get a junior job, despite designing own programming language and writing software in them. I even made a better HTML together with a rendering engine. But everyone says I need a psychiatric evaluation. I think I will write my own operating system instead.
I went from junior to senior at my company within 2 years. The advice in this article is basically exactly how i did it. Boiled down into a single sentence would be:
To be moved up, move yourself up.
I couldn’t agree with the “seniority” definition more. I’ve been with my company for 5 years now and I consider myself senior because of three facets
1) general programming and infrastructure knowledge
2) business domain knowledge
3) system domain knowledge (how all of our subsystems communicate)
If I entered another company, I’d drop steps 1 and 2 and just be a guy who knows how to program and understand other niches like docker and kubernetes…whilst those skills are valuable and allow you to build upon parts 2 and 3 quicker; I’d absolutely call myself a junior in a new business domain
So much depends on the person. There's a huge difference between a senior developer who entirely motivated collecting a paycheck and one who is curious about the code. What Kent is saying CAN be true of senior developers is 100% true of the senior developers who are primarily motivated by a paycheck. They won't try new things if they don't have to, because that's extra time and effort. The same can be true of junior devs who are just trying to skate by, however, most junior devs feel less secure in their jobs and are more eager to please.
However, someone who is motivated by their curiosity for coding and a personal desire to learn, whether they are senior or junior, is going to experiment with new tech and new coding patterns.
"brown bag lunch meeting" just sounds like forcing your coworkers to work through lunch...
oof.. this senior description fits me so well after this.. on top of that I even fix and report random bugs I encounter in the wild west of GitHub.
Senior means: Your colleagues and bosses think you are a mad man when you see things no other one sees.
being Senior is the same as being Wise. its your ability to recall your experiences and be able to avoid problems that have yet to happen.
Note that all these points basically carry to any job with a junior/mid/senior system. It's a bit clunky, sometimes it is used as an arbitrary way to categorize and lowball ppl on their pay or assignents, sometimes it's cleverly used to spread the work to the right people and for propper onboarding and training, ... But it all fluctuates and at the end of the day you can be in your first job and become as independent, fast, reliable and even able to teach others like a senior should in theory be able to.
Get in a team that respects you. If they don't trust you that's their problem.
Some teams / CEOs / leaders / managers trust you from day one and praise your skills, and for some you're never good enough.
It's possible to change someone's mind *sometimes* but not always.
I don't think that seniors are afraid to learn new things. Some are, some are not.
If i already found a great technique that works well for me, why change that.
Not every trend is worth following.
Sometimes they release new stuff and I'm the first on the hype train, because the new tool solves problems i've always had with the old one.
On the topic of new features one thing that sticks out in intermediate/junior devs is their eagerness to pull in 100 libraries to change the syntax to do some esoteric wrapping syntatic sugar nonsense because some guy on Twitter says it's the greatest thing over and it's going to change the world.
Senior devs see through it and reject unnecessary crap in their bundle that unnecessarily complicates their DX for a simple syntatic sugar feature that you don't even use that often
You absolutely do not need to speak at conferences and meetups as a junior in your first year, that's insane talk.
Juniors don't realize how many companies are still doing models database first and writing their own sql queries for migrations or even running some old php madness or ajax in their code base
The world is yours.
This is why it's best to take "any" job and get a year or two of experience and then jump to a conpany you really want to work for
11:53 I completely agree with removing the position of architect since it leads to so many bad outcomes like lack of ownership, good theoretically but bad in practice designs and you can’t be an expert on every system.
“Sr Dev: someone who can take a Jr to Medior to Sr.” - an add-on to all the stuff that Prime already mentioned.
5:56 As one of the team that has to mop up the VB6/Textfile Sync/"What the fuck is Normalization" horror that the senior "head of dev" caused (written in a time where C#, json/xml where a thing). I can tell you there are seniors that won't changes their ways unless they are forced to violently by the EOL.
i joined a company as junior dev and after about a year i got the senior title. i didn't even get a pay raise and when i asked for one, i didn't get an answer. i switched companies (to get a hefty raise) and still am a senior dev but honestly close to noone cares about your title. all they care about is what you have been able to build in the past
I’m at a company with little flexibility to get to a senior title without many years of investment. Probably won’t stay too long, but I have learned a lot. It’s an embedded role, and my day to day involves reading data sheets for our SoC, debugging our boot loader (assembly mainly), writing and debugging low-level drivers (C), etc. I’m one of 3 devs on my small team, and I’m the one most responsible for low-level changes and fixes. I found a bug in our trap table this week, which needs to be ported upstream and may be present in already shipped products. I spent a week performance testing and debugging issues with our L2 cache controller, exchanging email with our chip supplier, and prompting them to send out an updated errata sheet. Im trying to get more comfortable taking initiative on problems that I find and advocating that they are worth some investment.
Does that sound like a junior embedded engineer? Probably not, but it’s fine, I’ll have some great experience and should hopefully be able to jump up to a staff or senior position next time I change jobs.
I started learning GoLang and I started using NeoVim
Left the JS/TS (but my job requires it so need to do that, trust me I can't escape it)
that's so true, btw using Vim instantly made me Senior dev skipping Junior and Middle positions EZ
"Perception is 9/10's of the law" yup
"Senior", "Junior", bah, stuff and nonsense. Back in the day my job title was "Senior Software Engineer". That after only working for two years and half that time I was involved in electronics more than the assembly language we used at the time. "Junior" = younger, "Senior" = older. These terms do no relate to how much of a software wiz you are in any particular field or in general. There is no way what you call a "senior" developer of web apps or such is going to be a senior developer of things like ship simulation or jet engine management systems. It's not all about code, languages, libraries, debugging. There is a huge amount of problem domain knowledge and experience to take into account.
In order to be seen as senior within a little over a year, there were many weekends burnt and overtime hours I put in. Mostly because there aint no one who would give you space and time to create tools you feel your platform needs.
I agree that you need to do that and also pick up tasks and even ask to help with projects with more advanced features just to gain experience working through problems. But most people aren't willing to put in that much extra time.
That being said, I'm pretty confident I can get someone from junior to a solid mid in 3 months. Like, enough so that given the technical direction they are mostly independent and can produce most features. You don't have to be a senior, but you most definitely should stop being a junior.
As someone with 2 months of experience it makes me happy as im really doing all this stuff! I have rhis personal project called "bunget" that's a budgeting app I'm working on, and i use it to practice things i learn on it.
After quite shitty day at work (2yr java dev) that made me doubt in my abilities, that's the video I needed.
You are right. There is no requirement time. But there is a flipside. Some people expect to become seniors simply because time has expired. It's like the flipside to the coin.
If you can work really hard, then yeah, you could be a senior within two years. If you do the bare minimum, and ask to be made a senior because you've been a junior for two years... then no. That's not how it works.
My trick: look for things that will come up soon and preemptively find a solution, pitch it and offer to implement that for the team or even the other teams. Suddenly you find yourself in a cross-team role, responsibly for an important coming matter. Software Supply Chain Security might be one of those topics currently.
I'm a senior. Developing for over 20 years (last 15 in C# and SQL). I've used tons of languages over the years but that is my niche. In my current company my boss asked if I knew Python. I said I know about it. He asked if I'd try to fix a problem with a script than ran on the server overnight every night. I'd never seen Python code in my life I mainly was in the C type languages. Syntax confused me a little but fixed it in about 2 hours. Could have redone that as a console app in C# in about 10 minutes. Python on my hatred list made it right there beside PHP 😁
Prime this was a great video. Thanks for this!
4:30 not all water moves at the same speed. It'd fast in the middle, it can be slow in the outer fringes. Just barely trying. Just enough to get by
I know a "junior" dev with 30 years of experience. He knows a lot but don't care about advancing his career so he got stuck doing junior work for life.
Sometimes people just don't want the extra stress of responsibility. Work life balance is more important
IMO "senior" is not about development/tech skills as such but knowing the company environment (although in practice some people will get hired as seniors still). I.e. you could have a decade of experience in the tech but you don't understand the environment you can still make stupid mistakes. It's about knowing the non-documented dependencies. Practical outcome is that you can be trusted to not make a mess.
In my career, I cared a lot about quick advancement and having senior-level status as quickly as possible. It took me around 4 years despite of I didn't have any tech degree. It was a difficult time and I was fighting for more than I was able to deliver. There were even some job losses connected with this attitude. I was caring for the growth of income so, I knew what I was going into. 😁😁
The push for this kind of mindset is how companys get a senior dev while paying a junior wage. Best thing you can do as a junior dev is apply for dev roles. Once you get a dev role apply for senior dev roles. Once you get a senior dev role apply for principal dev. Doing the job of a higher rank for free is NOT a good use of your time or energy.
that's why people who get promoted usually have some relationship with their superior and that's how they are promoted.
"If you focus on comfort you will get dispair" Because... while you are focusing on the confort YOU WANT, you are also afirming you do NOT have comfort and, therefore, emitting uncomfortable vibrations, which can lead only to more and more uncomfortable situations, which in turn begets dispair. Make sense ?
The trick is thus to be aware and focus more and more on what you are ALREADY comfortable with. Enjoy it, be thankful, and the notion and feeling of comfort will grow stronger and spread into other areas of life, provided you are not qualifying them as uncomfortable anymore. Focus enhances the energy and strenghten the feelings. And absense of focus make then weaker and weaker, and in time they tend to simply vanish away. Make sense ?
This is half the path. The other half I share some other time, ok ?
please, no need, at least for me. i certainly do not subscribe to this type of thinking
Minus the vibrations (may be metaphorical?), that actually makes sense. Sounds along the lines of Stoicism or Buddhism. Former seems like appreciation of the present, and latter can seem like denial of your “needs” or training yourself to better ignore them.
I am a junior developer because I am 21 and have less than 2 months experience lol. However, I'm reading DDIA and have applied that to my current full stack work. I do believe time matters, because it takes time to build meaningful experience and learn
I've never used AWS or react native before, and I've made a highly interactive mobile app for safety reporting. I'm doing cloud inference using custom docker containers in a lambda, and I'm feeding those lambdas data with an SQS. So when a report is uploaded, it is immediately uploaded in the main API lambda, and is put in the SQS for classification and embedding generation for search
@@blackbriarmead1966 that's good, did you get a degree or are you a self taught developer, to get a job so early?
@@joesuss4669 I'm working on a CS degree rn
I graduated and got a job. However, my coworkers are some of the smartest I’ve seen. I am working on a daemon meant for managing edge computing nodes, and I regret not taking an operating systems class in college. There is a shit ton of knowledge to learn and I think I will not escape the junior mindset until at least 2 years. On the flip side I think I’ll become a kick ass developer so I should be able to find a job easily with what I learn from this job, if I choose to leave or am fired
I was coding for a decade and then had a year and half professional experience, and yet a hiring manager still told me i was “entry level” and come back when i had 3 years of professional experience MINIMUM. Well now i have 3 years and no one will even interview me 😮💨
Imagine writing an article teaching people how to hitting mega jackpot by spouting generics advices like just believe in yourself and buy tickets constantly. You're hitting senior role in a big corp after just a short time? Good on you then.
Thiiiiis is the gooood content right here.
thanks prime , needed this overview today.
++good review.
I quit my first startup company job after 1 year to get out of the junior perception, and they for no reason, gave me the title CTO on the letter of experience
😢
I would also advise sr not to act like jr. Doing repetitive works without thinking out of the box and automation, losing interests in learning, driven by hype instead of reason are just examples
Ambiguity around Jr./Mid/Sr./Staff/Principal seems to come down to having no growth framework with objective criteria for advancement. A Jr. Engineer may need a lot of support on small tasks. A Sr. Engineer should be able to own and drive multiple epics in their team. A Principal Engineer should be working close with Sr. Management to make systemic improvements to the organization across multiple teams (or not; depends on the organization).
Imo, seniors are more likely to consider new ideas. Juniors are more likely to follow the crowd and spend more time looking for premade solutions than just building them (leftpad), which just happens to include new things. Seniors form opinions about most new things rather quickly and don't have much interest in the majority. Most new things aren't new ideas anyway.
engineers who are set in their ways are engineers who have PTSD, and simply refuse to move on because they don't want to improve their workflow, they just want to get through the day and do something else. I wouldn't say those people are good for positions that require innovation (like new projects in big companies, or startups), they are probably good for maintenance as they are resistance to change.
Just want to ask a little question about taking job and being a junior in 2023; What is the most important knowledge a backend developer (doesn't matter is a golang or csharp or rust developer) should know? What is the most important part of the backend development every engineer always thought and including in their book? You guess it right, React. Wait what? "Why UI framework? I am backend developer/engineer. Are you talking about JavaScript or maybe Typescript?" maybe you asked for it and ıdk the answer. Go and ask to hiring managers. Spoilers: They don't know as well.
I got a degree in biotechnology because they offered me enough scholarships to turn a small profit after paying dorm rent, tuition, and fees. I took a software development course in Java one semester as an elective for fun after convincing the head of the computer science department (the professor for the class) to wave the prerequisites. There was a class project (which counted as the final exam iirc) to make a simple photo editor where you made shapes and dragged them around in layers, and we had to present our plans to the class for how we would complete the project the week after partners were assigned; as the lucky odd-one-out working solo, my presentation was the log of what I actually did + a live demo because I got the whole project done the day it was assigned. I had not used Java before that class but had a blast figuring it all out and somehow building a bug-free application that met all the requirements and bonus points without unit tests. Software engineering is a unique profession in this regard: there was no feasible way to do additional experimentation to further my knowledge and professional skills in biotech, but anyone can do any type of software development exercises/experiments they want to. (Biotech was a damnably difficult and inflexible degree to obtain -- the majority of the associates of arts degree I got in highschool did not count, and certain classes were only offered once a year rather than once a semester, so I and others in my situation ended up spending a whole 4 years getting the degree -- but there were some cool fellow honors program weirdos in that degree program, and I graduated magna cum laude before getting too burnt out, so it was on the whole not terrible.)
Addendum: out of the small handful of electives I got to take, my favorites were the biological research data analysis class where we learned to use R and the marine ecology + marine biology research methodologies classes where we went boating every other week to do real field research for the department and got to go snorkeling in the Florida Keys while staying at a research base the university had there. Those were way cooler than pipetting fluids between cell cultures and hoping to get the recipe right. Hard to screw up a semester long project of measuring fish, but it was quite easy for someone to switch out the pipettes in my lab counter space while my back was turned for a few seconds and require restarting the project we had been working on for weeks. I had to get into my senior year before I realized I strongly disliked the profession. I even tried growing plant cell cultures at home with my own makeshift protocols, but it was all wasted effort. Software is way better because you can get however much hands-on experience as you wish at your own convenience, and the stuff that works in a computer lab also works on your laptop at home.
Thanks for sharing! Biotech seems so fascinating, I almost went that route before pivoting to software engineering.
@@Zer-ei4co the CRISPR paper came out the year we graduated. My buddy lamented that almost everything we had learned had been superceded by that one paper or would soon be obsoleted by further developments of the technology. The advent of cheap custom gene sequence printing made even more of the biotech stack we learned obsolete. Again, this compares unfavorably to software development where one can pick up a new language, framework, or paradigm in a few weeks.
@@k98killer But still very comparable to industries close to SWE like AI/ML! The world is moving at such a break neck pace, technology sweeps everything and everyone from under our feet, increasingly (seemingly exponentially) so. That means we’ll have to be even more adaptable and open to learning and open minded.
But now we’re competing with AI so we’re going to have to speed up, and the collective burnout will be inevitable. Maybe everyone will stop and take a look around and realize we could be appreciating so much more and living richer by living without chasing infinite efficiency and artificial deadlines. I’m curious what’s next.
@@Zer-ei4co I went down the left-wing anarchist philosophy rabbit hole today, and they have some salient criticisms of capitalism as an ideology. "Growth for its own sake is cancer logic" is probably the most memorable quote that rings truest. It seems that the world we live in is structured based upon an unsustainable exploitation of natural resources (including people) to feed greedy egregores (they would say "the state" and "corporations", but I'm generalizing). The future seems like one in which we either restructure away from wage-slavery and growth-at-any-cost or one in which the earth dies enough to excise the cancer. We could see the emergence of library economies or a V for Vendetta type society.
On the topic of AI/ML, I am currently working on an evolutionary algorithm library in Go. I have a few more kinks to work out with some basic functionality (edge cases I discovered through experimentation that were not in my unit tests), but then I will implement back propagation + quickprop, refactor to handle multiple evolutionary epochs, and make a function for evolving a neural network that applies a few rounds of quickprop/backprop before measuring fitness. The library is FOSS, but I plan to make a cross-platform desktop application and tie it into an app for fine-tuning OpenAI models.
I see a lot of people with only 2 to 3 years that feel they are senior, buy they don't contribute to projects at a senior level. Some do in as little as a year. But most I feel let off the gas or get lazy. There may not be a minimum time necessary, but I feel like many people with only a few years fall short of a senior dev contributor.
I know a couple devs with just 2 or 3 years that are far more useful and insightful than devs of any tenure. But many are not.
His shouts sound like Even Baxter (Steve Carell).
I don't know what senior developers do in my company, as they rarely share about it.
He didn't say experienced engineers ALWAYS hesitant to try new things. You maybe not hesitant but many are. Again, normal human behaviour: being comfortable with what we have. New things start uncomfortable and one with experience needs time and enough motivation to cross that
why is it between junior and senior? isn't there middle level developer where most people are? =)
I've worked with people who have been working in Software engineering for 10 years that I would still concider junior. No title matters. Just judge people on what you encounter in their work.
Does the concept of seniority solely apply to individuals within a professional environment, based on their professional experience? How can one achieve the status or expertise equivalent to a "senior" outside of such a setting?
A Senior colleague of mine said that you cannot be a senior engineer until you crashed production at least once.
I know 11 programming langues, been a developer for 15 years, completed multi million dollar projects but I am sure as hell still a Junior.
I'm not even an intern yet but this article made me set my sights higher
Going for experience to measure "juniorism" would be a contradiction to the first statement that said no absolute time limit to when you finish being a junior, because experience is gained through time which then implies that there has to be a range where that "juniorism" happens and ends.
Senior means, you can predict your project going to fail from the beginning or if you see code from others. Senior developers have learned to avoid these train wrecks by pretending they don't understand it.
Can you elaborate more? Are there any actual examples?
@@demonrawr4769 Not easy to explain this one. As a senior developer you have been exposed to your own projects and other teams projects that fails. Over time you learn to detect those projects that will fail so you do everything to being avoided to be assigned to it because if you do it is the end of your career.
Senior developer learned to detect the golden path into a mine field. Sometimes you have to fake that you are not good enough so they choose another developer to assign to that project.
How do you detect failing projects that cannot succeed from day one? Instinct.
@@olafbaeyens8955 Your description is informative enough! Thx for the info
So what do you do when the company you’re working for keeps that Senior title gated by years of experience?
Im a little over 2 years in (no professional experience before this job) and I feel like I anticipate problems - and their solutions - well before many of the ‘Senior’ level devs I work with on a daily basis, in fact I end up in almost every architectural design meeting so they can get my input. But I’m essentially getting “oh it’s just a title, we already view you like one of the seniors” / “it’s been a tight year, the company just can’t afford to give out promotions right now” type response to my requests for getting that Senior promotion I feel like I’m qualified for.