4 ms·

OMG The PG comment from there is so condescending and self-aggrandizing it's offensive: > The difference is not so much where the software runs as what the goa

OMG The PG comment from there is so condescending and self-aggrandizing it's offensive: > The difference is not so much where the software runs as what the goal of the company is. I'm interested in startups: companies that at least try to grow huge. Whereas the "small ISVs" he writes about are just ordinary small businesses that happen to write software. Since in the latter there's little scope for brilliance, you're not willing to trade other things for it. There's PLENTY of ISVs which write complex and ambitious software which would make the brain of an average FAANGer melt. Just look at anything related to computer graphics, geophysics, CAD, data compression etc. Not to mention that a lot of the unicorns are just technically bland web pages that happen to grow huge for reasons unrelated to technical difficulty (see Facebook, Whatsapp etc.). So maybe these unicorns need business brilliance, but I don't think they need technical brilliance all that much.

adrianN 6y ago
You need some technical brilliance to make bland web pages that serve users at Facebook's scale. I don't know whether you need brilliant engineers right at the beginning when you haven't reached that scale yet.
- username90 6y ago
  Paul Graham made a store as a service product 1996, at the time it wasn't as easy to create a crud webapp. His views are probably biased by that.
  - killtimeatwork 6y ago
    Yeah I agree, web dev was not yet a solved problem in 1996 and maybe Paul just didn't update his biases since then.
username90 6y ago
> There's PLENTY of ISVs which write complex and ambitious software which would make the brain of an average FAANGer melt. Just look at anything related to computer graphics, geophysics, CAD, data compression etc. You don't think your attitude here is condescending and self-aggrandizing?
- username90 6y ago
  I guess people downvote since the bias against "web dev" is too strong. It isn't like computer graphics, geophysics, CAD or data compression are particularly hard spaces to work on for a software engineer. And if we talk about FAANG in particular, it isn't like they hire people who couldn't hack it in the other fields. I choose to work at Google over other more "pure" tech companies since Google had smarter coworkers and allowed me to work on more pure technical problems. But I bet that some of the people I worked with before would repeat what killtimeatwork said, thinking their company is somehow special just because they sell products instead of web services. Edit: About small more "pure" tech companies, what I learned is that they mostly sell shit. Success was more based on ability to bullshit customers than technical merit.
  - killtimeatwork 6y ago
    > It isn't like computer graphics, geophysics, CAD or data compression are particularly hard spaces to work on for a software engineer. As a software eng. in those spaces, you're required to grasp heavy math (quaternions, Lie Algebras, you name it), find suitable numerical algorithms and implement them them bug-free in a hard-to-work-with low-level language such as C++ (because performance matters). Writing correct code is tough for multiple reasons, for example these numerical algos are not perfect and the glitches you see may be an algorithmic problem and nothing wrong with your implementation. Compare this with the usual backend and web dev, where you're usually writing trivial endpoints which just move data from one system to another. Of course, there are some ambitious roles in the FAANGs (the algos behind distributed databases don't figure out themselves), but they come into the picture later, once the startup is already scaling up.
    - username90 6y ago
      > As a software eng. in those spaces, you're required to grasp heavy math (quaternions, Lie Algebras, you name it), find suitable numerical algorithms and implement them them bug-free in a hard-to-work-with low-level language such as C++ (because performance matters). None of that is particularly hard though. Quaternions and lie algebras sound esoteric but are simple to work with, C++ is standard basically anywhere that cares about performance including a large part of Google, and finding suitable algorithms and implementing them bug free is the absolute minimum of what is expected of people. Now, the work people do at Google isn't that hard either, but it isn't like your average engineer could easily do the job. At Google it is expected that a typical mid level engineer can design and build systems to handle millions of QPS, be fault tolerant to prevent errors from propagating and bringing all of Google at once, know how to write distributed scripts to do operations on user data like migrating it without bringing down the service, know how to debug errors in distributed systems, track it between servers and try to find its origin, create useful health metrics for servers so you can see what is going on since you have thousands of them at once and you can't look at them individually, etc. In practice the end result is that they just copy data between servers, but copying data at reasonable cost to the right places on live servers when you have many thousands of servers all over the world is hard. And that is just the typical boring backend job, a significant part of Google is only low level libraries, algorithmic performance, machine learning, databases, compiler optimizations for C++, video encodings, etc etc. I've worked on both at Google and I wouldn't say that one is harder than the other, however working on algorithms and libraries is more fun and less stressful than backend work so I prefer it. Also the team working at the more "fun" stuff wasn't that much better either, I don't think the people working at backend would have a terribly difficult time doing those jobs either. After all Google does interview and hire everyone as if they would work on interesting technical stuff, so everyone knows at least the basics of maths and algorithms. > Of course, there are some ambitious roles in the FAANGs (the algos behind distributed databases don't figure out themselves), but they come into the picture later, once the startup is already scaling up. You talked about the typical FAANG engineer though. They aren't geniuses but they are still pretty smart. You shouldn't underestimate them.
deleted 6y ago
[deleted]
ghroberts 6y ago
I find the quoted comment pretty mild. It is the small ISVs "he [Erik Sink] writes about". Around that time there was a market for tons of boring applications that solved a specific small problem. Of course there were interesting ISVs, too: For example, chess programs were driven and improved by small ISVs for a long time. By definition, those ISVs would attract hackers. But it wasn't the majority.

adrianN 6y ago

You need some technical brilliance to make bland web pages that serve users at Facebook's scale. I don't know whether you need brilliant engineers right at the beginning when you haven't reached that scale yet.

username90 6y ago
Paul Graham made a store as a service product 1996, at the time it wasn't as easy to create a crud webapp. His views are probably biased by that.
- killtimeatwork 6y ago
  Yeah I agree, web dev was not yet a solved problem in 1996 and maybe Paul just didn't update his biases since then.

username90 6y ago

> There's PLENTY of ISVs which write complex and ambitious software which would make the brain of an average FAANGer melt. Just look at anything related to computer graphics, geophysics, CAD, data compression etc. You don't think your attitude here is condescending and self-aggrandizing?

username90 6y ago
I guess people downvote since the bias against "web dev" is too strong. It isn't like computer graphics, geophysics, CAD or data compression are particularly hard spaces to work on for a software engineer. And if we talk about FAANG in particular, it isn't like they hire people who couldn't hack it in the other fields. I choose to work at Google over other more "pure" tech companies since Google had smarter coworkers and allowed me to work on more pure technical problems. But I bet that some of the people I worked with before would repeat what killtimeatwork said, thinking their company is somehow special just because they sell products instead of web services. Edit: About small more "pure" tech companies, what I learned is that they mostly sell shit. Success was more based on ability to bullshit customers than technical merit.
- killtimeatwork 6y ago
  > It isn't like computer graphics, geophysics, CAD or data compression are particularly hard spaces to work on for a software engineer. As a software eng. in those spaces, you're required to grasp heavy math (quaternions, Lie Algebras, you name it), find suitable numerical algorithms and implement them them bug-free in a hard-to-work-with low-level language such as C++ (because performance matters). Writing correct code is tough for multiple reasons, for example these numerical algos are not perfect and the glitches you see may be an algorithmic problem and nothing wrong with your implementation. Compare this with the usual backend and web dev, where you're usually writing trivial endpoints which just move data from one system to another. Of course, there are some ambitious roles in the FAANGs (the algos behind distributed databases don't figure out themselves), but they come into the picture later, once the startup is already scaling up.
  - username90 6y ago
    > As a software eng. in those spaces, you're required to grasp heavy math (quaternions, Lie Algebras, you name it), find suitable numerical algorithms and implement them them bug-free in a hard-to-work-with low-level language such as C++ (because performance matters). None of that is particularly hard though. Quaternions and lie algebras sound esoteric but are simple to work with, C++ is standard basically anywhere that cares about performance including a large part of Google, and finding suitable algorithms and implementing them bug free is the absolute minimum of what is expected of people. Now, the work people do at Google isn't that hard either, but it isn't like your average engineer could easily do the job. At Google it is expected that a typical mid level engineer can design and build systems to handle millions of QPS, be fault tolerant to prevent errors from propagating and bringing all of Google at once, know how to write distributed scripts to do operations on user data like migrating it without bringing down the service, know how to debug errors in distributed systems, track it between servers and try to find its origin, create useful health metrics for servers so you can see what is going on since you have thousands of them at once and you can't look at them individually, etc. In practice the end result is that they just copy data between servers, but copying data at reasonable cost to the right places on live servers when you have many thousands of servers all over the world is hard. And that is just the typical boring backend job, a significant part of Google is only low level libraries, algorithmic performance, machine learning, databases, compiler optimizations for C++, video encodings, etc etc. I've worked on both at Google and I wouldn't say that one is harder than the other, however working on algorithms and libraries is more fun and less stressful than backend work so I prefer it. Also the team working at the more "fun" stuff wasn't that much better either, I don't think the people working at backend would have a terribly difficult time doing those jobs either. After all Google does interview and hire everyone as if they would work on interesting technical stuff, so everyone knows at least the basics of maths and algorithms. > Of course, there are some ambitious roles in the FAANGs (the algos behind distributed databases don't figure out themselves), but they come into the picture later, once the startup is already scaling up. You talked about the typical FAANG engineer though. They aren't geniuses but they are still pretty smart. You shouldn't underestimate them.

deleted 6y ago

[deleted]

ghroberts 6y ago

I find the quoted comment pretty mild. It is the small ISVs "he [Erik Sink] writes about". Around that time there was a market for tons of boring applications that solved a specific small problem. Of course there were interesting ISVs, too: For example, chess programs were driven and improved by small ISVs for a long time. By definition, those ISVs would attract hackers. But it wasn't the majority.