Hacker News new | past | comments | ask | show | jobs | submit
SOLAR_FIELDS | on: Newgrounds.com – A community of games, music, and art
I worked at bigcorp for half a decade before all of the LLM stuff and there was exactly one time I really had to give a shit about algorithmic complexity in that entire tenure. Obviously some developers needed to care more than others, but the vast, vast majority of work and roles just didn’t really need to care about this. 9 times out of 10 you’re using the off the shelf library that already has the optimized bubble sort of whatever for your job
sigseg1v | parent | next
Working at bigcorp for 14 years so far and I struggle to think of a single day where I didn't need to consider algorithmic complexity or efficiency. Do you not write code that fetches things from a database? Do you not need to make tradeoffs between how much data you fetch at once, which fields you load, which things you cache, whether your query joins on the db or materializes things separately, whether you lazy or eager load, whether you are doing a O(1) or O(n^2) lookup and the tradeoffs, whether you can use a db index or not, memory/latency/compute/storage tradeoffs, etc? I feel like in even a simple bigcorp SAAS you need to consider this stuff daily.
SOLAR_FIELDS | root | parent
Unless you are dealing with data at true scale, and not many people are, often the imperfections are hidden because they run fast, even if they are quadratic. I'm more referring to being actually forced to sit down and write out your own algorithm in a novel way.

Yes, during my BigCorp tenure I had to think about complexity all the time, but 99 times out of 100 there was an off the shelf tool available for my specific data structure and I didn't have to think about the algorithm at all beyond "oh there's a library that solves this for my specific data structure, and it's O(N)log n that will be fast enough". Whereas so much attention in interviewing traditionally was based on these "write a bubble sort algorithm from scratch" type questions which your average engineer basically never has to do on the job unless they are operating in a very high performance/scaling type of role.

iamwil | parent | next
How often you have to take algorithmic complexity into account depends on what level of the stack you're at, but even at the application level, I think understanding algorithmic complexity is still important.

I was working at Company X around 2013, and we had a Rails ecommerce site. Trivial in the algorithmic sense. Had a contractor that pushed a change that somehow made everything crawl. When we did profiling together, it turned out he had written an O(n^2) algorithm when looking up country codes or something. Sometimes, there's no off-the-shelf library, and it's the minimum a dev should know not to do.

I'm not saying it should be a maniacal focus, but it should be taken into account. Of course, it's with judgement. We get shittier and shittier software if it's not taken into account at all.

bobthepanda | root | parent
Even doing a webapp it is fairly important, I have seen a lot of horribly optimized DOM tree traversal tank things.
alterom | parent
>I worked at bigcorp for half a decade before all of the LLM stuff and there was exactly one time I really had to give a shit about algorithmic complexity in that entire tenure.

Conversely, I've got a PhD in math, and all my tenure (whether it was bigcorp - Google, etc - or smallcorp) was about algorithms and performance where off-the-shelf library does not exist, and you can't throw compute at the problem to do it the dumb way.

To each their own.

| root | parent
{"deleted":true,"id":49948857,"parent":49948020,"time":1791070436,"type":"comment"}