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

321–330 of 392 posts

Re: New Grad vs. Senior Dev

#321

Post by joshuamorton »

wolco wrote: post #305
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…

In the end the junior spent a month working on this. Now you are on the latest python. How does this benefit the user again? Could the junior have been working on that spa for marketing? That's one months salary..

Faster iteration in the future. Infrastructure benefits the user in the long term.

Re: New Grad vs. Senior Dev

#322

Post by dnautics »

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.

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

Re: New Grad vs. Senior Dev

#323

Post by elbear »

redis_mlc wrote: post #279
bcrosby95 wrote: post #266

Earlier quoted context omitted.

A monolith can handle millions of daily unique users. The database is the hard part. In the web world, if you have less than 10s of millions of daily users, as long as you design an application that holds no state itself, the architecture is usually more important for scaling your team and the size of your codebase rather than the number of users you can handle.

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.

Can you explain why you lose that ability? It's not obvious to me.

Re: New Grad vs. Senior Dev

#324

Post by mads_ravn »

bcrosby95 wrote: post #266
capableweb wrote: post #262

Earlier quoted context omitted.

I just started working on a new project about half a year ago, completely greenfield. The backend developer (there is only one...) jumped into microservices directly, deploying on AWS Fargate, trying to split out as many things into containers as possible, because that's the "proper" way of doing it. We still have few users as the project is new, but hey, at least we could scale to 100000s users in a few minutes, ins…

A monolith can handle millions of daily unique users. The database is the hard part. In the web world, if you have less than 10s of millions of daily users, as long as you design an application that holds no state itself, the architecture is usually more important for scaling your team and the size of your codebase rather than the number of users you can handle.

This.

At least that is what I often think, when I hear people describing micro-services. If there is no data sharing between computations, then the problem is embarrassingly parallel [1] and thus easy to scale. The problem is not the monolith, it is the data sharing, which micro-services only solve if each service owns it’s own data. To be fair people advocating micro-services also often argue that they should own their data, but in quite a few of the instances I’ve heard described, this is not the case.

[1] https://en.m.wikipedia.org/wiki/Embarrassingly_parallel

Re: New Grad vs. Senior Dev

#325

Post by bialpio »

alasdair_ wrote: post #208
rriepe wrote: post #111

Earlier quoted context omitted.

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.

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

Re: New Grad vs. Senior Dev

#326

Post by ido »

bogdanu wrote: post #248
burpsnard wrote: post #240

Earlier quoted context omitted.

> some poor guys.. still going at it that's how you earn your thousand yard stare

I have that stare from the first few months of my career. The perks of working in outsourcing I guess.

I've never worked in outsourcing and almost every job I had in my >15 years career as a developer included at least somewhat-gnarly & often truly-gnarly code.

It is very rare to see a codebase several years old that can be fairly describe as "in good shape".

Re: New Grad vs. Senior Dev

#327

Post by rumanator »

cc81 wrote: post #290
bcrosby95 wrote: post #266

Earlier quoted context omitted.

A monolith can handle millions of daily unique users. The database is the hard part. In the web world, if you have less than 10s of millions of daily users, as long as you design an application that holds no state itself, the architecture is usually more important for scaling your team and the size of your codebase rather than the number of users you can handle.

I've been in discussions about internal applications with few hundreds users and very moderate amounts of data being shuffled and stored and some people, of various backgrounds, are just so convinced that we need to go all in on Kubernetes, Microservices, Istio etc. And all I can think about is "Hey, you could build this with a small team as a simple monolith and with proper caching you could probably run this on one…

> And all I can think about is "Hey, you could build this with a small team as a simple monolith and with proper caching you could probably run this on one or two raspberry pi, that is the amount of power you actually need here".

If your product has a global audience who needs to CRUD stuff, caching and a single raspberry pi won't get you very far in the game.

If it's just an intranet stuff with a few hundred users and your front-end isn't very chatty then you're right, you don't need much.

Re: New Grad vs. Senior Dev

#328

Post by rumanator »

redis_mlc wrote: post #279
bcrosby95 wrote: post #266

Earlier quoted context omitted.

A monolith can handle millions of daily unique users. The database is the hard part. In the web world, if you have less than 10s of millions of daily users, as long as you design an application that holds no state itself, the architecture is usually more important for scaling your team and the size of your codebase rather than the number of users you can handle.

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 issues like going with bounded contexts. Why do you believe this is a mystery that no one is aware of?

Re: New Grad vs. Senior Dev

#329

Post by austhrow743 »

TeMPOraL wrote: post #61
jakear wrote: post #50

Heh... reminds me of my first proper MS internship, when I too was responsible for speeding up some code, this time in the VS Code Go extension. This code was responsible for tokenization, so it affected pretty much every operation and ran on every edit. Important shit. Day 1: do some basic hoisting. O(n^3) => O(n^2). Tokenization times for a 10k line file go from ~15s to 500ms. Sweet. Days 2-30 [1]: ideate, develop,…

> But hey, all the people working in 500k line files must really love the couple seconds my month of toiling (more importantly, my month of not doing other, more impactful things) saved them. This stuff matters. These couple seconds per operation may very well be a difference between being able to open a 100k+ LOC file in the same editor you're doing your other work in, vs. giving up in frustration and looking for so…

I have adhd. Every "couple seconds" of waiting is a chance for me to lose focus and "wait what was I doing?" 15 minutes later. This stuff definitely matters.

Re: New Grad vs. Senior Dev

#330

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.

No, various bits and pieces of it did, but not the whole, coherent field, which is motivated by the existence of computers.

Post reply on HN