4 ms·

Interesting topic, lots of sweeping generalizations being thrown around. Personally, I've found my politics have not changed substantially as I've aged. As a 2

Interesting topic, lots of sweeping generalizations being thrown around. Personally, I've found my politics have not changed substantially as I've aged. As a 20 year old, I was liberal, and in my mid-30s with a mortgage and a family, I'm still quite liberal. However, I've found my professional proclivities have changed. I value maintenance and conscientiousness much more than I once did. I think that's due to a few reasons. For one, I've been through a few big rewrites, and inevitably, I've seen them fail or be much harder than anticipated. But also, my focus has shifted from using cool new technologies to delivering value through working software. It's often much less effort to maintain and slowly improve software systems than it is to innovate your way out of a mountain of technical debt. It's hard for businesses to understand this. Often, the expensive "A team" builds new software, while the cheaper "B team" maintains it, but the reality is that in short order, that software will effectively be written by the "B team". Software would last much longer and just function better in general if you kept the "A team" on to maintain, upgrade, refactor, etc. Of course, this isn't totally business's fault, because maintenance is seen as a career killer. So if you try to have the "A team" maintain, many will leave for greener pastures where they get to build new systems in new tools. As an industry, I wish we cared more about the longevity of systems, rather than what new tools are used. We seem to be impressed when we hear someone talk about building a new system in React, Elixir, and Kafka (or whatever's new and shiny at the moment), but nobody wants to hear someone talk about a system they built eight years ago in, say, Java that is still working well, still helping users, still meeting the needs of the business.

nostrademons 9y ago
Maintenance and green-field development are different skillsets. Green-field development requires that you can envision what doesn't exist and hold it in your head long enough, and precisely enough, to build it. Maintenance requires that you take what already exists and improve it. Green-field development tends to be more intuitive, and it requires the ability to balance many trade-offs and consider many possible solutions in your head. Maintenance programming requires less creativity and to some degree less short-term memory, but more attention to detail, more logical thinking, more communication skills, and more ability to read & make sense of existing code. I've worked in both situations, but I'm better at one than the other. It's very rare to find someone who is excellent at both. You do get the benefit of accumulated domain knowledge when you keep the initial developers on to maintain the system, but oftentimes they don't have the temperament or personality to be happy and successful in that role.
- Tenhundfeld 9y ago
  So, I think I agree with you, in general, that people can be better suited to green-field or maintenance, both from a skillset and personality perspective. But I also think good, active maintenance can have a lot of creativity and require, as you say, envisioning what doesn't exist. If we're just talking about bug fixes and level-2 support or something, sure, that's mostly about attention to detail, etc. However, maintenance is much more than that, in my experience. Maintenance involves keeping a system up to date and functioning in the face of changing business requirements. So, you have a new customer come onto the system or a department wants to change a business process, and now you need to change the system. What was once a single implementation of some feature now makes more sense as an abstraction with extensibility points. Or maybe just the system has more data than anticipated, and a good developer might realize that instead of putting a bandaid on the Postgres search, it's better to integrate a dedicated search solution like Elastic. The point is that software is never done, as long as it's being used. Drawing a line between development and maintenance is often just an arbitrary distinction.
  - nostrademons 9y ago
    I guess I should've said "a different kind of creativity" rather than "less creativity". When you're doing maintenance work - even the sorts of large scale rewrites that totally change the architecture - your requirements are known. You can write down the goal, ideally write automated tests for it, and then you're done when the system passes the tests. Figuring out the solution may require a lot of creativity and intuitive leaps, but at least both the starting and ending points are expressed in rational terms. For green-field software products (contracting is different, and much more akin to product maintenance), your requirements are unknown. Your ultimate acceptance criteria is "does the user like it?", which is an emotional one, not a logical one. This requires that you connect the rational part of your brain, which speaks the language of the machine, with the emotional part, which speaks the language of the user. Being able to exercise both parts in tandem is a very rare skillset, which is why market rates for truly innovative programmers range into the millions. (This ability to fuse emotional & rational thinking together is also a skillset required of CEOs, executives, politicians, and pop entertainers, all of which are also professions with compensation reaching into the millions.)

nostrademons 9y ago

Maintenance and green-field development are different skillsets. Green-field development requires that you can envision what doesn't exist and hold it in your head long enough, and precisely enough, to build it. Maintenance requires that you take what already exists and improve it. Green-field development tends to be more intuitive, and it requires the ability to balance many trade-offs and consider many possible solutions in your head. Maintenance programming requires less creativity and to some degree less short-term memory, but more attention to detail, more logical thinking, more communication skills, and more ability to read & make sense of existing code. I've worked in both situations, but I'm better at one than the other. It's very rare to find someone who is excellent at both. You do get the benefit of accumulated domain knowledge when you keep the initial developers on to maintain the system, but oftentimes they don't have the temperament or personality to be happy and successful in that role.

Tenhundfeld 9y ago
So, I think I agree with you, in general, that people can be better suited to green-field or maintenance, both from a skillset and personality perspective. But I also think good, active maintenance can have a lot of creativity and require, as you say, envisioning what doesn't exist. If we're just talking about bug fixes and level-2 support or something, sure, that's mostly about attention to detail, etc. However, maintenance is much more than that, in my experience. Maintenance involves keeping a system up to date and functioning in the face of changing business requirements. So, you have a new customer come onto the system or a department wants to change a business process, and now you need to change the system. What was once a single implementation of some feature now makes more sense as an abstraction with extensibility points. Or maybe just the system has more data than anticipated, and a good developer might realize that instead of putting a bandaid on the Postgres search, it's better to integrate a dedicated search solution like Elastic. The point is that software is never done, as long as it's being used. Drawing a line between development and maintenance is often just an arbitrary distinction.
- nostrademons 9y ago
  I guess I should've said "a different kind of creativity" rather than "less creativity". When you're doing maintenance work - even the sorts of large scale rewrites that totally change the architecture - your requirements are known. You can write down the goal, ideally write automated tests for it, and then you're done when the system passes the tests. Figuring out the solution may require a lot of creativity and intuitive leaps, but at least both the starting and ending points are expressed in rational terms. For green-field software products (contracting is different, and much more akin to product maintenance), your requirements are unknown. Your ultimate acceptance criteria is "does the user like it?", which is an emotional one, not a logical one. This requires that you connect the rational part of your brain, which speaks the language of the machine, with the emotional part, which speaks the language of the user. Being able to exercise both parts in tandem is a very rare skillset, which is why market rates for truly innovative programmers range into the millions. (This ability to fuse emotional & rational thinking together is also a skillset required of CEOs, executives, politicians, and pop entertainers, all of which are also professions with compensation reaching into the millions.)