3 ms·

> It is tedious. > to reduce the variance between the best programmer on a project and the worst. In my experience the only way this can be done as with tryin

> It is tedious. > to reduce the variance between the best programmer on a project and the worst. In my experience the only way this can be done as with trying to level anything is to bring down the level of the best. I find this awful.

AnimalMuppet 4y ago
It may be awful to the best programmer. But if you're looking at the team as a whole, well, how many of the best do you have on the team? It's really hard to create large teams where the average programmer on the team is better than the average programmer in the country. If you can bring up the lower half of the team, that may be a net win, even if it brings down the best one on the team. The effect of that may be that the best programmers leave the team, though...
- gmfawcett 4y ago
  If the skill difference among your devs is really high, it may be preferable to have the best programmer leave, or at least change roles (architect, team lead, trainer), as this may increase productivity of the median workers. At least the skill difference should be treated as a risk and properly mitigated.
  - tonyarkles 4y ago
    In the role in my sibling comment, I somewhat filled the role of the developer that went away. Hardcore Java/Spring Boot guy who could wrap his head around these amazingly complex code bases he made that the younger/less experienced devs could not manage on their own. I spent a ton of time mentoring in my role, and hopefully helped undo some of the mental damage the previous guy did :D. Things were running much smoother when I left then they did when I first joined at least, with teams that could have chosen whatever language they wanted choosing Go voluntarily.
- tonyarkles 4y ago
  I used Go (didn’t choose it exactly) at an olds job of mine 4 or 5 years ago. I was definitely the most senior and very likely the best developer at the company. Organizationally, many of their backend services were Java-based using Spring Boot, although there were a few Python and NodeJS ones as well. My general observation was: The people who called themselves Java programmers or Python programmers or JavaScript programmers complained a ton about Go. The people who weren’t committed to any particular language didn’t seem to mind at all. (I am in the whatever-language-let’s-write-code camp myself) We weren’t in love with it. I don’t use it for spare time projects (woo Common Lisp with SBCL). The only super positive feedback I really remember is “wow! It’s so easy to just walk through from when the program starts to knowing where all the endpoints are and where you can find the source!” which isn’t so much praise of Go but an indictment of Spring Boot.
- dhzhzjsbevs 4y ago
  Meh, the best developers sound like whiny brats. I'm not the best developer but I've been around long enough to know that bringing the bottom half of development up to the plate does more for me in my day job than catering to what magic bullshit the "best" developers are pumping.
BobbyJo 4y ago
I've found Go's compromises help good programmers too over the long run. It isn't lowering the variance by slowing down the quick, it does it by shrinking the space of possible solutions. Bad programmers and good programmers wind up making similar "good enough" design choices. You don't wind up with over engineered frameworks for every bit of logic in you backend.
mathattack 4y ago
For small companies, variance can be good. For large companies, avoiding surprises is everything. So they cram a bunch of processes to make everyone a B player. That’s great if you’re naturally a C player, and can be less work if you’re a B+ player who wants to coast. But it’s hell hell if you’re an A player who is now working with handcuffs, and getting paid the same as the C player.
- reedjosh 4y ago
  ^^ This!
  - cudgy 4y ago
    I guess the correct language depends on the ratio of good/bad developers in this case.
- Cthulhu_ 4y ago
  Can you consider yourself an A player if you think yourself too good to work with B / C players in a language that, as you say, handcuffs you? I mean it frees you up mentally to think about the bigger problems, beyond the bit of code you're working on right now. In the end, the person writing the code is just a cog in the machine. You can try and pretend you're an Important cog by being Very Clever and using very smart code, but in the end you're not actually important. If you want to be important, you need to let that code go and move up, towards architecture and company level.
  - mathattack 4y ago
    It’s not the people who handcuff, it’s the process. I will use Sales since the metrics less ambiguous there. In a startup, without a lot of structure, a great salesperson will find deals that others can’t, and will close many more of them. They will have the autonomy to get things done and are rewarded when they crush their quotas. In large companies, there are all kinds of Marketing and Sales support programs that lift the average salesman. But a great salesman is told “Only talk to companies on your list” and “All your deals must get approved by the deal desk” and “Don’t sell more than X because it will ruffle feathers downstream” These processes are good in aggregate but drive top performers nuts.
Cthulhu_ 4y ago
> In my experience the only way this can be done as with trying to level anything is to bring down the level of the best. > I find this awful. It mitigates risk; if "the best" is at a level above the other developers, to the point where a lot of things hinge on this individual, it's a huge company risk. You never want to rely on "the best"; see also https://en.wikipedia.org/wiki/Bus_factor https://en.wikipedia.org/wiki/Bus_factor Go is a language that tells people to put their ego aside. The problem you're solving is already complicated enough, no need to add complexity with a complex language. Dumb and verbose code is better than concise but complex and hard to comprehend code.
- thesz 4y ago
  Errors are introduced at constant ratio per line of code that is not syntactically checked by compiler. The ratio is specific to developer and language used. E.g., you can't make a mistake on a line that contains only curly bracket, but you can make (one-off) mistake on line "i += 10;" The more verbose code, the more lines of code that are not syntactically checked. The more errors you introduce during development. Why I talk about syntax and not types? Because type system of go and some other languages like C (and C#, C++ and some other including OCaml, for that matter) are not rich enough to express long dependencies as is done in Rust with its borrow checker. Rust has its own failing, of course. In some cases of type systems [1] it is possible to express environments with long dependencies without resorting to hacking of a compiler. But most languages do not have that luxury, the only dependence checking are balancing brackets and missing variable declarations. [1] http://blog.sigfpe.com/2009/02/beyond-monads.html http://blog.sigfpe.com/2009/02/beyond-monads.html The axiom of (not only) software engineering says that cost to fix a defect is directly propotional to the time between introduction and discovery of said defect. The funnel of defect filtering (personal review, colleague code review, CI, QA, beta, etc) is not perfect, it still allows for some defects to fall through. The more defects are on wide part of the funnel, the more defects are on the narrow part of it. And for these defects that pass through, the time between introduction and discovery is bigger than for all other defects. The more verbose code in some language, the more defects developer will generate using that language. The more defects will pass through defect detection funnel. The biger will be the cost to fix them and cost of software user to, well, use the software. Google can afford that, because they can afford extremely long funnel with prolonged code reviews, big QA teams and long lasting betas. They can afford that because of money they got. Practically everyone else cannot afford that. Ego is not even a problem when you factor all other problems you get with simple or good enough verbose solutions.

AnimalMuppet 4y ago

It may be awful to the best programmer. But if you're looking at the team as a whole, well, how many of the best do you have on the team? It's really hard to create large teams where the average programmer on the team is better than the average programmer in the country. If you can bring up the lower half of the team, that may be a net win, even if it brings down the best one on the team. The effect of that may be that the best programmers leave the team, though...

gmfawcett 4y ago
If the skill difference among your devs is really high, it may be preferable to have the best programmer leave, or at least change roles (architect, team lead, trainer), as this may increase productivity of the median workers. At least the skill difference should be treated as a risk and properly mitigated.
- tonyarkles 4y ago
  In the role in my sibling comment, I somewhat filled the role of the developer that went away. Hardcore Java/Spring Boot guy who could wrap his head around these amazingly complex code bases he made that the younger/less experienced devs could not manage on their own. I spent a ton of time mentoring in my role, and hopefully helped undo some of the mental damage the previous guy did :D. Things were running much smoother when I left then they did when I first joined at least, with teams that could have chosen whatever language they wanted choosing Go voluntarily.
tonyarkles 4y ago
I used Go (didn’t choose it exactly) at an olds job of mine 4 or 5 years ago. I was definitely the most senior and very likely the best developer at the company. Organizationally, many of their backend services were Java-based using Spring Boot, although there were a few Python and NodeJS ones as well. My general observation was: The people who called themselves Java programmers or Python programmers or JavaScript programmers complained a ton about Go. The people who weren’t committed to any particular language didn’t seem to mind at all. (I am in the whatever-language-let’s-write-code camp myself) We weren’t in love with it. I don’t use it for spare time projects (woo Common Lisp with SBCL). The only super positive feedback I really remember is “wow! It’s so easy to just walk through from when the program starts to knowing where all the endpoints are and where you can find the source!” which isn’t so much praise of Go but an indictment of Spring Boot.
dhzhzjsbevs 4y ago
Meh, the best developers sound like whiny brats. I'm not the best developer but I've been around long enough to know that bringing the bottom half of development up to the plate does more for me in my day job than catering to what magic bullshit the "best" developers are pumping.

BobbyJo 4y ago

I've found Go's compromises help good programmers too over the long run. It isn't lowering the variance by slowing down the quick, it does it by shrinking the space of possible solutions. Bad programmers and good programmers wind up making similar "good enough" design choices. You don't wind up with over engineered frameworks for every bit of logic in you backend.

mathattack 4y ago

For small companies, variance can be good. For large companies, avoiding surprises is everything. So they cram a bunch of processes to make everyone a B player. That’s great if you’re naturally a C player, and can be less work if you’re a B+ player who wants to coast. But it’s hell hell if you’re an A player who is now working with handcuffs, and getting paid the same as the C player.

reedjosh 4y ago
^^ This!
- cudgy 4y ago
  I guess the correct language depends on the ratio of good/bad developers in this case.
Cthulhu_ 4y ago
Can you consider yourself an A player if you think yourself too good to work with B / C players in a language that, as you say, handcuffs you? I mean it frees you up mentally to think about the bigger problems, beyond the bit of code you're working on right now. In the end, the person writing the code is just a cog in the machine. You can try and pretend you're an Important cog by being Very Clever and using very smart code, but in the end you're not actually important. If you want to be important, you need to let that code go and move up, towards architecture and company level.
- mathattack 4y ago
  It’s not the people who handcuff, it’s the process. I will use Sales since the metrics less ambiguous there. In a startup, without a lot of structure, a great salesperson will find deals that others can’t, and will close many more of them. They will have the autonomy to get things done and are rewarded when they crush their quotas. In large companies, there are all kinds of Marketing and Sales support programs that lift the average salesman. But a great salesman is told “Only talk to companies on your list” and “All your deals must get approved by the deal desk” and “Don’t sell more than X because it will ruffle feathers downstream” These processes are good in aggregate but drive top performers nuts.

Cthulhu_ 4y ago

> In my experience the only way this can be done as with trying to level anything is to bring down the level of the best. > I find this awful. It mitigates risk; if "the best" is at a level above the other developers, to the point where a lot of things hinge on this individual, it's a huge company risk. You never want to rely on "the best"; see also https://en.wikipedia.org/wiki/Bus_factor https://en.wikipedia.org/wiki/Bus_factor Go is a language that tells people to put their ego aside. The problem you're solving is already complicated enough, no need to add complexity with a complex language. Dumb and verbose code is better than concise but complex and hard to comprehend code.

thesz 4y ago
Errors are introduced at constant ratio per line of code that is not syntactically checked by compiler. The ratio is specific to developer and language used. E.g., you can't make a mistake on a line that contains only curly bracket, but you can make (one-off) mistake on line "i += 10;" The more verbose code, the more lines of code that are not syntactically checked. The more errors you introduce during development. Why I talk about syntax and not types? Because type system of go and some other languages like C (and C#, C++ and some other including OCaml, for that matter) are not rich enough to express long dependencies as is done in Rust with its borrow checker. Rust has its own failing, of course. In some cases of type systems [1] it is possible to express environments with long dependencies without resorting to hacking of a compiler. But most languages do not have that luxury, the only dependence checking are balancing brackets and missing variable declarations. [1] http://blog.sigfpe.com/2009/02/beyond-monads.html http://blog.sigfpe.com/2009/02/beyond-monads.html The axiom of (not only) software engineering says that cost to fix a defect is directly propotional to the time between introduction and discovery of said defect. The funnel of defect filtering (personal review, colleague code review, CI, QA, beta, etc) is not perfect, it still allows for some defects to fall through. The more defects are on wide part of the funnel, the more defects are on the narrow part of it. And for these defects that pass through, the time between introduction and discovery is bigger than for all other defects. The more verbose code in some language, the more defects developer will generate using that language. The more defects will pass through defect detection funnel. The biger will be the cost to fix them and cost of software user to, well, use the software. Google can afford that, because they can afford extremely long funnel with prolonged code reviews, big QA teams and long lasting betas. They can afford that because of money they got. Practically everyone else cannot afford that. Ego is not even a problem when you factor all other problems you get with simple or good enough verbose solutions.