The "nihilist" described here is a person that sees implementation as means towards an end, and in this perspective, functional requirements are at the center.

The "nihilist" described here is a person that sees implementation as means towards an end, and in this perspective, functional requirements are at the center. Because of this, for these people software is a black box where the only important things are the touching surfaces. The "optimist" described here is a person that sees software in a more broader sense: functional AND non-functional requirements. Non-functional requirements include maintainability, scalability, performance, security, configuration, etc. and will strive to implement them. -- Now, my opinion: My name for the "nihilist" programmer are "feature fairies" or "duct tape programmers". The problem with feature fairies are that they create more problems than they solve, and never volunteer to fix them. Feature fairies like to get credited with completed features, but never with the defects associated with their contributions. Therefore they will usually play dumb when a bug happens, or an incident is declared, and make someone else clean up after them while they implement the next feature. So after a couple of years, you have someone credited with a lot of features, and a team of people that have been cleaning up after such person. The duct tape fairy is now a 10xer, a rockstar whose time is very valuable therefore needs to be paid more, even promoted, even though this person is responsible for wasting 90% of the engineering payroll in fixing trivially avoidable defects. The way to prevent that is to leave a trail of evidence that can link commits to bugs. When an incident happens, make sure to identify the commit id causing the problem and put it directly in the ticket. Make it very clear where the defects are coming from and who they're coming from. Never volunteer to clean up after a feature fairy. By the time you do this, the feature fairy marked their task as complete and from the eyes of management you would be wasting your time working on a completed task. Rather than doing that: - When the feature fairy wants to take on the next task, ask if they have fixed one of the defects caused by them as per evidenced in the commit id. - Rather than opening a new ticket, reopen the original ticket. This better reflects the situation: you are completing the work the duct taper failed to complete, you are not adding new work. This also denies the duct taper of their prized fake task completion. When a feature fairy volunteers to be in a hiring committee, prevent it at all costs. They last thing you need is having to clean up after more people. Be careful while doing this to not be perceived as negative.