51–60 of 271 posts
Earlier quoted context omitted.
> Amazingly quickly he would suss out the problem and get things running -- making the customer happy and rescuing the SLA Probably skills they learned reading their own code. I've noticed it with other people, the ones he can quickly debug spaghetti are the ones that will create more of it. It's why they stick around, management likes them because the can solve problems, they just don't see the creation of yet more…
It's a balance you need to run. But as a PM, spaghetti fixers are indeed very nice to have around. Keeping an eye on technical debt is important though.
An even more egregious form of negative work is a developer who is stuck using out of date programming practices AND has a large amount of influence at a company. At the other extreme is the developer who is so entranced by "newer is better" mentality that they rewrite everything in an attempt to conform to "latest best practices", increasing complexity massively while introducing a bunch of bugs and huge dependencie…
+1 to this. I used to work with a guy like that and it created a ton of tech debt. He would write new services using a new technology for each one, not to documenting or maintaining any of them.
An even more egregious form of negative work is a developer who is stuck using out of date programming practices AND has a large amount of influence at a company. At the other extreme is the developer who is so entranced by "newer is better" mentality that they rewrite everything in an attempt to conform to "latest best practices", increasing complexity massively while introducing a bunch of bugs and huge dependencie…
The "convoluted code" gauge is a double-edged sword. You could also be working at a company with developers who have no experience with the benefits of functional programming. In this scenario it's those who write nested loops, branching if-statements, and mutating side-effects that are in charge and you're the bad developer for using fold and map. You could be seen as an elitist who likes to write clever, obfuscated…
Earlier quoted context omitted.
+1 to this. I used to work with a guy like that and it created a ton of tech debt. He would write new services using a new technology for each one, not to documenting or maintaining any of them.
What's sad is that it looks great on his or her resume to do that. That developer might leave a trail of carnage but they don't care--on to the new shiny job for them. It never catches up.
Neomaniacs gonna succumb to neomania. The bigger question is why the system permits that, rather than steer those urges to try something new into useful experiments that might advance the status quo.
I have one exception to the "convoluted code" developer. I worked with a guy whose code was pure spaghetti. Mostly write-only code. BUT: if a customer had a crisis he was the person to send. Amazingly quickly he would suss out the problem and get things running -- making the customer happy and rescuing the SLA. And he could explain what the problem was so someone else could implement it again, properly, perhaps in 10…
> Amazingly quickly he would suss out the problem and get things running -- making the customer happy and rescuing the SLA Probably skills they learned reading their own code. I've noticed it with other people, the ones he can quickly debug spaghetti are the ones that will create more of it. It's why they stick around, management likes them because the can solve problems, they just don't see the creation of yet more…
My guess is that most of us have our positive and negative moments, and hopefully the positives outweigh the negatives.
Not all developers make positive contributions, but no single developer in a team of developers can make a non-positive contribution. They can't, because as a team, you've decided to allow this person to make contributions alone. You need to own that contribution. If you don't want to that responsibility, there is a solution: code reviews. Anything that gets submitted is literally something you've agreed to support a…