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

221–230 of 510 posts

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

#221

Post by eloff »

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…

> Exactly the opposite for me.

Yeah, same here. I started my career as a huge dynamic languages fan, and Python was my favourite language for over a decade.

But now, after 20 years, I appreciate a static language with proper IDE support and code completion. Offload the work to the computer, that's what we do for a living after all.

However, after spending a year working in Rust, I think this can be taken too far. The safety guarantees in Rust are amazing, but the overhead for contorting programs to a form the borrow checker will accept, and the mental overhead related to async/await compared to goroutines is too much.

My favourite language is now Go, and I find it strikes a good balance between static checks and productivity. Rust is still a more elegant language in many ways with things like generics and iterators and their enum types (algebraic types I think is the term?) and zero-overhead abstractions and clean error handling. Go feels a little hacky by comparison. But it's simple and way more productive for me personally, so I prefer it.

Interestingly Evan Wallace (constexpr here on HN) implemented esbuild in Rust initially, and switched to Go and stayed with it for much the same reasons, but also noted that the Go version performed better: https://news.ycombinator.com/item?id=22336284

> But at a high-level, Go was much more enjoyable to work with. This is a side project and it has to be fun for me to work on it. The Rust version was actively un-fun for me, both because of all of the workarounds that got in the way and because of the extremely slow compile times.

After a year of working with Rust and switching back to Go, I second this. I'm enjoying programming again and finding it easier to put in long hours.

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

#222

Post by anyfoo »

tomnipotent wrote: post #214
anyfoo wrote: post #209

Earlier quoted context omitted.

Yes, I've started using python again with mypy static typing. I can hardly still call it a "dynamically" typed language if I do that, though.

The type hints are still just type hints, and have no influence on run time. This can still lead to plenty of scenarios not possible with a compiler.

Fair. My point was that I was able to make python "behave more like a statically typed language" to make it bearable, but you're right, it ultimately is still a dynamically typed language at runtime, with the type ultimately bound to the value, and any untyped code still getting away from the "compiler" (which is just a type checker here), to wreak havoc at runtime.

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

#223

Post by dewclin »

MikeDelta wrote: post #101
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…

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.

Along the same lines, I recently reviewed a junior engineer's design document and pointed out to them a diagram showing the actors, their roles and interactions would have saved two pages of dense, complex text, and made the solution clearer.

"A picture is worth a thousand words.."

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

#224

Post by [deleted] »

gkoberger wrote: post #203
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 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!

[deleted]

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

#225

Post by sbarre »

brundolf wrote: post #216

> It's not important to do what I like. It's more important to do what I don't hate. This one has started to dawn on me. I'm never going to love my job as much as I love my personal projects, so a job that I don't get very excited about but doesn't drain my energy is better than one that I get somewhat excited about but does drain my energy (not that it's impossible to have both, but it's rare)

I made this exact choice about 5 years ago and my life has dramatically improved.

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

#226

Post by wirrbel »

anyfoo wrote: post #194
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.

I mean by now it should be clear to everyone that there are certain trade-offs in the choice dynamic vs static typing.

I do like clarity of static type declarations, also the absence of weird polymorphism like functions returning a number or al ist of numbers depending on their parameters, etc.

But then, many statically typed code bases are just tested abysmally. It is as if the type signatures would constitute proper tests. I realise that you don't need to write as many tests in a statically typed setting, but in many cases - and esp. in underpowered type systems - the types won't test the program's logic.

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

#227

Post by repExpMon »

3pt14159 wrote: post #210
anyfoo wrote: post #194

Earlier quoted context omitted.

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.

I've been programming for over 20 years too, and I like dynamic languages. I like them a lot more when they're properly tested and well architected, but even the tire fire codebases are at least debuggable. The compiled stuff helps with types catching the trivial bugs, yes, but it's way too complicated to quickly debug things like seg faults. Dynamic languages let you introspect and modify things way more easily, and…

> but it's way too complicated to quickly debug things like seg faults

I know you've listed the common argument for static vs dynamic (dynamic -> so fast to code but slow to run, static -> way too complicated)but after a decade in SE I still have yet to see some good evidence of this.

Yes some static languages (like Java) will make developing certain things slower vs JS but is Java a good statically typed language ? Maybe these statements are "true" today with the current implementation of one or the other but there are a lot of languages that I just can't see getting in the way.

A new example of this: Kotlin and Swift are statically typed and I would love love to see where it slows these mythical developers that are so fast in a dynamic language but would be slowed down using them. There's obviously going to be a cost for the actual compile time but that should be minimal.

Unfortunately I'm starting to believe that this is just another case of certain developers are used to certain languages.

The trend of the JS move to TS also points to this. Basically JS looks very similar to Kotlin and Swift (TS is basically identical).

To look at your specifics > Dynamic languages let you introspect and modify things way more easily, and this makes things like fakes and mocks for testing way easier. It makes debugging easier. And not having to wait an hour for something to compile is nice.

> Dynamic languages let you introspect and modify things way more easily

In what way ?

> and this makes things like fakes and mocks for testing way easier

Fwiw this is what that fake/mocks look like for a static language `val x = mock()`

To be fair that's using a library and maybe that's part of your criteria ?

> It makes debugging easier

? how, I can see the argument for the other way (one less thing the developer has to worry about - typing issues) but how is dynamic easier to debug ?

> having to wait an hour for something to compile is nice

Completely Fair. Now whether or not the thing you're working on would take an hour to compile I highly doubt. If you're working on a project that would hypothetically take an hour to compile then I really hope it's not written in a dynamic language.

Not trying to pick on you at all, I believe a lot of developers would agree with you but I'm starting to think that there are developers that are just used to one or the other. I have to point out that I could be thinking this way with respect to statically typed languages but I really have a hard time seeing this point (as I would be if I was falling into the same trap I'm "accusing" you of).

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

#228

Post by dijit »

elliotec wrote: post #206
steindavidb wrote: post #160

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

Can you elaborate on that? Why journalism in particular? Have you done this? Are you better at docs?

I studied journalism at college as part of a more general media studies course.

It does help but I am not sure I would describe _my_ education as a panacea.

The main reason it was good was because it helps frame how you think of writing,

The most important things go first. Statement of fact, then you go into what the implications are, then you start introducing less and less relevant elements.

when you’re writing you keep the 5 “W’s” in mind, make sure you answer them. (Who what where when why), for instructive documentation you add: How.

Obviously an education bakes this into you in a better way than I can convey here.

What I learned is probably only decent for writing overviews.

Personally I find structure to be the biggest bottleneck/difficulty when making documentation.

What do others normally struggle with that don’t have this education?

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

#229

Post by anyfoo »

repExpMon wrote: post #227
3pt14159 wrote: post #210

Earlier quoted context omitted.

I've been programming for over 20 years too, and I like dynamic languages. I like them a lot more when they're properly tested and well architected, but even the tire fire codebases are at least debuggable. The compiled stuff helps with types catching the trivial bugs, yes, but it's way too complicated to quickly debug things like seg faults. Dynamic languages let you introspect and modify things way more easily, and…

> but it's way too complicated to quickly debug things like seg faults I know you've listed the common argument for static vs dynamic (dynamic -> so fast to code but slow to run, static -> way too complicated)but after a decade in SE I still have yet to see some good evidence of this. Yes some static languages (like Java) will make developing certain things slower vs JS but is Java a good statically typed language ?…

Read what they wrote again, but this time replace "static" with "compiled" and "dynamic" with "interpreted", and suddenly it made sense to me.

It's true that overall, compiled languages tend to be more static, and interpreted languages more dynamic (and there are good reasons for why they end up that way besides mere convention), but nevertheless that's not what this discussion is about.

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

#230

Post by JMTQp8lwXL »

runawaybottle wrote: post #37
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…

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.

Post reply on HN