Live data from Hacker News

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

old.reddit.com

41–50 of 510 posts

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

#41
post #18

>Don't meet your heroes. I paid 5k to take a course by one of my heroes. He's a brilliant man, but at the end of it I realized that he's making it up as he goes along like the rest of us. I thought they were going to go the direction of "he's an asshole" and was ready to accept that, but this particular criticism is actually disturbing. People with strong visions can often appear to be "making it up as they go along,…

A common meme I've seen recently is "no one knows what they're doing". I think people like to believe this because it helps them cope with impostor syndrome, or maybe they think it puts them on even ground with people who do in fact know what they're doing.

It's clearly not true in all circumstances. You can bet that an airline pilot has a very clear idea of what they are doing, and so will your dentist. Closer to home there are plenty of sub-fields in software where I'd be completely lost but when (say) we have to add a new endpoint to the webservice I work with, I absolutely don't have to make it up as I go along.

Your assessment of why people like to believe this seems spot on.

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

#42

> When I first started, I was enamored with technology and programming and computer science. I'm over it. This is the saddest. One more soul taken by the shrinking of the hacker culture.

I don't know. Possibly it's simply because when you accept a career in the thing you're passionate about the thing you're passionate about becomes work.

Another thought that has occurred to me of late: when I started in this field it was "Computers" (capital "C") — a thing really by nerds, for nerds. Increasingly it's the web, mobile. Our "customers" are increasingly not us and so the decisions that would have come so readily to us on how to proceed, what features to implement are instead handed down to us from design, marketing....

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

#43

Earlier quoted context omitted.

Try building something of your own just for fun. See if you see sparks of your old love back.

That's the thing, I've been trying to do that for years now. I've got about a dozen cool ideas that bounce around in my head and a new one every few months or so. I can spend all my non-free time thinking about and designing them in my head, but when it comes time to actually write the code, I just kinda lose all motivation.

Yes, wait until writing code is no longer your job though.

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

#44
post #22

Earlier quoted context omitted.

Amen. Something bizarre I have noticed though in junior-almost-senior engineers is that they pride themselves in obfuscating and writing "highly complex" logic, with no documentation. It's almost like they are demonstrating their new abilities in the worst way possible. I have been dealing with one of these engineers recently, and they have expressed to me that they love writing because it's so terse. It's been a poi…

i was debugging some very terse, elegant, and dense code. i added a bunch of logging throughout to understand what was going wrong. someone then removed all of my logging because it was ugly. and then had to put it all back in when another bug was coming from the same terse beautiful code.

That hurt me to read! Have you communicated this to your manager? Might be worthwhile to have a decision "from the top" that is essentially: all logging is good, so long as it doesn't hurt performance or contain PII/PHI.

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

#45
post #5

> Good code is code that can be understood by a junior engineer. Great code can be understood by a first year CS freshman. The best code is no code at all. This a thousand times. Having empathy for future devs, maintenance, and bug fixes is so important.

This sentiment is exactly why programming in an org-chart is so much different than programming as an individual.

Don't apply corporate best practice designed to withstand turnover to personal programming - you're leaving abstraction and efficiency on the table.

The better code for your own projects is almost definitely inscrutable to a newcomer a lot of the time. It's okay for there to be prerequisites to understanding.

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

#46

Earlier quoted context omitted.

It really depends. I take this really just to mean "everyone has faults". People often idealize heroes and think of them as beyond human. If you do that and met your hero then your illusion will often be shattered. But the problem is just that you were putting them on an unreasonable pedestal. Of course some people are frauds and some people have no idea what they are doing but manage to make people think they do. Bu…

I like the phrase “kill your heroes”. Not literally, of course. But in your mind. They are just flawed people like everyone else that happen to have been mythologized. Learning more about your heroes often leads to disappointment.

I've recently found a podcast called "your favorite band sucks" that's along these lines. They have real criticisms of popular bands, but it's also a bit tounge-in-cheek. It's a nice contrast to the typical worship of rock bands. I think it's healthy to be able to enjoy something, or be inspired by someone, without buying into the mythology.

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

#47
post #5

> Good code is code that can be understood by a junior engineer. Great code can be understood by a first year CS freshman. The best code is no code at all. This a thousand times. Having empathy for future devs, maintenance, and bug fixes is so important.

Someone please translate that to Latin and start plastering that on office walls so people take it more seriously. It’s going to save all of our mental health in the long run.

It's been seven years since I've tried writing any Latin, so you should assume this is butchered. (edit: I think it's less butchered now)

codex bonus a discipulo prendatur

codex magnus a novo prendatur

codex optimus nullus est

Part of the problem is I couldn't find any good word for "code". "Codex" sounds cool but may not be the best fit here.

EDIT: Forgot a word. Also, I think "prendere" is better for "understood" here than "scire", which is more like "to know".

EDIT2: My friend suggested using the subjunctive for "comprehend" so that it's "may be comprehended" instead of "is comprehended". Also I got the tense wrong initially and I think that's fixed now.

EDIT3: "Ablative agents" are a thing. This is a rough language. Thanks, James.

EDIT4: prendar -> prendatur; aka "oops, should have used third person"

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

#48
post #18

>Don't meet your heroes. I paid 5k to take a course by one of my heroes. He's a brilliant man, but at the end of it I realized that he's making it up as he goes along like the rest of us. I thought they were going to go the direction of "he's an asshole" and was ready to accept that, but this particular criticism is actually disturbing. People with strong visions can often appear to be "making it up as they go along,…

A common meme I've seen recently is "no one knows what they're doing". I think people like to believe this because it helps them cope with impostor syndrome, or maybe they think it puts them on even ground with people who do in fact know what they're doing.

Even worst is the meme that “programming is just copy+pasting from stack overflow”

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

#49
> If I'm awaken at 2am from being on-call for more than once per quarter, then something is seriously wrong and I will either fix it or quit.

Yes, something is wrong. But it could be many things. Here is how you can find out:

1. Is the thing that's broken a bug in your code? Then it's your fault, so fix it. This means you need better testing too, and maybe a redesign to resist failures. Try to get alerts at 9am in dev so that they don't come in at 2am from production.

2. Is the thing that's broken a server thing that Ops is supposed to deal with? Probably you should quit. You can also work with Ops to redesign the server stuff to be something less prone to failure. Often Ops can't do this themselves because they don't know enough about how your apps work. Go talk to them, help them out. Or quit.

3. Is the thing that's broken a false alarm, or not important? Quit. Or work with Ops to create better alarms and tests. Ops doesn't know your app, so you need to help them craft the SLIs and SLOs.

4. Did Ops create all these alerts themselves without your involvement? Quit. Or take ownership of the tests and alerts for your apps.

5. Is it a huge slog to try to figure out how the alerting works, to work with Ops to make changes, to add tests, or to figure out what's broken or not and troubleshoot it? Definitely quit.

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

#50
post #5

> Good code is code that can be understood by a junior engineer. Great code can be understood by a first year CS freshman. The best code is no code at all. This a thousand times. Having empathy for future devs, maintenance, and bug fixes is so important.

Came here to post exactly this quote. I've never seen a wiser drunk. So lucid, and so relatable.
Post reply on HN