As time goes by I don't see much of a difference. If I spent six months building something for client A and then a year doing something entirely different for client B, I will have to puzzle out what my intentions were a year ago just as I would have to do maintaining code anybody else wrote.

Truly agile developers approach development by building a working system that can run but is far from the requirements and then making subsequent changes to the code to satisfy them one by one. Each "Sprint" is just a round of maintenance. Even the first release to production would have been rehearsed on a staging environment so that release might not be such an emotionally charged event because it is not a chance to slow down but instead start fixing bugs and adding features...

80% Maintaining.

There was an article on HN. A while back about the value of maintainers over innovators. Keeping stuff ticking along is just as important and under valued (was the gist).

99% maintaining. I think part of the reason is I want to be paid well and so that naturally filters out greenfield stuff. The well paying greenfield requires greenfield experience in whatever hyperspecific stack they are using.

Most of my time has been maintaining. I've gotten the opportunity to build a couple of things as well from scratch and that is always fun, but I get more of a kick from maintaining large existing codebases, learning about them, trying to follow good practices and figure out why certain things were done the way they were. While building is fun, maintaining (if you have the opportunity to take the time to maintain properly and really invest in understanding the system) is rewarding in its own way.

80% building. I do specialize in this field of building things quickly and sustainably.

And in a lot of cases, like a "UI upgrade" of a decade old project we had lately, the hardware, the API, and the tech are so different that it's easier to rewrite from scratch.

Some large companies also contract other massive companies to build things for them, where the code belongs to the contractor. Updates can be very expensive, and so people often rebuild.

Depends on the job, but usually about 70% building, 30% maintaining.

There have been some exceptions to this, but they usually acted as a warning that the work environment wasn't going to be right for me. Indeed, it often feels like being stuck on maintenance work implies the managers don't believe you'll be around much longer/don't trust you with anything new.

You have to advocate for new features and upgrades regularly. Management typically likes new stuff if you can convince them they'll benefit, either in terms of a splashy project success, expanded head count, increased budget, etc.

Whenever possible, pawn off maintenance on junior programmers, too.

90% new for me, a very grudging 10% maintenance.

Arguably, most of the work there is to do on software is maintenance. The percentage will only increase as more and more of the software that people find useful or entertaining has been implemented to an MVP level.

I'm stuck inheriting other people's messes (when I far prefer making my own).

97.5% maintaining

2.5% building

needless to say I'm not where I began my career anymore as I believe the ratio should be more balanced

Probably 60% maintaining, 40% building. large corporate engineering.

99% building.