tldr; needle in a haystack, rolling polyhash
New Grad vs. Senior Dev
101–110 of 392 posts
Re: New Grad vs. Senior Dev
#102Earlier quoted context omitted.
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 oper…
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 slightly less convenient in that case, syntax-wise), improvements occur regardless of scale. The list-based solution was a bad one at the scale it was originally written for handling.
I believe a hallmark of an experienced developer is writing performant code from the get-go; this is accomplished by not making stupid mistakes like this, and it costs pretty much nothing in terms of coding time or code complexity. All it takes is a little knowledge and caring about the product's performance.
--
[0] - I hesitate to use the word "senior", because to me, whether it means anything depends on the company one works in. In many, a "senior" developer is just the one that came before all the "junior" hires, and it doesn't matter that that developer is a fresh bootcamp graduate. And once you can put "senior X developer" on your CV, it's likely your next job will give you seniorship immediately as well.
[1] - and an extra few more minutes would give an implementation that doesn't allocate new memory unnecessarily - also a huge performance win.
Re: New Grad vs. Senior Dev
#103The real lesson here should be: don’t make assumptions about performance. Take real world use cases and measure!
That’s what my professors drilled into me (I specialized in high performance computing) and it’s served me well.
Re: New Grad vs. Senior Dev
#104Sure. 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…
This statement works equally all when you swap "jr" and "sr", so just leave it out
Re: New Grad vs. Senior Dev
#105Admittedly clueless question: what does 'brrr' mean? (I'm not a software dev and idioms that may be obvious to others are unfamiliar to me.)
_brrrrrr_
Goes a fast spinning motor
Re: New Grad vs. Senior Dev
#106The senior dev knows the system, knows what they can get away with, and has choices to use those knowledge powers. A newbie will always follow the programming rules, like never going over the limit on a hwy. as they can’t take much calculated risks
Re: New Grad vs. Senior Dev
#107Earlier quoted context omitted.
That's an arbitrarily restrictive view of computer science. It's like saying teaching physics ignoring friction perfectly fine.
Yes you should ignore the details of friction for the first few semesters.
For how many semesters? All the way through to graduation?
Re: New Grad vs. Senior Dev
#108This reminds me of how insertion sort is the most efficient sorting algorithm for small values of n. I remember new-grad me always dismissing insertion sort in every situation because of asymptotic complexity. Engineers are supposed to find the most pragmatic solution without biases.
Re: New Grad vs. Senior Dev
#109The senior dev knows the system, knows what they can get away with, and has choices to use those knowledge powers. A newbie will always follow the programming rules, like never going over the limit on a hwy. as they can’t take much calculated risks
Senior has a lot more types of ammo to use to solve problems let’s just say
Re: New Grad vs. Senior Dev
#110Earlier quoted context omitted.
Every good cs course has a section on cache aware algorithms. And i call bullshit that constant factor is not mentioned too
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.
I can see how this wouldn’t be covered in an undergrad cs education. I took only a single computer architecture class which was extremely limited in scope. The only reason I knew about vectorization during undergrad is because a friend mentioned it to me once.