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

191–200 of 510 posts

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

#191

Post by BurningFrog »

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.

This is my extreme counter example:

What is better (A) a compiled bug free binary, or (B) well written source code that has a few bugs?

If you want to keep developing the software, the answer will always be (B).

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

#192

Post by anyfoo »

fmakunbound wrote: post #173

> The older I get, the more I appreciate dynamic languages. Fuck, I said it. Fight me. I see this in myself also. Static typing is such a fever at work especially amongst juniors and mids. Sometimes it’s almost as if they believe object types will spontaneously change at runtime, unpredictability.

But that’s exactly the point. It is too easy to introduce a code change that effectively will unpredictably (because it was unintended) change a type to something unexpected. And then blow up much later in spectacular ways.

Try writing something asynchronous in python with futures and complex nested data types. See how long you enjoy being told that you’re trying to look up a key in something that doesn’t seem to be a dictionary before you switch to static typing with mypy, and can spend your energy on solving the real problems.

I’ve been programming for way over 20 years, and I do not understand how people enjoy debugging something that the compiler would just tell them.

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

#193

Post by dataflow »

palijer wrote: post #110
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…

It really does matter to the customer if the junior understands it when the code fails though. Easy to understand code can be more quickly patched and repaired by anyone on the team. If you don't need to call in the senior who built it two years ago to repair it, and you can have someone do it right away, it is better for the customer.

I never said it doesn't matter. I said it matters. What I'm saying is the scenario you're portraying literally cannot play out pretty much by definition (and also empirically, from what I've seen) unless you accept that code readability for juniors is secondary to program quality. When you make readability your primary concern, it comes at the cost of fixing certain bugs and design issues... precisely because the best solutions may not t be trivial or easy to understand by the junior folks 100% of the time. So you never get into your purported state where everything was well designed and implemented in the first place and now you have to worry about getting a junior to fix a bug. Everything ends up clunky from the get-go and you never get a high-quality, robust program at all. Just something of mediocre quality with a ton of patches from devs of all level to get something like 85% working, shipping with know issues you could've avoided if you hadn't artificially restricted yourself and tied your hands behind your back for the sake of the juniors.

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

#194

Post by anyfoo »

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…

As I said in another ranty response in this thread, I do not understand how people enjoy spending time debugging trivial issues, that even a simple static type system would just plain tell them at compile time.

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

#195

Post by jeffreygoesto »

BurningFrog wrote: post #183
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 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…

There's even more. In the beginning you are proud if the code _works_. Later you find out it's 10x harder to write code that _can't fail_...

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

#196

Post by fmakunbound »

anyfoo wrote: post #192
fmakunbound wrote: post #173

> The older I get, the more I appreciate dynamic languages. Fuck, I said it. Fight me. I see this in myself also. Static typing is such a fever at work especially amongst juniors and mids. Sometimes it’s almost as if they believe object types will spontaneously change at runtime, unpredictability.

But that’s exactly the point. It is too easy to introduce a code change that effectively will unpredictably (because it was unintended) change a type to something unexpected. And then blow up much later in spectacular ways. Try writing something asynchronous in python with futures and complex nested data types. See how long you enjoy being told that you’re trying to look up a key in something that doesn’t seem to be…

I get all that, however I am saying that they’re being superstitious about it. I’ve been programming at least 20 years and thoroughly love programming in a dynamic language. My preferred being Common Lisp.

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

#197

Post by jeffreygoesto »

BurningFrog wrote: post #191
mgfist wrote: 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.

This is my extreme counter example: What is better (A) a compiled bug free binary, or (B) well written source code that has a few bugs? If you want to keep developing the software, the answer will always be (B).

This is not generally true, but strongly depends on the domain.

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

#198

Post by anyfoo »

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 I’d feel that way to if I had stayed in web development (which I only did as a short stint many years ago by now), and I felt it happening already.

It just doesn’t have much to do with computers and technology in the specific ways that I got enamored with computers and technology. Playing with bare metal stuff at work does. Of course, for someone else it might be the opposite.

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

#200

Post by craftinator »

mplanchard wrote: post #83
MaxBarraclough wrote: post #63

Earlier quoted context omitted.

It goes too far though. The virtue of simplicity needs to be balanced against the virtue of making proper use of advanced language features. A first-year student is unlikely to understand C++ template metaprogramming, or just about any Haskell code, but that's not to say they should always be avoided in production code. > The best code is no code at all This can be interpreted as advice to avoid the 'inner-platform e…

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".
Post reply on HN