4 ms·

I would say that you should be very careful with putting your Twitter-gained engineering knowledge to use in a startup. In most cases as a startup you should pu

by jconley 10y ago

I would say that you should be very careful with putting your Twitter-gained engineering knowledge to use in a startup. In most cases as a startup you should purposely not do many of the things Twitter does. For instance, micro services and an extremely complex distributed architecture will add a lot of overhead and points of failure when a monolith is probably the best route when you have a few engineers. In a startup implementation speed is usually the most important aspect of your development project. Hacking usually trumps engineering in terms of value-add to your infant company. You will most likely throw away a ton of code along the way in the early days as you discover your path to product/market fit. That and you will only have a handful of people actually using it. Most early scalability issues (into the 10-100k DAU range in my experience) can be solved easily by throwing hardware at the problem... The other thing to be conscious of is the silo you live in on a team at a large company like Twitter as an engineer. You don't have to think about much more than writing code. As others have mentioned, engineering is by far the easiest challenge at a startup as a founder unless you are doing some crazy high tech thing. All that being said, if your startup is successful and you get past the seed stage, then yes, you will have a good idea of how to build an engineering culture and use practices that are known to work at scale.

jacquesm 10y ago
> For instance, micro services and an extremely complex distributed architecture will add a lot of overhead and points of failure when a monolith is probably the best route when you have a few engineers. But micro services will be a lot easier to get right and test.
- jamesroseman 10y ago
  Have you ever tried building a web app in under six months and with three people? Step 1 is usually not "reading Apache Storm documentation". Your point is well-made, there are a lot of benefits of micro service architecture, but fast startup with few engineers is not one of them.
  - jacquesm 10y ago
    No, but I've built at least one project where I'm 100% sure that if we had not chosen the 'micro service' path we'd never have completed it at all. Mind you, this was in the early 90's and we called them administrators but the end result was much the same. Easy to understand components fit together with lightweight glue. That project was exactly that, fast startup with 3 programmers, one of who was doubling as the tech guy. It made a few hundred million and it is still running today in more or less unmodified form (it's a bit prettier now, but the essence remains). Monolithical development has a fairly low ceiling of complexity before you drown.
    - jconley 10y ago
      Separating things into components is great, at least in-process where you can enforce interfaces with compilers. Managing deployment, versioning, and compatibility of 10's of networked services (aka micro services) is not a good way to spend time in a young startup... Of course, one monolith is a bad idea. Probably need a handful of services -- especially separating long running background work from foreground work, glued together with a queue system.
jamesroseman 10y ago
You raise a lot of great points. It's interesting, I've learned a lot about what works at scale when you have thousands of engineers and by practicing some of those techniques on side projects I've learned what doesn't work when you have less than 10 engineers. > For instance, micro services and an extremely complex distributed architecture will add a lot of overhead and points of failure when a monolith is probably the best route when you have a few engineers. In a startup implementation speed is usually the most important aspect of your development project. Hacking usually trumps engineering in terms of value-add to your infant company. This is on point. The real question is -- will I learn the best technique for writing code in a monolith that lends itself to being converted to a microservice architecture.

by jconley 10y ago

jacquesm 10y ago

> For instance, micro services and an extremely complex distributed architecture will add a lot of overhead and points of failure when a monolith is probably the best route when you have a few engineers. But micro services will be a lot easier to get right and test.

jamesroseman 10y ago
Have you ever tried building a web app in under six months and with three people? Step 1 is usually not "reading Apache Storm documentation". Your point is well-made, there are a lot of benefits of micro service architecture, but fast startup with few engineers is not one of them.
- jacquesm 10y ago
  No, but I've built at least one project where I'm 100% sure that if we had not chosen the 'micro service' path we'd never have completed it at all. Mind you, this was in the early 90's and we called them administrators but the end result was much the same. Easy to understand components fit together with lightweight glue. That project was exactly that, fast startup with 3 programmers, one of who was doubling as the tech guy. It made a few hundred million and it is still running today in more or less unmodified form (it's a bit prettier now, but the essence remains). Monolithical development has a fairly low ceiling of complexity before you drown.
  - jconley 10y ago
    Separating things into components is great, at least in-process where you can enforce interfaces with compilers. Managing deployment, versioning, and compatibility of 10's of networked services (aka micro services) is not a good way to spend time in a young startup... Of course, one monolith is a bad idea. Probably need a handful of services -- especially separating long running background work from foreground work, glued together with a queue system.

jamesroseman 10y ago

You raise a lot of great points. It's interesting, I've learned a lot about what works at scale when you have thousands of engineers and by practicing some of those techniques on side projects I've learned what doesn't work when you have less than 10 engineers. > For instance, micro services and an extremely complex distributed architecture will add a lot of overhead and points of failure when a monolith is probably the best route when you have a few engineers. In a startup implementation speed is usually the most important aspect of your development project. Hacking usually trumps engineering in terms of value-add to your infant company. This is on point. The real question is -- will I learn the best technique for writing code in a monolith that lends itself to being converted to a microservice architecture.