[riku_iki]

I think the reason to like working on existing code is that infra is usually very complex nowdays, and for greenfield project you need to do lots of boring tasks to bootstrap it, and for existing code it is already bootstrapped by someone.

[therealdrag0]

Not just infra. It’s the tests, it’s the crud, its getting clients and config setup, it’s banal decisions around copying existing patterns or trying to refine them for next gen copy pasting.

It’s fun early in career, but gets boring fast IMO. These are good things to have junior and mid eng cut their teeth on.

[0xEFF]

The sweet spot is for someone with deep experience to lay down the skeletal structure of the tests, rpc, infra, lifecycle, etc… then hand it off to a broader team who could learn the intention behind the decisions.

[jrumbut]

> who could learn the intention behind the decisions

If people did learn those intentions we wouldn't have the problems we have.

I inherited a project like this once as the third generation to take it over. The (evidently, I never met them) well trained and experienced first developers laid down a foundation using a textbook OO style with a few little tricks needed to make that work in a language where OOP support was bolted on. The code was not perfect, but it was professional work and I would put it around the 80th percentile in terms of code quality.

These tricks caused the virtues of that foundation to be overlooked entirely, and so the project was essentially reimplemented in spaghetti style over time with various ad hoc stovepipes to pass data back and forth between the two sides when the original had functionality that wasn't understood well enough to be reimplemented.

The importance of training, communication, and retention can not be overstated.

[riku_iki]

Yeah, sorry, I personally call it dev infra