Live data from Hacker News

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

old.reddit.com

181–190 of 510 posts

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

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

A better approach is usually to write test covering all edge cases.

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

#182
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…

I end up reading the source half the time, anyway; documentation is often incomplete, dated, and possibly incorrect. For code, I'd prefer the time go into designing a cleaner interface and making what calls do obvious.

That said, I find high-level documentation for larger systems to be very valuable. I also find Python's docs to be lacking compared to Java's; I'm often left wondering about the definition of what type is returned, exactly what parameters should be, and which exceptions are raised. Java's docs are very explicit about all these things.

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

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

I think of it as writing code for the computer/compiler, rather than for human readers. If the computer "understands" the code, you think you're done.

I real life working on a team with ever changing code, that is the barest rank minimum.

As a young programmer, I thought I was a master when I got the code to work. Now I know that is just the start. Making it readable and changeable is where real mastery lies.

This is very hard to convey to young fools as I used to be.

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

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

Related thing I'd add: be very careful about taking a dream job; I've seen this happen a few times--it's likely to disappoint. Also dating a minor celebrity crush.

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

#185
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…

I worked with a guy very much in that vein. He had enough years of experience to call himself senior, but it was clear his actual skill level was halfway between junior and senior at best. He wrote the most clever, fancy, opinionated code I've seen in a while, and he wrote a lot of it. I weep for the programmers that will come along in a year or so that have to figure it out.

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

#186

> The older I get, the more I appreciate dynamic languages. Fuck, I said it. Fight me. The other ones are quite obvious but this is the one that really resonated with me. People, with experience, tend to get more pragmatic and less "academic".

Pragmatic for me is knowing what’s wrong at compile time, and not being told much much later at runtime that I nested this array in a dictionary in an array wrong, or that my string is an integer.

I got older, stopped using python for exactly the reasons above (I just really felt that it was wasting my time for trivial reasons), and found mypy which made it bearable again.

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

#187

> front end AND back end AND... AND... AND... AND... AND... AND... Seriously, why are [full stack] webdevs paid so little. Two reasons: 1. everyone calls themselves this these days, and 2. they are often quite weak in each of those parts of the “full stack”

Yeah. I'm nominally a full-stack developer, but I know fuck-all about React; I can maintain an existing project, but it would take me a significant amount of effort and googling to kickstart one from scratch, and diagnosing and debugging issues and writing effective tests is always a struggle.

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

#188
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…

The same goes for junior writers who think that complex sentences and words are a sign of superiority, and later discover that the real (and bigger) challenge is writing clearly.

"I would have written a shorter letter, but I did not have the time." – Blaise Pascal

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

#189
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…

> effectively communicating ideas through text was one of the most underrated skills in software engineering

Absolutely. So many hour long meetings could be shortened by better communication skills (just more targeted), or even a small email chain.

Communicating in short form confidently is a skill. Many people, including myself (something I've been working on) struggle with saying something that was a complete idea in a meeting and not stopping because they feel like they need to say more. Short and sweet is the way to go pretty much whenever you can, for technical work that is.

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

#190

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

Agreed. Try going from "I think this is a callback that returns a promise which can return a string or an int?" to "The compiler/IDE are telling me this future can only return an int and won't let me advance until I make my code comply"
Post reply on HN