
Ask HN: How much of your career has been building vs. maintaining? - cmorgan8506
Like most developers, I love to build. Unfortunately, the majority of my career has been maintaining existing applications.<p>I&#x27;m curious how much others have spent building new software versus maintaining old.
======
PaulHoule
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...

~~~
w4tson
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).

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

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

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

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

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

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

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

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

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

------
chrisbennet
99% building.

