4 ms·

The problem there is that your coworkers working in those languages who don't have Erlang/Elixir experience have not internalized those lessons yet and they're

The problem there is that your coworkers working in those languages who don't have Erlang/Elixir experience have not internalized those lessons yet and they're not going to understand why you're doing what you're doing when they review your code. Edit: I remember an interview that I had once with a team that was trying to bring on a senior to improve their PHP code and they were really unused to the code style I used to solve their problem. Their main issue was the way wrote their code duplicated most of the (very large) request data unnecessarily many times and forced PHP to add more chunks of RAM several times as it handled the request. My code cut all of that fat, but because they didn't understand that's what their problem was they wrote it off as "this guy doesn't know how to code". They didn't even ask and I was glad to not move forward, ultimately.

tluyben2 6y ago
This is a problem with 'theoretical' (books/uni 'experience') and 'IBM thinking' (people are more expensive than adding more machines, so always optimize for using less people time; just add machines... says the hardware (and per core software license) vendor. Amazon AWS agrees!) people is that they lack the real life experience where things do not fit in 'best practices' (as in design patterns) or green field architectures from books/tutorials if you don't want to scale up to 1000 nodes for 100.000 users. Optimizing this (so you can run those 100.000 on 1 node, but let's say 2 for failover) might not result in code which people might find 'understandable' from their point of view. A lot of people with even years of experience, work in a kind of 'process' way; stacking up code the way they have learned and handle every case as the same case with 'somewhat different logic'. They might not understand your code or they might understand it but think it's not adhering to proper best practices and standards. Their loss.
- busterarm 6y ago
  I also think that while these engineers all went to schools where they got both high level and low level programming under their belts, not enough of them really made the connection to understand what their code actually makes the computer do, aside from in the theoretical sense (Big O). We're not really training enough truly full-stack engineers.
  - hinkley 6y ago
    I walked out of college having made a game of one-upmanship with a friend (easy CS homework days, we’d compete against each other over runtime or algorithms), onto a project whose UI was so slow you could watch the screen paint itself. It was so bad I was ashamed to be associated with the project, but I moved a long way so I stuck it out for a bit, until it was respectable. I think I learned as much about performance tuning in the next six months as most people do in their entire careers. A couple jobs later and I could write a few chapters of an advanced book on performance analysis (in particular perf logs tend to hide critical info in plain sight). We mostly just don’t care, and too many of us have honed or at least mislearned excuses for our behavior that business folks have no way to talk us out of. Most vexing for me is when customers threaten to leave over performance and the senior staff pull up some graphs that say we have done all we can. It’s fairly straightforward to climb the ranks on such a project by proving them wrong. These sorts often leave 2-3x (that I know how to find, who knows what he real number is) on the table, which is often enough to satisfy the customer. It’s often hard work but there’s nothing magic about it.

tluyben2 6y ago

This is a problem with 'theoretical' (books/uni 'experience') and 'IBM thinking' (people are more expensive than adding more machines, so always optimize for using less people time; just add machines... says the hardware (and per core software license) vendor. Amazon AWS agrees!) people is that they lack the real life experience where things do not fit in 'best practices' (as in design patterns) or green field architectures from books/tutorials if you don't want to scale up to 1000 nodes for 100.000 users. Optimizing this (so you can run those 100.000 on 1 node, but let's say 2 for failover) might not result in code which people might find 'understandable' from their point of view. A lot of people with even years of experience, work in a kind of 'process' way; stacking up code the way they have learned and handle every case as the same case with 'somewhat different logic'. They might not understand your code or they might understand it but think it's not adhering to proper best practices and standards. Their loss.

busterarm 6y ago
I also think that while these engineers all went to schools where they got both high level and low level programming under their belts, not enough of them really made the connection to understand what their code actually makes the computer do, aside from in the theoretical sense (Big O). We're not really training enough truly full-stack engineers.
- hinkley 6y ago
  I walked out of college having made a game of one-upmanship with a friend (easy CS homework days, we’d compete against each other over runtime or algorithms), onto a project whose UI was so slow you could watch the screen paint itself. It was so bad I was ashamed to be associated with the project, but I moved a long way so I stuck it out for a bit, until it was respectable. I think I learned as much about performance tuning in the next six months as most people do in their entire careers. A couple jobs later and I could write a few chapters of an advanced book on performance analysis (in particular perf logs tend to hide critical info in plain sight). We mostly just don’t care, and too many of us have honed or at least mislearned excuses for our behavior that business folks have no way to talk us out of. Most vexing for me is when customers threaten to leave over performance and the senior staff pull up some graphs that say we have done all we can. It’s fairly straightforward to climb the ranks on such a project by proving them wrong. These sorts often leave 2-3x (that I know how to find, who knows what he real number is) on the table, which is often enough to satisfy the customer. It’s often hard work but there’s nothing magic about it.