Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

New Grad vs. Senior Dev

ericlippert.com

Post reply on HN
Print view View original

21–30 of 392 posts

Re: New Grad vs. Senior Dev

#21

Post by mbrameld »

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?

> Is it really so hard to help other people learn, and to accept that the only advantage you have on them is starting earlier?

If only the world were that black-and-white. It took me a long time to realize the habits I learned from my father in this area were toxic. Not everybody got the same upbringing you did, it sounds like yours was more advantageous than mine in that respect.

Re: New Grad vs. Senior Dev

#22

Post by ericlippert »

mettamage wrote: post #5

> NO! YOU CAN’T JUST USE BRUTE FORCE HERE! WE NEED TO USE SEGMENT TREES TO GET UPDATE TIME COMPLEXITY DOWN TO O(LOG N)! BREAK THE DATA INTO CHUNKS AT LEAST! OH THE INEFFICIENCY!!! I'm the opposite of this stereotype, and I think there are more like me. Two reasons as to why: (1) Psychological: I never had this. As a junior dev, I don't like to optimize because I feel a bit of pain when I need to moderately focus. I c…

The "malice" aspect is a great one and I did not go into that in this post because of course back in the 1990s we were not at all concerned that someone would maliciously craft inputs that would slow down this algorithm.

In modern code we'd want to do a threat model that considered the consequences of untrusted inputs.

Re: New Grad vs. Senior Dev

#23

Post by Ididntdothis »

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.

Re: New Grad vs. Senior Dev

#24

Post by king_magic »

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.

Re: New Grad vs. Senior Dev

#25

Post by saagarjha »

> The skipto method is a single x86 machine instruction.

That’s not always a good thing, especially on modern hardware. And obviously, the “single instruction” doesn’t mean it’ll take bounded time to execute…

Re: New Grad vs. Senior Dev

#26

Post by saagarjha »

samfisher83 wrote: post #15
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…

When you do big O analysis you get best case, worst case, and average case. You have to do some thinking about the structure of you data when doing big O analysis.

No, the point here is that big-O analysis means nothing if n is small. If n < 10 your algorithm could be exponential and still do better than a linear algorithm with a constant factor a thousand times larger.

Re: New Grad vs. Senior Dev

#27

Post by [deleted] »

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.

[deleted]

Re: New Grad vs. Senior Dev

#29

Post by saagarjha »

kevinventullo wrote: post #14
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…

To be fair, in my experience it is often the case that asymptotic complexity is a good proxy for real-world performance, even for small values of n. Not always, but often. I think it's fine that the academic courses focus a bit more on what's better in theory than in practice, because there are always caveats to "in practice"; the person who writes the special-purpose genomics libraries was also once a new grad.

Often, for small values of n performance matters less anyways matching that as n gets larger is often a nice bonus. Sometimes this makes the code more complicated, yes, but occasionally it can even make the code simpler, especially in a language with good data structures and algorithms (C++ is a shining example.)

Re: New Grad vs. Senior Dev

#30

Post by jpochtar »

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.

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.
Post reply on HN