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

331–340 of 392 posts

Re: New Grad vs. Senior Dev

#331

Post by snypox »

eyelidlessness wrote: post #258
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).

I’m on your side but what you refer to is not static typing and it’s not mandatory either.

Re: New Grad vs. Senior Dev

#332

Post by ericlippert »

rkagerer wrote: post #320
ericlippert wrote: post #144

Earlier quoted context omitted.

In this case I think not. However I strongly agree with your position and have tried hard to ensure that my code is commented such that it explains why the code works as it does. See https://ericlippert.com/2014/09/08/comment-commentary/ for more thoughts on this subject.

Hey Eric thanks for responding here! Love that article, it was interesting to read your dissection of code comments. For anyone else reading it, here's an updated link to the CS file referenced in his blog post (the original moved): https://github.com/dotnet/roslyn/blob/master/src/Compilers/C...

Yeah, all the links are wrong now. I'll fix them!

Re: New Grad vs. Senior Dev

#333

Post by vardump »

temac wrote: post #295
vardump wrote: post #75

Earlier quoted context omitted.

It's certainly been a while since I last optimized for the original Pentium architecture. Still faintly remember U & V pipes, unexplained causes for stalls, etc. As even nowadays, it would likely depend on the particular algorithm and data set. I'd be surprised if you can't do better than 4 cycles per char for sufficiently long strings. Most likely for short strings, REP SCASB wins due to setup costs. (Actually that…

You would be surprised about what is happening in modern computers. I don't know about REP SCASB, but IIRC, REP MOVSB is now an insanely efficient way to memcpy on last Intel microarchs (not necessarily always the fastest, but really fast enough for tons of scenario, and very I cache friendly). But it might be less interesting on some other x86 processors. It makes sense to delegate some of the microoptims to the har…

I might have been surprised, but I still optimize for the modern hardware. :-)

Yes, REP MOVSB is fast at least on Intel CPUs nowadays.

Re: New Grad vs. Senior Dev

#334

Post by saagarjha »

bialpio wrote: post #325
alasdair_ wrote: post #208

Earlier quoted context omitted.

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

I guess in that case you can also skip teaching them about angular momentum!

They’d still have angular momentum; it just wouldn’t be immediately apparent.

Re: New Grad vs. Senior Dev

#335

Post by makapuf »

twotwotwo wrote: post #204

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…

I sometimes think that you should be be able to hint the compiler that this is a smallish string, this one can be big, this list should be mostly under 1000 elements so that it handles the correct version of an algorithm (bonus point to let me provide several algorithms with different use cases)

Re: New Grad vs. Senior Dev

#336

Post by makapuf »

daxfohl wrote: post #36

As a senior dev, I wish that I could say I always knew more than my interns, and that all the code that's there is because it was carefully planned to be that way. But more often than not, I don't, and it's not. My take on it is that for the most part senior devs are a lot more paranoid on breaking things and don't want to make code changes unless enough people are asking for it and it'll make a notable difference. E…

Ah, spacebar cpu overheat https://xkcd.com/1172/

Re: New Grad vs. Senior Dev

#337

Post by JamesBarney »

rumanator wrote: post #328
redis_mlc wrote: post #279

Earlier quoted context omitted.

With microservices, you lose the ability to use database transactions across services/tables. Later on, when people realize this, it's too late. It's priceless to see their expressions when senior mgmt. and business owners finally find out.

> With microservices, you lose the ability to use database transactions across services/tables. Later on, when people realize this, it's too late. I don't follow your reasoning. I mean, the ACID vs BASE problem you described is extensively covered in pretty much any microservices 101 course or even MOOC, along other basic microservices tradeoffs such as the distributed tax and ways to mitigate or eliminate these issu…

I've seen a couple of projects where the original team didn't think they needed transactions, or underestimated how much harder eventually consistent distributed systems are to reason about than an acid system.

Re: New Grad vs. Senior Dev

#338

Post by jrs95 »

corysama wrote: post #65
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…

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…

And then we seriously overvalue these "core CS skills" for a lot of positions, many of which will not involve actually using any of it at all. I can't tell you how many people I've worked with that could tell you a bunch of Big O crap off the top of their heads but all they were working on was web apps and they couldnt seem to remember that running an ORM query in a loop is a bad idea. The way the U.S. uses college education as a prerequisite to employment but also seems to not be very good at teaching stuff that's actually relevant to the work you allegedly need the degree for is very disturbing to me.

Re: New Grad vs. Senior Dev

#339

Post by erpellan »

dnautics wrote: post #322
JamesBarney wrote: post #252

Earlier quoted context omitted.

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.

You can have a monolith and still suffer form these problems and need these technologies, as soon as you introduce a load balancer.

If the application is stateless (all state lives in the DB) you can run as many copies of the monolith as required behind a load balancer.

Re: New Grad vs. Senior Dev

#340

Post by darkteflon »

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.

Why is distributed logging hard? Genuinely curious.
Post reply on HN