New Grad vs. Senior Dev • Hacker News Board

Re: New Grad vs. Senior Dev

#41

Post by ericlippert » Sat, Mar 28, 2020, 4:27 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…

That's a great example; the most important part of your anecdote is the end which says what was the user impact? There is no prior reason to believe that a 50x speedup is actually a win; taking an algorithm from 100K nanoseconds to 2K nanoseconds when hitting the file system takes billions of nanoseconds is not a win for the user, and taking an algorithm that takes 5000 years down to 100 years is probably not either.

But a 50x win that, as you note, goes from "let's have lunch" to "let's change this one thing ten times and re-do the analysis to see which gets us the best results" is a huge game changer; it's not just that it saves time, it's that it makes possible new ways to work with data.

Re: New Grad vs. Senior Dev

#42

Post by dmoy » Sat, Mar 28, 2020, 4:27 PM UTC

TeMPOraL wrote: post #35

justinmeiners wrote: post #32

Earlier quoted context omitted.

I regularly see people make this mistake and don't grasp it after correction. You could make a hash table with a constant time lookup, but the hash takes 1 hour. Big oh only tells you how it scales, not it's performance (runtime).

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.

> the array is contiguous in memory - so operations like search or moving stuff around after addition make extremely good use of CPU's cache

Also - if I see someone try to use a linked list for an enormous data structure again.... Wow it does not scale worth crap because it turns out that the hardware is actually important, and contiguous memory is amazing.

Re: New Grad vs. Senior Dev

#43

Post by hhjinks » Sat, Mar 28, 2020, 4:27 PM UTC

king_magic wrote: post #24

aerovistae wrote: post #9

I dislike the mentality that one must "struggle" to be patient with new devs and that it's "more than they deserve." Is it really so hard to help other people learn, and to accept that the only advantage you have on them is starting earlier?

Except it is a struggle. It's often a struggle to get newer devs to stop wasting time, it's often a struggle to get them to focus on the problem you're trying to solve instead of the new library all the cool kids are using, etc. I agree with the "more than they deserve" mentality, but let's be honest here: it's a struggle. We've all been through it as new devs, and we'll all help new devs struggle through it as well.

I've worked with juniors who always scope creep their very simple introductory tasks. Something as simple as "add these two fields to the existing API response" suddenly turns into "change the method signature of 90% of existing methods because DTOs make code lines shorter".

Re: New Grad vs. Senior Dev

#44

Post by toolz » Sat, Mar 28, 2020, 4:29 PM UTC

jeromebaek wrote: post #6

Sure. But most senior devs are not Tim Patterson.

but it's not uncommon for jr. devs to believe every piece of code deserves the most efficient runtime. Runtime speed causing projects to fail is very uncommon. What does add an incredible amount of work time is combing through a codebase looking for micro optimizations. I've never once seen a jr. dev who claimed to care about efficiency start by writing benchmarks over large parts of the system and using that to find real bottlenecks. No, they always comb through the code trying to impress the sr. dev. with their algorithmic knowledge.

Re: New Grad vs. Senior Dev

#45

Post by TeMPOraL » Sat, Mar 28, 2020, 4:30 PM UTC

Ididntdothis wrote: post #23

I always envy people who work on this level instead of cobbling systems together that integrate several systems all with their own set of flaws and you can be happy if you can make them work together somehow. The algorithm stuff seems pretty simple in comparison. A very local problem that can be profiled well and you can understand most of the factors at play.

The "cobbling systems together" stuff is code bureaucracy rather than programming. You're no longer dealing with constraints of physics, mathematics and sound system design - you're building a bit-pushing layer in between Kafkaesque monstrosities that were never truly intended to work together.

Sadly, most programming jobs seem to primarily involve code bureaucracy rather than the "algorithmic" level.

Re: New Grad vs. Senior Dev

#46

Post by tspop » Sat, Mar 28, 2020, 4:30 PM UTC

TeMPOraL wrote: post #11

Oh god. That meme. I've seen it a day or two ago. Can't find the picture anywhere now (I've seen it in some group chat). Anyway, beyond the words quoted at the beginning of this article, the meme's "nested loops go brrr" had a picture of a triple-nested loop using Active Record to do some simple database operations. To which the correct response is: "it's a 'senior developer' in an industry where you get called a 'se…

Hey, I made that meme.

It was based on a similar story the one in OPs blogpost. At my first job I used to work with some really talented fresh grads that wanted to show off their algorithms skills and ended up over-engineering stuff.

One of them implemented a trie and stored it in SQL lite to implement some string autocomplete where the number of strings was something like 100.

The other implemented a 2D segment tree for doing some grid updates where the size of the grid was small. This inspired the first part of the meme. Segment trees and sqrt decomposition are topics that are popular at programming contests and nowhere else really.

Regarding the triple nested loop, I just wrote the simplest pseudocode that represents nested loops, not necessarily something a "senior" developer would write.

Re: New Grad vs. Senior Dev

#47

Post by varjag » Sat, Mar 28, 2020, 4:31 PM UTC

Ididntdothis wrote: post #23

I always envy people who work on this level instead of cobbling systems together that integrate several systems all with their own set of flaws and you can be happy if you can make them work together somehow. The algorithm stuff seems pretty simple in comparison. A very local problem that can be profiled well and you can understand most of the factors at play.

Applying algorithms in non classroom assignment style is rarely trivial. Takes some insight into nature of the problem to spot the opportunity and good familiarity with applicable solution in the first place.

Re: New Grad vs. Senior Dev

#48

Post by TeMPOraL » Sat, Mar 28, 2020, 4:32 PM UTC

dmoy wrote: post #42

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.

> the array is contiguous in memory - so operations like search or moving stuff around after addition make extremely good use of CPU's cache Also - if I see someone try to use a linked list for an enormous data structure again.... Wow it does not scale worth crap because it turns out that the hardware is actually important, and contiguous memory is amazing.

Oh god. Don't talk to me about linked lists. One of the bigger performance improvements I've made in a certain company is taking the code working with lots of numerical data in linked lists because they had easier syntax, and rewriting it using honest-to-god, contiguous-memory arrays of doubles. After that, we could process three orders of magnitude more numbers per operation, and one order of magnitude more of operations, and we still came ahead.

Re: New Grad vs. Senior Dev

#49

Post by ericlippert » Sat, Mar 28, 2020, 4:34 PM UTC

jpochtar wrote: post #30

ericlippert wrote: post #18

Earlier quoted context omitted.

Hint: what is the correct behaviour of this method when given empty strings? Every string contains the empty string as a substring.

Oh, I'd assumed disagreement on behavior of query="" between the two code samples meant it was UB and was looking for crashes/invalid memory accesses.

A Visual Basic program is not allowed to have undefined behaviours like a C program; InStr has a specification and that specification has to be implemented; that spec includes defining the behaviour for all inputs.

There's also no null handling here, which was a deliberate omission for clarity. In practice, the convention used inside the VB source code is that null string pointers are semantically the same as empty strings, which introduces some complexities.

Re: New Grad vs. Senior Dev

#50

Post by jakear » Sat, Mar 28, 2020, 4:34 PM UTC

Heh... reminds me of my first proper MS internship, when I too was responsible for speeding up some code, this time in the VS Code Go extension. This code was responsible for tokenization, so it affected pretty much every operation and ran on every edit. Important shit.

Day 1: do some basic hoisting. O(n^3) => O(n^2). Tokenization times for a 10k line file go from ~15s to 500ms. Sweet.

Days 2-30 [1]: ideate, develop, bug fix, iterate on, etc, a novel (to me) data-structure to speed up the program even more. O(n^2) => O(n x log(n)) (expected). Great! Runtime on 10k line file went from 500ms to maybe 300ms. Oooops.

But hey, all the people working in 500k line files must really love the couple seconds my month of toiling (more importantly, my month of not doing other, more impactful things) saved them.

Learned a lot from that experience, and writing this out now I can see how that impacted engineering decisions I make to this day. I suppose thats the real point of an internship, so time well spent, in a way.

[1] It probably wasn't actually a month, but certainly a significant chunk of the internship.