Live data from Hacker News

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

old.reddit.com

131–140 of 510 posts

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

#131
post #95

Earlier quoted context omitted.

> I’d take clear code that wasn’t working over code that was hard to reason about and somehow worked every day. Then you'd be out of business.

I look at it this way: Most likely the code I write has a bug in it. Or, at the time of writing, the customer requirement is fuzzy. Or, I have a limited grasp of the problem domain. Even if it is not any of the above, most likely there will be a change in a business requirement that impacts the code. So whenever possible, I opt to write code that is either stupidly obvious, trivially testable, or easily replaceable.

You have explained it much more clearly than me! Thanks.

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

#132
> Tech stack matters. OK I just said tech stack doesn't matter, but hear me out. If you hear Python dev vs C++ dev, you think very different things, right? That's because certain tools are really good at certain jobs. If you're not sure what you want to do, just do Java. It's a shitty programming language that's good at almost everything.

This got me and somehow bloody true.

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

#133

Earlier quoted context omitted.

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 s…

Yeah, I don't think there's anything special about working in tech. I've seen the same exact dynamic happen in lots of other fields. People who love cooking and become professional chefs only to leave after a few years is extremely common, for instance. So much so that I would have said it is pretty common advice that if you try to turn a hobby you love into a job, there's a good chance you'll end up losing your pass…

I still love programming and if I wasn't working I'd be doing it as a hobby. But its halfway satiated/suppressed by the sheer amount of it I have to do every week now.

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

#134
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,…

Also which "hero" is charging 5k for courses and what form does the course take?

(I work at Red Hat, and my programming heroes are also my colleagues.)

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

#135
post #22
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.

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…

Sounds to me like you have a bored engineer, and their energy is misdirected :)

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

#136
post #109

This, and the current “sober” posts on r/ExperiencedDevs, makes me think of Herodotus describing the way the Persians made important decisions - once sober, once drunk, and if the drunk and sober decisions were the same they knew it was a good one.

https://en.wikipedia.org/wiki/In_vino_veritas Is the phrase. Useful if you want to appear cultured at a company party.

This is right for the drunken dev thoughts, but not for the Herodotus example. "In vino veritas" - in wine there is truth - means that people expose their true thoughts when they're drunk rather than the filtered version they might present when sober, but the story of the Persians is more about the fact that there's value in considering both drunk and sober reactions, particularly when they tally.

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

#137
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.

But, I do not know if this metric is quite 'complete'. Because, I am very sure, wrapping concepts in mind is more difficult than understanding the code.

I am not saying the code cannot be made better or more clear. But, it also depends on who you are writing to. Somebody who is not familiar with certain style of programming cannot easily read the code of certain level of complexity.

When I was hacking away my first big program, I could not write functions. Or find reading functions easy. The whole thing was a big wall of glorified assembly sewn together by labels. I am not sure why I was like that then, but I found concepts 'functions' and recursion or any other conceptual stuff really hard. My code was, in its own twisted way, 'most simple' and utterly unreadable.

I find the same sort of difficulties while reading some FP snippets. I confess it was a very short affair, but I had some difficulty reading it and even when I understood, I could not just write or think code in the same style.

There are ways to make your code better, your intentions clear but 'can be understood by a first year CS freshman' is bit abstract criterion.

It is kind of like, vocabulary and prose. You can make your prose clear. But, people have to work on the vocabulary on their own.

> The best code is no code at all.

This is completely agreeable.

Edit : Changed some poor word choices. Added an analogy.

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

#138
post #65

Earlier quoted context omitted.

Antescriptum is probably the closest to the root of the word “pro-gram”.

That's a good find, but I was unsure of whether "program" is semantically equivalent to "code" here. Plus I'm tempted to leave codex since it sounds so good.

The Stanford law-as-code project used "codex", so I think it's good.

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

#139
post #94
post #8

Probably people are honest when they are drunk. There is nothing to argue with any of those comments. But this one stood out for me! > Titles mostly don't matter. Principal Distinguished Staff Lead Engineer from Whatever Company, whatever. What did you do and what did you accomplish. That's all people care about.

That's true unless you get acquired. At that point, your title is what your new overlords will use to determine your role, salary, and even whether to lay you off.

I've seen that happen to an excellent domain expert at a company during radical downsizing. Though TBF, that round saw fat, muscle, sinew, and bone cut.

To say nothing of a lot of brain.

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

#140
post #85

> 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. Sometimes fixing the problem will require special access to Production which you don't have, or even a specific role with that extra bit of initiative. Otherwise i agree 100%.

> Sometimes fixing the problem will require special access to Production which you don't have

If it's unfixable, that's when you quit

Post reply on HN