4 ms·

I enjoy the details, but I don’t get paid to tell my executives how we’re running things. I get paid to ship customer facing value. Particularly at startups, i

I enjoy the details, but I don’t get paid to tell my executives how we’re running things. I get paid to ship customer facing value. Particularly at startups, it’s almost always more cost effective to hit that “scale up” button from our hosting provider than do any sort of actual system engineering. Eventually, someone goes “hey we could save $$$$ by doing XYZ” so we send someone on a systems engineering journey for a week or two and cut our bill in half. None of it really matters, though. We’re racing against competition and runway. A few days less runway isn’t going to break a startup. Not shipping as fast as reasonable will.

layoric 2y ago
I’ve been in similar situations, but details matter. If your scale up button is heavily abstracted services, your choice starts to become very different as the cost of reimplementing what the service does might be high enough that you end up with a no win situation of your own making. The closer your “Scale up” button is referencing actual hardware, the less of a problem it is.
- aeyes 2y ago
  That's the next problem startups should avoid at all cost. Don't do heavily abstracted services, just put it all in a monolith which will make it faster and easier to iterate. Don't overthink it, just get the feature out of the door. Chances are high that you won't get it right from the beginning, you can create these abstractions once you really understand the problem space with real world data. When you get to that point I have another pro tip: Don't refactor, just rewrite it and put all your learnings into the v2.
  - theoreticalmal 2y ago
    This is exactly, precisely what my experience has been.
  - alanmoraes 2y ago
    Why don't refactor just the parts the need it instead of rewriting everything?
    - aeyes 2y ago
      You can do small refactors here and there but usually things get complex after some time. My first advice was to not overthink on architecture in the beginning so it is inevitable that you will end up with something quite unorganized after a while. The assumption here is that in the beginning you won't know what the architecture will look like in the future because you are in startup/discovery mode. Refactoring such a codebase while keeping everything running can be a monumental effort. I found it very hard to keep people who work on such a project motivated. Analyzing the use cases, coming up with a new design incorporating your learnings and then seeing clear progress towards the goal of a cleaner codebase is much more motivating. Engineers get the chance to do something new instead of "moving code around". I'm not saying rewrite everything. When you get to this point it usually makes sense to start thinking about these abstractions which I advised to avoid in the beginning. You can begin to separate parts of the system by responsibility and then you rewrite just one part and give it a new API which other parts of your system will consume. Usually by that time you'll also want to restructure your database.
sgarland 2y ago
Wild idea: maybe if more devs had good fundamental knowledge to begin with, the good systems engineering could be done along the way.
- SkyPuncher 2y ago
  It all takes time, mental energy, etc. Different environments require different tradeoffs. The vast majority of startups will die before their systems engineering becomes a problem.
  - sgarland 2y ago
    Constant firefighting because you engineered a pile of shit also takes time and mental energy.
    - dzhiurgis 2y ago
      You are describing worst of both worlds - systems engineering, done poorly. I find good abstractions to be almost maintenance-free.
    - closewith 2y ago
      Only if you let it. None of that is your problem - just consume the task queue. Unless of course you're in a leadership role, in which case it's going to be priority #1,000 in 99.9% of cases.
- ketzo 2y ago
  And if more systems engineers had more design knowledge, navigating the AWS console wouldn’t be like walking on hot coals. But it’s still $X0 billion/year business! We’re all different at good things, and it’s usually better to lean into your strengths than it is to paper over your weaknesses. We can wish everyone were good at everything, or we can try to actually get things done.
  - godelski 2y ago
    > We can wish everyone were good at everything, or we can try to actually get things done. False dichotomy. There's no reason we can't have both. I want to be clear, there's no perfect code or a perfect understanding or any of that. But the complaint here about not knowing /enough/ fundamentals is valid. There is some threshold which we should recognize as a minimum. The disagreement is about where this threshold is, and no one is calling for perfection. But certainly there are plenty who want the threshold to not exist. Be that AI will replace coders or coding bootcamps get you big tech jobs. Zero to hero in a few months is bull.

layoric 2y ago

I’ve been in similar situations, but details matter. If your scale up button is heavily abstracted services, your choice starts to become very different as the cost of reimplementing what the service does might be high enough that you end up with a no win situation of your own making. The closer your “Scale up” button is referencing actual hardware, the less of a problem it is.

aeyes 2y ago
That's the next problem startups should avoid at all cost. Don't do heavily abstracted services, just put it all in a monolith which will make it faster and easier to iterate. Don't overthink it, just get the feature out of the door. Chances are high that you won't get it right from the beginning, you can create these abstractions once you really understand the problem space with real world data. When you get to that point I have another pro tip: Don't refactor, just rewrite it and put all your learnings into the v2.
- theoreticalmal 2y ago
  This is exactly, precisely what my experience has been.
- alanmoraes 2y ago
  Why don't refactor just the parts the need it instead of rewriting everything?
  - aeyes 2y ago
    You can do small refactors here and there but usually things get complex after some time. My first advice was to not overthink on architecture in the beginning so it is inevitable that you will end up with something quite unorganized after a while. The assumption here is that in the beginning you won't know what the architecture will look like in the future because you are in startup/discovery mode. Refactoring such a codebase while keeping everything running can be a monumental effort. I found it very hard to keep people who work on such a project motivated. Analyzing the use cases, coming up with a new design incorporating your learnings and then seeing clear progress towards the goal of a cleaner codebase is much more motivating. Engineers get the chance to do something new instead of "moving code around". I'm not saying rewrite everything. When you get to this point it usually makes sense to start thinking about these abstractions which I advised to avoid in the beginning. You can begin to separate parts of the system by responsibility and then you rewrite just one part and give it a new API which other parts of your system will consume. Usually by that time you'll also want to restructure your database.

sgarland 2y ago

Wild idea: maybe if more devs had good fundamental knowledge to begin with, the good systems engineering could be done along the way.

SkyPuncher 2y ago
It all takes time, mental energy, etc. Different environments require different tradeoffs. The vast majority of startups will die before their systems engineering becomes a problem.
- sgarland 2y ago
  Constant firefighting because you engineered a pile of shit also takes time and mental energy.
  - dzhiurgis 2y ago
    You are describing worst of both worlds - systems engineering, done poorly. I find good abstractions to be almost maintenance-free.
  - closewith 2y ago
    Only if you let it. None of that is your problem - just consume the task queue. Unless of course you're in a leadership role, in which case it's going to be priority #1,000 in 99.9% of cases.
ketzo 2y ago
And if more systems engineers had more design knowledge, navigating the AWS console wouldn’t be like walking on hot coals. But it’s still $X0 billion/year business! We’re all different at good things, and it’s usually better to lean into your strengths than it is to paper over your weaknesses. We can wish everyone were good at everything, or we can try to actually get things done.
- godelski 2y ago
  > We can wish everyone were good at everything, or we can try to actually get things done. False dichotomy. There's no reason we can't have both. I want to be clear, there's no perfect code or a perfect understanding or any of that. But the complaint here about not knowing /enough/ fundamentals is valid. There is some threshold which we should recognize as a minimum. The disagreement is about where this threshold is, and no one is calling for perfection. But certainly there are plenty who want the threshold to not exist. Be that AI will replace coders or coding bootcamps get you big tech jobs. Zero to hero in a few months is bull.