

Ask HN: When are you no longer a “junior” developer? - cblock811

I was wondering when a developer has gone from junior to a regular developer. I imagine I&#x27;ll be on the junior end for quite a while (totally fine with this btw, right now I&#x27;m more focused on learning than title) but titles are sort of thrown around in the startup world. I imagine there can be certain criteria&#x2F;levels of competency that need to be hit that are more defined than &quot;When you feel comfortable and are productive working alone&quot;.<p>If you want more context, I&#x27;m a junior rails developer and am largely self taught. I&#x27;m still rather new in the startup scene as well.
======
klimslava
When you can see more than one way to build a project, understand all the pros
and cons in each of the solutions and can articulate them.

I'll give you an example: My friend hired two developers to build him an
e-commerce site with inventory control in the backend. There are dozen of ways
to approach this problem but the main thing to understand is, that he needs a
solid working solution.

This was their first job, they decided to build it from scratch in Django, by
reasoning that it has a great admin ui out of the box. Django maybe a good
solution if he had an IT department or the e-commerce was his main business,
but it isn't.

They should've offered him an off-the-shelf solution with minor modifications,
a solution that is widely used and can be supported by a lot more developers.

Their main concern was to build some thing new from scratch which is
tremendous amount of fun, and should be done when it is right, but it also
means that you are getting your leg work on the client's expense, which can
cost him to lose money.

~~~
5h
Django wasn't the problem there, and I hope you don't associate it with
difficult to complete projects!

~~~
cblock811
Everything has it's place for sure. In my case my coworker and I inherited a
rails app a contractor built. He did a good job getting a product out quickly,
but it was definitely rushed. So I'm going through the usual learning pains
(ex: I didnt know ReactJS, now I will) but I'm also encountering painpoints in
how our schema is designed. We just log what we don't have time to refactor
and move forward because of our labor constraint.

------
nostrademons
It pretty much is "when you feel comfortable and are productive working
alone". However, there's a lot to unpack in that statement. In particular, it
requires being able to understand trade-offs, knowing what to do when there
isn't a clear "right" way to do things, and understanding that often the
"right" way is situationally dependent.

If you're still focusing on the "how?" and "what?" of programming, you're
still junior. If you're starting to look more into the "why?", "who?", and
"when?", then that's an indication of a transition to a more senior role.

~~~
cblock811
Thanks for the feedback. Part of why I say that I'll be a junior for a while
is that I need to pick up a lot of best practices and general intuition on
projects. Learning alone sort of blocked me off from that experience early on.
Just gotta put in the time.

------
MalcolmDiggs
I tend to think of it like this:

Senior Developer: Comfortable leading a project, can understand architectural
problems at the birds-eye-view but can also zoom-in and get granular. Proves
their worth by heightening others' output, not just their own.

Developer (not senior, not junior): Provides lots of value to the team, in
(likely) a narrow area of growing expertise. Can be assigned loosely-defined
tasks and can "run" with them, and figure out problems independently. Asks for
help when stuck, lends help to others. Proves their worth by sheer effort.

Junior Developer: Needs guidance for most tasks. Needs tasks defined in detail
if they're going to be left on their own to complete them. Asks a lot of
questions. Proves their worth by being a sponge, learning very quickly, and
being willing to do anything.

------
5h
To add to the other answers,

Any given team has information flowing between members (be it business or
technical knowledge) - some members give out more information than they
consume - they are usually the senior ones.

~~~
ganarajpr
Love the sheer simplicity of this answer.

------
eshvk
nostrademons made some excellent points. I agree with him and also will
emphasize that it is a wide spectrum.

Very few "senior folks" are never interested in the "how" and "what". It is
just that you go through a cycle where initially someone else drives a lot of
your projects; then you find yourself working independently on many projects.
As you pick up more and more projects, you start delegating/helping other
people pick up more work. Enabling you to do more things. Now what title you
have is a function of your companies internal procedures. If you are new, I
would worry more on aggressively just doing more and more projects. Till you
feel comfortable going beyond the nitty gritty of programming to the why we
take up one project vs the other; technical tradeoffs, business risks etc.

------
cyberrodent
Check this out: [http://www.kitchensoap.com/2012/10/25/on-being-a-senior-
engi...](http://www.kitchensoap.com/2012/10/25/on-being-a-senior-engineer/)

