6 ms·

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 b

• TillE 3y ago
  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.
  • dexwiz 3y ago
    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.
  • kelseyfrog 3y ago
    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.
    • blowski 3y ago
      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.
    • kqr 3y ago
      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.
      • kelseyfrog 3y ago
        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.
        • munch117 3y ago
          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.
    • PeterisP 3y ago
      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.
  • kqr 3y ago
    Especially since the research on expertise already has a useful and operationally defined scale! https://two-wrongs.com/stop-using-junior-and-senior.html https://two-wrongs.com/stop-using-junior-and-senior.html
    • 082349872349872 3y ago
      TIL a "journeyman" is a "journée-man" (for thoughts on how to progress beyond "master", see https://news.ycombinator.com/item?id=39494801 https://news.ycombinator.com/item?id=39494801 )
      • CRConrad 3y ago
        > 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.
• SAI_Peregrinus 3y ago
  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.
  • xandrius 3y ago
    Speaking like a senior :D
• vinay_ys 3y ago
  clearly, you are a junior developer :-)
• eyelidlessness 3y ago
  > 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.
• lolinder 3y ago
  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.
  • WWLink 3y ago
    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.
  • dopylitty 3y ago
    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.
    • Aurornis 3y ago
      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.
  • mjr00 3y ago
    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.
• hnfong 3y ago
  > 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.
  • lolinder 3y ago
    > 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.
• ben_w 3y ago
  "Senior" is also pretty weirdly defined in our sector. I've seen it used for anything from "2+ years", to "10+ years".
• Aurornis 3y ago
  > 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.
  • neilv 3y ago
    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.)
• manicennui 3y ago
  Horrible companies are more common than well-executing companies.