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

151–160 of 510 posts

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

#151

Post by mikepurvis »

daenz wrote: post #40
swader999 wrote: post #32

Earlier quoted context omitted.

What is wrong with making it up as you go? I mean everything I've ever built I had a notion of what I was doing but most of the real work was in the details. Anyone could say I was making it up as I go. I'd be like yeah, if I knew completely how to do it, I'd already be finished it. Then there's the times where you think you know exactly what you're doing and after going down a road you realize it's the wrong way. Fa…

Nothing wrong with making it up as you go, and I didn't mean to sound like I was knocking it, if I did. Sometimes everyone fumbles around trying to find solutions that work...it's a totally valid way to approach some problems. Sometimes it's a hybrid of knowing what you are doing but not knowing the implementation specifics. You know you need to connect high-level pieces A, B, and C with specific constraints, but it…

Using a phrase like "fumbles around" still sounds like you're placing it on a lower rung, whereas I would say that basically everything I've ever done has been an iterative, collaborative process, including in situations where I'm highly confident of both the problem domain and technology choices. There are always going to be new discoveries made during implementation, and you can't have a written-in-stone design doc that prevents anyone on the team suggesting a refinement.

For myself as an opinionated person in a devops role, the vision that I try to communicate to my colleagues is mostly broad principles like configuration as code, helping people help themselves, consolidation of systems, and then some more pointed specifics like don't touch prod, don't make changes without a consensus, start by understanding why it's the way it is before changing it, etc.

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

#153

Post by ocdtrekkie »

AlexCoventry wrote: post #66
daenz wrote: 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…

> Something bizarre I have noticed though in junior-almost-senior engineers is that they pride themselves in obfuscating and writing "highly complex" logic I think it happens because most measures of code quality are quite fuzzy, but brevity (which is valuable, other things being equal) is relatively objective. "Have I made the code shorter?" is a much easier question to answer than "Have I made the code easier to un…

I think another place people can end up here is if they don't know what the compiler is doing under the hood, it's easy to assume the shortest code will perform the fastest or something like that. "Presumably this cool trick avoids these extra steps" type of things.

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

#156

Post by obstacle1 »

sharken wrote: 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%.

If you're frequently being paged for stuff you literally can't fix, then the process/monitoring/alerting has broken down somewhere and needs to be fixed. If it can't/won't be fixed, then the company needs to hire ops people whose specific job is to react to and triage system failures -- devs should not be treated as escalation machines. If the process can't be fixed and the company won't hire people to handle the process, then you quit.

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

#157

Post by porker »

ratww wrote: post #120
daenz wrote: 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…

Amen to that too. That's probably the most complicated part of being a manager or tech lead. You have those amazing junior-almost-senior engineers that could be way more productive and yet deliver better code, purely by "doing less", but the over-engineering gets in the way. You know they could be top-contributors, so you don't want them to leave. But at the same time it's very tiring! I noticed that they put a lot o…

What alternative methods have you found to get them to "see the light"? I've found myself wishing they'd do therapy, but that doesn't help and can't be expressed.

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

#158

Post by wilsonthewhale »

creamytaco wrote: post #62
sundvor wrote: post #33

Earlier quoted context omitted.

Do it, if only to find Clojure.

Clojure goes against so many of lisp's timeless philosophies and principles that it can hardly be described as a lisp. When someone says "lisp is the greatest programming language" it's these principles that they refer to, most of which Clojure discards so it can play nice with Java and promote very specialized ways of solving problems in order to best fit a particular niche. The best way to discover the essence of l…

There it is again. Care to name any of those timeless philosophies without resorting to the minutiae of cons cells?

Clojure has very tangible and definite downsides and tradfeoffs (to name some: weaker REPL, though not as weak as some Schemes. JVM required. Heavy interop reliance), but it has served well as the flagship functional lisp.

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

#159

Post by phreack »

kylestlb wrote: post #36
eqmvii wrote: 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.

Future devs? More like future me... how can I build this so I can change it or fix it when PM decides against it in 2 weeks?

Absolutely, you need to care for that future dev who's an idiot when writing code today because that's going to be you in a week or two when you've forgotten all about it.

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

#160

Post by steindavidb »

> 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.)

Highly recommend a journalism class at local community college.

Post reply on HN