HN Explorer

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

4 points by cblock811 ↗ HN
I was wondering when a developer has gone from junior to a regular developer. I imagine I'll be on the junior end for quite a while (totally fine with this btw, right now I'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/levels of competency that need to be hit that are more defined than "When you feel comfortable and are productive working alone".

If you want more context, I'm a junior rails developer and am largely self taught. I'm still rather new in the startup scene as well.

10 comments

[ 3.2 ms ] story [ 41.1 ms ] thread
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.
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.

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