New Grad vs. Senior Dev • Hacker News Board

Re: New Grad vs. Senior Dev

#181

Post by dwohnitmok » Sat, Mar 28, 2020, 7:54 PM UTC

MaxBarraclough wrote: post #152

corysama wrote: post #65

Earlier quoted context omitted.

It’s because Big O is Computer Science. Cache effects are Software Engineering. Professors of CS do a fine job of teaching CS. They even briefly mention that there is a implicit constant factor k in O(k n log(n)) and then they never mention it again. They certainly don’t mention that k can easily vary by 128x between algos. AKA: 7 levels of a binary tree. Or that most of the data they will be dealing with in practice…

> briefly mention that there is a implicit constant factor k in O(k n log(n)) and then they never mention it again A fine concrete example of this is the Coppersmith–Winograd algorithm (and its derivatives), a matrix multiplication algorithm with impressive complexity properties, but which in practice always loses to the Strassen algorithm, despite Strassen's inferior complexity. [0][1][2] (Aside: the Strassen algori…

Even Strassen can be overly expensive for reasonably sized matrices. Almost all matrix multiplication algorithms have a threshold only beyond which do they use Strassen.

Although apparently that threshold can be lowered (http://jianyuhuang.com/papers/sc16.pdf), but even then it's a matrix that's several hundred columns by several hundred rows large.

Some CS classes explicitly use Strassen to teach the realities of asymptotic vs wall-clock time complexity, challenging students to come up with a hybrid matrix multiplication algorithm that performs the fastest and switches at the best thresholds of matrix size.

Re: New Grad vs. Senior Dev

#182

Post by [deleted] » Sat, Mar 28, 2020, 7:54 PM UTC

onekorg wrote: post #135

corysama wrote: post #86

Earlier quoted context omitted.

It wasn’t taught to me. And, in my previous job I interviewed many dozen fresh grads. One of my questions was “How much slower is it to sum integers in a trivial linked list vs. a trivial array?” 90% answered “Umm... I don’t know. 2x?” When asked why, they all said “1 op to sum the int +1 op to traverse the pointer.” It was amazingly consistent.

The answer could be 2x. Let's say you're in a 64 bit platform. Your linked list nodes consist of a next pointer and a 64 bit integer. If your linked list nodes are all allocated sequentially in memory then it'd only be 2x as slow as an array of 64 bit integers. But maybe it's not fair to call sequentially allocated linked list a "trivial linked list".

[deleted]

Re: New Grad vs. Senior Dev

#183

Post by [deleted] » Sat, Mar 28, 2020, 7:58 PM UTC

T-hawk wrote: post #96

xenocyon wrote: post #76

Admittedly clueless question: what does 'brrr' mean? (I'm not a software dev and idioms that may be obvious to others are unfamiliar to me.)

It's the whirring sound of a motor. The for loop is metaphorically spinning to loop over everything instead of doing something smarter to find what it needs. The programmer thinks the whirring sound means it's doing a lot of work for him. It's an interesting dichotomy because the most practical solution could go either way. Maybe it's looping over a table of 20 customers and the wasted time is microseconds that would…

[deleted]

Re: New Grad vs. Senior Dev

#184

Post by 29athrowaway » Sat, Mar 28, 2020, 7:58 PM UTC

maliker wrote: post #136

I'm the senior dev on my team, and whenever a new dev joined my team they would look at the codebase and go "ew, python2? Just use python3." That gave me a chance to explain the testing and refactoring cost that would come with changing python versions, and how the benefits to users would be almost zero. And then at some point one of the new juniors said, "hey, there's a lot of filesystem performance improvements and…

Another reason to use Python 3: you won't get any more updates.

https://www.python.org/doc/sunset-python-2/

Re: New Grad vs. Senior Dev

#185

Post by LeoTinnitus » Sat, Mar 28, 2020, 8:01 PM UTC

saagarjha wrote: post #33

By the way, here’s an anecdote for the flip side: at one of my internships I was working on a tool to process large log files, and by careful application of Aho-Corasick I was able to make it about 50 times faster on the dataset we were dealing with, which made using the tool change from “let’s go grab lunch while this finishes” to “let’s stream the logs through this live”. Sometimes you do know how to make things fa…

But sometimes you can get a supervisor who doesn't care what you do, you're not changing it because they don't want to learn something new...

Re: New Grad vs. Senior Dev

#186

Post by maliker » Sat, Mar 28, 2020, 8:03 PM UTC

mgkimsal wrote: post #175

maliker wrote: post #136

I'm the senior dev on my team, and whenever a new dev joined my team they would look at the codebase and go "ew, python2? Just use python3." That gave me a chance to explain the testing and refactoring cost that would come with changing python versions, and how the benefits to users would be almost zero. And then at some point one of the new juniors said, "hey, there's a lot of filesystem performance improvements and…

and... if after 3-4 weeks, it was nowhere near completion, or you'd hit so many snags it was going to take several more months, I'd hope you'd have the good sense to put a cap on it, and revisit later. There's nothing inherently wrong about trying something like that, especially if there's some tests in place, a known goal, a reasonable time boundary relative to the potential benefit, and a willingness to stop if the…

We mostly stick to a single master with our code, but this was one case where we branched so we could watch progress via test passing percentage to make sure we were moving fast enough to finish before we got sick of it.

Definitely have been one or two refactors that have been shutdown. We've been lucky to have clients that give us the freedom to retire some technical debt/risk instead of just churning out features. And we're small enough (200 kLoc approx, 6 devs) that full codebase refactors are still doable.

Re: New Grad vs. Senior Dev

#187

Post by maliker » Sat, Mar 28, 2020, 8:05 PM UTC

29athrowaway wrote: post #184

maliker wrote: post #136

I'm the senior dev on my team, and whenever a new dev joined my team they would look at the codebase and go "ew, python2? Just use python3." That gave me a chance to explain the testing and refactoring cost that would come with changing python versions, and how the benefits to users would be almost zero. And then at some point one of the new juniors said, "hey, there's a lot of filesystem performance improvements and…

Another reason to use Python 3: you won't get any more updates. https://www.python.org/doc/sunset-python-2/

We wrapped up our conversion about 1 week after the sunset date. I think we could have lived with no new features, but the no security updates issue was a big reason why we upgraded.

Re: New Grad vs. Senior Dev

#188

Post by Koshkin » Sat, Mar 28, 2020, 8:06 PM UTC

reader_1000 wrote: post #114

In real life, you will always start with simple working implementation and go with it. Then if things are slow, you profile your code with a good profiler while running for some kind of real life scenario and spot the slow parts (also keep in mind that profiling may affect the program's behaviour). After that you may want to consider alternatives with less asymptotic complexity iff that's the part causing slowness. O…

There is also such thing as "design for performance," and sometimes - just sometimes - any amount of effort spent later on optimization would end up going nowhere, because what you are trying to optimize is in fact a huge steaming POS.

Re: New Grad vs. Senior Dev

#189

Post by fchu » Sat, Mar 28, 2020, 8:08 PM UTC

corysama wrote: post #65

dimtion wrote: post #7

I find that the biggest misunderstanding happens because "new grads" (and I happen to be one) confuse _asymptotic complexity_ with actual complexity. I'm not sure sure why, but CS courses and interview questions mostly focus on _asymptotic complexity_ and usually forget to take into consideration the complexity for "little values of n". And funnily enough, in real life n never goes to infinity! In a strict sense big…

It’s because Big O is Computer Science. Cache effects are Software Engineering. Professors of CS do a fine job of teaching CS. They even briefly mention that there is a implicit constant factor k in O(k n log(n)) and then they never mention it again. They certainly don’t mention that k can easily vary by 128x between algos. AKA: 7 levels of a binary tree. Or that most of the data they will be dealing with in practice…

As a side note: O(k n log(n)) and O (n log (n)) have exactly the same meaning for k non-null constant by the definition of big O notation. The more you know!

Re: New Grad vs. Senior Dev

#190

Post by XelNika » Sat, Mar 28, 2020, 8:09 PM UTC

deathanatos wrote: post #115

TeMPOraL wrote: post #35

Earlier quoted context omitted.

It's not even that. You could have a normal hash table with a decent hashing function, and you'll still get beaten by a flat array for small n (hundreds, low thousands), because the array is contiguous in memory - so operations like search or moving stuff around after addition make extremely good use of CPU's cache.

> by a flat array for small n (hundreds, low thousands) Some of us are working in, say, Python. A flat array can outperform at small n, yes, but people overestimate where the tradeoff point is. It's at # A list of [0, 1, 2, 3, 4] In [10]: linear = list(range(5)) # A hash set, same thing. In [11]: hashing = set(range(5)) # 44ns / linear search In [12]: %timeit 3 in linear 44.2 ns ± 0.412 ns per loop (mean ± std. dev.…

You only benchmarked the search itself, but in the real world it might also take time to set up the data. You can't really pinpoint a tradeoff point without knowing how many times a data structure will be used.

I ran your Python test on my machine and the hash set was faster in every case: 10x faster at size 50, 2x faster at size 5, 1.3x faster at size 3.