Hacker News Reader

Comment by misframer | Hacker News Reader

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

View on HN

There was a question a week ago about junior developers.

mrmekon [1] gave an excellent answer:

It depends on when and why I'm defining it, but my guidelines are more based on how they work than what they know:

* Junior developer - Will not produce much business value if left alone, and may produce nothing at all. Requires supervision.

* Intermediate developer - Will produce something if left alone, but not necessarily what the business most needs. Needs minimal supervision, but defined goals.

* Senior developer - Will produce immediate business value if completely ignored.

The domain and language don't matter for these, really. A Senior Go developer is going to produce immediate business value if you suddenly throw him/her into a Lisp team, too. Just slower.

Between the two answers I think they have it covered. Now some businesses will call people senior after they've been there 5 years, but they might still be a junior in capability.

[1] https://news.ycombinator.com/item?id=12557542

This is very much the perspective I have taken over the years. When I'm hiring a senior developer, I'm looking for someone who will step in and own the project they're given. If I had to pick a single expression, especially one recognizable to this crowd, I would say it is someone who can execute. I also tend to view senior developers almost as internal consultants (good ones) because they should be willing and able to step away from they keyboard and talk to a stakeholder to discern what the business really needs without needing someone else to act as an intermediary.

Where I do disagree just a little bit with mrmekon, is that I tend to look for people who have experience with the necessary stack. I would be hesitant to hire a senior developer for a C#/MVC position if they have (broadly) never used C# or never done web development, for example. Modern stacks have a lot of moving parts, and I would prefer senior developers to understand how to troubleshoot, tune, upgrade, test, and deploy on the needed stack. These are things that a very strong developer could remediate within a few projects, though, which is why I only slightly disagree with mrmekon.

With regard to your last comment about hiring senior devs with experience in the stack: I would say it depends on what you're hiring for and your long term vision for your team I think.

In my team's case, I was hired to do ML/BigData but had no prior experience. My boss's philosophy is that he wants smart engineers with a desire to learn more than he wants area experts. He's been burned more than once with area experts who were unable to pivot well with the shifting priorities of the team.

That said - if you're hiring someone to come be your ML expert then that requires an expert. Tech stacks are less that way in my opinion and they're rarely static. Even the debugging and troubleshooting tends to be similar if you know the problem space.

This seems to be a good road to go down, but low hanging fruit skews this a bit. For example at my first IT job they used a system that text messaged customers to remind them of appointments. It cost $250 a month per office (12 offices), I took initiative (I was the only IT person in the company, I had very little management) and replaced it with an alternative I wrote in Python that used Twillo and brought that cost to below $5 a month per office. The savings were slightly greater than my salary (I also provided general IT services that were then basically free for them), but I wouldn't call myself a senior developer or a developer at all really as I've only held IT services jobs.

Senior developers also learn to stop being needlessly pedantic.

You're right I am a senior developer.

I think he was saying the opposite. (Your reply seemed pretty pedantic to me).

The real question is, what is 'business value' then?

The business value defined by the engineering department and the business value defined by the business department, can be sometimes very different.

... And you expect a "senior" to be able to understand, negotiate and resolve this, as well as understand when and how to escalate, etc.

The term 'business value' is hard to measure for any given developer I think. The easiest measure is to say your managers define 'business value' and you deliver what they want or deliver to their strategic objectives, but that equates 'business value' to 'management whim'... if the manager is a perfect guide to maximizing profit then I guess that's ok, but I doubt most managers have that perfect ability to detect how to create profits. Alternatively, you might suggest that some cash/profit measure determines 'business value', but that's both hard to measure and not always strategic... some businesses need the best developers to build the systems that lose money in order to make money in other areas.... it's hard to measure.

With the way you've outlined it I think you've emphasized that a 'Senior developer' is someone who can be both social and technical, that's a good thing and would be very beneficial for any person who can do those two things well... but I wouldn't discount people who are exceptionally technical but need someone else to help them prioritize and define their work and focus.

I noticed a few years ago that what set me apart from my junior days was that now when I have a question, I decide what I think the best course of action is, send an email with the question and my choice, along with a statement that I'm proceeding in that direction unless someone stops me, and then start working on it.

Previously, I'd either have no idea what to do with it, or just not work on that thing at all. (Usually I'd move on to something else, since there was seldom that I didn't have multiple things that needed doing.)

It means that I'm a lot more efficient at getting things done, but I never get so far out of the proper path that it's a problem. And even going down the wrong path usually produces something of value for the correct path.

Ha, and the next level is; just do it and wait for someone to tell you it's wrong, which they probably won't but you've already argued the alternatives to yourself anyway. So criticism at that point is just opinion and doesn't matter.

I don't think I'll ever reach that level. While I'm very confident in my decisions, I'm wrong (at least a little bit) often enough that I always point out when I'm making those decisions.

Quite often I get no response, and just continue. But those time that I do get a response are still important enough that I'm not willing to risk missing them.

I've noticed a steady movement by companies to treat anyone with X number of years of experience as "senior" rather than their capability. Your definition is far better but harder to gauge compared to years of experience (likely why they do it this way).

Intermediate developer - Will produce something if left alone, but not necessarily what the business most needs. Needs minimal supervision, but defined goals. Senior developer - Will produce immediate business value if completely ignored.

The difference between these two do not seem to be related to technical ability but rather being able to detect 'business value' within the organization's general business model.

Technical ability, beyond basic competence and the ability to look 2 steps ahead, is a surprisingly small amount of what makes a developer useful.

Unfortunately this is glorifying a lot of terrible practices.

People who work in environments with, for example, "pressure -- lots of pressure" often end up not realizing there's another option that's actually a lot healthier for them, their coworkers, and their organization.

Senior professionals avoid all of that nonsense like the plague and would never glorify it. Senior people are professionals who work efficiently and effectively.

That's just beautiful!

So true! i also have this saved up. I read it time and time again, during rough and smooth times.

You gotta do you fucking time. Best Advice Ever!

Reply on news.ycombinator.com