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

211–220 of 510 posts

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

#211

Post by ng12 »

sidlls wrote: post #204
ng12 wrote: post #171

Earlier quoted context omitted.

> And I’d take the full stack dev before a front end one So you think one person can't know the entire stack but also half of the stack is not complex/important enough to be worth specializing in?

No, I just would have to think really hard to recall a front end specialist who didn’t get bogged down in fad chasing or wrote code better than a backend dev half-assing it.

I would say then that your project is simple enough that an underpaid full-stack dev is exactly what you want.

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

#212

Post by dmlittle »

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.

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

#213

Post by thisismyswamp »

daenz wrote: post #18

>Don't meet your heroes. I paid 5k to take a course by one of my heroes. He's a brilliant man, but at the end of it I realized that he's making it up as he goes along like the rest of us. I thought they were going to go the direction of "he's an asshole" and was ready to accept that, but this particular criticism is actually disturbing. People with strong visions can often appear to be "making it up as they go along,…

Building a new framework should be way at the bottom of your list of things to consider. If you do, please make it a blackbox. It's tiring how many details one often needs to get into before being able to do something they could have summarized in a sentence the whole time. But this is a general issue!

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

#214

Post by tomnipotent »

anyfoo wrote: post #209
tomnipotent wrote: post #201

Earlier quoted context omitted.

TypeScript, PHP, and Python have support for typing and the commiserate IDE benefits, and I'd imagine these languages account for a super majority of software written in dynamic languages.

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.

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

#215

Post by dmlittle »

chx wrote: post #152

Whiteboard paint exists.

Ive never had a good experience with whiteboard paint. The walls are not smooth so you always leave some residue when removing the ink. Over time it becomes pretty noticeable unless you spend a significant amount of elbow grease cleaning it.

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

#216

Post by brundolf »

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

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

#218

Post by brundolf »

dehrmann wrote: post #165
nautilus12 wrote: post #146

Seriously. Fuck pandas. And fuck dark for encouraging it.

It has one of the more confusing interfaces I've seen, and operator overloading just makes it worse. Numpy, on the other hand, is fairly straightforward and intuitive (and to be fair, a much simpler tool).

They basically created a DSL within Python. It's a total nightmare unless you're someone who uses it in notebooks every day (and it's impossible to typecheck)

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

#219

Post by diob »

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…

Yeah, I loved it when I started because I could easily try things out in JavaScript. Eventually I've come to love Typescript because I don't waste time on dumb things anymore.

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

#220

Post by anyfoo »

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…

EDIT: Reading again, I think you are comparing interpreted with compiled languages, not so much static with dynamic type systems.

Seg faults are a prime argument for static typing. The more static and stricter the type system, the less things like seg faults can even happen. Compare Rust to C (both are static, but one more than the other), and at the extreme end handwritten assembly (extremely dynamic). Those are languages used by kernel developers, where errant memory accesses of all kinds are a constant concern.

I don't know why dynamic languages would make introspecting things easier, or debugging in general. I agree that mocking can be easier with dynamic types. Compilation rarely takes long nowadays (incrementally it's usually just a few seconds), so the time saved in knowing that the code is still correct at least within the confines of the type system is well worth it.

Post reply on HN