What I've Learned After 13 Years of Web Engineering(coderwall.com)
coderwall.com
What I've Learned After 13 Years of Web Engineering
https://coderwall.com/p/izxoyw
12 comments
Couldn't have said it better myself. Basically, this guy is a hack ...
> 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.
How many fresh CS grads have a strong command of database performance or concurrency?
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.
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.
> Avoid SQL joins in your website code
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)
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)
Avoid SQL joins in your website code
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?
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?
This response is more amusing in light of the author's first claim.
It depends on the join.
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)
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)
I read it this way ...
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 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.
@OP - points 2 and 5 are opposing each other - you can't be paid too much and demand to be treated as a King in the Bay.
Kings are known for their high incomes.
Kings are known for their high incomes.
"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.
True but being a waiter doesn't not required much skills or staying up all night to fix a product blocker issue.
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.
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.
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.
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.
> Engineers are paid way too much
but
> you should be fired for not treating your engineers like solid gold
The former is a good way to do the latter.
but
> you should be fired for not treating your engineers like solid gold
The former is a good way to do the latter.
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.
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.
Wait, you're a CTO?
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.
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.
> Engineers are paid way too much
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.
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.
>> 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.
The SQL joins thing is also full of it.
---
I agree with most of the other points though.
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.
> 2) Engineers are paid way too much
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.
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.
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.
I see you haven't had to
* 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* deal with re-orgs, layoffs, and acquisitions
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.
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.
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.
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.