"Mid-Level: Understands one or more languages more deeply"
I would change that up and require that a mid level have some proficiency with a second language. Preferably one with some notable differences as compared to the one they know. Like static vs dynamic or functional vs imperative.
I'd take it a few steps further. Change "Junior" to "Bootcamp graduate" and "Mid-level" to "Junior."
If there is anything even close to linearity between the "levels" of software development proficiency, then "Will understand code found on the Web before even thinking about copying & pasting code." is not equidistant from senior engineer as it is to "Might copy & paste code from the web (such as Stack Overflow) without understand it, if it just works"
Being a Junior developer should be a proud accomplishment, not a title for what you can buy for $10k and sitting in a classroom for a few weeks.
This was a very good read, thank you. To expand I'm an intern and some of the regular Software Engineers ask me for help, or I will show them how to do things. This helps me not get locked in my head that I'm just a "intern".
Being able to read and write code (even in multiple languages!) is one thing, but I'd argue that the real tipping point between a junior developer and any of the multitude of roles past that point is their understanding of the processes behind software development. Being able to establish testable requirements, architect and argue for/against possible designs for a solution, collaborate and help others do their jobs effectively in a team, and effectively design test cases are way bigger tells with regard to how far you've come than whatever it means to deeply understand languages. I'd even argue that hitting the books for long enough and writing enough purely hobbyist code would allow one to reach that point of deep understanding for nigh /any/ language. The same just cannot be said for those process-oriented skills, despite the fact that they're arguable of greater importance than the ability to write code itself as a professional software developer.
I am only 2.5 years into my career, and have written almost all of my teams shared libraries, security toolchain and deploy tools. I also am the sole person to maintain and develop our CI and artifact repos, do most of training of new hires in writing production code, as well as some architecture decisions.
I also recently quit because I felt I wasn't being compensated enough for my efforts, in either freedom to learn/explore further, nor money.
I agree with you about deep understanding and hobby code. At some point in my education, something just 'clicked' and I could see clearly that software contains no magic, only careful thought about data and trade-offs.
Another part I would like to emphasize is reading (other peoples) code. Related is learning different languages and their paradigms. It is very hard and time consuming to come up with well designed techniques and patterns, and reading code let you explore this knowledge in a much more efficient manner.
For the most part, one should specialize for performance reasons. If the project requires it, do it all -- put the whole stack together yourself -- it's not so hard to find the nuances to architecture as it once was.
I prefer the pursuit of possibility. I like the adventure, but I'm a dreamer by default. And I really enjoy building something out from the first, smallest grain and seeing it grow and eventually bloom.
To the parent thread: I have no idea. I run into counter opinions and situations regularly. So I just turned on the live stream from the ISS. He's (Fischer I think) outside right now and he takes turns leaving the camera on the horizon and pointing it straight down to the surface. A lot of feature on the Canadarm -- unintentionally probably.
My personal take on it is that junior/mid-level/senior/etc. are driven less by pure technical knowledge (someone can have encyclopedic knowledge of a piece of technology and still not be "senior"!) and more by how you think about things and affect others around you.
A rough breakdown would be:
* Junior: your focus and what you think about stays mostly on the piece of code you're currently working on. You should be able to answer questions about what you're doing, and explain how the code works.
* Mid-level: your focus is a bit broader. Now you're thinking more about a bigger chunk of a project, and several developers' efforts on it. This is where you should start being able to talk not just about what is being done or how, but also a bit about why. You may start being expected to pair with others of your level, or junior to you.
* Senior: again your focus is broader. Now you're thinking about entire projects/teams, and while you still do and must write code for those projects, you also spend an increased amount of time identifying things that slow or block everyone else, and putting in effort to speed up or un-block (for example, you might develop reusable libraries or solutions for common problems the team is running into, allowing everyone else to get work done faster).
12 comments
[ 3.0 ms ] story [ 40.9 ms ] threadI would change that up and require that a mid level have some proficiency with a second language. Preferably one with some notable differences as compared to the one they know. Like static vs dynamic or functional vs imperative.
If there is anything even close to linearity between the "levels" of software development proficiency, then "Will understand code found on the Web before even thinking about copying & pasting code." is not equidistant from senior engineer as it is to "Might copy & paste code from the web (such as Stack Overflow) without understand it, if it just works"
Being a Junior developer should be a proud accomplishment, not a title for what you can buy for $10k and sitting in a classroom for a few weeks.
Just a sec, let me glance at the date in the corner of the screen ...
The answer is a resounding "Yup!"
Ask me again in, oh, 2027.
I also recently quit because I felt I wasn't being compensated enough for my efforts, in either freedom to learn/explore further, nor money.
I agree with you about deep understanding and hobby code. At some point in my education, something just 'clicked' and I could see clearly that software contains no magic, only careful thought about data and trade-offs.
Another part I would like to emphasize is reading (other peoples) code. Related is learning different languages and their paradigms. It is very hard and time consuming to come up with well designed techniques and patterns, and reading code let you explore this knowledge in a much more efficient manner.
Also, full stack is a lie.
For the most part, one should specialize for performance reasons. If the project requires it, do it all -- put the whole stack together yourself -- it's not so hard to find the nuances to architecture as it once was.
I prefer the pursuit of possibility. I like the adventure, but I'm a dreamer by default. And I really enjoy building something out from the first, smallest grain and seeing it grow and eventually bloom.
To the parent thread: I have no idea. I run into counter opinions and situations regularly. So I just turned on the live stream from the ISS. He's (Fischer I think) outside right now and he takes turns leaving the camera on the horizon and pointing it straight down to the surface. A lot of feature on the Canadarm -- unintentionally probably.
A rough breakdown would be:
* Junior: your focus and what you think about stays mostly on the piece of code you're currently working on. You should be able to answer questions about what you're doing, and explain how the code works.
* Mid-level: your focus is a bit broader. Now you're thinking more about a bigger chunk of a project, and several developers' efforts on it. This is where you should start being able to talk not just about what is being done or how, but also a bit about why. You may start being expected to pair with others of your level, or junior to you.
* Senior: again your focus is broader. Now you're thinking about entire projects/teams, and while you still do and must write code for those projects, you also spend an increased amount of time identifying things that slow or block everyone else, and putting in effort to speed up or un-block (for example, you might develop reusable libraries or solutions for common problems the team is running into, allowing everyone else to get work done faster).