danwee

I would love to work as an Infra engineer. The biggest downside is that then you have to be on-call. I couldn't hate more being on-call. As a regular software engineer I hate being on-call for "normal" issues (e.g., a bug in our product breaks production on a saturday morning)... but being on-call for infrastructure issues (e.g., disk full, data corruption in db, dns problems, our aws region is down, etc.) must be the most miserable thing in the software industry.

Agree with the sentiment (statically-typed languages are cool), but TS is not ideal. Is the best we have if you want something JS-like, but try to explain the following monstrosity to a junior colleague who's starting with TS in the context of web applications (using one of the most popular frameworks out there, NestJS):

     // a DTO that handles the creation of some kind of resource
      ...
     @IsArray()
     @ArrayMinSize(1)
     @IsString({ each: true })
     @ApiProperty({
       example: ['software', 'maths'],
     })
     tags: string[]

That's real code. Since the TS types gets erased when the code is transpiled to JS, one has to annotate the whole thing just to be sure the clients are not sending us invalid data. And the validation via annotations couldn't be more cumbersome. 90% of the code in the DTO file is annotations. Reminds me Java from 10 years ago.

If the company doesn't have a decent on-call plan for such issues that happen outside of regular hours, then why on earth should I be the one who has to fix that? The company is not making me a favor by giving me a job, nor I am making a favor to the company either; it's just a regular business transaction and contracts matter. If my contract says 40h/week, then why the company should expect more? If my contract says that I'm getting paid X per week for doing on-call, then sure it's my job to fix shit outside working hours.

If you tell that "you break it, you fix it", I say "agree, but during working hours"

> which is not to sit at a desk for a few hours a day, but to deliver a product

Please, let's be professionals. You work is whatever your contract says (which yes, it usually says "to deliver a product" but it also says "40h/week"... at least mine says so)

> If you work more then you should get paid more

I guess you meant "if you produce more then you should get paid more", right? If so, yes I agree. But if you imply that just by working 25% more hours peer week than my peers I should get paid more, well, that's idiotic (maybe I'm working more because I cannot be as good as others who need less time to do the same?).

At least in IT, working more doesn't necessarily mean to produce (things of value) more.

There is a huge difference between "doing the bare minimum" and working outside of your regular working hours. One can do nothing at all working 10h/day, while another can provide high value working 9-5 (or even less).

Obviously, there are people who work 10h/day and produce high value as well, but it's not a requirement and most sane tech companies out there do not expect that from you.

Indeed, but I think we are too late for that. It's not like the usage of GOTO: someone who mattered wrote that its usage should be considered harmful, and hence nowadays GOTO has practically a niche usage.

If only someone that mattered would have written on time an essay titled "Microservices Architecture Considered Harmful".

What an argument.

Sun: can I live forever in a cave so I don't get any sunlight? No, you can't (in practical terms). But you can use sunscreen and you can limit the number of hours you get exposed to sun (don't be a dick and lay down on the beach 5h straight during hot summer days). Problem fixed.

Alcohol: can I live forever without drinking any alcohol. Yes, you can. Problem fixed.

> But alcohol is a cheap, readily available blunt instrument against this pain. No matter how bad you feel, if you down a litre of booze, that pain will definitely, and quickly, stop.

Never happened to me. I'm not a drinker but I have of course consumed alcohol. Life is as painful as usual with or without alcohol in my body. If any, life is more miserably with alcohol because I look more pathetic than usual (classic drunk face), my voice is not clear, my mouth smells like shit, and I walk funny (if I can walk at all).

Not sure about other drugs, though (never tried).

BTW, really dislike when companies call us such names. I imagine the reason is to create an atmosphere of security/family, but on me it creates the opposite reaction.

> * Most phone calls could have been an e-mail, with screenshots, facts, and numbers in it. On the phone, the caller has to read it out aloud, and I have to write it down. That is not efficient.

- You assume people know how to use e-mail and take screenshots

- People tend to assume phone calls cannot be forged (these kind of people haven't heard yet of LLMs) while e-mails can

- It's generally easier to call someone and tell them what's needed instead of spending time thinking ahead, write down the outcome (properly), send it and follow up the response

So, basically: people are lazy. It's human nature

Maybe offtopic: are take home projects or whiteboard excersises still needed for senior and staff positions? I had the impression that for anything below senior, yes these things were required, but for anything equal or above senior, the focus was mainly: systems design and communication skills.

Perhaps I'm a bit cynic here but this whole mess, turmoil, and hype is so far playing in our advantage (as "engineers"). If any, the real ones that are losing are the companies themselves (because we could work much much efficiently but we don't because we cannot even agree on what DevOps means, or if we actually need DevOps or not). This regardless of the latest trend of layoffs we have seen (I'm considering the whole planet, not just SV).

Don't get me wrong, I'm all for efficiency and the like, but if I were a mere "programmer" or "sysadmin" or "webmaster" I don't think I would earn as much as I do now that I'm a "platform/software engineer". Words matter. If you're called an "engineer" (regardless of whether you have a degree in engineering or not), then business people will think something more of you than if you're just a "programmer". Same for "platform" and "devops". Same for "data scientist" and "statistician".

You think knowing K8s justifies the $150K/year paycheck in your startup that has only 20 "engineers" and merely 5 services on production? C'mon. But here we are, and I'm more than happy to get those $150K/year for applying K8s and Terraform when it's not actually needed at all.

Posts like this one only reminds us that we live in a time where people is making money out of hype (scrum masters anyone?)... but as long as I'm making money as well, I'm happy to join the conversation and play the "let's fix this!" pantomime.

If I'm interviewing person A and person B, all things being equal, I'll go for the one that has a degree on CompSci (or equivalent). That's it. It's not that difficult. Obviously if person A doesn't have a degree but knows much more (based on the tech interview) than person B who has one, I'll go for person A.

> Every time I fought the double daily standups, the pointless plannings (where we plan when we know nothing, and by the time we get to work on the tasks, everybody forgets what they agreed on), I failed.

That's because indirectly you're suggesting to get rid of people as well. You see, for any pointless ceremony, there's someone (or more) behind it who get paid for that. If you suddendly suggest that perhaps ceremony A and ceremony B don't actually add value (which is probably true), then what you're suggesting is that the people who brought and who offer those ceremonies (typically scrum masters, sometimes PMs) are doing something pointless. You may expect that they won't hear you at all because who likes to hold the "I'm doing pointless stuff and get paid for it" label?

Upper management may know about this, but upper management is too concerned with other topics that they barely listen to the people at the bottom of the ladder.

Roles are meaningless, every company have their own. If you think you are senior, you'll put the "Senior..." in your linkedin profile (and CV) to get future offers.

So I don't think you're taking a step back at all (unless you are getting a salary cut as well, then yes, don't do it).

I did exactly the same: I was tech lead at company X (staff engineer) but then I quit to join company Y working just as a normal senior engineer. I got a 20% bump in salary raise... and now I have ahead more levels with the senior level to grown to (and also levels within the staff level as well)... whereas at company X I as already thinking about switching to management (I didn't want that either).

Also, I do always the same kind of job no matter where I am: if I can lead, I lead, if I can mentor I mentor... it doesn't really matter if that's my role or not.

If you're really a leader, then they will notice and will promote you within their imaginary and meaningless career path ladder.

I thought it was clear, but perhaps my English is not at that level yet. All the bullet points except the last one were more or less tongue in cheek. Sure, long names are required some times, just like super short names have their place as well.

Look, do suggest whatever you want, but if I'm maintaining an important codebase, I'll reject BS like:

- features without tests

- extraLongNamesJustBecauseYouHaveWorkedTheLastTenYearsInAJavaShop

- domain logic in my "Http controllers"

- domain logic in my "DAOs"

- copy-pasted regexes that you cannot explain

- adding 4 unmaintained dependencies from em-pee-em instead of writing the "algorithm" directly (which is at most 50 LOC)

- non-deterministic systems commiting to master

I know, humans are non-deterministic, but at least they dare to say "You were right. I don't know what I was thinking" when you point out their mistakes (if they don't say that, that's on you: they were a bad hire)

Well, you only have to pay $3.5K to find out!

It's the year 2023, and the human race cannot simply just talk to fix issues. Incredible.

To kill (or hurt) other human beings to protect "your" land or "your" loved ones baffles me. Yes, I love my loved ones (wow) but that doesn't mean I'm willing to kill people who are 99.99999% similar to my loved ones just because the politicians that manage the countries we happen to live in decide so.

We think that because we can send probes the the outer space or because we can do calculus we are so intelligent. We are still just monkeys who get mad when other monkeys say/do something to us that we don't like.

> You have to do “team” things too, and part of that is knowing what your team mates and boss are doing and expecting. How are you planning on doing that without talking to them?

You can talk without having weekly scheduled 1:1s. If there's a topic that needs to be addressed and you are the one thinking about it first, then you gather the necessary people, you write the necessary text for them to know the context before the meeting happens, and you scheduled a meeting inviting the people you think should know about the topic. Having scheduled 1:1s is orthogonal. I like to treat my managers using the hollywood principle: "don't call me, I'll call you"

> Their VR "visions" differ but only at the margin. No matter how you execute it, we are talking about people (homo sapiens) putting a major something on their heads that dramatically takes over their visual field for the pursuit of... what exactly? That is the puzzle.

I definitely think VR/AR is the next big think, but not via headsets, but via holograms or whatever it takes to get rid of physical screens and mouses (peripherals in general). You tell me I can have a huge 4K "hologram screen" projecting whatever is on my phone by just clicking a button? I'm sold. I mean, why would I read HN on my tiny phone if I can read it in a 13inch hologram display being projected from my wrist while I'm on the bus? Or a 30inch display when I'm on my couch? Same for whatever you do on the internet.

What Apple has showned us in the demo is the future... but not with headsets (if I go to the supermarket to buy milk, I'm not taking my headset, if I go to the bathroom I'm not taking my headset, if I'm taking the public transportation I'm not taking my headset).

You may think "high definition holograms" are just too sci-fi, but I don't think so. In any case, headsets are just too clumsy. Perhaps Apple's v2 for their headsets becomes just some glasses ala Google glass? In that case I don't know, maybe that gets traction if implemented correctly.

> Regional trains are as clean as any other trains. ICE really aren't that nice (and I find it hard to accept the price difference on that basis - the only reason why I'd ever take ICE is because I don't feel like taking 5 hours to travel from Cologne to Berlin).

I'm not saying regional ones are crap, just that in my experience ICE trains have been always cleaner than regional ones.

> They can be crowded around the times people are commuting, but otherwise they're not that crowded and it's easy to find a place to sit. If you're using the 49 Euro ticket to check out places nearby, there's no reason to believe you'll end up in a crowded train. Just make a tiny bit of effort not to take a train at peak times.

That's what I wanted to say. But again, compared to ICE, regional trains are "more" crowded (e.g., in peak times you see people standing and you can't barely move. I hardly see that on ICE)

> They're only particularly noisy if, I don't know, there's a big game locally and people are drinking on the trains. Even in a full train when everybody's going to or coming from work, people are really fucking quiet.

The more people, the more noise. Nothing particular about Germans/Germany. This is a human thing. So, taking into account the peak times, I think this is just pure common sense.

> I'm not sure what your angle is, but I'm not sure why you're misrepresenting the state of German regional trains.

My main point was that with the 49 euro ticket, one cannot travel as comfortably as one may think across Germany: mainly in terms of time.

For the ones who don't live in Germany: it's just for regional trains. So for instance if you would like to travel from Dusseldorf to Frankfurt (~200 km) people usually take ICE trains (direct, around 1h 45min. and 90 euros if you don't buy the ticket in advance).

On the other hand, if you are planning to use the 49 euro ticket... well, you either can't make it for the time slot you want, or you'll spend 4h-5h (best case scenario) with multiple changes in between. Also, regional trains are not like the ones one see in the movies: they are usually crowded, noisy, not that clean, and they are not always on time... which is rather critical if you are changing trains many times (ICE trains are more like the ones you see in the movies).

> It's easy to get overwhelmed by all the moving pieces

Exactly my thoughts! Isn't there something (open source and as good as Prometheus+Grafana) that doesn't have as many moving parts as the stack used by OP? I can imagine there are many use cases for that: from side projects (homelabs) to small startups that don't have huge distributed systems, but still need monitoring (without relying on third-parties).

Ideally, my setup would be:

- install an agent in each server I'm interesting in gathering metrics from. In this regard, Prometheus works just fine

- one service to handle logs/metrics/traces ingestion and that allows you to search and visualize your stuff in nice dashboards. Grafana works, but it doesn't support logs and traces out of the box (you need Loki for that)

So, basically 2 pieces of software (if they can be installed by just dropping a binary, even better)

> This is an interesting use case, I could see why GraphQL would be useful here where the contract between frontend and backend modules is not known in full and can change often.

But that's a misconception. If your contracts between frontend and backend are not known, you cannot just "open" your backend resources to the frontend so they are queried at will. That creates a huge entanglement that is only discovered after years of maintenance (at the beginning it may seem as a huge boost in productivity, but it's just pure tech debt: the debt you pay for not designing contracts between frontend and backend)

I don't. Not because of the idea of itself (I think the idea is good), but because of the implementation: we need yet another layer of abstraction to make it happen.

I would use GraphQL if it were natively supported (just like GET/POST/PATCH is, so no libraries on top needed).

It's because Apple is a (top) hardware company (and a software one) and they have years of experience at it. Meta is a software company; they could become a hardware company, but that doesn't happen in just a few years.

Google Search is in decline for the users who know how the internet works. For my mother, the internet is still Google (and would remain like that no matter what). For me, for some friends of mine, and for many of my colleagues who know more or less how things work on the web, Google Search is just in free fall: we use it as last resort, but as other search engines (or other tools, like ChatGPT) improve over time, Google Search would just disappear from our bookmarks.

I know that many of you would say that it doesn't really matter what "hackers" think about Google Search, that all that matters is that the majority of the non-tech-savvy users still think Internet == Google. Well, let's talk again in 5 years.

> There's more to a job than the salary

That only works for people who are earning a lot. I mean, for SV engineers there's probably a big difference between company A paying $350K/year with 10 days of vacation per year, and company B paying $300K/year with 30 days of vacation per year (I bet most would apply for company B, because the +$50K is not such a big difference).

For the rest of the engineers in the world (99% of us), a salary of $80K/year vs $130K/year is big difference and I don't know who would go for a job that pays $50K less no matter the other perks (which, at least in Europe are quite standard, so there's not much to be picky about)

If you're looking for a "junior" and you don't know what a "junior" means, then that's your problem, no? I mean, if you are willing to pay X for position Y, you (your company) should know exactly what you are looking for.

Otherwise you are just fishing and see what happens. Not bad, though, but I don't think that's an excuse for "can't list salaries in job ads"