Drunk Post: Things I've Learned as a Sr Engineer • Hacker News Board

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

#111

Post by boojing » Sun, May 30, 2021, 5:09 PM UTC

whateveracct wrote: post #88

dataflow wrote: post #87

Earlier quoted context omitted.

I disagree strongly with it on multiple fronts. That concern should be secondary to your program actually doing its job well. Your customer will literally not care how elegant or ugly your code is; they just see the end result. And when the program fails them, it really doesn't matter to them whether your juniors understand the code or the error. Moreover, not every abstraction is (or can be expected to be) accessibl…

Exactly. How many entry level engineers come onto a project per year? 5? Is onboarding them onto the project is a deliberate and streamlined way such an undue burden that you must change your programming style to avoid it?

It's not only about new hires. You will have to figure out things about code that you wrote 3/6/12 months ago.

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

#112

Post by jlos » Sun, May 30, 2021, 5:11 PM UTC

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.

As a junior, the best I've seen is surfacing the complexity appropriately:

1) Readable Interfaces usable by juniors when parts of the code will be used by lots of devs and will almost certainly change

2) Higher complexity behind the interface for parts of the code that change less often and require more skilled engineers

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

#113

Post by whateveracct » Sun, May 30, 2021, 5:11 PM UTC

boojing wrote: post #111

whateveracct wrote: post #88

Earlier quoted context omitted.

Exactly. How many entry level engineers come onto a project per year? 5? Is onboarding them onto the project is a deliberate and streamlined way such an undue burden that you must change your programming style to avoid it?

It's not only about new hires. You will have to figure out things about code that you wrote 3/6/12 months ago.

But you can write code you can understand 12mo from now but have that same code be inscrutable to a new hire. Definitely different litmus tests.

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

#114

Post by MikeDelta » Sun, May 30, 2021, 5:12 PM UTC

user_50123890 wrote: post #103

andreilys wrote: post #48

Earlier quoted context omitted.

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

Because good senior programmers are rare (as can be observed if you post a job listing). Most of this stuff comes from students / junior developers, where yes, they probably visit stack overflow every 20 minutes

They should try programming on an airplane or without internet connection. For some the productivity drops to zero without stack overflow.

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

#115

Post by whateveracct » Sun, May 30, 2021, 5:13 PM UTC

tarsinge wrote: post #102

whateveracct wrote: post #45

Earlier quoted context omitted.

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

I’m not sure, you can become the newcomer yourself when you have to come back to parts of your code base months later. My experience writing simpler code has been pretty successful to respond to customers wanting random new features.

That's true, but it's not true in situations where you build on more abstract concepts that a newcomer wouldn't be able to understand.

e.g. I'll understand my monad transformers in a year, but a new hire with no Haskell experience will not.

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

#116

Post by andy_ppp » Sun, May 30, 2021, 5:13 PM UTC

mgfist wrote: post #95

andy_ppp wrote: post #93

Earlier quoted context omitted.

This assumes you are absolutely certain you know what the code should do. And that it does what you think it does. Hence while you might think “performs its task” is an easily defined I’d disagree. I’d take clear code that wasn’t working over code that was hard to reason about and somehow worked every day.

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

No because I’d fix the easy to fix code, and make it work correctly. The other code is useful for sure. I mean people have built billion dollar businesses on crap software that barely works. And very rarely do they manage to fix them... I’m just suggesting I have a preference for what I’d rather work on. You might like code that works and is impossible to understand and sits there surrounded by an even more obtuse test suite (if at all), but it’s not something I enjoy is what I was saying. To some degree this is inevitable but I think it’s always worth trying to fight the good fight.

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

#117

Post by fighterpilot » Sun, May 30, 2021, 5:15 PM UTC

swader999 wrote: post #82

josephorjoe wrote: post #68

Earlier quoted context omitted.

three things i find to be true of every web app i work on: 1. good logging is the most important part of the app. whatever the app is meant to do is secondary. the app should be a logging app first, and then a backend service to sell widgets second. 2. assume performance requirements for request latency and transactions per second will be at least 3x whatever the product owner tells you at the start of the project an…

Logging at the boundaries or seems is especially helpful.

Can you elaborate on what you mean by a boundary? You mean logging the interface between two services or modules?

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

#118

Post by catlifeonmars » Sun, May 30, 2021, 5:21 PM UTC

dataflow wrote: post #87

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.

I disagree strongly with it on multiple fronts. That concern should be secondary to your program actually doing its job well. Your customer will literally not care how elegant or ugly your code is; they just see the end result. And when the program fails them, it really doesn't matter to them whether your juniors understand the code or the error. Moreover, not every abstraction is (or can be expected to be) accessibl…

As with all software engineering, it’s all about trade offs and context.

That performant code that you wrote maybe at the expense of readability? It could very well become bad code when you leave the company and it falls to a junior engineer to modify it to fit some changing business requirement. Or, there’s a bug in the code and the amount of time it takes to fix it is a direct function of how quickly and completely that junior engineer can understand the code.

For me, the hard part is knowing when and how to make that trade off. I’ve definitely erred on both sides often enough.

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

#119

Post by mikepurvis » Sun, May 30, 2021, 5:23 PM UTC

fighterpilot wrote: post #117

swader999 wrote: post #82

Earlier quoted context omitted.

Logging at the boundaries or seems is especially helpful.

Can you elaborate on what you mean by a boundary? You mean logging the interface between two services or modules?

Boundaries between anything. I recently was dealing with an issue in a Jenkins pipeline, where I didn't realise that state was being serialized to string form between job stages until I explicitly logged it out. The thing that was a list in the previous stage was suddenly a string, but then Groovy would happily accept the join method on a string because it's still an iterable. Auuugh.

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

#120

Post by ratww » Sun, May 30, 2021, 5:23 PM UTC

daenz wrote: post #22

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.

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 of their self-worth in the sophistication of their code, so it's difficult to criticise without making them feel bad. You need alternative methods of getting them to "see the light" and write code that's more understandable and maintainable by others.