
Am I still a Junior Developer? - rbanffy
https://dev.to/clickclickonsal/am-i-still-a-junior-developer
======
foundry27
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.

~~~
kochthesecond
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.

Also, full stack is a lie.

~~~
52-6F-62
A lie, maybe... I think it's conditional.

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.

------
ubernostrum
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).

------
tyingq
"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.

~~~
dieselz
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.

------
genkimind
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".

------
azekhv
There is a nice competency matrix for that:
[http://sijinjoseph.com/programmer-competency-
matrix/](http://sijinjoseph.com/programmer-competency-matrix/)

~~~
yoz-y
Level 2^n web programming: cannot make a large table viewable on mobile.

------
kazinator
> _I started to learn how to code in August 2014_

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.

