I was a hands-on engineering manager brought to lead a similar effort at an ad agency to build out their adtech stack inhouse.
Worked out fine. I've also interviewed a number of people in similar situations. Seems to work out fine when people are interested in what they are doing.
One thing to consider is the cost of it, and the size of the team you would need. I would argue you'd need at least five people regardless of the size of your project to get any semblance of dev culture that would propel the team forward.
As for attracting talent, there's a tremendous amount of talented developers that don't make the cut to get into FAANG for different reasons. Get a technical manager to bootstrap the project, set up interviews, and you should be good.
Also, don't forget about dev tools and ops expenses, a need for oncall, and hiring devops to run it.
As an Engineering Manager, I find that solving this kind of problems really helps in my work, and it also helped to make our interview process more objective.
When working with high-load systems, it kinda doesn't help that a person knows what "DRY"/"SOLID"/refactoring etc is.
What helps is the ability to write code that handles corner cases and does it efficiently.
HTTP/2 Push allows to _really_ optimize first page load, giving a wow effect. (Especially when you can use a single server w/o geodns to serve the whole world with a really low latency!)
I use it on my pet project website, and it allows for a remarkable first page load time.
And I don't have to make all these old-school tricks, like inlining CSS & JS.
HTTP/2 Push allows for such a pleasant website development. You can have hundreds of images on the page, and normally, you'd be latency-bound to load it in a reasonable amount of time. And the way to solve it old-school is to merge them all into a one big image, and use CSS to use parts of the image instead of separate image URLs. This is an ugly solution for a latency problem. Push is so much better!
The fact that 99% of people are too lazy to learn a new trick shouldn't really hamstring people into using 30-year old tricks to get to a decent latency!
> The fact that 99% of people are too lazy to learn a new trick shouldn't really hamstring people into using 30-year old tricks to get to a decent latency!
What amazes me is that in this <1% there is not even Google, which implemented push in its own protocol. Any insights on that?
Looking at their highly optimized code on google.com, my guess is that they already use all the tricks that work on _every_ browser. And it might not make much sense for them to have two builds: one elegant, with multiple files per page for newer browsers, and ugly optimized blob for older ones.
Would inlining CSS and JS work on web sites (not apps)? I kinda feel inlined JS will bypass bytecode cache and the parsing costs have to be paid on each page load.
The whole point of this discussion is that push only optimizes the first load, and then it pessimizes all subsequent loads. That's why no one adopted it.
I think it's about a product discovery. If we always sort this way, new products don't have a chance.
And I don't think Amazon would sort like this, it would make more sense for them to use hn/reddit way to sort items that give a chance for the new items to get to the top.
He is sadly correct. I've made the same experience with Perl. Most of the popular and wide-spread Perl books are written in the 90s, and since then we've learned as a community that many of the things they teach are outright dangerous to newbies and should never be found in anything but the worst throwaway code, because they're both harder to read and sources of errors.
There is a number of great, recently written books, that teach Modern Perl. A Perl style that makes code easier to read and more correct.
Yet time and time again there are people who will recommend Learning Perl 4th, because they read it, and when told about the new ones and the bad properties of the books they recommend, they'll dig in and argue, often ending in: "They teach Perl in an entertaining manner, so they're fine to recommend."
You simply cannot "help" such people. To "help" would amount to destroying large parts of their world view in a "you have been doing things wrong for decades" manner. Many minds are neither able nor willing to take that and will reject it as strongly as possible.
Indeed. I think I fit into that category, first used UNIX(TM) in 1978, first programmed in C in 1980-1 ... and I've never thought K&R was a good book. It was Lions' Commentary on UNIX 6th Edition, with Source Code (https://en.wikipedia.org/wiki/Lions%27_Commentary_on_UNIX_6t...) that was the key, and since its first edition, I've used C: A Reference Manual by Harbison and Steele (as in Guy Steele), initially written for a CMU spinoff compiler company because K&R was an insufficient reference for implementing a compiler.
If I remember correctly the details of why Nginx might be better at handling massive amount of clients is that it has event-driven architecture.
If you consider a slow client that consumes 1mb of html in, say, half a minute, an Apache thread(2.0)/process serving him would be effectively locked during this time. And thread/process has a relatively big overhead, both memory and cpu wise. Nginx, on the other hand, would just switch to serving the next client/clients, whos socket is ready (using epoll/select).
Worked out fine. I've also interviewed a number of people in similar situations. Seems to work out fine when people are interested in what they are doing.
One thing to consider is the cost of it, and the size of the team you would need. I would argue you'd need at least five people regardless of the size of your project to get any semblance of dev culture that would propel the team forward.
As for attracting talent, there's a tremendous amount of talented developers that don't make the cut to get into FAANG for different reasons. Get a technical manager to bootstrap the project, set up interviews, and you should be good.
Also, don't forget about dev tools and ops expenses, a need for oncall, and hiring devops to run it.