So you're implying only people who are passionate about tech should be allowed to work in tech? This does not hold water for almost any profession. Tech pays extremely well, and if you can do the work, who cares how you feel about it?
If you can do the work, awesome, no one cares how you feel about it. But that's the keyword: *IF* you can.
People who went into IT for the love of it are diligent by default (from my personal experience) and CAN do the work. Then you get people who enter IT for the money (nothing wrong with that) and not all of them can do the work.
Those are the show-stoppers usually which incur various debts (from tech-debt to actual financial debt) because you end up having to carry them.
Let's not pretend as if they don't exist, there's so many of them.
Absolutely, and it's hugely demoralizing to work with them.
A person like that was moved off of my team recently, and the general lift on the team from just having them gone has been astounding. Everything is up: velocity, stability, even just the vibe of technical planning sessions.
> We've known since the early sixties, but have never come to grips with the implications that there are net negative producing programmers (NNPPs) on almost all projects, who insert enough spoilage to exceed the value of their production. So, it is important to make the bold statement: Taking a poor performer off the team can often be more productive than adding a good one. [6, p. 208] Although important, it is difficult to deal with the NNPP. Most development managers do not handle negative aspects of their programming staff well. This paper discusses how to recognize NNPPs, and remedial actions necessary for project success.
The other most interesting part of the book (while certainly dated), is the citations to see what came before and more material on it.
Weinberg, Gerald M. The Psychology of Computer Programming (New York: Van Nostrand Reinhold, 1971)
Dunn, Robert H. Software Quality: Concepts and Plans (Englewood Cliffs: Prentice Hall, 1990)
Christenson, D. A. et al, "Statistical Methods Applied to Software", collected in Schulmeyer, G. Gordon & McManus, James I. Total Quality Management for Software (New York: Van Nostrand Reinhold, 1992)
(and so on)
And while one can certainly debate the "is the advice given in something that is 30 or 50 years old still valid" - that debate itself is interesting in considering what was going on in the minds of managers back then and how they tried to solve these problems.
There is a certain lack of institutional knowledge and a desire to throw much of it away with the phrase "we're agile" or some other management buzzword of the day... and yet Brook's Law is still as valid today as it was nearly five decades ago (gotta keep an eye on that... I wonder if they'll do a third edition in 2025).
I once had to fire that person. I hated it, it was very hard to do because they guy was a personal friend of mine and he never talked to me again afterwards. However, it fixed the team and we went on to do a lot of very good work that we couldn't have done otherwise.
Bit of a tangent, but it's kind of harder to hire as well.
Years ago when interviewing people I didn't have to wonder as often how passionate the candidate actually is towards the field, or whether they're just looking for a high pay job.
These days I get those doubts a bit more. I think most people are still at least somewhat passionate though (bad/awkward programmer tooling which we've gotten used to are somehow great filters....)
It is more fun to work with people that love the work they are doing, who get jazzed up on covering all the corner cases and really good test suites and efficient use of a computer. People who will listen to tech talk for ten minutes and then act like they are thinking, “how will this get me director or VP by thirty” are less engaged and less fun.
During the dot-com days, you could get a job if you can fog a mirror and turn on a PC. Now you typically need to get a degree to get your foot in the door so at least there is a vested interest. (Not to say there aren’t talented people without degrees.) I think the OP is talking about getting rid of some of the dead weight. We’ve all worked with someone who coasts along and wonder how the hell they have a job in the first place.
Excitement about what you’re doing brings excitement to others too and many great ideas come from people tinkering with side projects and the like. We shouldn’t stop anyone from going into tech on anything but competency but yes, given the choice to hire someone passionate about it or someone who sees it as a droll 9-5 with roughly equivalent skill sets, I’d pick the passionate one.
