Live data from Hacker News

Drunk Post: Things I've Learned as a Sr Engineer

old.reddit.com

481–490 of 510 posts

Re: Drunk Post: Things I've Learned as a Sr Engineer

#481

Earlier quoted context omitted.

Glassdoor's tool is not very useful I've found. It only even somewhat works for salary, since it doesn't require bonus or equity incentives (which is sufficient in some markets, not others), leading to deflation of total comp. It also doesn't track things like overall years of experience, or how long a person has been in a position. All of those matter, as internal raises have tended not to match the market's increas…

"I have never worked extra hours to come up to speed (and in general haven't put in extra hours" What kind of job do you have? I thought extra hours were normal in tech? I have looked around. This area (Philly region) seems to be pretty terrible for tech jobs. There are some higher paying ones, but they tend to be niche.

Software dev, then manager.

Every place I've worked I've seen the same thing. Work/life balance is stressed as being important, BUT you will totally end up working extra hours if you cave to implicit pressures others set on you (oftentimes the business, product, etc). Someone will try and schedule you for a meeting at 5 PM, or say "we need this by next week", or whatever. And every place, I've said "No". Sometimes it's "I can't make that, I have to be home", sometimes it's "That isn't what we committed to this sprint" or even "That's what we committed but the sprint has been broken because (other thing)". Occasionally it's even been "Hey, we ran into something unexpected; even though we committed to that it isn't going to happen by that date".

On call pages happen; I always take time off the next day. As a manager, I -tell- my team to take time off the next day if they get paged.

Even where I am now, where I will have meetings scheduled at 7 AM, and 6 PM, routinely, I just close my laptop up in the middle of the day. Sometimes I'll even book time pre-emptively just to prevent people from trying to schedule me straight through (and thus leading to a > 8 hour day).

Etc. The perverse thing is that by doing this people actually get a -better- impression of me. There's an element of confidence; couple that with the fact I do deliver, and they don't question it or push back on it. And ultimately even if they wheedle enough I say "okay, fine, yeah, I have to talk to the guys in China; 6 PM meeting it is", I just book time 9-5 for my own stuff, or (when in the office), leave at like 3 so I can get home, unwind a bit, have dinner, and take that call, and still only work 8 hours.

I can't speak to Philly; you might be right. If you're tied to the area, consider remote. If you're not tied to the area, consider looking for things outside of it.

Re: Drunk Post: Things I've Learned as a Sr Engineer

#482
post #3

> The most underrated skill to learn as an engineer is how to document. Fuck, someone please teach me how to write good documentation. Seriously, if there's any recommendations, I'd seriously pay for a course (like probably a lot of money, maybe 1k for a course if it guaranteed that I could write good docs.) I agree but think it is more than just _documentation_: effectively communicating ideas through text was one o…

Not only in writing but also in plain English. I see situations like described below over and over.

Example 1 - too much details. Morning stand up. Manager: what's the status of that new feature. Senior Engineer: well I tried to call that service but it was timing out so I spoke to Bob and he said to check with DBA on why that stored procedure but it's so slow and turns out index is missing so we tried to add it but mysql and varchar something fckn something...

Dude couldn't you just tell it's delayed due to DB and then expand if needed.

Example 2 - insufficient details I return from the meeting and discover avalanche of emails, chat messages and urgent meeting invite, all with same topic - "Blah service fails, we are blocked" but no details apart from that. On the call I get description of the problem - blah service fails and how everyone is blocked and how infinitely critical it is and what ETA for resolution would be. What endpoint? How does it fail - timeout, connection aborted, 503 response, 200 response but with error message?

Re: Drunk Post: Things I've Learned as a Sr Engineer

#483

"I don't know why full stack webdevs are paid so poorly." - The barrier to entry into webdev is low. You just need a laptop. - An awful lot of websites seem to have been thrown together by morons; shipped; and never improved. - For most sites, performance isn't an issue - strong tuning skills for PHP, SQL and Javascript are not an issue. - A "full-stack webdev" generally doesn't do the full stack - few of my webdev c…

Most of full stack web devs I know know everything but know it anywhere between poorly and ok-ish. It works more or less fine until there is some issue which requires deep knowledge of either of the stacks.

Generally I'd prefer to have front end dev + backend dev in my team over two full stack devs.

Re: Drunk Post: Things I've Learned as a Sr Engineer

#484

> The older I get, the more I appreciate dynamic languages. Exactly the opposite for me. I just can't stand hovering a variable or a parameter and not getting its exact type, or typing "." after a variable and not having my editor gives me all the available methods on that variable, or running my code just to discover that it instantly crashes because I made a typo or forgot an argument or passed the wrong argument o…

I've been doing TypeScript for 4+ years and been a web developer for 20+ years. And I experience literally zero benefit from TypeScript. Never has it given me anything useful. To me, it's a massive pain in the ass that slows down myself and my team, even if they think it doesn't. They just don't know JavaScript or have shitty quality of code to begin with. That, and TypeScript generics can get so freaking complex tha…

In response to that article: Well, probably the gold-standard for "native JavaScript" tooling is actually provided by TypeScript itself lol. In VSCode it's the TypeScript compiler and language server that's providing the excellent JavaScript autocomplete.

So I'm in agreeance then? Well, no, and that's why I air quoted "native JavaScript". It's extra good because TypeScript/VSCode is silently utilizing the ".d.ts" files that third party libs ship with in the background! I believe as well, at least at one point, it would auto-fetch existing "@types" packages for libs that don't ship their own.

Re: Drunk Post: Things I've Learned as a Sr Engineer

#485

Earlier quoted context omitted.

You have a great point, but let's balance this out with a few of the author's other comments. - OP uses the phrasing senior engineer. - Never worked for FAANG. This is relevant because $120k + bonus/benefits is basically a FAANG new grad. Fairly normal for SV tech companies. - Those numbers likely provide a solid standard of living, but as a senior engineer you are likely underpaid. - Esoteric and proprietary knowled…

I'm an intermediate dev, masters degree, 9 years experience, non-FAANG, higher cost of living area (not SV, NYC or NVA), and work with obscure tech and proprietary tools. It sucks that I suck. Oh well.

Obscure tech and proprietary tools do translate… if you can translate them.

Programming languages are all the same, so learn 3 or 4 new ones and discover that you can probably write in any language for an interview (then do some in relatively unfamiliar languages for kicks and giggles to practice).

Tech is all the same. Take data in, poop data out. That’s the whole job. The formats and protocols change, but once you starting thinking about your stacks as data-in, data-out, they all start looking the same.

Make video games or hardware drivers from scratch, those are the hardest things to make. Video games from complexity overload, and hardware drivers from interface complexity.

Re: Drunk Post: Things I've Learned as a Sr Engineer

#486

Earlier quoted context omitted.

Eh, that's a nice thing to say, but it only makes sense at certain scales, and no matter what, there's always a person that can break it. If any random person can break it, it's already broken. If any employee can break it, it's probably broken (there are very small scales where even this doesn't apply. Ever worked for a company with less than ten people? There's probably something any employee can break). If any emp…

There are lots of places where we require that no single person can break the system at least in a certain way. For example code review and LGTM ensures that a single individual can't just break the system by pushing bad code. Often there are other control planes that don't have the same requirement, but I think the idea that there must always be one person who can break the system isn't clearly true.

> For example code review and LGTM ensures that a single individual can't just break the system by pushing bad code.

Assuming code reviews are 100% effective at catching issues, particularly issues that cross multiple projects. Yes.

Re: Drunk Post: Things I've Learned as a Sr Engineer

#487

Earlier quoted context omitted.

There are lots of places where we require that no single person can break the system at least in a certain way. For example code review and LGTM ensures that a single individual can't just break the system by pushing bad code. Often there are other control planes that don't have the same requirement, but I think the idea that there must always be one person who can break the system isn't clearly true.

> For example code review and LGTM ensures that a single individual can't just break the system by pushing bad code. Assuming code reviews are 100% effective at catching issues, particularly issues that cross multiple projects. Yes.

I'm making an (admittedly subtle) distinction here between complex mistakes, where something was missed, and simple mistakes/bad actors where someone used a privilege in a manner they shouldn't have.

LGTM ensures that, for example, a single individual can't push a code change that drops the database. On the other hand, that same individual might be able to turn of the database in the AWS console.

Re: Drunk Post: Things I've Learned as a Sr Engineer

#488
post #432

Earlier quoted context omitted.

See: https://danluu.com/hn-comments/ >HN comments are terrible. On any topic I’m informed about, the vast majority of comments are pretty clearly wrong. ... >And yet, I haven’t found a public internet forum with better technical commentary. On topics I'm familiar with, while it's rare that a thread will have even a single comment that's well-informed, when those comments appear, they usually float to the top. On othe…

Pretty much this. HN is still gazillion times better than everything else on the internet. And that is excluding the absolute gold comment from members that were part of those battle stories. It is also a reason why I dont want to mention or see HN links in mainstream media. Although I think most reporters sort of know this as well and tend to not mention or link to HN as source.

My experience of Hacker News comments is not positive. They tend to be very convincing but actually kinda bullshit (or just vacuous), which is arguably a lot worse than communities that are transparent.

Re: Drunk Post: Things I've Learned as a Sr Engineer

#489
post #432

Earlier quoted context omitted.

Pretty much this. HN is still gazillion times better than everything else on the internet. And that is excluding the absolute gold comment from members that were part of those battle stories. It is also a reason why I dont want to mention or see HN links in mainstream media. Although I think most reporters sort of know this as well and tend to not mention or link to HN as source.

My experience of Hacker News comments is not positive. They tend to be very convincing but actually kinda bullshit (or just vacuous), which is arguably a lot worse than communities that are transparent.

That’s what Dan is saying - but once in awhile you find a pearl in an area you know enough about to confirm.

Otherwise it’s best to assume everything you read here is full of it.

Re: Drunk Post: Things I've Learned as a Sr Engineer

#490

Earlier quoted context omitted.

"I have never worked extra hours to come up to speed (and in general haven't put in extra hours" What kind of job do you have? I thought extra hours were normal in tech? I have looked around. This area (Philly region) seems to be pretty terrible for tech jobs. There are some higher paying ones, but they tend to be niche.

Software dev, then manager. Every place I've worked I've seen the same thing. Work/life balance is stressed as being important, BUT you will totally end up working extra hours if you cave to implicit pressures others set on you (oftentimes the business, product, etc). Someone will try and schedule you for a meeting at 5 PM, or say "we need this by next week", or whatever. And every place, I've said "No". Sometimes it…

That sounds nice.

I've found that if I only work 8 hours they will say that I'm not getting things done fast enough. It makes sense if they are comparing you to people who work more. I know one department where the tech leads all work 10 hours consistently.

I was once in a discussion about how to get to a senior dev position (after filling the role of senior dev for a year and tech lead for another year). I was told I had to work an extra hour per day. That's a 13% increase for a 7% raise and a role with higher expectations...

Post reply on HN