8 ms·

Apologies in advance for being a bit negative. I feel like this sentence is just so revealing: > That said, he and I will likely never see eye-to-eye on this b

Apologies in advance for being a bit negative. I feel like this sentence is just so revealing: > That said, he and I will likely never see eye-to-eye on this because he more-or-less invented Choose Boring Technology, and most of what I advocate is to break playbook, embrace narrative, and be interesting. It really comes down to what you prioritize. Do you prioritize the output and the value added? Or do you prioritize making your engineers feel like "rockstars"? If you don't care about your end product, then yeah sure let your engineers break prod using untested technologies. The reason playbooks have sprung up, is because 99% of use-cases for businesses are for the most part "solved." We're not in the era of renting colos and manually setting up MySQL anymore (which the author advocates for in order to return to "creatives," btw). We have managed solutions that you can throw money at. So, do you leverage those solutions to help you solve your problem? Or do you let your engineers re-invent the wheel so they can feel smart? The "rockstar" treatment is a result of supply and demand. Talent in Hollywood/music can get the rockstar treatment, because the talent alone is the difference between millions of dollars. If you have a really talented coder who can be interchanged with another really talented coder, you do not have a "rockstar." The "rockstar" era of coding was the result of a massive imbalance in supply/demand for engineers, so the rockstar treatment would help attract talent. Now that the supply has began shifting up to meet the demand, it makes sense that the "rockstar" treatment is starting to go away. And good riddance to all that too. I don't need to work with any more software engineers who think it's okay to be a massive dick to everyone just because they can implement a CRUD app. If you want to be a rockstar, go actually be a rockstar, don't make software engineering worse.

majormajor 3y ago
I've seen teams today have just as large an FTE team dedicated to infrastructure as my employee 10 years ago to manage a set of cloud services that cost wayyyy more than the colo hardware we had doing basically the same amount of traffic. So people cost hasn't always gone down as infra cost has gone up. "Shitty internal heroku" has some advantages once you have engineers that have been at the company more than 3 months: there's just not nearly as much surface area to understand + you have the source code right there if you really have to get int here. Let's leave judgements out of this - you can just as easily build a fragile tower of cloud services and abstractions to "feel smart" as you can reinventing serving an application (reinventing is a strong word anyway... it's just a different set of off the shelf tools usually). And in many cases "managed" services manage the easy part (standing up the hardware and installing the service) and don't manage the hard part (configuring the hundreds of knobs to optimize your particular use case) particularly well. I'm not close enough to the metal for those services/infra teams, though, to be able to completely tell if the FTE hours spent on all that cloud stuff are necessary. That is - can you throw stuff into the cloud and set-it-and-forget-it and not deal with ongoing cloud/infra/config maintenance? But one of the main things those teams seemed to often focus on was spend - if you leave it unattended is the cost just going to eat you up? But then there's a big irony.
- milesvp 3y ago
  My experience with cloud migrations was that you could migrate and forget about it. This was for a high traffic metro newspaper, that was easy to cache for external users but needed to handle a large newsroom using wordpress to manage the content (wordpress can be a huge resource hog). The main costs in terms of labor end up being making sure that backends services are updated. Same pain you’d feel in a colo, except you cloud provider may force an upgrade you’d otherwise wish to put off. Now I intentionally kept most things at the VM level of abstraction, because it was clear that the added complexity of something like Kuberetes wasn’t worth any savings you might get by needing one less server, and I had enough granularity of healthchecks to just automatically spin down any server that was causing problem and let autoscaling work it’s magic. This was also 10 years ago, some choices might make less sense today, YMMV. Also, don’t think I’m saying all those people aren’t necessary based on the current needs of the business. I just knew I was in a very constrained environment and prioritized anything that allowed for the constant shrinking headcount my department was facing.
- YetAnotherNick 3y ago
  Just curious, what is the ratio of employee cost vs server cost for the team under you?
  - majormajor 3y ago
    Wasn't running them all, but a couple recent companies had ratios of about 1:4 and 1:2 (employee cost : cloud cost) with cloud spend in the low-to-high hundred Ks annually. Curiously, the company with the higher cloud bill also had the lower ratio (spending more on both, but proportionally more on engineering); my diagnosis after the fact is that they were building for a "do 10x the scale" future that was never realized but which would've pushed the cloud spend higher without needing more dev spend. In the future, I wouldn't spend so much that far in advance of actually needing to scale.
thr_ddv 3y ago
The reason why we don't have rockstar engineers is because the markets been filled with talentless hacks who can't code their way out of a paper bag without a jira epic breaking it down for them. I had the pleasure of pair programming with ye olde rockstar for two weeks and we added more value in those two weeks to the company than the rest of the team did in a year. I'm the cto I should know.
- lukebitts 3y ago
  It's always so funny seeing these kinds of comments from throwaway accounts
  - eterm 3y ago
    Not so funny: someone wrote a tool which attributes throwaways with alarming accuracy.
    - swores 3y ago
      I found the tool submission you're talking about, I remember putting my username into it when it was first shown and it did produce a list of accounts with % probabilities (in my case all unrelated to me), but when I tried doing it again now it says "This user does not have any public activity in the previous three years." for "swores" (and I've multiple comments just this week). Luckily for the throwaway person above, it says the same for them. But does still show results for some, maybe only big accounts now? https://news.ycombinator.com/item?id=27568709 https://news.ycombinator.com/item?id=27568709 edit: ahh, I think it just took a one-time snapshot of the three years leading up to its 2021 creation, as my old username that I changed to swores does show up. So it's an interesting proof of concept that someone could do similar analysis, but not an ongoing tool. So it won't be telling us which CTO to avoid :P
      - eterm 3y ago
        That's not the tool I remember, the tool I remember was similar but it correctly found all my alts, whereas that one does not. Edit: I think it was this one that has been shut down: https://stylometry.net/ https://stylometry.net/
turtledragonfly 3y ago
I feel like the author themselves is a bit scattered on this point. In the very quote you lead with, they link to another post[1], which says "...MySQL is boring. Postgres is boring." Our author says they don't like that Boring approach, but then they advocate for a "pets, not cattle" approach, which I think is in line with administering a MySQL server, or such. Maybe this all comes down to different people's definitions of Boring. Maybe modern developers think of "Cloud everything" as the boring/playbook approach, while other people (like me) see the older (in my mind simpler) idea of administering a few machines, maybe even on bare metal, to be Boring. You wrote: > So, do you leverage those solutions to help you solve your problem? Or do you let your engineers re-invent the wheel so they can feel smart? In my charitable interpretation of TFA, I think they are saying to let your engineers use smaller-scale solutions/technologies that address the problem at hand, as needed, rather than getting pulled into the Cloud-everything solve-all-your-future-problems-you-don't-even-have-yet ball of wax that's often advocated these days. I can get behind that sentiment, but yeah I'm not a big fan of the way it's framed in the article, and I have never liked the "rockstar" term. [1] https://mcfunley.com/choose-boring-technology https://mcfunley.com/choose-boring-technology
srpablo 3y ago
Hi! Author here :) > It really comes down to what you prioritize. Do you prioritize the output and the value added? Or do you prioritize making your engineers feel like "rockstars"? If you don't care about your end product, then yeah sure let your engineers break prod using untested technologies. First, the post is about sentiment. It's a response to a piece called "Software and its Discontents," about how people feel. So it's going to focus on that. But I also think the narrative of people working on a project does impact its success. I don't think you pick EITHER "make developers feel like they're doing great, innovative work" OR "do you care about the end product for customers"; the key is to find a way to achieve both, because they feed off each other and are related. It's as if I asked "do you want company growth, or customer happiness?" Try both! > The reason playbooks have sprung up, is because 99% of use-cases for businesses are for the most part "solved." We're not in the era of renting colos and manually setting up MySQL anymore (which the author advocates for in order to return to "creatives," btw). We have managed solutions that you can throw money at. I disagree they're solved! Again, this is in response to a 3-part series basically saying "everything is expensive and everyone is miserable and fewer businesses are succeeding." From a profitability perspective, when was the last Google or Facebook made? > And good riddance to all that too. I don't need to work with any more software engineers who think it's okay to be a massive dick to everyone just because they can implement a CRUD app. To be 1000% clear: I also hate(d) the machismo/showboating we got from the rockstar/ninjas era. I'm a former theatre artist and I'm mostly about embracing people and creativity.
- rvbissell 3y ago
  This article was my first introduction to your blog. I'd like to tell you that I love your writing style.
- billllll 3y ago
  > It's as if I asked "do you want company growth, or customer happiness?" Try both! Obviously, both are "good," but again, what's the end goal? To truly be the problem solver, you must make the hard decisions and tradeoffs. Companies trade-off growth versus customer happiness all the time. Right now, a lot of the largest companies are the ones that prioritize growth. To loop back to the point, obviously employee morale and a good end product is "good" and can have synergy, but again, what's the end goal? At some point, you must prioritize. A lot of companies have been very successful prioritizing the end product versus making their engineers feel good, which is why I think this topic recurs. > I disagree they're solved! Again, this is in response to a 3-part series basically saying "everything is expensive and everyone is miserable and fewer businesses are succeeding." I some ways, I think the 3-part series and your article are basically saying the opposite. The 3-part series acknowledges the market conditions and overabundance in the past, and says that in order to get the same results, we need to be smarter moving forward. Whereas your post is (in general) saying that it use to be really good in the past when we were treated like rockstars, we should return to that. And returning to the point, technical problems being "solved" is not mutually exclusive with a general market downturn. That is to say, you can't point at the general market downturn to say that deploying a CRUD app is not a solved problem. And this gets to my main point (which I think the author of the 3-part series would agree with): returning to the "rockstar" era will absolutely not bring software companies back to the crazy valuations and money. The "rockstar" era was the result and not the cause of the crazy valuations of the past.
bob1029 3y ago
I believe the new "rockstar" developer is one who can completely subvert their own ego in order to better serve the business/customer/team. The age of toiling away with weird tech in a dark corner and then expecting the team to be amazed at your contraptions is 2000% over. I've definitely been through this lesson a few times myself. It works and works until it doesn't and then one day you find that you are left holding a really big bag. My new ego trip is watching junior team members quickly ramp and become productive. Maybe you don't have to turn that ego off at all. Perhaps you just need to find a way to redirect it and get it hooked onto a new, more productive target. If you want to go try crazy new stuff - do it on your own time. I really don't understand why this is controversial. It's the best of both worlds. I've heard some excuses for why this is infeasible but they're super-duper bullshit to my ears. If it works on your home lab and it is obviously a cool/valuable thing, then maybe put together a 5 minute pitch deck and present it to your manager/cto/etc.
- poslathian 3y ago
  Beautiful. Agree. The juniors come in with a lot of technical education that would have been near impossible to learn on the job. Effective teamwork in this setting is just as foundational as skills they acquired in school but they only begin learning it after they graduate. Very rewarding to contribute to the growth in jr devs teamwork when it happens.
- Solvency 3y ago
  Maybe for CRUD business apps this is true, but there are constant innovations and research papers coming from rockstars in dark corners of the world. All of the time.
feoren 3y ago
I think you're suffering from a lack of imagination. > 99% of use-cases for businesses are for the most part "solved." History is over, technology is done advancing, every business idea has already been had and executed well, everything that can be done has already been done. Sure. And you would have said the exact same thing last year, and 10 years ago, and 50 years ago, and 400 years ago, and you would have been monumentally wrong each time. But June 29, 2023 is different. This is the first day of the end of history. By the way, the quotes around your word "solved" stand for many things, including paying through the nose for ineffective B.S. jobs that only exist due to inertia. > do you let your engineers re-invent the wheel so they can feel smart? The Curiosity Rover's wheels, which were re-invented for that purpose, are getting holes in them because the kind of rocks they expected to find are slightly different. Perseverance had its wheels re-invented again to fix this. Someone should have told those so-called rocket scientists at NASA that they're only trying to make themselves feel smart! If we never re-invented the wheel, we'd all be driving around on carved stone. "But you're not NASA, loser!" you say. Why not? Why aren't you doing something new too? > the talent alone is the difference between millions of dollars This is still true. One single talented coder can be the difference between a multi-million dollar business succeeding or failing. I have no idea why you think this is not true anymore; my guess is that you're completely unable to recognize these people when you're around them. Don't worry, most people can't recognize them. In before: "wow, you really think you're an underappreciated rockstar, huh?" -- potentially. Of course I can't prove it over the internet. But rockstars are as much of the product of the environment you put them in as they are their own brains. Maybe rockstars actually are more common than you realize -- maybe you're the reason they're not rocking out. > If you have a really talented coder who can be interchanged with another really talented coder, you do not have a "rockstar." Or maybe the shackles and chains you're putting around these talented coders are forcing them into the same sub-optimal modes where they can't shine. I suspect if you really fostered an environment where software engineers could grow, learn, and shine -- where you fucking TRUST them, in other words -- you'd find they're not so replaceable as you think. > I don't need to work with any more software engineers who think it's okay to be a massive dick to everyone It's never okay to be a massive dick to everyone. In my experience, dickishness is negatively correlated with skill and talent, not positively. This is not an argument against highly talented programmers.

majormajor 3y ago

I've seen teams today have just as large an FTE team dedicated to infrastructure as my employee 10 years ago to manage a set of cloud services that cost wayyyy more than the colo hardware we had doing basically the same amount of traffic. So people cost hasn't always gone down as infra cost has gone up. "Shitty internal heroku" has some advantages once you have engineers that have been at the company more than 3 months: there's just not nearly as much surface area to understand + you have the source code right there if you really have to get int here. Let's leave judgements out of this - you can just as easily build a fragile tower of cloud services and abstractions to "feel smart" as you can reinventing serving an application (reinventing is a strong word anyway... it's just a different set of off the shelf tools usually). And in many cases "managed" services manage the easy part (standing up the hardware and installing the service) and don't manage the hard part (configuring the hundreds of knobs to optimize your particular use case) particularly well. I'm not close enough to the metal for those services/infra teams, though, to be able to completely tell if the FTE hours spent on all that cloud stuff are necessary. That is - can you throw stuff into the cloud and set-it-and-forget-it and not deal with ongoing cloud/infra/config maintenance? But one of the main things those teams seemed to often focus on was spend - if you leave it unattended is the cost just going to eat you up? But then there's a big irony.

milesvp 3y ago
My experience with cloud migrations was that you could migrate and forget about it. This was for a high traffic metro newspaper, that was easy to cache for external users but needed to handle a large newsroom using wordpress to manage the content (wordpress can be a huge resource hog). The main costs in terms of labor end up being making sure that backends services are updated. Same pain you’d feel in a colo, except you cloud provider may force an upgrade you’d otherwise wish to put off. Now I intentionally kept most things at the VM level of abstraction, because it was clear that the added complexity of something like Kuberetes wasn’t worth any savings you might get by needing one less server, and I had enough granularity of healthchecks to just automatically spin down any server that was causing problem and let autoscaling work it’s magic. This was also 10 years ago, some choices might make less sense today, YMMV. Also, don’t think I’m saying all those people aren’t necessary based on the current needs of the business. I just knew I was in a very constrained environment and prioritized anything that allowed for the constant shrinking headcount my department was facing.
YetAnotherNick 3y ago
Just curious, what is the ratio of employee cost vs server cost for the team under you?
- majormajor 3y ago
  Wasn't running them all, but a couple recent companies had ratios of about 1:4 and 1:2 (employee cost : cloud cost) with cloud spend in the low-to-high hundred Ks annually. Curiously, the company with the higher cloud bill also had the lower ratio (spending more on both, but proportionally more on engineering); my diagnosis after the fact is that they were building for a "do 10x the scale" future that was never realized but which would've pushed the cloud spend higher without needing more dev spend. In the future, I wouldn't spend so much that far in advance of actually needing to scale.

thr_ddv 3y ago

The reason why we don't have rockstar engineers is because the markets been filled with talentless hacks who can't code their way out of a paper bag without a jira epic breaking it down for them. I had the pleasure of pair programming with ye olde rockstar for two weeks and we added more value in those two weeks to the company than the rest of the team did in a year. I'm the cto I should know.

lukebitts 3y ago
It's always so funny seeing these kinds of comments from throwaway accounts
- eterm 3y ago
  Not so funny: someone wrote a tool which attributes throwaways with alarming accuracy.
  - swores 3y ago
    I found the tool submission you're talking about, I remember putting my username into it when it was first shown and it did produce a list of accounts with % probabilities (in my case all unrelated to me), but when I tried doing it again now it says "This user does not have any public activity in the previous three years." for "swores" (and I've multiple comments just this week). Luckily for the throwaway person above, it says the same for them. But does still show results for some, maybe only big accounts now? https://news.ycombinator.com/item?id=27568709 https://news.ycombinator.com/item?id=27568709 edit: ahh, I think it just took a one-time snapshot of the three years leading up to its 2021 creation, as my old username that I changed to swores does show up. So it's an interesting proof of concept that someone could do similar analysis, but not an ongoing tool. So it won't be telling us which CTO to avoid :P
    - eterm 3y ago
      That's not the tool I remember, the tool I remember was similar but it correctly found all my alts, whereas that one does not. Edit: I think it was this one that has been shut down: https://stylometry.net/ https://stylometry.net/

turtledragonfly 3y ago

I feel like the author themselves is a bit scattered on this point. In the very quote you lead with, they link to another post[1], which says "...MySQL is boring. Postgres is boring." Our author says they don't like that Boring approach, but then they advocate for a "pets, not cattle" approach, which I think is in line with administering a MySQL server, or such. Maybe this all comes down to different people's definitions of Boring. Maybe modern developers think of "Cloud everything" as the boring/playbook approach, while other people (like me) see the older (in my mind simpler) idea of administering a few machines, maybe even on bare metal, to be Boring. You wrote: > So, do you leverage those solutions to help you solve your problem? Or do you let your engineers re-invent the wheel so they can feel smart? In my charitable interpretation of TFA, I think they are saying to let your engineers use smaller-scale solutions/technologies that address the problem at hand, as needed, rather than getting pulled into the Cloud-everything solve-all-your-future-problems-you-don't-even-have-yet ball of wax that's often advocated these days. I can get behind that sentiment, but yeah I'm not a big fan of the way it's framed in the article, and I have never liked the "rockstar" term. [1] https://mcfunley.com/choose-boring-technology https://mcfunley.com/choose-boring-technology

srpablo 3y ago

Hi! Author here :) > It really comes down to what you prioritize. Do you prioritize the output and the value added? Or do you prioritize making your engineers feel like "rockstars"? If you don't care about your end product, then yeah sure let your engineers break prod using untested technologies. First, the post is about sentiment. It's a response to a piece called "Software and its Discontents," about how people feel. So it's going to focus on that. But I also think the narrative of people working on a project does impact its success. I don't think you pick EITHER "make developers feel like they're doing great, innovative work" OR "do you care about the end product for customers"; the key is to find a way to achieve both, because they feed off each other and are related. It's as if I asked "do you want company growth, or customer happiness?" Try both! > The reason playbooks have sprung up, is because 99% of use-cases for businesses are for the most part "solved." We're not in the era of renting colos and manually setting up MySQL anymore (which the author advocates for in order to return to "creatives," btw). We have managed solutions that you can throw money at. I disagree they're solved! Again, this is in response to a 3-part series basically saying "everything is expensive and everyone is miserable and fewer businesses are succeeding." From a profitability perspective, when was the last Google or Facebook made? > And good riddance to all that too. I don't need to work with any more software engineers who think it's okay to be a massive dick to everyone just because they can implement a CRUD app. To be 1000% clear: I also hate(d) the machismo/showboating we got from the rockstar/ninjas era. I'm a former theatre artist and I'm mostly about embracing people and creativity.

rvbissell 3y ago
This article was my first introduction to your blog. I'd like to tell you that I love your writing style.
billllll 3y ago
> It's as if I asked "do you want company growth, or customer happiness?" Try both! Obviously, both are "good," but again, what's the end goal? To truly be the problem solver, you must make the hard decisions and tradeoffs. Companies trade-off growth versus customer happiness all the time. Right now, a lot of the largest companies are the ones that prioritize growth. To loop back to the point, obviously employee morale and a good end product is "good" and can have synergy, but again, what's the end goal? At some point, you must prioritize. A lot of companies have been very successful prioritizing the end product versus making their engineers feel good, which is why I think this topic recurs. > I disagree they're solved! Again, this is in response to a 3-part series basically saying "everything is expensive and everyone is miserable and fewer businesses are succeeding." I some ways, I think the 3-part series and your article are basically saying the opposite. The 3-part series acknowledges the market conditions and overabundance in the past, and says that in order to get the same results, we need to be smarter moving forward. Whereas your post is (in general) saying that it use to be really good in the past when we were treated like rockstars, we should return to that. And returning to the point, technical problems being "solved" is not mutually exclusive with a general market downturn. That is to say, you can't point at the general market downturn to say that deploying a CRUD app is not a solved problem. And this gets to my main point (which I think the author of the 3-part series would agree with): returning to the "rockstar" era will absolutely not bring software companies back to the crazy valuations and money. The "rockstar" era was the result and not the cause of the crazy valuations of the past.

bob1029 3y ago

I believe the new "rockstar" developer is one who can completely subvert their own ego in order to better serve the business/customer/team. The age of toiling away with weird tech in a dark corner and then expecting the team to be amazed at your contraptions is 2000% over. I've definitely been through this lesson a few times myself. It works and works until it doesn't and then one day you find that you are left holding a really big bag. My new ego trip is watching junior team members quickly ramp and become productive. Maybe you don't have to turn that ego off at all. Perhaps you just need to find a way to redirect it and get it hooked onto a new, more productive target. If you want to go try crazy new stuff - do it on your own time. I really don't understand why this is controversial. It's the best of both worlds. I've heard some excuses for why this is infeasible but they're super-duper bullshit to my ears. If it works on your home lab and it is obviously a cool/valuable thing, then maybe put together a 5 minute pitch deck and present it to your manager/cto/etc.

poslathian 3y ago
Beautiful. Agree. The juniors come in with a lot of technical education that would have been near impossible to learn on the job. Effective teamwork in this setting is just as foundational as skills they acquired in school but they only begin learning it after they graduate. Very rewarding to contribute to the growth in jr devs teamwork when it happens.
Solvency 3y ago
Maybe for CRUD business apps this is true, but there are constant innovations and research papers coming from rockstars in dark corners of the world. All of the time.

feoren 3y ago

I think you're suffering from a lack of imagination. > 99% of use-cases for businesses are for the most part "solved." History is over, technology is done advancing, every business idea has already been had and executed well, everything that can be done has already been done. Sure. And you would have said the exact same thing last year, and 10 years ago, and 50 years ago, and 400 years ago, and you would have been monumentally wrong each time. But June 29, 2023 is different. This is the first day of the end of history. By the way, the quotes around your word "solved" stand for many things, including paying through the nose for ineffective B.S. jobs that only exist due to inertia. > do you let your engineers re-invent the wheel so they can feel smart? The Curiosity Rover's wheels, which were re-invented for that purpose, are getting holes in them because the kind of rocks they expected to find are slightly different. Perseverance had its wheels re-invented again to fix this. Someone should have told those so-called rocket scientists at NASA that they're only trying to make themselves feel smart! If we never re-invented the wheel, we'd all be driving around on carved stone. "But you're not NASA, loser!" you say. Why not? Why aren't you doing something new too? > the talent alone is the difference between millions of dollars This is still true. One single talented coder can be the difference between a multi-million dollar business succeeding or failing. I have no idea why you think this is not true anymore; my guess is that you're completely unable to recognize these people when you're around them. Don't worry, most people can't recognize them. In before: "wow, you really think you're an underappreciated rockstar, huh?" -- potentially. Of course I can't prove it over the internet. But rockstars are as much of the product of the environment you put them in as they are their own brains. Maybe rockstars actually are more common than you realize -- maybe you're the reason they're not rocking out. > If you have a really talented coder who can be interchanged with another really talented coder, you do not have a "rockstar." Or maybe the shackles and chains you're putting around these talented coders are forcing them into the same sub-optimal modes where they can't shine. I suspect if you really fostered an environment where software engineers could grow, learn, and shine -- where you fucking TRUST them, in other words -- you'd find they're not so replaceable as you think. > I don't need to work with any more software engineers who think it's okay to be a massive dick to everyone It's never okay to be a massive dick to everyone. In my experience, dickishness is negatively correlated with skill and talent, not positively. This is not an argument against highly talented programmers.