8 ms·

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 playe

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.
- samhw 4y ago
  > In the end, the person writing the code is just a cog in the machine. I mean, I hate to break it to you, but everyone is a cog in the machine. The person running the company is a cog in the machine. The person running the country is a cog in the machine. And, more than that, there's no hierarchy, there's no order. A person may go their entire lives working as a cleaner, looking up at the person running the company, and that person may look up at the pension fund that owns their company, which fund in turn exists to invest the pension of the cleaner. The world is a graph, not a tree. In the context of the dynamical chaos that we call the world, some people like to take pride in their craft. I think that's OK.
- thesz 4y ago
  go has null and has modifiable function parameters. The first thing is a reintroduction of billion dollar mistake [1] which is not acceptable in 21-st century. It was acceptable when Hoare did that because noone knew better then. It is not acceptable now. [1] https://en.wikipedia.org/wiki/Tony_Hoare#Apologies_and_retractions https://en.wikipedia.org/wiki/Tony_Hoare#Apologies_and_retra... The second point means that some predicate on locally constructed and held data that is true before calling a function with that data as parameters, may not be true after return from a call. These two "features" of a language make language hard to use. Instead of thinking about bigger things, you think about whether you may have NULL or not in this variable after that call to that function. In my not so humble opinion, taking OCaml and bolting on it type constructors (monads for hand-made channels, software transactional memory, etc, and even more than monads) could been better choice than reimplementing Simula on Plan 9, poorly. And I do not like OCaml at all. As per "unimportant cog" argument, I can only say that some companies recognize(d) talents in different areas. AFAIR, IBM used to have parallel ladders for officing-oriented and engineering people, with comparable salaries on comparable levels. I believe it is a good thing.

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.
samhw 4y ago
> In the end, the person writing the code is just a cog in the machine. I mean, I hate to break it to you, but everyone is a cog in the machine. The person running the company is a cog in the machine. The person running the country is a cog in the machine. And, more than that, there's no hierarchy, there's no order. A person may go their entire lives working as a cleaner, looking up at the person running the company, and that person may look up at the pension fund that owns their company, which fund in turn exists to invest the pension of the cleaner. The world is a graph, not a tree. In the context of the dynamical chaos that we call the world, some people like to take pride in their craft. I think that's OK.
thesz 4y ago
go has null and has modifiable function parameters. The first thing is a reintroduction of billion dollar mistake [1] which is not acceptable in 21-st century. It was acceptable when Hoare did that because noone knew better then. It is not acceptable now. [1] https://en.wikipedia.org/wiki/Tony_Hoare#Apologies_and_retractions https://en.wikipedia.org/wiki/Tony_Hoare#Apologies_and_retra... The second point means that some predicate on locally constructed and held data that is true before calling a function with that data as parameters, may not be true after return from a call. These two "features" of a language make language hard to use. Instead of thinking about bigger things, you think about whether you may have NULL or not in this variable after that call to that function. In my not so humble opinion, taking OCaml and bolting on it type constructors (monads for hand-made channels, software transactional memory, etc, and even more than monads) could been better choice than reimplementing Simula on Plan 9, poorly. And I do not like OCaml at all. As per "unimportant cog" argument, I can only say that some companies recognize(d) talents in different areas. AFAIR, IBM used to have parallel ladders for officing-oriented and engineering people, with comparable salaries on comparable levels. I believe it is a good thing.