This is good to know. I always thought it meant 10x average which seemed absurd. I can certainly attest to having worked on teams where there are one or two developers 10x better than the worst developers on the team. Tbh I think the worst developers are actually negative value because they take so much time from other developers.
One source for the 10x number is the book Peopleware. They did Coding War Games where developer got an exercise. The 10x is the time it took them to code an application which fulfills the requirements. The best is 2.5x compared to average.
Since it is a single person task, they cannot impact anyone negatively.
However, the most interesting fact in my opinion is that within the same organization the difference is only 0.3x. Either the organizational environment determines your productivity or the organization determines which kind of developers get there. The experiment does not tell us anything how the productivity of a developer changes when he changes organizations.
>If you split up clauses, having things modify other things across long distances with other ideas in between, it can get complicated.
I found this version easier to read. I think because with the other one I have to remember the beginning part of "It can get complicated" and try to apply that to all the conditions that come up throughout the rest of the sentence. I prefer to build up the picture of 'split clauses', 'long distance modifications' etc and then classify this as complicated afterwards rather than start with the classification.
Yeah, with just a few splits/nestings, it can go either way. It's only when you get a whole bunch that it gets difficult. I think I came up with a poor, lazy example.
Sounds kind of dismissive and passive aggressive. The architecture suggested in the article is terrible but I think the way to respond to it is to explain why it's terrible from a security standpoint and then also a maintenance standpoint. If they are smart they will get it and then move on to finding a way to fix the planning problems. Stonewalling and defending your corner is something I have personally seen evolve as a kind of toxic thing in big companies leading to breakdown of communication.
Clients, services... the original developer didn't see anything wrong with it, since transactions exist and foreign key relationships make sure the data model stays consistent, right? And you can combine some frequently used methods accessing the database in some helper classes, and if some of the clients use those, that's basically your business logic!
It's a pretty impressive house of cards.
Refactoring (or rather re-designing) this sort of thing while still churning out new features is tricky to say the least.
If you use React Native, React and a shared Redux layer you can share all this business logic between iOS, Android and Web. If you make breaking DB changes you still have the REST layer to buffer them. If REST won't cover your breaking changes with data transforms because you are deleting whole tables and restructuring then it's time to refactor the front end as well anyway. I disagree with the front end sending SQL directly but a thin REST layer with a little validation seems ideal to me.
(Besides the obvious cruelty and injustice as well as the extreme likelihood of rebellion and creation of a world government of evil monkey overlords, which might not necessarily be worse than what we currently have.)
I find the soft gel ones don't do me any good. I do better with the hard pill type and even better with topical cream. I think it's something to do with the cheap vegetable oil they are packed in.
