Disagree. If you need to join data, you have do do it somewhere. You think you are going to do a better job of it than the database engine, which has probably been optimized for years if not decades to do this very thing?
The lesson is that if you find yourself doing joins, then you need to consider whether the database should be redisgned. A join is sometimes necessary, and the engine is the right place to do it if it must be done, but it's a warning. So if possible, design your DB to avoid joins.
The idea is to pay during write, at about any cost, to avoid paying during read. Of course that does not fit all usage cases, so the advise has to be taken with a huge grain of salt.
If you can denormalize your schema so there's no joining, that's great. If you can change the product so there's no joining, great. If the schema and database are designed to do the join you're going to do, that's probably fine.
If not, it's cheaper and easier to add capacity to the pool of shared nothing web machines than to add capacity to the pool of databases machines, so grab the data and run the join on the webserver. (or at least benchmark it; you may be surprised)
"For example, when I see the wait staff at a restaurant running around to serve dinner, I feel these people as working much harder than any internet engineer you’ll ever see"
True but being a waiter doesn't not required much skills or staying up all night to fix a product blocker issue.
Both have highly stressful moments, and both can require ingenuity to get things done well. Most of the time, the work you're doing as a web engineer isn't groundbreaking stuff - it's just perceived as more high-brow than serving tables.
I've done both, and I'm glad I'm not a server anymore. The people are way more interesting in the kitchen than they are in some of the cubicles around me however. Sometimes I think about picking up some bartending shifts on a weekend night here or there for some extra cash and some extra entertainment.
Most people can become an average waiter very quickly, whereas most people hardly care to know how their computer works. The additional pay is for the huge amounts of time we've spent learning the craft, some of us being obsessed with it since childhood, and the mild rarity of the skill. Also because writing some code has the possibility of affecting huge numbers of people and bringing in a decent sum of money for a company, whereas you can only wait on so many tables per day for an industry known for its low margins.
That's not to say that the proportions are balanced, or that all good waiters are getting what they deserve, or that there aren't shoddy engineers who are getting far more than they deserve. There's just a lot more money in computers than foodservice.
I hate when people say stuff like X should get paid more or Y should get paid less. You can't say that without explaining your moral system. You can't go from is to ought.
That's none sense. There is nothing wrong with SQL joins in your code so long as you've properly indexed and understand the query execution plan. Table joins are also not going to be a likely culprit of deadlocks either (varies depending on database platform, but generally true)
Fun read. You do have a point in that engineers are paid way too much, what we do is actually fun and we sit and code most of the time where as the wait staff have to deal with bad tippers and be on their feet all the time.
As opposed to dealing with malicious unidentifiable people who are actually trying to take information from you and all your users consistently? I wonder where y'all work where you're not on toes all the time.
* deal with product owners
* deal with customer service
* deal with marketing
* deal with legacy code
* deal with emergency production issues
* deal with whatever the latest buzzword is in project management
Also, for everyone saying we're paid too much, keep in mind that it might be just that on an individual level, you're underachieving. Being a good programmer is very hard, and being a good engineer in a large, bureaucratic org is even harder.
However, do make sure to tip your servers well, they deserve every dollar you'd ever give.
Engineering skills take years to acquire. Sure it's not rocket science or a brain surgeon which takes another level of dedication to profession. The job of a waiter or a 711 guy or a janitor and similar does not take much skill and hence the term 'unskilled'. The salaries merely reflect this fact.
> My lack of a proper CS degree only haunts me during bullshit interviews as many interviewers who do have a CS degree tend to focus on CS academic topics rather than things a web developer would actually do during his tenure at the company
You don't know what you don't know. I could hurt you in other ways you just don't know it. For example it shows when you write blogs that claim SQL joins why there are deadlocks in your web application code. You don't have to go do a 4 year college but not knowing the basics of O(n) notation, how relational databases work inside, how concurrency works, different programming paradigms, is going to hurt you.
> 2) Engineers are paid way too much
Bullshit. If you feel like you are fraud and you are paid too much, well you might just well be. Doesn't mean everyone is.
Software engineering is qualitatively different from being a waiter. The equivalent would be compare a software engineer with a robot maker that builds waiter robots.
It is not about fairness. Tell someone born in a war torn country about fairness. He'd love to swap places with any waiter in US probably.
> One of the bigger websites I worked on relied heavily on SQL joins at runtime.
Now I am laughing. That is a pretty broad assertion. It is like saying "don't use C" or only use 3 space indents. Basically ignore this and use joins, use indices, and benchmark and even better -- (gasp) hire people who have got a CS degree and know about O notation, about concurrency, relational databases.
> Bullshit. If you feel like you are fraud and you are paid too much, well you might just well be. Doesn't mean everyone is.
Agreed. It's the market that decides the price, not the employers. Capitalism isn't always fair.
Sure as hell more than history, biology, sociology grads and high school students.
We did have to study concurrency and a database course. They were general and were not tied to any particular database, and good thing, because that a while ago. But it was a good theoretical understanding.
Wow, what a nonsense. Honestly, comparing a waiter to a software engineer ? Really ?
You see these types of claims are usually made by someone who doesn't know what he's talking about. I've been a "software engineer" for over 7 years now and the amount of stuff you have to know is overwhelming. Honestly in my current project I'm working with at least 4 different languages, a lot of software engineering concepts, platforms, a tons of tools and I can promise you that in my professional career there wasn't a time where I stopped studying just trying to keep up.
Having said that, I've seen a lot of "engineers" like the OP, that think it's all too easy until they make a huge mess and call the "real engineers" to fix it up.
Please don't complain about CS degrees being useless and then state some technical rule-of-thumb which a proper theoretical background would help you to understand is poor advice.
Ever been SCUBA diving? It's completely impossible to see your own tank. Your peripheral vision sucks in a dive mask, and you can't turn your head that far. Funny thing is the valve with your primary regulator connected makes an excellent hook for things. Most divers carry knives or scissors just in case they get some fishing line, rope, or kelp wrapped around their tank. Divers also focus a lot on streamlining to maintain an efficient swimming profile. Efficiency underwater means that you breathe less, which means you can stay down longer, see more, and/or get more done. Very occasionally a diver will get something caught on their tank, but it won't trap them. It just slows them down. They wind up breathing through their air much quicker than the rest of the other divers because they're completely unaware that something is giving them an uneven challenge.
Or let's talk about it in a more direct sense...
Let's say you have two candidates. One has 8 years of experience. The other has a BS in Computer Science and 8 years of experience. Otherwise they've rated identically in your interview process. Which one are you going to hire? Are you honestly saying that the guy or gal with 4 years of rigorous formal training in addition to the 8 years of on-the-job experience is only just equally qualified?
Regarding salaries, effort is in absolutely no way related to value. It's a sad fact, but it's a fact nonetheless. Saying it "should" or "shouldn't" be this way is a bit like passing moral judgement on the laws of physics. "This is wrong. If I flap my arms really hard, I should be able to fly."
Further, the idea that value and effort aren't strictly coupled is a key component of scaling a business. As someone with a C-level title, you should understand that intuitively.
As others have commented, this is totally market, which is detached from the actual working conditions. Can 100K really be considered overpaid in the bay area? Or is everyone making much less than 100K just crazy to live there (I don't live there, so I don't know how much you really need to make to survive there.)
I think sometimes it's hard for us to see how much we really learn over time. It seems so easy, yet have someone who has never written a line of code try to get to the point where you are at.
Second point removes all value if this article. Do you think your work brings same value to business as work of officiant? Well, then yes, you are paid too much, but not all engineers.
>> Engineers are paid way too much?
Wtf is this guy a CEO or something?
This is bullshit. If other people waiting tables are working harder then why can't every body be an engineer? Why is there are a small population of engineer? Or a small population of doctor? It's because it's fucking hard to acquire the skill and you should be rewarded for it. Supply and demand. If it's overpay then the author can go ahead and take the 20k salary that is equivalent to waiting tables. Just don't expect me to do take it, that's just a fucking slap in the face.
27 comments
[ 3.1 ms ] story [ 70.1 ms ] threadDisagree. If you need to join data, you have do do it somewhere. You think you are going to do a better job of it than the database engine, which has probably been optimized for years if not decades to do this very thing?
The lesson is that if you find yourself doing joins, then you need to consider whether the database should be redisgned. A join is sometimes necessary, and the engine is the right place to do it if it must be done, but it's a warning. So if possible, design your DB to avoid joins.
If you can denormalize your schema so there's no joining, that's great. If you can change the product so there's no joining, great. If the schema and database are designed to do the join you're going to do, that's probably fine.
If not, it's cheaper and easier to add capacity to the pool of shared nothing web machines than to add capacity to the pool of databases machines, so grab the data and run the join on the webserver. (or at least benchmark it; you may be surprised)
True but being a waiter doesn't not required much skills or staying up all night to fix a product blocker issue.
I've done both, and I'm glad I'm not a server anymore. The people are way more interesting in the kitchen than they are in some of the cubicles around me however. Sometimes I think about picking up some bartending shifts on a weekend night here or there for some extra cash and some extra entertainment.
but
> you should be fired for not treating your engineers like solid gold
The former is a good way to do the latter.
That's not to say that the proportions are balanced, or that all good waiters are getting what they deserve, or that there aren't shoddy engineers who are getting far more than they deserve. There's just a lot more money in computers than foodservice.
That's none sense. There is nothing wrong with SQL joins in your code so long as you've properly indexed and understand the query execution plan. Table joins are also not going to be a likely culprit of deadlocks either (varies depending on database platform, but generally true)
Also, for everyone saying we're paid too much, keep in mind that it might be just that on an individual level, you're underachieving. Being a good programmer is very hard, and being a good engineer in a large, bureaucratic org is even harder.
However, do make sure to tip your servers well, they deserve every dollar you'd ever give.
Engineering skills take years to acquire. Sure it's not rocket science or a brain surgeon which takes another level of dedication to profession. The job of a waiter or a 711 guy or a janitor and similar does not take much skill and hence the term 'unskilled'. The salaries merely reflect this fact.
You don't know what you don't know. I could hurt you in other ways you just don't know it. For example it shows when you write blogs that claim SQL joins why there are deadlocks in your web application code. You don't have to go do a 4 year college but not knowing the basics of O(n) notation, how relational databases work inside, how concurrency works, different programming paradigms, is going to hurt you.
> 2) Engineers are paid way too much
Bullshit. If you feel like you are fraud and you are paid too much, well you might just well be. Doesn't mean everyone is.
Software engineering is qualitatively different from being a waiter. The equivalent would be compare a software engineer with a robot maker that builds waiter robots.
It is not about fairness. Tell someone born in a war torn country about fairness. He'd love to swap places with any waiter in US probably.
> One of the bigger websites I worked on relied heavily on SQL joins at runtime.
Now I am laughing. That is a pretty broad assertion. It is like saying "don't use C" or only use 3 space indents. Basically ignore this and use joins, use indices, and benchmark and even better -- (gasp) hire people who have got a CS degree and know about O notation, about concurrency, relational databases.
We did have to study concurrency and a database course. They were general and were not tied to any particular database, and good thing, because that a while ago. But it was a good theoretical understanding.
You see these types of claims are usually made by someone who doesn't know what he's talking about. I've been a "software engineer" for over 7 years now and the amount of stuff you have to know is overwhelming. Honestly in my current project I'm working with at least 4 different languages, a lot of software engineering concepts, platforms, a tons of tools and I can promise you that in my professional career there wasn't a time where I stopped studying just trying to keep up.
Having said that, I've seen a lot of "engineers" like the OP, that think it's all too easy until they make a huge mess and call the "real engineers" to fix it up.
Kings are known for their high incomes.
Please don't complain about CS degrees being useless and then state some technical rule-of-thumb which a proper theoretical background would help you to understand is poor advice.
Ever been SCUBA diving? It's completely impossible to see your own tank. Your peripheral vision sucks in a dive mask, and you can't turn your head that far. Funny thing is the valve with your primary regulator connected makes an excellent hook for things. Most divers carry knives or scissors just in case they get some fishing line, rope, or kelp wrapped around their tank. Divers also focus a lot on streamlining to maintain an efficient swimming profile. Efficiency underwater means that you breathe less, which means you can stay down longer, see more, and/or get more done. Very occasionally a diver will get something caught on their tank, but it won't trap them. It just slows them down. They wind up breathing through their air much quicker than the rest of the other divers because they're completely unaware that something is giving them an uneven challenge.
Or let's talk about it in a more direct sense...
Let's say you have two candidates. One has 8 years of experience. The other has a BS in Computer Science and 8 years of experience. Otherwise they've rated identically in your interview process. Which one are you going to hire? Are you honestly saying that the guy or gal with 4 years of rigorous formal training in addition to the 8 years of on-the-job experience is only just equally qualified?
Regarding salaries, effort is in absolutely no way related to value. It's a sad fact, but it's a fact nonetheless. Saying it "should" or "shouldn't" be this way is a bit like passing moral judgement on the laws of physics. "This is wrong. If I flap my arms really hard, I should be able to fly."
Further, the idea that value and effort aren't strictly coupled is a key component of scaling a business. As someone with a C-level title, you should understand that intuitively.
As others have commented, this is totally market, which is detached from the actual working conditions. Can 100K really be considered overpaid in the bay area? Or is everyone making much less than 100K just crazy to live there (I don't live there, so I don't know how much you really need to make to survive there.)
I think sometimes it's hard for us to see how much we really learn over time. It seems so easy, yet have someone who has never written a line of code try to get to the point where you are at.
This is bullshit. If other people waiting tables are working harder then why can't every body be an engineer? Why is there are a small population of engineer? Or a small population of doctor? It's because it's fucking hard to acquire the skill and you should be rewarded for it. Supply and demand. If it's overpay then the author can go ahead and take the 20k salary that is equivalent to waiting tables. Just don't expect me to do take it, that's just a fucking slap in the face.
The SQL joins thing is also full of it.
---
I agree with most of the other points though.