4 ms·

That's awesome and it is a tech stack that I try to mirror and am confident running myself as well! It's incredible the amount of knowledge required for a sing

by aprdm 7y ago

That's awesome and it is a tech stack that I try to mirror and am confident running myself as well! It's incredible the amount of knowledge required for a single person tho when you think about it eh? It's the full frontend (which I would have more trouble with) + databases + caches + search engine + metrics + deployment + source control + sysadmin all baked in a single person who is also trying to make it a business! Kudos for the effort and making it happen, one day I might be joining the same journey with the same stack! Just gotta figure out what actually motivates me to build a business on top of =)

mtnGoat 7y ago
as someone who has only worked on small teams, i thought this was normal. My current position is leading a small team, but we have interactions with a number of teams inside of FANG companies and it's amazing the limited amount of knowledge and access each position/person has. Most of my engineers can run circles around our partners. I always thought every engineer should know how to deploy a server, install deps, understand caching, etc and setup an app... turns out, that is apparently not even remotely expected at most companies. I guess the bigger the company the more narrow the skillset required.
- aprdm 7y ago
  Yeah, I worked in start ups and that's where I got the fast pace and I think that allowed me to rise to high ranks very fast at bigger companies as I have a solid understanding of all the stack. In bigger companies traditionally they had a person / department more specialized per part of the stack, I think is a lot about the "devops" culture.
- earthboundkid 7y ago
  And the thing is, generalists do better work. They do less work overall because there are fewer of them, but compare a typical enterprise 50 person team to the output of a team of 5 generalists, hands down the generalists will make a better product every time because there's no buck passing or shoulder shrugging about problems.
  - jedberg 7y ago
    I think specialists make more robust systems, but generalists get more done. When I work at large companies, it makes me sad how long it takes to get anything done. But once the work is complete, it is really solid. It scales well, it handles edge cases gracefully, it deploys cleanly, all because a large team of specialists made each part of the puzzle work really well. The slow progress was dictated by the extra communication to coordinate the specialists, but at the end of the day it ends up being worth it. (All of this of course assumes you work in an org with lots of really good specialists).
    - mtnGoat 7y ago
      i agree on this point. having highly specialized SMEs certainly helps with scale, for sure. iteration is slower at bigger companies but some of those teams are inventing wheels as they go. which requires slower movement than general web/mobile dev.
  - encoderer 7y ago
    “Every time” until they are asked to build a product that requires a deep specialized skill set. I am a generalist full stack developer who has built a SaaS business very similar to the way OP has. No team of me’s could’ve produced, say, TensorFlow. Great teams and companies have generalists and specialists.
  - caspar 7y ago
    IMO, the reduced output of a team of specialists vs a team of generalists has less to do with generalists doing better work, and more to do with it being impractical to hire specialists at lower levels of scale - and higher levels of scale are less efficient. A 3 person engineering team doesn't want to hire a specialist DB admin who knows Postgres back to front but can't code. A company of 1000+ engineers might, because they might have problems that require that expertise. But any engineer working in a company of 1000+ engineers is also subject to friction resulting from resource allocation inefficiencies, communication overhead, regulatory compliance, etc: the reduced output from those factors has little to do with the specialist engineers doing worse work, and more to do with them working at the size of company that can afford to hire specialists. (You could make the case that buck passing is an example of resource allocation inefficiencies, as it is often accidentally or purposely enabled by company management, but nonetheless, that's not a generalist vs specialist tradeoff.)
- ignoramous 7y ago
  You're right. That's been my experience, as well. But... the crème de la crème from FANG are different beasts altogether. I must also point out that what FANG employees do get in abundance is the ability to learn from highly scalable systems that others build, cutting edge tech others work on, experiment on company's dime, pursue an eng/mgmt tract more in line with their personal interests, and job stability. It also affords them an opportunity to be part of a team that one day builds a groundbreaking tech and pushes the envelope forward not just for the company but the entire industry.
- endtime 7y ago
  Having been the CTO of a startup and then a SWE at a FAANG company for 8 years, I disagree. Being at a startup does indeed require a broad technical skillset, but being effective inside a large company requires a lot of skills (both technical and not) that early startup employees may not have or need. I've grown a lot from both environments.
  - o-__-o 7y ago
    Are you me? I am constantly being gutchecked that a startup mentality does not fly when you have several hundred million in the bank. That said, my enterprise and upper management butt kissing experience from the 00s don’t seem to matter either. I can stay heads down in code and I’m not in fear over being downsized. The hard part is teaching these young kids how to scope.
- z3t4 7y ago
  It might take Alice 10 hours to do the sysadmin, 5 for the database, and 15 for the devops. Bob however can do the devops in 2 hours, sysadmin in 3 hours and database in 4 hours. Bob is of course more productive, but if you let Alice do all the DBA, then Bob will be even more productive, and the total output of your team will increase.
  - mushufasa 7y ago
    Ricardo strikes again https://en.wikipedia.org/wiki/Comparative_advantage https://en.wikipedia.org/wiki/Comparative_advantage
grepfru_it 7y ago
I finally created an account because your comment resonated with me. I have created 95% of my platform by myself which itself was the manifestation of several business ideas. I started out buying servers and starting a dedicated, then vps, then shared hosting farm that requires all of the frontends you mention. I took a different approach, I went all out open-source and spent time creating glue and flashy bootstrap frontends to orchestrate everything reliably. I currently run the remains of my companies as a lab that is spread out to a few datacenters and provides a UX where anyone can request a VM, launch a container, or drop a php/java war/RoR/django/etc onto a custom app server of varying security restrictions. You can request a service/vm/container by API, by chat, or any other host of events through my half-baked event controller and change mgmt database. In a lot of cases, changes are a two-way street. You can modify e.g. a bind zone file and that will reflect upwards in a CMDB or vice-versa and watch the zone file update automagically. The original idea was to allow mixing sysadmin strengths and still maintain a reliable complex system. So now I have a platform that spans multiple datacenters, uses infra as code as you would expect (supporting another cloud provider is simply adding glue to their apis), has loadbalancing and SSO, and it's just literally sitting on the sidelines exhausting the remaining budget until I finally get tired and liquidate it all. The motivation of building a business on it is so tiny after years of failed attempts and seeing the shared cloud model completely destroy ROI on holding hardware. I can and have built e.g. fleet tracking services. I have gobs of storage, so I run an object store for giggles. But have no clue how to generate revenue from these ideas when the market is already saturated. My last ditch idea is to create a learning ground for the public. Training on how to build apps that scale, manage systems at scale, and give a real world environment to folks who may otherwise not work at an organization with more than 100 servers. shrug . until then I chop-chop away at my dayjob :)
- pm 7y ago
  There are people who create consumer products, and there are people who create the products that power those products. It's no different to when id Software sold licences of their engines to other game developers. Perhaps you can turn your infrastructure into a business of its own.
  - 7y ago

by aprdm 7y ago

mtnGoat 7y ago

as someone who has only worked on small teams, i thought this was normal. My current position is leading a small team, but we have interactions with a number of teams inside of FANG companies and it's amazing the limited amount of knowledge and access each position/person has. Most of my engineers can run circles around our partners. I always thought every engineer should know how to deploy a server, install deps, understand caching, etc and setup an app... turns out, that is apparently not even remotely expected at most companies. I guess the bigger the company the more narrow the skillset required.

aprdm 7y ago
Yeah, I worked in start ups and that's where I got the fast pace and I think that allowed me to rise to high ranks very fast at bigger companies as I have a solid understanding of all the stack. In bigger companies traditionally they had a person / department more specialized per part of the stack, I think is a lot about the "devops" culture.
earthboundkid 7y ago
And the thing is, generalists do better work. They do less work overall because there are fewer of them, but compare a typical enterprise 50 person team to the output of a team of 5 generalists, hands down the generalists will make a better product every time because there's no buck passing or shoulder shrugging about problems.
- jedberg 7y ago
  I think specialists make more robust systems, but generalists get more done. When I work at large companies, it makes me sad how long it takes to get anything done. But once the work is complete, it is really solid. It scales well, it handles edge cases gracefully, it deploys cleanly, all because a large team of specialists made each part of the puzzle work really well. The slow progress was dictated by the extra communication to coordinate the specialists, but at the end of the day it ends up being worth it. (All of this of course assumes you work in an org with lots of really good specialists).
  - mtnGoat 7y ago
    i agree on this point. having highly specialized SMEs certainly helps with scale, for sure. iteration is slower at bigger companies but some of those teams are inventing wheels as they go. which requires slower movement than general web/mobile dev.
- encoderer 7y ago
  “Every time” until they are asked to build a product that requires a deep specialized skill set. I am a generalist full stack developer who has built a SaaS business very similar to the way OP has. No team of me’s could’ve produced, say, TensorFlow. Great teams and companies have generalists and specialists.
- caspar 7y ago
  IMO, the reduced output of a team of specialists vs a team of generalists has less to do with generalists doing better work, and more to do with it being impractical to hire specialists at lower levels of scale - and higher levels of scale are less efficient. A 3 person engineering team doesn't want to hire a specialist DB admin who knows Postgres back to front but can't code. A company of 1000+ engineers might, because they might have problems that require that expertise. But any engineer working in a company of 1000+ engineers is also subject to friction resulting from resource allocation inefficiencies, communication overhead, regulatory compliance, etc: the reduced output from those factors has little to do with the specialist engineers doing worse work, and more to do with them working at the size of company that can afford to hire specialists. (You could make the case that buck passing is an example of resource allocation inefficiencies, as it is often accidentally or purposely enabled by company management, but nonetheless, that's not a generalist vs specialist tradeoff.)
ignoramous 7y ago
You're right. That's been my experience, as well. But... the crème de la crème from FANG are different beasts altogether. I must also point out that what FANG employees do get in abundance is the ability to learn from highly scalable systems that others build, cutting edge tech others work on, experiment on company's dime, pursue an eng/mgmt tract more in line with their personal interests, and job stability. It also affords them an opportunity to be part of a team that one day builds a groundbreaking tech and pushes the envelope forward not just for the company but the entire industry.
endtime 7y ago
Having been the CTO of a startup and then a SWE at a FAANG company for 8 years, I disagree. Being at a startup does indeed require a broad technical skillset, but being effective inside a large company requires a lot of skills (both technical and not) that early startup employees may not have or need. I've grown a lot from both environments.
- o-__-o 7y ago
  Are you me? I am constantly being gutchecked that a startup mentality does not fly when you have several hundred million in the bank. That said, my enterprise and upper management butt kissing experience from the 00s don’t seem to matter either. I can stay heads down in code and I’m not in fear over being downsized. The hard part is teaching these young kids how to scope.
z3t4 7y ago
It might take Alice 10 hours to do the sysadmin, 5 for the database, and 15 for the devops. Bob however can do the devops in 2 hours, sysadmin in 3 hours and database in 4 hours. Bob is of course more productive, but if you let Alice do all the DBA, then Bob will be even more productive, and the total output of your team will increase.
- mushufasa 7y ago
  Ricardo strikes again https://en.wikipedia.org/wiki/Comparative_advantage https://en.wikipedia.org/wiki/Comparative_advantage

grepfru_it 7y ago

I finally created an account because your comment resonated with me. I have created 95% of my platform by myself which itself was the manifestation of several business ideas. I started out buying servers and starting a dedicated, then vps, then shared hosting farm that requires all of the frontends you mention. I took a different approach, I went all out open-source and spent time creating glue and flashy bootstrap frontends to orchestrate everything reliably. I currently run the remains of my companies as a lab that is spread out to a few datacenters and provides a UX where anyone can request a VM, launch a container, or drop a php/java war/RoR/django/etc onto a custom app server of varying security restrictions. You can request a service/vm/container by API, by chat, or any other host of events through my half-baked event controller and change mgmt database. In a lot of cases, changes are a two-way street. You can modify e.g. a bind zone file and that will reflect upwards in a CMDB or vice-versa and watch the zone file update automagically. The original idea was to allow mixing sysadmin strengths and still maintain a reliable complex system. So now I have a platform that spans multiple datacenters, uses infra as code as you would expect (supporting another cloud provider is simply adding glue to their apis), has loadbalancing and SSO, and it's just literally sitting on the sidelines exhausting the remaining budget until I finally get tired and liquidate it all. The motivation of building a business on it is so tiny after years of failed attempts and seeing the shared cloud model completely destroy ROI on holding hardware. I can and have built e.g. fleet tracking services. I have gobs of storage, so I run an object store for giggles. But have no clue how to generate revenue from these ideas when the market is already saturated. My last ditch idea is to create a learning ground for the public. Training on how to build apps that scale, manage systems at scale, and give a real world environment to folks who may otherwise not work at an organization with more than 100 servers. shrug . until then I chop-chop away at my dayjob :)

pm 7y ago
There are people who create consumer products, and there are people who create the products that power those products. It's no different to when id Software sold licences of their engines to other game developers. Perhaps you can turn your infrastructure into a business of its own.
- 7y ago