41–50 of 271 posts
Earlier quoted context omitted.
True. Code reviews and standards are the tools to use in this case.
I've found that code reviews are one of the best ways to increase code quality. Even just talking with other developers about why they've done things is helpful in thinking about simpler options and keeping things closer to the architectural vision.
There's this magical process called continuous integration that internalizes the impact of bad (or, more likely, misguided) developers. Don't let them merge their branch until all tests pass. If their commit breaks something while all tests still pass, then direct them to write the missing tests.
Sometimes they are in politically privileged positions and you can't get rid of them, ask me how I know.
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…
At a previous company, the tech influencers believed in the archaic "do everything in the database." While we were technically using the .Net stack, we weren't allowed to do any actual business logic in C#. Instead it had to all be done in MS-SQL procedures (or at least at much as possible with very little CLR glue).
Similarly at my current company, we had a product were the initial devs wanted to jump on the RXJS and Socket.io bandwagons. The only problem was the rest of the company was using standard REST endpoints and promises to do the same thing, so any new devs who joined that team suddenly had massive cognitive overhead they had to overcome. Any changes to the codebase we're done by people who only half understood what they were doing, and so the complexity compounded. Thankfully, I was given the chance to rewrite the whole codebase to match what our other products looked like, so now the code is much more sane to work with.
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…
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…
To be fair, many debugging tool chains are crap with folds and maps instead of loops. And code is rarely written in anger, but often debugged that way.
Debugging can bring out the worst in the best of us.
Luckily I don't often have to debug code from functional programmers. The errors are usually mitigated by design and often easier to spot or reason about than in a function with a dozen branches mutating the object behind a pointer.
The reason I call it a double-edged sword is because the majority will determine what is normal or acceptable. If you come to their office expecting to reveal the shadows on the wall you may very well find yourself looking for another office elsewhere.
The harrowing difficulty is in bridging the gaps between each other and our differing approaches to developing software.
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 10X the time, and ship the patch to all the customers.
In other words: if the river was rising and the dam was leaking, this guy would stride in confidently and jam his fingers into all the holes, saving the city. Not a long term or scalable fix, but preventing disaster.
(I'm pretty sure 50% of developers on HN have used this guy's code BTW).
If the resident developer A has used the wrong approach to solving a problem and developer B comes along and uses a better approach, dev B could be seen as introducing something overly complicated and less understandable.
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…
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 problems.
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…