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

251–260 of 392 posts

Re: New Grad vs. Senior Dev

#251

Post by asveikau »

vardump wrote: post #161
asveikau wrote: post #64

Earlier quoted context omitted.

Tangentially to your point, here's something I haven't thought about much: when these instructions get an interrupt, I imagine they've updated (r|e)si and (r|e)di, (r|e)cx etc. to reflect where they are in their copy or scan loop. So if you get a page fault in the middle, then the kernel does enormous amounts of work in response to it, then resumes that single instruction, it resumes in the middle of the loop, not th…

Pretty pointless as said page fault would occur no matter how you access the string. Besides, the page in question would very likely be already present.

> Pretty pointless as said page fault would occur no matter how you access the string.

When did I dispute this?

> Besides, the page in question would very likely be already present.

Really? How are you so sure? I guess you can just abandon all notion of virtual memory and mmap then. 'Cause it ain't gonna happen.

Re: New Grad vs. Senior Dev

#252

Post by JamesBarney »

marktolson wrote: post #239
Lapsa wrote: post #217

Earlier quoted context omitted.

I would argue that main reason for adaptation of microservices is to actually prolong development time (moar dollars) and make devops as convoluted as possible to safeguard data. Or foolishness.

I don't understand the hate for microservices on hn. I have found microservices are a great way to extend monoliths developed with legacy frameworks. There are so many pros with the cons easily avoidable with the right tooling / processes.

Basically it comes down to

Distributed logging:hard

Distributed debugging: hard

Distributed versioning: hard

Distributed transactions: very hard

And on 95% of projects these problems aren't worth solving for the benefits of microservices.

Re: New Grad vs. Senior Dev

#253

Post by burpsnard »

nickysielicki wrote: post #244

I think it's really interesting how complexity theory sort of falls apart in the face of hardware-specifics and concrete use cases. The motto in computer architecture is to make the common case fast (it's in like every textbook), whereas the motto in computer science is to make the program scale/to solve generically. When push comes to shove (as this article shows), the computer architects seem to have the final word…

in the 80s, alongside ibm, cray, heimdall, amdal, hitachi, etc etc you had the volume generics - intel. the generic overtook the custom, enough so the revenue and economy of scale won big. it came accompanied with a sci mindset of functional perf, * / ÷ / ^ / sqrt, rather than tps or $/transaction.

The big iron was a product of large-data-volume business problems - payroll, airline reservations, insurance quotes, credit cards, catalog order stats.

But comp-sci mostly put FLOPS ahead of TPS.

hands up who's heard of data flow programming

Re: New Grad vs. Senior Dev

#254

Post by vardump »

asveikau wrote: post #251
vardump wrote: post #161

Earlier quoted context omitted.

Pretty pointless as said page fault would occur no matter how you access the string. Besides, the page in question would very likely be already present.

> Pretty pointless as said page fault would occur no matter how you access the string. When did I dispute this? > Besides, the page in question would very likely be already present. Really? How are you so sure? I guess you can just abandon all notion of virtual memory and mmap then. 'Cause it ain't gonna happen.

>> Besides, the page in question would very likely be already present.

> Really? How are you so sure?

It was in a BASIC interpreter. Most of the time string needle in a haystack search is done, haystack is relatively fresh, almost certainly on a page that is present. Might not be in CPU dcache, but that's another matter.

Re: New Grad vs. Senior Dev

#255

Post by kazinator »

I would use the standard ISO C strstr instead of writing the function they are calling find.

Yes, we had strstr in 1994; it was in the 1989 ANSI C standard.

On a very small system, strstr will probably just be naively coded, to save space. On a big system, it might use Knuth-Morrison-Pratt or Boyer-Moore. I don't have to care; by using strstr, that decision is taken care of.

Re: New Grad vs. Senior Dev

#256

Post by bogdanu »

JamesBarney wrote: post #252
marktolson wrote: post #239

Earlier quoted context omitted.

I don't understand the hate for microservices on hn. I have found microservices are a great way to extend monoliths developed with legacy frameworks. There are so many pros with the cons easily avoidable with the right tooling / processes.

Basically it comes down to Distributed logging:hard Distributed debugging: hard Distributed versioning: hard Distributed transactions: very hard And on 95% of projects these problems aren't worth solving for the benefits of microservices.

> And on 95% of projects these problems aren't worth solving for the benefits of microservices.

And especially with a team of 4 or 5 developers.

Re: New Grad vs. Senior Dev

#257

Post by gen220 »

chiefalchemist wrote: post #8
gen220 wrote: post #4

Earlier quoted context omitted.

Putting it another way, knowledge with the bare minimum experience required to be effective is very sharp, and that sharpness is sometimes what’s required to cut through old, retrospectively “wrong” ways of doing things. I don’t disagree with what you’ve said, I think we all have met plenty of people fitting your description, I just mean to say there’s another side of the coin. As food for thought, much (not all) of…

The New Grad had knowledge. The Senior Dev had Understanding. Understanding > Knowledge It's that simple.

I agree with the thrust, but I think this has two sides as well.

Having an intricate understanding how things are connected, doesn't necessarily mean that one feels compelled to make it better.

Sometimes, "understanding" actually begets a cynical form of apathy. The whole world is chaotic and full of holes and injustices, so why bother trying to do the right thing, if it won't make a difference in the "big picture"?

Sometimes, knowledge (of your corner of the graph) with a hefty dose of misunderstanding (of the nodes and edges you're about to be traipsing down) is what's needed to most successfully face the challenges at hand. One name for this is "idealism", but without the negative connotation it is sometimes shipped in.

This is more what I was getting at with the whole knowledge + inexperience bit, if this makes sense.

Re: New Grad vs. Senior Dev

#258

Post by eyelidlessness »

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 benefits to users would be almost zero

Only if you just fix whatever breaks in the upgrade and never use the features in Python 3. The static typing benefits alone should either make your software more reliable (benefit to users) or speed up feature delivery (benefit to users).

Re: New Grad vs. Senior Dev

#259

Post by MaxBarraclough »

msla wrote: post #201
MaxBarraclough wrote: post #152

Earlier quoted context omitted.

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

> textbook being sufficiently obsolete every year or so

I wasn't very clear on that point, but didn't mean to suggest it be the same textbook. These other topics deserve courses and books of their own. The algorithms lecturer should be careful to emphasise the limitations of complexity theory though.

> that knowledge (at least once you attach numbers to it) has a shelf life, and not a very long one

Plenty of long-lived principles to be learned there, even if the particulars change over time. Caches are still going to be around in 10 years time.

Re: New Grad vs. Senior Dev

#260

Post by deathanatos »

XelNika wrote: post #190
deathanatos wrote: post #115

Earlier quoted context omitted.

> by a flat array for small n (hundreds, low thousands) Some of us are working in, say, Python. A flat array can outperform at small n, yes, but people overestimate where the tradeoff point is. It's at # A list of [0, 1, 2, 3, 4] In [10]: linear = list(range(5)) # A hash set, same thing. In [11]: hashing = set(range(5)) # 44ns / linear search In [12]: %timeit 3 in linear 44.2 ns ± 0.412 ns per loop (mean ± std. dev.…

You only benchmarked the search itself, but in the real world it might also take time to set up the data. You can't really pinpoint a tradeoff point without knowing how many times a data structure will be used. I ran your Python test on my machine and the hash set was faster in every case: 10x faster at size 50, 2x faster at size 5, 1.3x faster at size 3.

That's not a bad point, and perhaps I should test creation times too. (I wanted to ignore that s.t. the test isolated a single thing: searching / wasn't mixing two things together.) Both hashsets and vectors are O(n) in setup, and I'd mostly expect their real-world performance to be very similar: hash tables tend to use contiguous arrays for storage and vectors do by definition, both tend to overallocate (hash tables to prevent collisions, vectors to amortize appends to O(1)), so I'd expect the performance in the real-world to be similar. Vectors tend to insert in-order, though, whereas the insertions in hashsets would bounce around the table, so that might make it more interesting.
Post reply on HN