Such a great video. Sharing this with my younger colleagues. I'm extremely fortunate - I'm by far the oldest person among my team - I'm 54, and most of the team I work with are under 27 years old. Some in their early 20s. Nevertheless, I'm impressed every single day by their intelligence, and their tenacity, and have huge respect for all of them. They've accepted me into their young environment I really feel no age difference between us - they are, all of them, the loveliest of people. I'm very fond of them. This video might serve as an excellent illustration of the path from a programmer, to an _engineer_ - which is a topic that always comes up! I keep telling them they are not programmers or coders. They are _engineers_ .
I love the remark on Softwaredevelopment being work of creativity - this aspect is so often overlooked by non-dev people just having the coding thing in mind. And a lot of programmers do not reach that point of meta-understanding or, conceptual understanding because of focusing to much on one framework and/or language/techstack. That difference in beginner and expert made me laugh but in the end it is true: an expert simply fucked up more (and obviously learned from it) than a beginner. Great video :)
I'd add that a senior also has domain(s) knowledge and commercial awareness. After all, we are about providing value to our customers, a senior must understand this and have the knowledge and skills to deliver value. Maybe I'm describing a consultant engineer (my job title).
I'm also a consultant engineer and I completely agree. While most people determine their seniority based on time served and which and how many 'cool' languages or 'patterns' they have under their belt, very few of them have commercial awareness or any concept of providing value to customers and that includes a lot of management.
@@gppsoftware What I find extraordinary is how little understanding there is in most businesses that engineers effectively spend money, hopefully for the betterment of the whole business. The Financial Director complained that the company was "too engineering lead" not understanding where this months, year, 5 year profit is actually coming from. Even though the word "Technology" is in the company name.
@@nickbarton3191 Yes, that is a very good point. The Financial director says that because he looks at the budgets and sees what the business really is by virtue of where most of the expenditure goes. Unfortunately, these 'financial types' don't like the change that has occurred over the last 1-2 decades whereby companies today are focused around technology departments (which should be leading the business and innovation) and not accounts departments (which are typically not innovative).
@@nickbarton3191 Agreed. One only has to look at the budget sheets to see that many organisations these days are technology companies by virtue of where most of their expenditure goes. Unfortunately, Finance Directors have a problem with a business being led by a technology department instead of the finance department.
Extremely good description. But I'd be careful judging these things based on a resume. Me for example, I spent 20 years on the same tech stack. But I was building my own things on the side with all the latest and greatest technologies and practices. And so I was always ready to take on new stuff with an in-depth and breadth of understanding. It was no problem for me to move from a university to a stock exchange, for example. I think having a thorough interview process is far superior then judging based on resume
Agreed with everything. Personally, I also quantify these concepts using the stages of growth that a *developer* typically goes through: 1. Programming 2. Algorithms and Data Structures 3. Design 4. Architecture 5. Analysis (beyond Functional and NF requirements -- what the problem _really_ is, how it could develop in the future, etc; this guides the architecture, then the design and so on) 6. Organizing Processes and Teamwork To me a Senior Developer is at least level 5. There are levels within the levels, of course, but this simplified scheme is easier to track and has proven to be predictive of the observed future performance (in my experience).
1:30 Diversifying to multiple platforms is generally good advice for the dev. However sometimes you'll get a careerist who decides to re-write the entire code base in the paradigm and platform he is currently learning, in order to bolster his CV, without adding any value to the project. I've seen a dev do this for over 2 years until a technical senior DBA finally called him out on it. He effectively added 0 value for two years until somebody even noticed. This was at a gov lab.
Some years back I said when mentoring Juniors, was that programming is more linguistics than math. Our job is to find true representations of human ideas in a machine executable form. I was then still under the impression of a brilliant engineer who was a trained linguist. Now I am on the more mathematical interpretation, but it is only the second step, just like we use math to describe things, math in software development describes the linguistics or insights we gained of the problem
A lot of the best work in development is done in visual maps - if you can efficiently draw up a full picture of the process and interactions and scopes, you can more easily work with business as well as technical teams as well as project managers. Junior (and I still feel a bit junior myself) devs tend to hear "we need to fix X problem" and then focus on that specifically, rather than taking a holistic view.
Absolutely agree that writing code to solve problems is generally not very hard - especially with your typical line-of-business apps. Junior developers are challenged to find a solution to a problem - seniors are challenged by finding a solution that best solves the problem. Seniors also have a healthy dose of cynicism when considering the promises of tools or patterns, and are more aware of the costs of maintenance and refactoring incorrect assumptions. These are hard skills to learn outside of direct experience - and leads to the dangerous newly minted seniors throwing every "best practice" pattern into their next solution. I have often felt, especially in the last 5-10 years, that many engineers are uncomfortable with the current state of excellent tooling and frameworks - they feel that a simple problem requires the same levels of effort (and lines of code) as a 2000s era solution. Honestly the expressiveness of the tooling has improved to the point where if there is much more code than a plain English description of the solution, then something has gone horribly wrong.
I think being senior also includes being effective at enabling others in the team: one of the benefits of being able to solve problems in many ways is being able to engage with less experienced or able developers on their terms, not requiring them to adapt to you; being able to fill the gaps or smooth the edges of the work of less experienced colleagues approach so that it can succeed on their terms. This drives real collective ownership which is a critical part of long term team success, consistent team output, effective handling of incidents, etc. And it also enables learning, being shown that your ideas are right but can be improved, being shown how your 8/10 can be a 10/10, is more effective for learning than being made to feel your work is a dead end and being pushed to try and deliver in a space of solutions you don't really understand. This also builds trust and confidence so that when you do need to lead people into a different solution space they're much more willing to follow you.
Multiple tech stacks seems weird. Lots of them are almost identical with extremely nuanced gotchas. People love to tout the numbers of tech they "know" when they're all so similar and/or they've never used it for a significant period of time and/or in a production environment and/or in maintenance mode. If your goal is 3 actual different tech stacks with actual, full product lifecycle knowledge, I don't realistically see how you accomplish this in less than 10 or so years. A year per stack isn't enough. 3 might be.
A senior has the commercial ability to be able to evaluate whether multiple tech stacks are even appropriate. Just because you can, doesn't mean you should!
What makes you think its "3 tech stacks that do the same"? My day job is mobile (iPad) development with .Net.iOS. My current course work is Python+SQL Server. My current pet project is C++ on ESP32's. That's already 3 tech stacks and that's just this last semester. Now, am i as proficient in the "not my job" parts? No, because i only use them for what i need, not as a "every day". And it's not the "multiple stacks" per se, but the attitude towards it. Everyone i know that i would call senior will gnash and gnaw when told to go do something out of their "comfort zone", but will go and get it done. The juniors will just s**t their pants while running to the nearest senior for guidance. The juniors that became seniors just s**t their pants, went do some research and then kept knocking on senior's door when faced with real roadblocks. And eventually they become the ones the juniors go to, and we go full circle.
They just want to lower senior salaries and find somehow a way for us seniors to accept juniors paid even higher that we have to help. I’m talking to a team of rtards that need a team lead but they asked me for my WordPress experience. I’ll get back if I hear from them again, I’ve played along so far ;)
This reminds me of the MBA at the bank data center who decided he would write the code to generate a business account summary report himself in APL. It brought the mainframe to its knees and ran for hours. I took pity on the auditor tasked with running the report. It took me 10 minutes to rewrite it in the data retrieval scripting language and submit to operations where it ran in just minutes. The MBA was furious but everyone else couldn't thank me enough.
@@brownhorsesoftware3605 I’m a new developer in a mainframe environment. How did he manage to make the report run for hours? Did you rewrite it in COBOL?
@@iamhereblossom1588 Using matrix manipulation in APL to produce a simple summary report required more memory than was available on a small mainframe in the early 1980s. Most of the time was probably spent swapping things in and out of memory. Even COBOL would have been overkill - Easytrieve was sufficient.
@@brownhorsesoftware3605thank you for the reply and for sharing your knowledge. That’s fascinating. I’ve got to get more experience with easytrieve. You’ve just convinced me of that.
There is the purely rational and technical approach to such a problem. It's the approach you took. And there is the politics involved, because you're solving a problem while employed in a corporation. The MBA dude is likely to spend most of his time making friends with the senior management. And making the MBA dude furious here, although your contribution was technically right, and although it benefited the company, could get you fired, sadly.
The fundamental difference between a junior, intermediate and senior is responsibility. A junior is invested with no trust. They are given simple tasks that are not in the critical path, and their solutions are reviewed in depth. They often have a mentor. An intermediate has developed the respect and trust required to write code independently based on a story without much oversight. They are given story level responsibility. Senior developers are responsible for the product as a whole, the architecture, the design, delivery and quality assurance. While the whole team is technically responsible, it falls to seniors to enforce standards through mentorship and guidance.
I was managing entire areas of systems I was responsible for development of well before anyone would have considered me a senior of any kind. But the environment was dramatically different from the typical, small video game studio with a great senior mentor and lots of hats to grab was one of the best starting places I can imagine even today for a self-motivated person. And probably a nightmare for someone that stresses easily and doesn't want to adopt responsibility before they're familiar with the entire domain. But for me, it allowed me to develop my skills dramatically faster than anyone I know and having a very pedantic senior as my first mentor helped keep the guard rails by not allowing me to take stupid shortcuts.
@@RiversJ That does sound really good, lots of freedom and opportunity to grow, but also someone experience to direct you. I didn't have that responsibility in my first job but had a great senior in my team who kept the guard rails up which helped me to learn some solid fundamentals I think. You made a good point about some people who stress easily might find it a nightmare, that is probably true. I do think growth depends on personality a lot, but also just luck of the draw on jobs. As we learn more about what a job might entail, it could be good to filter certain ones out if you need progression. The one I'm currently in has very slow/little progression (they don't even really have it in place yet, HR is working on it), so promotions etc are super hard to get.
It takes having such a broad range of skills, plus so many years of experience to become a good senior SW engineer. The high salaries good senior SW engineers get are justified.
4:50 if coding is not the hard part for seniors then why is it the focus of nearly every senior job interview? I agree and my focus is never the code itself, it is about understanding the user problems, refining the UX, names represent the domain, and ensuring the API and data models are good. Of course architecture, performance, reliability, extensibility, testing, security, and CICD are in there too.
Senior developers are generally people that have more agency and less friction with entities. There's a good point where friction in the company disables a senior developer from working efficiently. While a junior developer will probably create frictions that lead to uncertainties and greater time spent on projects. There's also the level of responsibility a senior developer can have on a product or a system.
There's a reason for narrow experience and it has to do with power structures at your company. The trick is to get closer to value creation and your customer. At the end of the day, this is what's valuable. The problem is, often your boss won't let you do that, because he prefers to be the one who's indispensable lol With a good LLM, developers can now better focus on value creation, and for the first time in herstory, actually advance their career.
“Breadth of experience” can count for so much. Textbook knowledge can only take one so far! Imo the difference between a junior vs. senior is similar between a software engineer vs. a coder.
I have interviewed people who expected a senior role because they spent 5+ years at their first programmer job. I had to disappoint them and offer a Junior role. Don't get stuck in a single gig!
Interesting take, but there is something to be said for someone staying in one place for long enough to see the consequences of their decisions play out. That really requires **at least** three years in the same place.
As someone invovled in hiring developers, how do you feel about someone with an associates degree if someone is otherwise qualified? Mine is specific to mobile applications. Just curious about your opinion.
I don’t think there’s a hard divide, just characteristics that I expect both to have: For juniors I expect: - To need occasional supervision to avoid time sinks - To be able to complete concrete tasks with some general directions from a senior - To require me to ask them if they need help every once in a while - Their biggest asset is knowing *what to do*. For seniors: - To autonomously identify when they are spending too much time on something and adapt. - to be able to plan and complete tasks expressed as vague goals by non-technical folk - to be proactive about asking for help - Their biggest asset is what we *should NOT do*.
If it can be done at all, the only blocker is motivation and resources. I still remember developing a custom rendering system without really knowing anything about how they're supposed to work. Managed to create some unique and extreme performance characteristics for it, got some things horribly wrong too but those I could correct from the things I learned from that project and the work of others once I got experienced with the domain. Having drive and courage to try new things don't just give you new shinies, the most important thing it gives is perspective, after many such projects it gives a lot of confidence and knowledge of your own limits at the same time so as not to become arrogant either.
@@TheBrick2 And don't succumb to "imposter syndrome". You ARE the best person for the job, because you understand the issues, if not the whole solution from the beginning, that'll come.
Detailed instructions are not required but detailed acceptance criteria certainly are and from the start. Without them, a developer senior or junior is the easiest thing on earth to scapegoat.
No. A good developer must be able to elicit those acceptance criteria. Otherwise they are not engineers, but just programmers and often won't take responsibility for their output. And I'd say being able to elicit requirements well is a big differentiating factor between seniors and juniors.
@ it doesn’t matter how well you think you elicit acceptance criteria if they are not accepted by the user, like the name suggests. “It’s done because it meets the criteria that I elicited” is not a message that I would put out to any customer. By all means elicit them but you better have the end user review/sign off on them in advance.
Yes, it needs to be done in collaboration. No one role has all of the answers, we need to collaborate to make good software, but the technical skills to value, and understand, how to get to good acceptance criteria are an important facet of SW dev, so are a skill that the good, effective developer needs.
Loved this one, agree mostly! Thanks. I would love to hear your take about which roles go better together when a startup is short on staff. I've been a UIDesigner/FunctionalQA and I think those go great together. ProjectLeader and Developer... not so much. Maybe BusinessAnalist/PL go ok? A Sagitarius with a Libra? haha
Seniors have to be able to think ahead, and not cul-de-sac the development path. The easy path isn't necessarily the best. They recognise the sources of tech debt and fragility. Juniors do it now and don't care what happens next. They maybe lucky, but they haven't had the pain of fixing horrible design decisions 2 years down the road because they didn't follow good design principles early on. Micro managing, senior managers often look like junior developers as well! "Do it now", "don't worry about what is next, just fix it"
@@ByToothandClaw Just 2 years? We're living with architectural decisions made 15 years ago. My motto is "never give up", eventually you'll succeed in reversing history.
The biggest difference is senior engineers are able to integrate economic thinking into how they do their job, and that requires deep knowledge in all three domains of the application under development, tools and the stack, and business values
If you simplify programming to a flow chart and pay attention to the diamonds...Yes and No. The junior will concentrate on the yes branch(and get it to work when things are going well), the senior will worry about the 'no' branch. Much software specifications ignore the 'no' branch. I think verbal or written software definitions(often called narratives) tend toward 50% of what is really needed. You can zip down the path to demonstrable completion when everything is correct on the input. Dump some incorrect input into the situation and things fail miserably. Junior is not aware, senior is quite aware.
This is fairly important. I run a team of 8 devs etc and I can rank them first to last in terms of capability, and it's not necessarily based on time served.
yet, hiring companies will ask for xxx years of experience in their JD. Plus, they will ask you to go through all these live coding tests, although senior engineers who have experience interviewing report there is little correlation between how well a guy did at the hiring interview and how good he is as an engineer.
I think this isn't a complete view. Some people never get past their junior phase and no matter how much mentoring is dumped they are resisting learning. A video about that would be great
I think that all of these kinds of role are very poorly defined, each org interprets them differently from every other in some way. Here are a few videos that may help clarify what I think... th-cam.com/video/jMpCF0Z623s/w-d-xo.html th-cam.com/video/rTWc_Sd-kE4/w-d-xo.html
I am of the opinion that a detailed and clear scope is required to get the job done. Expectations, outcome, verification, etc. Should all be present. Throwing jargon together and expecting a person to figure it out because they are senior is a sure-fire way to get them to have mental breakdowns and possibly quit. Senior does not equate to reading minds.
As a senior dev you should be able raise and articulate the issue with requirements so there is clarity. Most of the requirements I receive don't make sense and it sometimes takes weeks to define them from the requestor - quite often there is no PM/BAs nor architects so you cover those roles as well.
Not true of the orgs that are genuinely good at SW dev in my experience, and understanding of what orgs like Google, Amazon and Microsoft do at interview. Often asking questions that are, at heart, trying to understand how good the person is at "problem solving" rather how good their memory of obscure technical detail is.
This is on point and, sadly, will get you fired in today's industry. Seniors now have soft skills (neurotypical, office politics, fit in with cliques, part of the "family"), can slop together solutions quickly without thinking about the problem so they have much higher "velocity" than the junior devs and don't hurt junior devs feelings by disagreeing with them. Good luck!
This is accurate, .. but it's also pointless. There is no measurement of seniority within the management circles. We may have a good understanding of it but reality says NO. A person spending 10 years working on 20 failed (by his own fault) projects will still have more decision making power than one who did 5 years on 5 successful projects. They say that an average software company is 3x less efficient than a high performance one. Meaning, if a company is in the middle of the bell curve they have, effectively, no idea how to build software. And the vast majority of companies are in the middle of the bell curve (duh). People who are interested in you, your books, your ideas do know that there is more to it, the rest is that vast majority.
Não concordo muito, se ficarmos programando em várias linguagens, frameworks, SO´s diferentes seremos um pato. Nada mal, anda mal e voa mal. Um dev senior precisa ter pelo menos 4 anos em uma mesma linguagem, pois é nela que você irá masterizar os conceitos que depois podem ser aplicados em outras linguagens, stacks, etc.
Loved it. One of my favorite sayings is "Experience is what you get when you don't get the result you were expecting".
Such a great video. Sharing this with my younger colleagues. I'm extremely fortunate - I'm by far the oldest person among my team - I'm 54, and most of the team I work with are under 27 years old. Some in their early 20s. Nevertheless, I'm impressed every single day by their intelligence, and their tenacity, and have huge respect for all of them. They've accepted me into their young environment I really feel no age difference between us - they are, all of them, the loveliest of people. I'm very fond of them. This video might serve as an excellent illustration of the path from a programmer, to an _engineer_ - which is a topic that always comes up! I keep telling them they are not programmers or coders. They are _engineers_ .
Communication is also a big quality of senior developers.
Senior devs should be able to detect and raise possible issues before they arise.
27 yrs developer. I always tell the juniors: wear a user's hat. Solid solutions are built with experience, discipline, and respect.
I love the remark on Softwaredevelopment being work of creativity - this aspect is so often overlooked by non-dev people just having the coding thing in mind. And a lot of programmers do not reach that point of meta-understanding or, conceptual understanding because of focusing to much on one framework and/or language/techstack.
That difference in beginner and expert made me laugh but in the end it is true: an expert simply fucked up more (and obviously learned from it) than a beginner.
Great video :)
I'd add that a senior also has domain(s) knowledge and commercial awareness.
After all, we are about providing value to our customers, a senior must understand this and have the knowledge and skills to deliver value.
Maybe I'm describing a consultant engineer (my job title).
Completely agree. Domain knowledge is insanely crucial.
I'm also a consultant engineer and I completely agree.
While most people determine their seniority based on time served and which and how many 'cool' languages or 'patterns' they have under their belt, very few of them have commercial awareness or any concept of providing value to customers and that includes a lot of management.
@@gppsoftware What I find extraordinary is how little understanding there is in most businesses that engineers effectively spend money, hopefully for the betterment of the whole business.
The Financial Director complained that the company was "too engineering lead" not understanding where this months, year, 5 year profit is actually coming from. Even though the word "Technology" is in the company name.
@@nickbarton3191 Yes, that is a very good point. The Financial director says that because he looks at the budgets and sees what the business really is by virtue of where most of the expenditure goes. Unfortunately, these 'financial types' don't like the change that has occurred over the last 1-2 decades whereby companies today are focused around technology departments (which should be leading the business and innovation) and not accounts departments (which are typically not innovative).
@@nickbarton3191 Agreed. One only has to look at the budget sheets to see that many organisations these days are technology companies by virtue of where most of their expenditure goes. Unfortunately, Finance Directors have a problem with a business being led by a technology department instead of the finance department.
Extremely good description. But I'd be careful judging these things based on a resume. Me for example, I spent 20 years on the same tech stack. But I was building my own things on the side with all the latest and greatest technologies and practices. And so I was always ready to take on new stuff with an in-depth and breadth of understanding. It was no problem for me to move from a university to a stock exchange, for example. I think having a thorough interview process is far superior then judging based on resume
good point. i always put those side projects on my resume
@xybersurfer I do too but it may not always be the case.
Agreed with everything. Personally, I also quantify these concepts using the stages of growth that a *developer* typically goes through:
1. Programming
2. Algorithms and Data Structures
3. Design
4. Architecture
5. Analysis (beyond Functional and NF requirements -- what the problem _really_ is, how it could develop in the future, etc; this guides the architecture, then the design and so on)
6. Organizing Processes and Teamwork
To me a Senior Developer is at least level 5.
There are levels within the levels, of course, but this simplified scheme is easier to track and has proven to be predictive of the observed future performance (in my experience).
1:30 Diversifying to multiple platforms is generally good advice for the dev. However sometimes you'll get a careerist who decides to re-write the entire code base in the paradigm and platform he is currently learning, in order to bolster his CV, without adding any value to the project. I've seen a dev do this for over 2 years until a technical senior DBA finally called him out on it. He effectively added 0 value for two years until somebody even noticed. This was at a gov lab.
Some years back I said when mentoring Juniors, was that programming is more linguistics than math. Our job is to find true representations of human ideas in a machine executable form.
I was then still under the impression of a brilliant engineer who was a trained linguist.
Now I am on the more mathematical interpretation, but it is only the second step, just like we use math to describe things, math in software development describes the linguistics or insights we gained of the problem
A lot of the best work in development is done in visual maps - if you can efficiently draw up a full picture of the process and interactions and scopes, you can more easily work with business as well as technical teams as well as project managers. Junior (and I still feel a bit junior myself) devs tend to hear "we need to fix X problem" and then focus on that specifically, rather than taking a holistic view.
Great points. The over/under confidence call out is great. It also relates to having a growth vs fixed mindset to be continually learning.
Absolutely agree that writing code to solve problems is generally not very hard - especially with your typical line-of-business apps. Junior developers are challenged to find a solution to a problem - seniors are challenged by finding a solution that best solves the problem. Seniors also have a healthy dose of cynicism when considering the promises of tools or patterns, and are more aware of the costs of maintenance and refactoring incorrect assumptions. These are hard skills to learn outside of direct experience - and leads to the dangerous newly minted seniors throwing every "best practice" pattern into their next solution.
I have often felt, especially in the last 5-10 years, that many engineers are uncomfortable with the current state of excellent tooling and frameworks - they feel that a simple problem requires the same levels of effort (and lines of code) as a 2000s era solution. Honestly the expressiveness of the tooling has improved to the point where if there is much more code than a plain English description of the solution, then something has gone horribly wrong.
I think being senior also includes being effective at enabling others in the team: one of the benefits of being able to solve problems in many ways is being able to engage with less experienced or able developers on their terms, not requiring them to adapt to you; being able to fill the gaps or smooth the edges of the work of less experienced colleagues approach so that it can succeed on their terms. This drives real collective ownership which is a critical part of long term team success, consistent team output, effective handling of incidents, etc. And it also enables learning, being shown that your ideas are right but can be improved, being shown how your 8/10 can be a 10/10, is more effective for learning than being made to feel your work is a dead end and being pushed to try and deliver in a space of solutions you don't really understand. This also builds trust and confidence so that when you do need to lead people into a different solution space they're much more willing to follow you.
I appreciate this approach and the patience of seniors and mentors like you
As a junior, thank you so much!
Multiple tech stacks seems weird. Lots of them are almost identical with extremely nuanced gotchas. People love to tout the numbers of tech they "know" when they're all so similar and/or they've never used it for a significant period of time and/or in a production environment and/or in maintenance mode.
If your goal is 3 actual different tech stacks with actual, full product lifecycle knowledge, I don't realistically see how you accomplish this in less than 10 or so years. A year per stack isn't enough. 3 might be.
A senior has the commercial ability to be able to evaluate whether multiple tech stacks are even appropriate. Just because you can, doesn't mean you should!
What makes you think its "3 tech stacks that do the same"? My day job is mobile (iPad) development with .Net.iOS. My current course work is Python+SQL Server. My current pet project is C++ on ESP32's. That's already 3 tech stacks and that's just this last semester. Now, am i as proficient in the "not my job" parts? No, because i only use them for what i need, not as a "every day".
And it's not the "multiple stacks" per se, but the attitude towards it. Everyone i know that i would call senior will gnash and gnaw when told to go do something out of their "comfort zone", but will go and get it done. The juniors will just s**t their pants while running to the nearest senior for guidance. The juniors that became seniors just s**t their pants, went do some research and then kept knocking on senior's door when faced with real roadblocks. And eventually they become the ones the juniors go to, and we go full circle.
They just want to lower senior salaries and find somehow a way for us seniors to accept juniors paid even higher that we have to help. I’m talking to a team of rtards that need a team lead but they asked me for my WordPress experience. I’ll get back if I hear from them again, I’ve played along so far ;)
What are you saying, the difference between junior and senior , is "ju" and "se"
You for sure are thinking out of the box 😀
Not even a software developer, but I love this channel. Great insight that applies elsewhere!
This reminds me of the MBA at the bank data center who decided he would write the code to generate a business account summary report himself in APL. It brought the mainframe to its knees and ran for hours. I took pity on the auditor tasked with running the report. It took me 10 minutes to rewrite it in the data retrieval scripting language and submit to operations where it ran in just minutes. The MBA was furious but everyone else couldn't thank me enough.
@@brownhorsesoftware3605 MBAs are doing a great service to humanity 😅
@@brownhorsesoftware3605 I’m a new developer in a mainframe environment. How did he manage to make the report run for hours? Did you rewrite it in COBOL?
@@iamhereblossom1588 Using matrix manipulation in APL to produce a simple summary report required more memory than was available on a small mainframe in the early 1980s. Most of the time was probably spent swapping things in and out of memory. Even COBOL would have been overkill - Easytrieve was sufficient.
@@brownhorsesoftware3605thank you for the reply and for sharing your knowledge. That’s fascinating. I’ve got to get more experience with easytrieve. You’ve just convinced me of that.
There is the purely rational and technical approach to such a problem. It's the approach you took. And there is the politics involved, because you're solving a problem while employed in a corporation. The MBA dude is likely to spend most of his time making friends with the senior management. And making the MBA dude furious here, although your contribution was technically right, and although it benefited the company, could get you fired, sadly.
The main difference is Juniors are all laid off right now and can’t get hired
The fundamental difference between a junior, intermediate and senior is responsibility. A junior is invested with no trust. They are given simple tasks that are not in the critical path, and their solutions are reviewed in depth. They often have a mentor. An intermediate has developed the respect and trust required to write code independently based on a story without much oversight. They are given story level responsibility. Senior developers are responsible for the product as a whole, the architecture, the design, delivery and quality assurance. While the whole team is technically responsible, it falls to seniors to enforce standards through mentorship and guidance.
I was managing entire areas of systems I was responsible for development of well before anyone would have considered me a senior of any kind. But the environment was dramatically different from the typical, small video game studio with a great senior mentor and lots of hats to grab was one of the best starting places I can imagine even today for a self-motivated person.
And probably a nightmare for someone that stresses easily and doesn't want to adopt responsibility before they're familiar with the entire domain.
But for me, it allowed me to develop my skills dramatically faster than anyone I know and having a very pedantic senior as my first mentor helped keep the guard rails by not allowing me to take stupid shortcuts.
@@RiversJ That does sound really good, lots of freedom and opportunity to grow, but also someone experience to direct you. I didn't have that responsibility in my first job but had a great senior in my team who kept the guard rails up which helped me to learn some solid fundamentals I think. You made a good point about some people who stress easily might find it a nightmare, that is probably true. I do think growth depends on personality a lot, but also just luck of the draw on jobs. As we learn more about what a job might entail, it could be good to filter certain ones out if you need progression. The one I'm currently in has very slow/little progression (they don't even really have it in place yet, HR is working on it), so promotions etc are super hard to get.
It takes having such a broad range of skills, plus so many years of experience to become a good senior SW engineer. The high salaries good senior SW engineers get are justified.
This is the best explanation of the difference, even when I was junior my approach leaned towards senior🤯
4:50 if coding is not the hard part for seniors then why is it the focus of nearly every senior job interview? I agree and my focus is never the code itself, it is about understanding the user problems, refining the UX, names represent the domain, and ensuring the API and data models are good. Of course architecture, performance, reliability, extensibility, testing, security, and CICD are in there too.
Senior developers are generally people that have more agency and less friction with entities.
There's a good point where friction in the company disables a senior developer from working efficiently.
While a junior developer will probably create frictions that lead to uncertainties and greater time spent on projects.
There's also the level of responsibility a senior developer can have on a product or a system.
There's a reason for narrow experience and it has to do with power structures at your company.
The trick is to get closer to value creation and your customer. At the end of the day, this is what's valuable.
The problem is, often your boss won't let you do that, because he prefers to be the one who's indispensable lol
With a good LLM, developers can now better focus on value creation, and for the first time in herstory, actually advance their career.
"What's the definition of an expert?"
Witty and brilliant, cheers!
@@vst-name An expert is the person who knows one more thing than you do. 👩🔧
“Breadth of experience” can count for so much. Textbook knowledge can only take one so far!
Imo the difference between a junior vs. senior is similar between a software engineer vs. a coder.
1:05
1:14
2:01
3:45 big difference between junior and senior
4:28
4:47
I have interviewed people who expected a senior role because they spent 5+ years at their first programmer job. I had to disappoint them and offer a Junior role. Don't get stuck in a single gig!
Interesting take, but there is something to be said for someone staying in one place for long enough to see the consequences of their decisions play out. That really requires **at least** three years in the same place.
As someone invovled in hiring developers, how do you feel about someone with an associates degree if someone is otherwise qualified? Mine is specific to mobile applications. Just curious about your opinion.
I don’t think there’s a hard divide, just characteristics that I expect both to have:
For juniors I expect:
- To need occasional supervision to avoid time sinks
- To be able to complete concrete tasks with some general directions from a senior
- To require me to ask them if they need help every once in a while
- Their biggest asset is knowing *what to do*.
For seniors:
- To autonomously identify when they are spending too much time on something and adapt.
- to be able to plan and complete tasks expressed as vague goals by non-technical folk
- to be proactive about asking for help
- Their biggest asset is what we *should NOT do*.
Don't be afraid to start. Don't be afraid to start again. You sometimes don't get the perspective until you've run down a few dead ends.
If it can be done at all, the only blocker is motivation and resources.
I still remember developing a custom rendering system without really knowing anything about how they're supposed to work. Managed to create some unique and extreme performance characteristics for it, got some things horribly wrong too but those I could correct from the things I learned from that project and the work of others once I got experienced with the domain.
Having drive and courage to try new things don't just give you new shinies, the most important thing it gives is perspective, after many such projects it gives a lot of confidence and knowledge of your own limits at the same time so as not to become arrogant either.
@@TheBrick2 And don't succumb to "imposter syndrome".
You ARE the best person for the job, because you understand the issues, if not the whole solution from the beginning, that'll come.
Detailed instructions are not required but detailed acceptance criteria certainly are and from the start. Without them, a developer senior or junior is the easiest thing on earth to scapegoat.
No. A good developer must be able to elicit those acceptance criteria. Otherwise they are not engineers, but just programmers and often won't take responsibility for their output. And I'd say being able to elicit requirements well is a big differentiating factor between seniors and juniors.
@ it doesn’t matter how well you think you elicit acceptance criteria if they are not accepted by the user, like the name suggests. “It’s done because it meets the criteria that I elicited” is not a message that I would put out to any customer. By all means elicit them but you better have the end user review/sign off on them in advance.
Yes, it needs to be done in collaboration. No one role has all of the answers, we need to collaborate to make good software, but the technical skills to value, and understand, how to get to good acceptance criteria are an important facet of SW dev, so are a skill that the good, effective developer needs.
Loved this one, agree mostly! Thanks.
I would love to hear your take about which roles go better together when a startup is short on staff.
I've been a UIDesigner/FunctionalQA and I think those go great together.
ProjectLeader and Developer... not so much.
Maybe BusinessAnalist/PL go ok?
A Sagitarius with a Libra? haha
Juniors understands a tech stack, seniors understands the business and solution domain.
Seniors have to be able to think ahead, and not cul-de-sac the development path. The easy path isn't necessarily the best. They recognise the sources of tech debt and fragility. Juniors do it now and don't care what happens next. They maybe lucky, but they haven't had the pain of fixing horrible design decisions 2 years down the road because they didn't follow good design principles early on.
Micro managing, senior managers often look like junior developers as well! "Do it now", "don't worry about what is next, just fix it"
@@ByToothandClaw Just 2 years?
We're living with architectural decisions made 15 years ago.
My motto is "never give up", eventually you'll succeed in reversing history.
a senior is a junior who kept on trying and never gave up
I agree because a dev even in one tech or lang can't know everithing ...
It's by trying and trying and trying that later you know what to do 🙂
♥
The Tshirts are funny. Especially today's one is suited for meetings where complicated solutions are defined. 😂
The biggest difference is senior engineers are able to integrate economic thinking into how they do their job, and that requires deep knowledge in all three domains of the application under development, tools and the stack, and business values
THIS is the right answer !
Very well said! 👍
If you simplify programming to a flow chart and pay attention to the diamonds...Yes and No. The junior will concentrate on the yes branch(and get it to work when things are going well), the senior will worry about the 'no' branch. Much software specifications ignore the 'no' branch. I think verbal or written software definitions(often called narratives) tend toward 50% of what is really needed. You can zip down the path to demonstrable completion when everything is correct on the input. Dump some incorrect input into the situation and things fail miserably. Junior is not aware, senior is quite aware.
Good takes!
Especially the parts where I've felt that people have been given Senior titles for the wrong (only time) reasons.
This is fairly important.
I run a team of 8 devs etc and I can rank them first to last in terms of capability, and it's not necessarily based on time served.
yet, hiring companies will ask for xxx years of experience in their JD. Plus, they will ask you to go through all these live coding tests, although senior engineers who have experience interviewing report there is little correlation between how well a guy did at the hiring interview and how good he is as an engineer.
I think this isn't a complete view. Some people never get past their junior phase and no matter how much mentoring is dumped they are resisting learning. A video about that would be great
I’ve been given a Lead Systems Engineer role, is there a difference between a Lead Eng and a Tech Lead? I often see them used interchangeably.
I think that all of these kinds of role are very poorly defined, each org interprets them differently from every other in some way. Here are a few videos that may help clarify what I think...
th-cam.com/video/jMpCF0Z623s/w-d-xo.html
th-cam.com/video/rTWc_Sd-kE4/w-d-xo.html
I am of the opinion that a detailed and clear scope is required to get the job done. Expectations, outcome, verification, etc. Should all be present. Throwing jargon together and expecting a person to figure it out because they are senior is a sure-fire way to get them to have mental breakdowns and possibly quit. Senior does not equate to reading minds.
As a senior dev you should be able raise and articulate the issue with requirements so there is clarity. Most of the requirements I receive don't make sense and it sometimes takes weeks to define them from the requestor - quite often there is no PM/BAs nor architects so you cover those roles as well.
But hopefully we agree that a Jira headline for a huge feature implementation is not enhough ;-)
And what's the difference between senior and specialist
The 0s on your paycheck?
Any of your sponsors take programmers from poland ?
Why do I get an AI generated German translation? Where can I hear the original one?
Check your browser settings. Maybe there the translation may be activaded
Unfortunately, only technical skills matter to all the major companies until you make to the last few of 5-7 rounds of interviews.
Not true of the orgs that are genuinely good at SW dev in my experience, and understanding of what orgs like Google, Amazon and Microsoft do at interview. Often asking questions that are, at heart, trying to understand how good the person is at "problem solving" rather how good their memory of obscure technical detail is.
This is on point and, sadly, will get you fired in today's industry. Seniors now have soft skills (neurotypical, office politics, fit in with cliques, part of the "family"), can slop together solutions quickly without thinking about the problem so they have much higher "velocity" than the junior devs and don't hurt junior devs feelings by disagreeing with them. Good luck!
Almost all of this is true for technical consultancy as well.
This is accurate, .. but it's also pointless. There is no measurement of seniority within the management circles. We may have a good understanding of it but reality says NO. A person spending 10 years working on 20 failed (by his own fault) projects will still have more decision making power than one who did 5 years on 5 successful projects.
They say that an average software company is 3x less efficient than a high performance one. Meaning, if a company is in the middle of the bell curve they have, effectively, no idea how to build software. And the vast majority of companies are in the middle of the bell curve (duh). People who are interested in you, your books, your ideas do know that there is more to it, the rest is that vast majority.
One can report to a 22 year old CTO, the other cannot.
Não concordo muito, se ficarmos programando em várias linguagens, frameworks, SO´s diferentes seremos um pato. Nada mal, anda mal e voa mal. Um dev senior precisa ter pelo menos 4 anos em uma mesma linguagem, pois é nela que você irá masterizar os conceitos que depois podem ser aplicados em outras linguagens, stacks, etc.
My takeaway is that seniors wear glasses and juniors don't.
@@bernhardkrickl5197
😄😃😀
Juniors write code seniors build systems.
One have grey hair, and the other does not need little blue pills to perform.
Talking about developers here, not your dad