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

361–370 of 392 posts

Re: New Grad vs. Senior Dev

#361

Post by maliker »

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.

Our initial prototype was a cluster-based approach, and once we had a better estimate of user growth and resources we moved to a monolith for all the reasons you cite.

Re: New Grad vs. Senior Dev

#362

Post by fulafel »

Were the x86 string instructions much faster in 94? That was 486/Pentium era, right? IIRC this has varied over the years with sometimes slow microcoded string instructions and then faster improved instructions again.

Re: New Grad vs. Senior Dev

#363

Post by eyelidlessness »

snypox wrote: post #331
eyelidlessness wrote: post #258

Earlier quoted context omitted.

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

You can get a lot of the benefits of static typing with mypy. I know it's not mandatory, my first sentence acknowledged that.

Re: New Grad vs. Senior Dev

#364

Post by willberman »

temac wrote: post #285
willberman wrote: post #110

Earlier quoted context omitted.

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.

The basic speed up will not even be because of vectorisation. It will be because of caches.

Are you saying that the majority of the speed up is from caches and then there's a secondary, much smaller, speed up from the vectorization? Or are you saying all the speed up is from caches and I'm off base here with vectorization.

Re: New Grad vs. Senior Dev

#365

Post by a_c »

There is another type/layer of new grad - the kind without CS background and not being able to make a right solution (let alone balancing different concerns)

Re: New Grad vs. Senior Dev

#366

Post by capableweb »

lima wrote: post #345
capableweb wrote: post #341

Earlier quoted context omitted.

If you don't pile abstractions on top of abstractions on top of kubernetes on top of docker, you'd be surprised how much you can do with a single small-sized instance.

k8s has no performance overhead and can be useful even for simple applications (like for reproducible dev environments and CI). Agreed, otherwise.

I'm not talking about performance overhead, I'm talking about architecture overhead. Kubernetes doesn't have any advantages over not using Kubernetes for simple applications. Reproducible dev environments and CI you can get easily without Kubernetes, without having to add complex solutions for logging, profiling and other introspection tools.

One could argue that you need the reproducible dev environments and CI to be solved BEFORE even start using Kubernetes.

Re: New Grad vs. Senior Dev

#367

Post by MaxBarraclough »

LolWolf wrote: post #283
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. They are in many places I'm aware of. At least, as an EE (at Stanford, but I've heard MIT and several others do the same), I had to take a digital system design class, but the majority of the…

> They are in many places I'm aware of.

Yes, sure. I hadn't meant to imply otherwise. The pure-algorithms lecturer needn't cover these other topics in detail in their course, but should be careful to emphasise the uses and limitations of complexity theory.

> this class is not a requirement for CS since it's potentially too hardware oriented

I don't see the sense in this. Computer scientists publish work on applying GPU acceleration, as they should - that's not electronic engineering work they're doing. We could quibble about whether it's computer science of software engineering.

Re: New Grad vs. Senior Dev

#368

Post by ericlippert »

twelfthnight wrote: post #213
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…

This is a nice counter example. Although it's clear the article has good intentions, it's promoting unscientific thinking with an appeal to authority ("yes, they go brrrrrr extremely quickly much of the time, and senior developers know that!"). I think there is a point to be made about how we all could benefit from quelling our outrage at decisions we initially disagree with before we've heard all the evidence, but t…

It's not clear to me why you think that this anecdote had any particular intention. My intention was not to promote any position at all, but rather to tell an amusing personal story that I was reminiscing about because of an email I got from a young friend.

Anecdotes are by definition anecdotal; I am not promoting an anti-science position by relating a personal anecdote and I resent the statement that I am doing so.

If you'd like to write a blog article that promotes scientific thinking, I strongly encourage you to do so.

Re: New Grad vs. Senior Dev

#369

Post by jb3689 »

To be fair, there have also been plenty of times in this situation where the senior dev was wrong. You were right to question things and we should make sure to continue to encourage questions. The difference between a new grad and a senior dev is that the senior dev has the real-life experience to make the "yes/no" decision as to whether the new grad's input actually makes things better (e.g. it could be true that it doesn't matter if it is asymptotically faster if we are always working with small data). It's also a trait of a senior dev to be able to stay level-headed in these situations

Re: New Grad vs. Senior Dev

#370

Post by eternauta3k »

lonelappde wrote: post #107
pretendscholar wrote: post #100

Earlier quoted context omitted.

Yes you should ignore the details of friction for the first few semesters.

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

Funnily enough, you only solve problems with friction in your first semester (and maybe a little bit afterward when you study waves).
Post reply on HN