Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: When are you considered a “senior” programmer?

news.ycombinator.com

Post reply on HN
Print view View original

61–70 of 162 posts

Re: Ask HN: When are you considered a “senior” programmer?

#61

Post by captn3m0 »

>The final stage of programmer evolution is the Finder. These folks are considered experts in their chosen domain (and are prudent about others). Writing Finder job descriptions is an exercise in futility. As my boss put it: “I can’t tell you the specifics of what you’ll be doing here because your first task will be to figure that out.” A Finder will be able to anticipate problems before they happen, usually because they’ve been in that situation before.

From https://rkoutnik.com/2016/04/21/implementers-solvers-and-fin..., which is a really great read.

Re: Ask HN: When are you considered a “senior” programmer?

#62

Post by Shanea93 »

wvh wrote: post #54
TurboHaskal wrote: post #26

When you are valuable and ask for a raise but they cannot give the amount expected because it's already Q4 so they give you the senior title instead. It can happen even with two years of experience.

That's also my experience. "Senior" is little more than a random title in most companies I worked for. It can be someone in their early twenties who just happened to have worked for 2 years on one product, even if it's their first job. It's frustrating at first to join a new company as someone who is older and has many more years of experience, then you remind yourself it's just a random title and try not to get hung…

Anecdotally, I feel like this is how my older peers see me.

I've been working (professionally) in this industry since I was 16 years old, I got my first job as a junior after tinkering with computers since I was 8 years old. At the age of 23, I've found it very difficult to earn the respect of the people around me because of my age.

I have the title of senior developer because I've had experience working on scalability issues and complex service based infrastructures, but many of my peers who are my age and recently graduated university and are still in their first junior roles often act like I haven't earned it - despite me graduating with a part-time degree in software engineering (okay, it's not computer science, but I'm still glad I did it.)

My point is that while age is generally a good indicator of knowledge and ability, it's not the be-all-and-end-all.

Re: Ask HN: When are you considered a “senior” programmer?

#63

Post by z3t4 »

zumu wrote: post #28
z3t4 wrote: post #6

I would consider you a “senior” programmer? Mainly because you know that you do not know much. While a junior or intermediate programmer think they know everything. There are of course more to it, like when you are stuck on something; you ask the senior programmer, that will probably have solved it ten times in the past. Or if you want to know what the best method is to do this, you ask the senior programmer, that ha…

I'm interested in this 'two-paradigm shifts' rubric. Could you elaborate?

Programming languages and best practices evolve. For example object oriented programming, functional programming, goto instructions, global variables, include files, module systems, classes, template languages, PHP, MVC, XML, JSON, unit tests, test driven development, Git, JavaScript frameworks, SQL, noSQL, sequential, asynchronous, multi-threaded, etc.

Re: Ask HN: When are you considered a “senior” programmer?

#64

Post by misframer »

I really liked this comment by @stray [0] from a similar Ask HN from a few months ago. That thread was titled "Ask HN: What makes a Senior Dev".

    Mistakes, rewrites, late nights, firefights, and deadlines.
    Core dumps, memory leaks, hardware faults, and plain bad luck.
    Big O, data flow, always learning -- or out you go.
    Manager metrics, schedules hectic, methodology hegelian dialectic.
    Taking the heat, feature creep, open office, uncomfortable seat.
    Holy wars, revolving doors, carpal tunnel, all you can take? There's always more.
    Fucking suits, random reboots, and the ever present "thousand language stare".
    Oh yeah, pressure -- lots of pressure. And time, time, time.
    Metric shitloads of time.
    Time, man. You gotta do your fucking time.
[0] https://news.ycombinator.com/item?id=11341567

Re: Ask HN: When are you considered a “senior” programmer?

#66

Post by Nemcue »

merb wrote: post #36
CaRDiaK wrote: post #20

Earlier quoted context omitted.

"selecting/recommending tools and frameworks, based on what is most valuable for the business and the team" This is so true, I would say it extends to style amongst other things also. Having worked seniors on teams who had to seemingly make problems "worthy" of their skill and time served. For example working on a large OO Monoliths where a senior started to add lots of "clever" functional code. When I started the qu…

> For example working on a large OO Monoliths where a senior started to add lots of "clever" functional code. Adding a simplier design with functional code is a good thing. If there is a mid level developer that can't follow the current state of the art, than he is not a good mid level developers. Also "good" junior developers have mostly zero problems in understanding more functional code. I mean you don't need to u…

You need to realize most mid- and junior programmers simply aren't good.

Re: Ask HN: When are you considered a “senior” programmer?

#68

Post by fowlerpower »

I think a senior engineer has to know a few things.

They have to have the basics we all need as engineers simply to pass the interview process. The data structures and algorithms, Big O and be able to walk through systems they have worked on in the past and the trade offs they made and why.

Then on top of the basics I look for a few more things. Usually the understanding of multi threading, multi process, asynchronous programming is very different between junior and senior folks. I dive into distributed systems and see if they have any exposure. I dive into multi paradigms and how deep their knowledge is in their respective toolset they have listed on their resume.

I don't necessarily think you need to know multi threading in and out, or distributed systems in and out, or your tool set in and out. You certainly need to know one or two of those though. You need to have some body of work you can speak very well to, this is a huge indicator of seniority. Mentorship and all the other things that go with that help differentiate as well between junior and senior.

I don't think there is a hard rule anywhere. Different folks will look for different things and at least where I work those things I listed are very important differentiators.

Re: Ask HN: When are you considered a “senior” programmer?

#69

Post by qznc »

zamalek wrote: post #14
jakecarpenter wrote: post #10

To me, it is about what they are able to create independently, and the value of the end product. Senior people have made the right mistakes, wasted weeks of time, and know what to avoid, what to embrace, and what to ignore. A senior dev can understand the requirements and figure out what is important and deliver something without a lot of external input.

> Senior people have made the right mistakes This really sums it up, almost every other answer could be seen as a consequence of this.

Do you have to make the right mistakes yourself?

Re: Ask HN: When are you considered a “senior” programmer?

#70

Post by jobvandervoort »

At GitLab we have a formal definition for senior engineers [0] (where we accept merge requests, of course).

1. Technical Skills a. Great programmers: are able to write modular, well-tested, and maintainable code b. Know a domain really well and radiate that knowledge

2. Leadership a. Begins to show architectural perspective b. Leads the design for medium to large projects with feedback from other engineers

3. Code quality a. Leaves code in substantially beter shape than before b. Fixes bugs/regressions quickly c. Monitors overall code quality/build failures d. Creates test plans

4. Communication a. Provides thorough and timely code feedback for peers b. Able to communicate clearly on technical topics c. Keeps issues up-to-date with progress d. Helps guide other merge requests to completion e. Helps with recruiting

[0]: https://about.gitlab.com/jobs/developer/#senior-developers

Post reply on HN