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

241–250 of 510 posts

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

#241

Post by aYsY4dDQ2NrcNzA »

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.

You’re right, but in practice the IDE regularly catches type mismatches in my code, and it has been hugely beneficial.

Then again, I am a fastidious about adding type annotations to my codebase.

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

#242

Post by marcinzm »

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…

>I am concerned about how to effectively communicate visions to people, because it gets everyone rowing in the same direction. If nobody thinks that you have a vision, when you do, there is no reason they should choose your direction vs just do their own thing.

I used to have visions. Now I have collaborative design discussions driven by some starting designs. I found that if people don't contribute to the overall design then they have little impetus to actually understand it. This tends to lead to a better design and a more engaged team so a win on all counts.

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

#244

Post by mdtusz »

dehrmann wrote: post #172
ocdtrekkie wrote: post #153

Earlier quoted context omitted.

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.

Before I had written much assembly, I used to think ifs to avoid assignments was smart. Turns out avoiding branching is better for both testability and performance.

A similar thing I've noticed a trend of recently in frontend react codebases is overuse of memoization. It seems as though people don't realize how it works and that it is often _less_ performant than just doing some low cost computation on each render (like a comparison or basic math).

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

#245

Post by anyfoo »

dmlittle wrote: post #212
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.

I don't know why you have been downvoted, you do have a point. Algorithms are tailored towards specific purposes. If you for example have something that runs with an n of about 5, and it's not in a hot path, the clear concise solution may well be better. Besides, with small n there is more to the cost of an algorithm than just its asymptotic growth.

However, to the point of the person you've replied to: It's good to know that stuff to be able to assess the situation in the first place.

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

#247

Post by sanderjd »

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…

Agreed. I did this journey twice. It was all static types when I was in high school and early college. Then I thought I was too smart to need the computer to do all that type checking for me ("I know what my program does, I don't need a compiler's help!") later in college and early in my career. Then I got incredibly sick and tired of working on really big projects in dynamic languages lacking the ergonomics of good static analysis.

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

#248

Post by sanderjd »

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…

What's a seg fault? I jest, but static languages have come incredibly far since C++ (where they are already less common than in C) and I truly haven't dealt with a segmentation fault in the past many years working with static languages.

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

#249

Post by stingraycharles »

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!

Yeah, this is something I’ve been pondering about. I’ve been doing 10 years of C++, and after a 6 months affair with Haskell fell in love with LISP. Now I’ve been doing Clojure professionally for about 5 years, and now am in a phase where I realize the grass is not green anywhere. I’ve been shocked at some of the bugs in my Clojure code that went unnoticed for way too long, and at the same time I remember the amount of “compiler fighting” that C++ or Haskell required.

It’s just a trade-off, in the end, and depends on what poison you can digest.

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

#250

Post by yarcob »

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

As a Swift dev, the reason why it slows me down is that I often end up fighting the type system.

I start with a concept, design my data structures on the whiteboard in a way that makes sense, then I try to code it and because of some detail in the type system it doesn't work, and I end up spending huge amounts of times wondering how to translate my concept into code.

I don't have that issue in other languages.

Also, the Swift compiler is really really slow.

Post reply on HN