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

201–210 of 392 posts

Re: New Grad vs. Senior Dev

#201

Post by msla »

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…

> To mirror what some others are saying here, students should also be taught the realities of cache behaviour, SIMD-friendliness, branch prediction, multi-threaded programming, real-time constraints, hardware acceleration, etc.

Which would have the positive knock-on effect of the textbook being sufficiently obsolete every year or so that the students could no longer trade it in for credit, saving the bookstores money!

More seriously, that knowledge (at least once you attach numbers to it) has a shelf life, and not a very long one. Teaching big-O analysis means the knowledge is timeless, which any good theoretical knowledge is, and moving more towards practice would force the professors to keep on top of the state of the art, and the state of the mainstream, of hardware design in addition to everything else they're doing.

Re: New Grad vs. Senior Dev

#202

Post by msla »

duck2 wrote: post #150
Jasper_ wrote: post #139

Earlier quoted context omitted.

Models are easy when you turn every cow into a sphere. But physicists never believe their models respect the real world. Computer Science should be about the Science of Computers, not hypothetical models acting on hypothetical architectures.

Computer Science existed long before there were computers. I think the Science of Computers you mention is known as Computer Architecture.

> Computer Science existed long before there were computers.

Not in its current form, and not if you define "computers" with a sufficiently broad net.

(Or broad loom, tipping a hat to Jacquard... )

Re: New Grad vs. Senior Dev

#203

Post by ADanFromCanada »

johncalvinyoung wrote: post #167
karatestomp wrote: post #128

Earlier quoted context omitted.

I see this so much in Rails codebases that at this point the two are nearly synonymous in my mind. But maybe I’ve been cursed to work only on bad Rails projects or something and there’s a universe of them out there that aren’t full of that sort of thing.

There are rails codebases written by people who love both ActiveRecord and SQL and try to optimize both performance AND developer productivity. ;)

But this is war. Pick a side!

Re: New Grad vs. Senior Dev

#204

Post by twotwotwo »

Go's strings.Index/bytes.Index also often use the "find first byte" approach; now on amd64 it's a fancy vector instruction. If it finds the first byte too many times without a full match, it falls back to a Rabin-Karp match using a rolling multiplicative hash.

The strings.Index code is at https://golang.org/src/strings/strings.go?s=25956:25988#L101... and the internal bytealg package with all the CPU intrinsics is at https://golang.org/src/internal/bytealg/ with index_amd64.{go,s} as the relevant files for x64.

Battle-tested implementations of fundamental things like string searches, sorts, hashtables, allocators, graphics primitives, etc. are often interesting 'cause you find out a lot about what you need (and/or don't need) to work well in practice as well as protect from exploding worst-case scenarios.

Re: New Grad vs. Senior Dev

#205

Post by TheOtherHobbes »

corysama wrote: post #160
joshlemer wrote: post #149

Earlier quoted context omitted.

What would be the kind answer you're looking for?

The question had 2 goals: 1) Do you think about cache at all or is it just something you heard mentioned as important that one time? 2) It's a good lead-in to discussing the effects of cache in algorithms. How that conversation goes helps me to understand how that person thinks and discusses complex problems. A good answer would be "I'm not sure, but probably way, way slower because linked list can point all over mem…

I sometimes wonder if CS should be renamed Computer Pseudo-Science. I blame Knuth and (mostly) Dijkstra for propagating the falsehood that you can estimate the performance of real code on real hardware with a some elegant academic blackboard math which gives you the wrong answer for many practical applications.

It's not that Big O isn't useful - it's that it's taught as a set of "proofs" which somehow make it appear objective and "correct", when in reality performance is at least as dependent on cache architecture, median size-of-n, memory bandwidth, and other implementation details.

Anyone who graduates CS without having been taught this very forcefully - preferably during a practical project - should be refunded at least some of their course fees.

Re: New Grad vs. Senior Dev

#206

Post by commandlinefan »

bogdanu wrote: post #145
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…

The reverse of this also happens: new team manager joins a team of 4-5 dev and goes "eww... a monolith, we'll write an MVP in 3 weeks with microservices, CQRS and all". Long story short, one year and a half passes and the mvp is still not finished, the architect leaves the company and some poor guys (from an outsourcing company) are still going at it with the same architecture.

On the other other hand, I’ve worked on system that stuck with “the old way” (like ColdFusion) for so long that it was impossible to even find documentation on the old programming environment if you could find somebody willing to maintain it. The longer you wait to upgrade, the more it’s going to hurt when you finally do.

Re: New Grad vs. Senior Dev

#207

Post by [deleted] »

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…

[deleted]

Re: New Grad vs. Senior Dev

#208

Post by alasdair_ »

rriepe wrote: post #111
lonelappde wrote: post #107

Earlier quoted context omitted.

For how many semesters? All the way through to graduation?

No. You wouldn't want people slipping on stage.

> No. You wouldn't want people slipping on stage.

Since all the students will merely be spheres of equal density, that shouldn’t matter much.

Re: New Grad vs. Senior Dev

#209

Post by herbstein »

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…

I always loved my algorithms and datastructures professor talking about Brodal queues[0] - a datastructure named after him. They're super interesting from a theoretical point of view, but they're not useful for anything.

[0] https://en.wikipedia.org/wiki/Brodal_queue

Re: New Grad vs. Senior Dev

#210

Post by herbstein »

TheOtherHobbes wrote: post #205
corysama wrote: post #160

Earlier quoted context omitted.

The question had 2 goals: 1) Do you think about cache at all or is it just something you heard mentioned as important that one time? 2) It's a good lead-in to discussing the effects of cache in algorithms. How that conversation goes helps me to understand how that person thinks and discusses complex problems. A good answer would be "I'm not sure, but probably way, way slower because linked list can point all over mem…

I sometimes wonder if CS should be renamed Computer Pseudo-Science. I blame Knuth and (mostly) Dijkstra for propagating the falsehood that you can estimate the performance of real code on real hardware with a some elegant academic blackboard math which gives you the wrong answer for many practical applications. It's not that Big O isn't useful - it's that it's taught as a set of "proofs" which somehow make it appear…

But Big O was a lot more directly correlated when the CPU wasn't doing "magic" optimizations on its own. It was still estimations with an invisible constant factor, of course,
Post reply on HN