Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

old.reddit.com

Post reply on HN
Print view View original

251–260 of 510 posts

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

#251

Post by tobesure »

vageli wrote: 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 find documentation to be relatively straightforward to write. The issue for me is sitting down and slogging through the activity, which seems almost antithetical to writing code. It's like doubling the work in a far less rewarding way. And then you have to go back and update it any time the code changes. It's a sort of necessary evil I suppose...I think most of the problem is that devs just can't be fucked to take the time, and I'm often guilty.

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

#252

Post by anyfoo »

akvadrako wrote: post #239
gkoberger wrote: post #203

Earlier quoted context omitted.

I think it's a grass-is-always-greener thing? Early in your career, you lean into one or the other. And then years later, after you're confident you're right, you find yourself trying the opposite paradigm and liking things about it. Both have pros and cons, and if there was a correct answer we'd all just go with that one!

I've switched between the two several times – not out of choice, just because that's what was needed. The order was BASIC, C, Python, Java, Go, Python, with Javascript mixed in the for the past few. I mostly prefer dynamic languages because static typing is just redundancy. The point of programming is to express high-level concepts which can't be captured quickly with types - if you don't understand the concept of th…

Yes, types are redundant, and that is their entire point. Just as much as giving your functions and variables names is redundant, you could just number them. So is splitting up your project into multiple files, all comments, and even structural keywords themselves--you don't need "for" and "while", you just need "goto".

Take all that redundancy away and what you get is not even assembly, it's exactly machine code. We used to program computers that way when they were invented. We still do sometimes in extreme situations. We got away from it for almost all of programming because it's incredibly error prone (and tedious).

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

#253

Post by MaxBarraclough »

craftinator wrote: post #200
mplanchard wrote: post #83

Earlier quoted context omitted.

IME good commenting alleviates a lot of the “problems” with using complex language features. I’m thinking redis style comments (see here[0] for antirez’s philosophy on the issue). If you’re doing something that’s not immediately obvious, explain what you’re doing! That way others can verify it during review, and when someone is reading the code later they can read the comment to understand what’s happening rather tha…

The mantra I use with my team is "comment the details, document the strategy".

See the taxonomy of documentation solutions, https://documentation.divio.com/ and https://youtu.be/t4vKPhjcMZg?t=324

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

#254

Post by gautamnarula »

frereubu wrote: post #17

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.

Reminds me of Hemingway's "Write drunk, edit sober."

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

#255

Post by dehrmann »

dmlittle wrote: post #212
dehrmann wrote: post #169

> Algorithms and data strictures are important--to a point For me, 90% of day-to-day algorithms use is not writing O(nm) or O(n^2) code, and knowing which data structures to use to avoid it (usually a hashtable, occasionally a heap or balanced tree).

It all depends on your use case. If your input is bound to a small N, I’ll take the simplest to understand implementation regardless of algorithmic complexity. Future you and other people will thank you later.

If small-bound is 50, yes. Otherwise, be careful; future people will not thank you for that timebomb.

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

#256

Post by Siira »

ggregoire wrote: post #179

> 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 started programming with .Net languages via Visual Studio (which is quite a good IDE), and I disliked dynamic languages exactly for the reasons you list. But nowadays I mostly prefer dynamic, optionally typed languages ala Julia.

Typing a '.' and seeing the members is very nice, except when the type is not concrete and it's not clear what type is actually being returned. Then you'd have to do trial-and-error using a slow compile cycle. In a dynamic language like lisp, you could just `(inspect x)`. In Python, you can just `embed()` and run, e.g., `x.__dict__`.

The IDE telling you about syntax errors and non-existent functions etc is very nice, except when you use macros and meta-programming and now your stupid IDE won't just shut up (I have this problem even with Python in VSCode).

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

#257

Post by edoceo »

gautamnarula wrote: post #254
frereubu wrote: post #17

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.

Reminds me of Hemingway's "Write drunk, edit sober."

Not for code tho. I've never seen booze help make good code

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

#258

Post by runawaybottle »

JMTQp8lwXL wrote: post #230
runawaybottle wrote: post #37

Earlier quoted context omitted.

I wish more managers and business stakeholders investigated this more carefully. Team members of this type add a shadow overhead that impacts velocity dramatically. It’s always visible to average competent devs on the team, but can be invisible to managers who don’t investigate as to why only one person is particularly productive on the team. Most people won’t go to their bosses and say ‘so and so writes overly compl…

> Totally neutral party that can come in and say ‘We’re pretty sure the codebase is too complex and we noticed the commits came from so and so’. This sounds like it'd reduce psychological safety on the team, to have someone without the project context come in and criticize your engineers. The morale decline of such a choice could outweigh the benefits.

It’s a suggestion. Generally, code complexity is created by someone that is actually pretty knowledgeable and competent. A straight confrontation won’t easily neutralize such a person in a discussion. They will know how to defend. If they also have peers they are close with, those friends will also negligently condone it with a simple ‘I don’t see anything wrong with that implementation’.

It’s a tough one, so I don’t even know where to begin other than an independent arbiter. Anyhow, I agree with you that it is a delicate matter from an emotional perspective (even though the underlying can be a reasonably objective matter).

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

#259

Post by Jiocus »

b3morales wrote: post #236
Tempest1981 wrote: post #16

Earlier quoted context omitted.

I've seen lack-of-documentation worn as a badge of honor. "I'm moving so fast, I can't waste my time on documentation. That's the next guys problem." And management is usually/always ok with this short-term optimization.

Also "if the code is clear, it documents itself". Which in my opinion completely misses the point. Good documentation doesn't tell you what the code is doing, it tells you why it's not doing something else.

That's a useful take,

Code says what is done. Docs says why

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

#260

Post by draw_down »

ilrwbwrkhv wrote: post #13

> 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 think it’s ok. That quote describes me too. There are lots of things to be interested in and excited by in life, computers are only a very very small thing. So don’t be saddened.

For me it’s almost like a graduation or transcending, getting so worked up about the details of computer shit just seems so silly nowadays. It’s actually quite dry and dull when you get down to it. There is a lot more to life.

Post reply on HN