Hacker News Reader

Comment by xandrius | Hacker News Reader

It's just reads that the author works/worked at horrible companies.

Also because someone gives you the title senior, you don't immediately become one: for me being senior is about changing one's mentality (through experience) that a problem can almost always be solved, and bringing that confidence to the team. As a junior one often worries whether they have enough skill, as a senior you know you do and whatever you don't know, you'll learn it.

Boring meetings, working during the weekends, stress and awful legacy tech is not a necessity.

View on HN

The bit about working weekends and evenings was especially annoying to me.

What people who do that don't realize is that pulling late nights and weekends for a deadline more often than not just validates badly planned deadlines that were never going to work out. It's a vicious cycle: if you sacrifice your personal life to hit a deadline, then the people in charge of setting deadlines get a false idea of what "normal" is and you'll end up doing the same thing next time.

It's not that there's never a valid case for working after hours (like, say, a dedicated on call rotation), but I'm pretty firmly opposed to doing so to meet a deadline. It's unfair to yourself and your co-workers to teach product/management/whoever that work can be planned out on the assumption that your team will pull late nights to make it happen on an arbitrary schedule.

Easy. This dude is probably a business owner trying to neg their programmers into thinking that they're easily replaced cogs in a machine that should give their job priority over their life.

A dedicated on call rotation also isn't a valid case for working after hours.

If companies want their infrastructure worked on 24/7 they need to hire 3 shifts to take care of it. If they don't want to pay for 3 shifts they should shut their business down after hours like a normal business, not exploit people by making them work 24/7.

If you don’t like on call rotations then you shouldn’t be working on services that come with on call responsibilities.

However, suggesting that every Internet business needs to shut down after hours is one of the more out of touch things I’ve read in this comment section.

> not exploit people by making them work 24/7.

That’s not what on call rotation means. You shouldn’t be “working 24/7”.

On call should be a rare event.

Part of being senior is having enough business context to know when to pull late nights and weekends. If you're doing it because the gantt chart some PM created 18 months ago said project X would be done by next month but everything is off the rails, yes, it's foolish and unfair to work nights and weekends to make it happen. If you're doing it because re:Invent is in a month and your team has a new AWS service to announce, that's a much better reason. Or in the startup world, if there's a major client demo next week and you're quickly hacking in a new feature they've been asking for.

Maybe but then you are reinforcing bad planning and behaviour from management. Far better to reduce the scope or content so you don’t hit that deadline totally spent.

I agree that sometimes you need to do it in order to not totally screw up the business, but I think any case where you make that decision should require a postmortem where everyone involved in that deadline gets together and figures out why it couldn't happen during the team's regularly scheduled hours. If you do it quietly without making it very clear to the business that this was abnormal and should not happen again, then you're still feeding the false idea that it's okay to plan around late nights and long hours.

An early stage startup is a possible exception as long as your entire team is on board with it and getting a satisfactory amount of equity compensation. But the entire team has to be on board with working extra hours, it can't just be you deciding that for the team.

As your project manager I now know I just have to come up with a "good reason".

The good news for everyone is, you can't just make up a good reason out of thin air! (unless you're lying). There's either a critical business need, or there isn't.

This of course requires this senior engineer to be business-savvy enough to discern when there's a legitimate business reason given, and at big companies that may require knowledge of politics among the higher ups which may be opaque to most folks.

That's a whole long list of caveats you got there.

I don't think it's really about "the people in charge of deadlines". When you, as a senior engineer on the team, work crazy hours, all the junior folks on your team who look up to you (even simply because they also want a fancy job title down the line) copy that behavior. And then it becomes the new normal.

Also when a senior engineer does this, it sets expectations for junior engineers.

A senior engineer who does this is harming their team more than most other technical related things.

> just validates badly planned deadlines

I’ve spread this message far and wide across dozens (hundreds?) of industries. I’m sure we know but I think it’s helpful to be explicit: the mindset at the heart of this is not specific to software and can be found at pretty much every management level and it’s hurting everything.

At “best” you have an endless stream of overworked employees who burn out and get replaced when they stop being able to “keep up” but even then the business has no idea what things actually cost. They can’t do budgeting, they can’t do calculations, every report based on employee productivity is wrong.

Working beyond your means sets the company up for long-term failure.

> Boring meetings, working during the weekends, stress and awful legacy tech is not a necessity

I did some mentoring in a program for juniors for a while.

The most common problem we saw was unrealistic expectations. Kids had grown up reading comment sections like HN and Reddit where people complained about every little thing and painted unrealistic pictures of what a job should be like.

Then these people grew up, graduated, and thought they were going to walk into jobs where they would work exclusively on passion work in greenfield projects with the hottest tech stacks, never have to sit in a meeting, and that they could work at whatever comfortable pace they wanted and nobody should be able to complain about how long it was taking.

There were frequent crises when people took their first jobs and got assigned to work on legacy codebases, for example. I lost track of how many times I had to explain to someone that a big company isn’t going to entrust the fresh-out-of-college (in this case, mid-tier college) junior to own a greenfield project in React, or how often I had to explain that deadlines are a fact of life in some businesses (e.g. those with contracted deliverables to customers depending on the product going live at predictable times).

Of course, there were other times we had to explain to people that their jobs were bad: People who had 25 hours of recurring meetings every week or companies that expected people to work 9AM to 9PM every day. This was very rare, though.

I don’t know the solution, but I can say that the way the internet talks about tech jobs as if they should never be the slightest bit uncomfortable is causing a lot of whiplash for juniors when they encounter reality. Sometimes you’re going to have to sit in some boring meetings or work on a legacy project. You shouldn’t be grinding away every weekend, but a job is sometimes going to be a little uncomfortable relative to some of the hyper-idealistic things we talk about online.

Agreed, it's absolutely true (in this and other things) that some people need to be advised "more than your current is better", while others need to be advised "less than your current is better".

I think you can teach that (at least at this org) the job is about professionalism, in a team, and what the actual nature of the goals is.

You really teach it by example. Articulating it can help, as a suggested interpretation of what you're demonstrating, but people will notice if you say one thing and do another.

Also, if they're still confused, tell them that much of what they've read on the Internet is for different kinds of organizations or individuals. (I'm recalling, for example, one of those influencer videos about day in the life at a FAANG, where almost the entire day is spent getting free food, walking around campus and bumping into other barely-20 friends and chatting and laughing like you're still carefree in school and don't know anything yet, plus a coding/debugging session and a product meeting, both of which seemed like fashion poses. Hahaha. Learn the professionalism, and have a life, but think more about conscientiousness than fabulousness.)

I feel like it's only in the past few years people have been talking about "junior" vs "senior" except as literal job titles. It's a weird binary distinction when of course gaining experience is a gradient.

Because they are two different jobs usually. Juniors are more focused on code while senior trends towards planning, reviewing, and leading. In my experience a senior is just as likely to spec out some work and pass it on as do it themselves.

It is of course a gradient, however, on that gradient there exists an important threshold: can this person, under their own direction, produce positive net value?

Juniors require your active guidance. Seniors require your availability.

I consider the size of relevant “horizons” - time, number of features, number of people. A junior should be able to have a positive impact working independently within very narrow horizons (a single function, 1 other person, 1 hour), and is showing growth as those horizons increase.

There is no such universally accepted definition of these terms.

The one you propose is useful and how the literature on expertise defines a journeyman but the word "senior" is highly ambiguous.

There's no universally accepted definition of any term so I'm not sure how that's relevant. That's how I describe my own perspective, others are free to differ. Language can be vague and useful.

When it comes to being ambiguously defined, "senior" is not just any old term. A senior can be someone who's two years out of school, or it can someone of retirement age (senior citizen), or anything in-between.

Given context, an otherwise ambiguous word can be useful. "Senior" needs a lot of context, though.

I'd assume at least a three-layer distinction for this - juniors require guidance, seniors can provide it, but there's a lot of middle grounds and many years of work where you're not junior (at least according to this criterua) anymore but not yet senior.

Especially since the research on expertise already has a useful and operationally defined scale! https://two-wrongs.com/stop-using-junior-and-senior.html

TIL a "journeyman" is a "journée-man"

(for thoughts on how to progress beyond "master", see https://news.ycombinator.com/item?id=39494801 )

> TIL a "journeyman" is a "journée-man"

By that guy's "executing a day’s work" definition. Usually it's used in the same sense as medieval - early modern guild terminology: After having apprenticed with your first master you set out on a journey to learn further from other masters of the craft in other towns. (Hopefully to graduate to master yourself after a while. No intermediary "expert" step in those days.)

But maybe that's what you meant. Sarcasm is sometimes hard to detect online.

> It's just reads that the author works/worked at horrible companies.

Hard disagree.

> Boring meetings, working during the weekends, stress and awful legacy tech is not a necessity.

Boring meetings are not a necessity, but meetings are. (Article mentions no "boring" meetings.) If you don't think so, you're not senior enough.

Working on weekends is not a necessity, but when unexpected crap happens the senior engineers will be called upon whether it's a weekend or not.

Stress is not a necessity, but most people feel it out of increased responsibility. This is a personal/subjective thing, but it doesn't reflect that the company is horrible. Quite the opposite -- if you believe your work is meaningless, and feel OK with doing meaningless work, there's actually not much you can stress yourself about. It's only when you believe there's high stakes that stress becomes high.

As for legacy codebases, it doesn't have to be awful (also note "awful" is not mentioned in the article). A senior engineer who has worked on the project/team for a couple years probably had a role in creating it, or at least has the most experience with it, which is why it tends to be the senior engineer who has to debug it. And if you think overhauling systems just because they're almost 10 years old is always a great idea... well you're not senior enough.

To be fair, I suspect in the contemporary scale of "senior" titles, the stuff in the article is more akin to "staff" level roles than "senior" roles (the latter AFAICT basically means you're technically capable of doing things independently, which is what you're alluding to).

The realization that you need to hold meetings to align and share information with the team (and management), that if you don't fix the outage at 2am nobody else could, that you rather fix the issue in the legacy codebase yourself than assign it to junior team members and subject them to endless frustration... is probably beyond the experience of the typical "senior" level dev.

> Working on weekends is not a necessity, but when unexpected crap happens the senior engineers will be called upon whether it's a weekend or not.

But the headline for that section wasn't "senior engineers spend more time on a formal on call rotation", it was "it’s fine, I’ll finish the work on Saturday."

Unexpected issues should be expected and planned for with a dedicated on call rotation that is almost never used because you're setting time aside during the work week to fix common issues. Unexpected issues shouldn't lead to random senior engineers getting called when they're not expecting it.

And as for "I'll finish the work on Saturday", it's a hard red flag of a bad work environment if that's happening with any kind of regularity. Normal work bleeding onto weekends and evenings should be a five alarm fire that gets addressed immediately in any company that values their employees. It should not be in a list of things to expect as a senior engineer.

I generally agree with what you say. Except that I think it's more likely a red flag for the author of the article, not necessarily the company (but of course could be), depending on whether which side had the greater authority to set or influence the deadlines.

Sometimes it's easier said than done though. At some point of seniority you basically have to make the engineering estimates whether features/tasks could be done within a deadline. If you made a mistake, you might end up having to own it.

A problem can almost always be solved, the question is usually whether it's economical and/or timely to do so. If I have to learn a new skill to do something I have to factor that learning time into my estimates, so that management can plan enough time in the schedule.

Speaking like a senior :D

> As a junior one often worries whether they have enough skill, as a senior you know you do and whatever you don't know, you'll learn it.

Heh, basically becoming senior means overcoming impostor syndrome? Aligns pretty well with my experience.

"Senior" is also pretty weirdly defined in our sector. I've seen it used for anything from "2+ years", to "10+ years".

Horrible companies are more common than well-executing companies.

clearly, you are a junior developer :-)

Reply on news.ycombinator.com