4 ms·

I think you need senior _technology_ people from day one, if you want to build to scale, and you don't really want to pay to build everything twice _and_ pay fo

I think you need senior _technology_ people from day one, if you want to build to scale, and you don't really want to pay to build everything twice _and_ pay for extreme server costs _and_ pay to migrate from the old to the new system. Maybe this means something different than "Heavy Hitters". I've never run a huge company division; I prefer to work in a startup environment, and except for a short stint at Amazon, that's where I've stayed. But I have been able to step into small companies as an interim CTO and turn their technology from a mess that won't scale and that was written by junior developers into something that will scale cleanly from day one. And I typically do this by throwing away most of what was there to begin with and rebuilding from the ground up. Most junior devs just don't have good architecture and design in their blood like a strong senior developer. Which means there's 2-3x extra work to prevent the current system from dying or failing during the transition process ("Changing the tires while driving at 60MPH"). If instead you have someone like me drive the project from the start, when the project is _finally_ seeing traction you can focus on adding features your customers are demanding and pivoting if necessary. And you don't end up hemorrhaging money by paying for 50x as many servers as you would need if you'd start with a strong architecture. And the funny thing? Hiring a strong dev early on will likely get you to a working product much sooner than several junior devs, and you overall save money due to launching sooner. So it's a huge win. And a lot of the time, founders _are_ junior devs (I've been coding for 30 years; anyone with less than five years is junior, from where I sit, and a decade is bare minimum to be "senior"). But everyone wants to cut costs and hire the $10/hour developers, or the green developers fresh out of college. And now articles like this are being written that imply that you shouldn't even hire a "heavy hitter" until some vague criteria have occurred... Well, good luck with that. You might be able to pivot and improve your technology in time. Or you might end up going the way of Friendster, pissing off your user base because your site keeps failing, and by the time you have it working reliably, they've all left. [1] Or maybe the fact that they left allowed it to work reliably? Hard to say. [1] https://en.wikipedia.org/wiki/Friendster https://en.wikipedia.org/wiki/Friendster

gonedevin 9y ago
Spot on and I just escaped a company that hired a junior dev as their lead. It was horrendous. I don't want to call out the junior to management because he has kids but he's really screwing up their product and they don't even realize it because they know nothing about technology
SimbaOnSteroids 9y ago
As a sub-junior developer, how does one go about architecturing software to scale?
- jaggederest 9y ago
  Part is just experience. You have to have seen enough different kinds of people and systems work together to understand what works and what does not. I think another part is simply nomenclature. There's a joke about the only two hard problems in computer science: Cache expiry and naming things. It's a joke because cache expiry reduces to naming the keys correctly if you do it right. Basically, if the different parts of the system don't have sensible names that represent what they actually do (and that there are, indeed, different parts of the system), then there's an architecture problem. You have to have an effective metaphor for the way that you want the system to work, and the problems you want each part of it to solve, or nobody will be able to understand the entire thing. I run into this often. People have a functional but struggling system designed with the "big ball of mud" pattern, where you just keep slapping gobs of code onto it until it does what you need, and then they want someone to come in and "do architecture" at it. This predictably fails. So, there's your heuristic: if it has good names, and the pieces do what they say on the tin, you're on the right path. When something starts to have responsibilities that aren't under that name, you should move those responsibilities somewhere else and name them appropriately. Edit: There's also a second-order level where you start to recognize the way that cross-cutting concerns happen in different areas and design a piece of the system to handle that concern in an organized way. You can probably think of a bunch yourself, but an easy example you want to handle earlier rather than later is logging, and another significant one is authentication
  - SimbaOnSteroids 9y ago
    So a the goal is a bunch of people can have their claws in the code base and avoid this reaction [0], but not necessarily code optimization, just as long as everything is highly modular and works independently of other parts you're kosher. [0] https://www.youtube.com/watch?v=BGpDGJoe6P0 https://www.youtube.com/watch?v=BGpDGJoe6P0

gonedevin 9y ago

Spot on and I just escaped a company that hired a junior dev as their lead. It was horrendous. I don't want to call out the junior to management because he has kids but he's really screwing up their product and they don't even realize it because they know nothing about technology

SimbaOnSteroids 9y ago

As a sub-junior developer, how does one go about architecturing software to scale?

jaggederest 9y ago
Part is just experience. You have to have seen enough different kinds of people and systems work together to understand what works and what does not. I think another part is simply nomenclature. There's a joke about the only two hard problems in computer science: Cache expiry and naming things. It's a joke because cache expiry reduces to naming the keys correctly if you do it right. Basically, if the different parts of the system don't have sensible names that represent what they actually do (and that there are, indeed, different parts of the system), then there's an architecture problem. You have to have an effective metaphor for the way that you want the system to work, and the problems you want each part of it to solve, or nobody will be able to understand the entire thing. I run into this often. People have a functional but struggling system designed with the "big ball of mud" pattern, where you just keep slapping gobs of code onto it until it does what you need, and then they want someone to come in and "do architecture" at it. This predictably fails. So, there's your heuristic: if it has good names, and the pieces do what they say on the tin, you're on the right path. When something starts to have responsibilities that aren't under that name, you should move those responsibilities somewhere else and name them appropriately. Edit: There's also a second-order level where you start to recognize the way that cross-cutting concerns happen in different areas and design a piece of the system to handle that concern in an organized way. You can probably think of a bunch yourself, but an easy example you want to handle earlier rather than later is logging, and another significant one is authentication
- SimbaOnSteroids 9y ago
  So a the goal is a bunch of people can have their claws in the code base and avoid this reaction [0], but not necessarily code optimization, just as long as everything is highly modular and works independently of other parts you're kosher. [0] https://www.youtube.com/watch?v=BGpDGJoe6P0 https://www.youtube.com/watch?v=BGpDGJoe6P0