New Grad vs. Senior Dev • Hacker News Board

Re: New Grad vs. Senior Dev

#191

Post by erik_seaberg » Sat, Mar 28, 2020, 8:11 PM UTC

bitwize wrote: post #180

New Grad: I'd use a linked list here because insertion into the middle is O(1) rather than O(n). Senior Dev: Linked lists have very many more cache misses than do vectors, and the difference between hitting cache and hitting main memory is such a huge constant factor that for most reasonable list sizes it never makes sense to use a linked list. Use a vector. Checkmate, smug Lisp weenies.

Yeah, the Lisp world figured out cdr-coding in the 1970s and had moved on to chains of vectors by 1985 according to https://cpsc.yale.edu/sites/default/files/files/tr362.pdf. Fortunately they avoided changing the API to make this tradeoff.

Re: New Grad vs. Senior Dev

#192

Post by codr7 » Sat, Mar 28, 2020, 8:14 PM UTC

TeMPOraL wrote: post #102

matwood wrote: post #90

Earlier quoted context omitted.

Maybe you knew the scale up front, but if you didn’t the easier syntax was the right first choice. It may have been the right first choice because it was easier to code even with the scale known up front. Only after measuring and understanding the trade offs should the easier to reason about code have been removed. IMO, thinking about and understanding these trade offs is one of the main differentiators between a jun…

> IMO, thinking about and understanding these trade offs is one of the main differentiators between a junior and senior developer. I agree, but in a way opposite to what you intended. An experienced developer[0] should be able to look at a situation like this and realize that few more minutes of focus can yield a better (array-based vs. list-based) implementation[1]. There are no downsides to that (arrays were only s…

The most important lesson I've learned from 34 years of writing software, it's to stop pretending I know shit about the problem I'm trying to solve before I have written an actual working solution. Which means getting there asap is top priority and nothing else matters. Sometimes that code runs fast enough, often it turns out I'm solving the wrong problem which means performance doesn't matter at all.

Re: New Grad vs. Senior Dev

#193

Post by ThePhysicist » Sat, Mar 28, 2020, 8:14 PM UTC

jakear wrote: post #50

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

Wow that still sounds really long for simply tokenizing a file? I worked on parsers a while ago and for reference I benchmarked e.g. the Python parser at 300.000 loc / second (for tokenization and building an AST) on my machine (a i7 laptop). Also tokenization complexity should not increase quadratically with the length of the file?

You probably know what you’re doing, just curious why these numbers seem to be off so much to what I would expect. What approach did you use for tokenization if I may ask?

Re: New Grad vs. Senior Dev

#194

Post by koala_man » Sat, Mar 28, 2020, 8:20 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".

This kind of CS-based rationalization is arguably another aspect of what the article comments on. I wrote a benchmark and found the difference in this case to be 3x-3.5x.

Re: New Grad vs. Senior Dev

#195

Post by [deleted] » Sat, Mar 28, 2020, 8:20 PM UTC

lalaland1125 wrote: post #53

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…

For interest's sake, did you try simply using a decent regex engine as an alternative? Any DFA regex engine implicitly implements Aho-Corasick for you.

[deleted]

Re: New Grad vs. Senior Dev

#196

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

ericlippert wrote: post #137

tyleo wrote: post #66

I see these senior vs non-senior engineer contrasts pop up a lot. I’m not a huge fan of them. It seems that there is a spectrum of skills an engineer could excel at: programming, infrastructure, managing, planning, etc. I’ve known senior engineers who only excel at a particular skill. I’ve also known senior engineers who are moderately good at many but not particularly good at one. In my experience the only differenc…

Well then, feel free to write your own blog post on a topic you enjoy more!

I don't think he dislikes the topic, but rather the way it is framed as senior vs. junior instead of subject matter expert vs. non-expert. The skipto example from your post is not exemplary of the difference between a senior dev and a new grad, it seems very domain-specific.

Re: New Grad vs. Senior Dev

#197

Post by [deleted] » Sat, Mar 28, 2020, 8:31 PM UTC

ericlippert wrote: post #18

jpochtar wrote: post #10

Can someone explain the bugs in the code samples? The author says they're there but I honestly can't find them.

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

[deleted]

Re: New Grad vs. Senior Dev

#198

Post by SaxonRobber » Sat, Mar 28, 2020, 8:32 PM UTC

lonelappde wrote: post #83

RookyNumbas wrote: post #68

Earlier quoted context omitted.

I like to start by thinking about cache locality and ensuring linear layout. Next focus on one-time, or minimal memory allocation. Then there are a bunch of small, systemic things you need to get right. After that you can start worrying about worst case big O scenarios. Of course this depends on your language. A c programmer will have a different mental model than a python one.

In Python performance is your last consideration, and that's OK. Most things computers do don't need to be fast. Only the innermost loops run the most do.

This is the philosophy that has led to our software becoming slower despite improvements in hardware.

Performance is always important. Especially for consumer applications, where your software will probably need to run alongside many other processes each competing for resources.

Re: New Grad vs. Senior Dev

#199

Post by heymijo » Sat, Mar 28, 2020, 8:35 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…

This sounds like the phenomenon dubbed Chesterton's Fence [0].

A core component of making great decisions is understanding the rationale behind previous decisions. If we don’t understand how we got “here,” we run the risk of making things much worse.

So you helped the new dev understand the current lay of the land. They listened, then suggested an improvement based on their new understanding. You agreed and together improved the code.

[0] https://fs.blog/2020/03/chestertons-fence/

Re: New Grad vs. Senior Dev

#200

Post by jakear » Sat, Mar 28, 2020, 8:40 PM UTC

ThePhysicist wrote: post #193

jakear wrote: post #50

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

Wow that still sounds really long for simply tokenizing a file? I worked on parsers a while ago and for reference I benchmarked e.g. the Python parser at 300.000 loc / second (for tokenization and building an AST) on my machine (a i7 laptop). Also tokenization complexity should not increase quadratically with the length of the file? You probably know what you’re doing, just curious why these numbers seem to be off so…

I don't recall the exact numbers to be honest. I know the original was in many seconds, and in the end it was sub 1.

As mentioned in another comment:

The go extension is a thin wrapper around standard go tooling, we weren’t tokenizing ourselves just converting between their tokens and ones we could process; a large part of that was converting from byte offsets to UTC-8 character offsets.

The quadratic behavior was a bug caused by reconverting segments over and over again instead of converting deltas between previously converted subsegments.