I might also say that, perhaps taking this question on from another angle, that a developer's job is not truly done until someone else can modify and maintain this code without speaking to the original developer.
Beekey Cheung is a software engineer with a large amount of enthusiasm for economics and a passion for education. He loves mentoring other programmers and is currently building an application to te...
I would agree in general, though while there are exceptions to my view, there are exceptions to this one as well. There are times when taking on a lot of technical debt makes sense. A cash crunch is one of them. No one will be modifying or maintaining the code if the company goes under. Maybe if it's a popular open source project, but even then it needs an evangelist.
30+ years of tech, retired from an identity intelligence company, now part-time with an insurance broker.
Dev community mod - mostly light gardening & weeding out spam :)
I would suggest that there are two conditions that indicate when someone is done with a codebase:
1: As Ben says, when all responsibility can be handed over.
2: When the code is no longer in service, because it's been withdrawn / replaced [or the company has gone under!] This is typically a much longer timespan than initial delivery, and gets forgotten when companies operate a project mentality (cf: construction metaphors that fail), instead of a product life cycle one.
As a developer, it's good to have these exit conditions in mind when you create new code :)
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I might also say that, perhaps taking this question on from another angle, that a developer's job is not truly done until someone else can modify and maintain this code without speaking to the original developer.
I would agree in general, though while there are exceptions to my view, there are exceptions to this one as well. There are times when taking on a lot of technical debt makes sense. A cash crunch is one of them. No one will be modifying or maintaining the code if the company goes under. Maybe if it's a popular open source project, but even then it needs an evangelist.
I would suggest that there are two conditions that indicate when someone is done with a codebase:
1: As Ben says, when all responsibility can be handed over.
2: When the code is no longer in service, because it's been withdrawn / replaced [or the company has gone under!] This is typically a much longer timespan than initial delivery, and gets forgotten when companies operate a project mentality (cf: construction metaphors that fail), instead of a product life cycle one.
As a developer, it's good to have these exit conditions in mind when you create new code :)