[srpablo]

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.

[chinchilla2020]

I think the analogy is a good one but needs to be tweaked a bit.

"Rockstars" make tens/hundreds of millions or even billions. A good software engineer can make as much as a doctor (in the US) or accountant. You don't have to be a rockstar to be a 400k/year accountant.

The pay in tech has never been high enough to justify the sort of extreme talent competition in sports and hollywood. Even some of the greatest software engineers (e.g. Guido Van Rossum) are paid pretty modestly in the low seven figure range.

Real world Rockstars like Taylor Swift live a glamorous lifestyle, travel the world, and tend to work short, 2-3 hour gigs. Nobody with a rockstar personality is going to sit in a flourescently-lit office building staring at screen for 8 hours a day. No matter how many ping pong tables and free kombucha kegs there are, it is a very dull environment and does not attract the sort of ambition that rockstars have.

[sublinear]

> Nobody with a rockstar personality is going to sit in a flourescently-lit office building staring at screen for 8 hours a day. ... it is a very dull environment and does not attract the sort of ambition that rockstars have.

Maybe I'm just old, but when I think of a rockstar I think of a lead singer or guitarist that has spent most of their life practicing their craft and loves it so much that when we see them perform it's just a taste of what's inside of their head and heart.

[MichaelZuo]

There's at least several tens of thousands in 'tech' worldwide taking home mid 7 figures to 8 figure salaries USD or USD equivalent, and not including those in the C-suite either.

They are just rarely mentioned on HN because there's already enough tech billionaires to exhaust the patience and attention span of most readers seeking out that kind of content.

[pillefitz]

That sounds absolutely unbelievable to me. Any sources on that? Or even single examples

[MichaelZuo]

> Or even single examples

Most, if not all, Google fellows? Just randomly pick one.

[opportune]

If you want to be as profitable as Google or Facebook, you probably do need some rockstars, but you also need to be developing a technology or business that produces tremendous amounts of value. You can’t just hire rockstars to work on something low margin or without significant demand and expect because they’re amazing engineers that you’ll make a lot of money. Conversely Airbnb has made a lot of money and is just CRUD - they pay a lot and I’m sure there’s some fancy stuff behind the scenes, but you could probably copy most of the user visible functionality with a team of bootcamp devs.

I feel like the tail is wagging the dog a bit here because if what you’re actually trying to optimize for is building >$100b business, hiring rockstars or creating a rockstar culture is just one aspect of getting there which you may not even need.

[srpablo]

> If you want to be as profitable as Google or Facebook, you probably do need some rockstars, but you also need to be developing a technology or business that produces tremendous amounts of value.

Definitely agree on this.

> You can’t just hire rockstars to work on something low margin or without significant demand and expect because they’re amazing engineers that you’ll make a lot of money.

This isn't what I'm trying to argue though — I think when you reach for the ceiling instead of avoid a floor, you're more likely to find those tremendous business value opportunities. Consider what Google shipped/built under Schmidt, "20% time," "Don't be evil," and "we're a different kind of company" vs… the last 10 years?

I'm not saying "being wild and creative makes a bad business good," I'm saying "embracing some narratives of a creative industry may increase output and be more cost-effective, even if playing "outside the playbook of the 0% era" is scary."

---

On another note, I'm regretting that "rockstars" is in the title . It was meant to support the idea that tech was more of a "creatives" industry (and the organic use of that to mean "great talent" is a symptom of that); but I think my "break playbook and embrace creativity" is being read as "let's go back to rockstars/ninjas! Genius hackers who don't sleep and don't care about HR!!!!" which is… not how I feel haha.

[opportune]

That’s fair, I think I strawmanned you a bit - I know you’re not arguing that taking a creative approach to software will automatically add value.

To your point about Google, that approach did lead to gmail, but also many abandoned projects like Buzz and Reader that led to Google’s infamous reputation for canceling products.

My original point remains: I think the business requirements and goals should inform the culture and hiring processes of a company. If you don’t need to deviate from the playbook to get things done, why should you? And not every developer wants to deviate from the playbook either, some prefer stable predictable work - while I’m not personally in that camp I think it’s not a moral failing, doing unpredictable things is more stressful as more things can go wrong, you might have to work more or suffer the consequences of delays/starting over, etc.

If you’re a bank, or a web consultancy, you want boring and predictable solutions. Conversely if you’re OpenAi you want people willing to reason from first principles and invent crazy new things because you’re shipping cutting edge technology at massive scale - and I think they’re doing that. So I guess I’m left wondering where exactly you think opportunities are being left on the table due to overly rote software development practices that would be improved by creativity?

[patja]

The term "creative" has always bothered me as it seems to usually be applied to roles that don't actually create anything other than pretty pictures/designs/words. I guess it makes sense from the aspect of "creativity" but it seems like those who glom onto the appellation of "creative" almost always rely on someone else to do the heavy lifting of building (the actual creation of a product) and bringing anything to market.

[namaria]

I think you're conflating 'creation' as in coming up with something new, with 'production' as in making stuff/providing services...

[billllll]

> 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.

[srpablo]

> 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.

I like this framing, thanks for it. Typically, when something is suboptimal, there's one argument that says "go back to before we [X]-ed" and another that says "no, we need to [X] smarter."

Illustrating this, [on another post of mine, I discuss how Alex Russell effectively says "SPAs/React are terrible" and Laurie Voss has a rebuttal of "no, we need better frameworks, smarter frameworks!"][1] Another example is when FB was in trouble of Cambridge Analytica stuff, it seemed like the answer to Bad Facebook was always More Facebook.

I'll look over it again, but I didn't get a giant message from Kellan's posts of "we need to be smarter moving forward," more about "how we got here." And I certainly don't remember how we're supposed to be "smarter moving forward."

But I also don't think Kellan and I disagree too hard on anything actually concrete. From [the footnote][2]: I think we both want technical decision-making to be grounded in business reality. I think a lot of scared leaders took the "Boring Technology" slogan to mean "something that doesn't scare me," which is IMO in practice was variations of "we won't innovate" / "we'll operate like money will always be free" / "we will use the most popular things I see in the blogosphere."

---

Said it in another comment, repeating here: I'm regretting that "rockstars" is in the title . It was meant to support the idea that tech was more of a "creatives" industry (because the organic use of "rockstars" to mean "great talent" is indicative of this); but I think my "break playbook and embrace creativity" is being read as "let's go back to rockstars/ninjas! Genius hackers who don't sleep and just HACKHACKHACK!!!!" which is not how I feel. What I'd like to go back to is taking some technical risk when there's a good justification for it, even if it's not what Uber did for their problems.

---

> 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.

Well, many developers who were around in the Heroku era think it's harder to deploy a simple CRUD app than it felt like it was then :-p

But I'm also not talking about CRUD apps, I was talking about building a cost-efficient technology org for a better business. That's why the examples I used (deployment pipelines that costs tons of money and entire teams of developers to build and run) tended to be expensive. Many in the industry called these things "solved," but mostly ran giant bills. Your initial comment said "you could throw money at it," and I never thought that was the way, but especially now that money isn't free.

---

> 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.

Again (and it's on me that this isn't more clear): I'm not saying "RETVRN TO ROCKSTAR," it's more "I think we should move the slider a little back to the "creatives" era." But while I don't know if it will create crazy valuations, I think it _can_ lead to happier developers, doing better work, and probably more profitable businesses, even if their market caps are lower.

  [1]: https://morepablo.com/2023/02/little-piece-on-the-great-divide-of-javascript.html
  [2]: https://morepablo.com/2023/06/creatives-industries.html#footnote1

[rvbissell]

This article was my first introduction to your blog. I'd like to tell you that I love your writing style.

[Karrot_Kream]

It's interesting. I work for what is now a Big Tech company, but I started before the IPO.

We built a lot of in-house infra. We had few runbooks. We ran tons of high-scale services with a pretty low corresponding headcount. And we had a great culture, that was definitely more personality based than the rest of Big Tech. Individuals had Opinions (TM). On-call was about having a durable understanding of the system and sleuthing around to figure out what was happening (along with a strong emphasis on learning from failures and putting systems/practices into place to fix those.) And we, as engineers, were weird. My tech lead rolled into work at 11 AM every morning on their skateboard. I used to take a 2 hour daily break from 2-4 PM, go home at 6, and work again between 8-10 PM (ish, this was flexible) before I went to bed and was known to enjoy coffee with fried chicken. Our infrastructure and our services reflected our personality quirks and the interpersonal relationships we had in the office. On-call was one of my favorite things at the company because all the different personalities would weigh in with their different quirks and would offer different perspectives on big problems, and together we'd solve tough issues.

Somewhere along the ZIRP-age this all changed. We needed to become a Real Company (TM) now. We needed to have runbooks. We needed to have Boring Technology. We were poised for huge growth after all (aka our stock value shot through the roof.) The new managers we brought in needed to build out new teams to grow fast, fast, fast. How can we grow when we had such immature processes? We started building runbooks and hiring teams to manage them. Incidents started requiring 3-pages minimum of paperwork to document, which was enforced by an incident management team. Teams dreaded these incidents and where once we collaborated to fix problems, now teams became defensive and combative during incidents. Now we needed the incident management team to force engineers to cooperate during incidents because each team was trying to be as defensive as possible. Managers stopped thinking in terms of individuals with strengths and weaknesses and started thinking about headcount, both cost and allocation. Headcount became everything. With this change, attrition also spiked.

What used to take 1-2 engineers to spin up over a week or two now took months. We load tested our new services, but now we needed to make load tests repeatable and runnable in a runbook. Teams became extra defensive about features because the cost of every incident became so high. Nobody wanted to be the team that missed an integration test which came up as a cause of an incident. Our net reliability didn't actually change though the thinking was that repeatability would allow more seamless swapping of headcount. Program managers managed migrations and we started creating status meeting meetings which rolled up statuses of multiple ongoing initiatives cascading over multiple teams.

My own experience at the company went from having fun writing code and interacting with quirky folks at work to dealing with engineers who were dotting their is and crossing their ts in every aspect of their job. The managers treated us as headcount and so headcount we became. It's been a highly depressing arc to a job I loved and where I built a lot of high-scale code at, but perhaps the most frustrating has been watching our velocity decrease despite our headcount ballooning due to the overhead of programs, migrations, and incident management that developed their own bureaucracies. The saddest part is that the oldest parts of the company have become so essential and the bureaucracy so thick around them that replacing them has become really challenging. The parts of the company that were developed with the least care are the hardest to replace.

[dlisboa]

Great comment, I think a lot of us can find something in it that we relate to, even if not the whole story.

> Nobody wanted to be the team that missed an integration test which came up as a cause of an incident. Our net reliability didn't actually change though

This caught my eye because I’ve seen similar phenomena as well. No matter how well meaning those processes are very rarely do apps get significantly more reliable. It still seems entirely down to how complex the software is, it’s very hard to integration test your way to multiple 9s if it isn’t simple (some companies do it, but at bigger cost and slower velocity).

As for some other points…

I’ve come to believe change in culture is really something inevitable after a certain number though. And that number for an engineering team is not even hundreds, but may be only dozens. You operate less as a team and more like an army, with all the personnel issues that come with it.

What interests me lately is the idea that, for many companies, 80% of the value/growth seems to be delivered when the company is relatively small at X headcount. Then increasing the headcount to 5X does not deliver much more than incremental changes built on top of the core product.

Now if you have that many employees you need to find things for them to do, like managing themselves, creating processes or going off on new market bets, and you risk losing focus.

But at the same time a company with 5X headcount seems more attractive to investors than one with X. The measure of success being only an IPO means there isn’t much pride in being well-run, small and focused, admitting that you’ll never be the top player in the market. That precipitates changes in developer culture.

[mindentropy]

>Somewhere along the ZIRP-age this all changed. We needed to become a Real Company (TM) now. We needed to have runbooks. We needed to have Boring Technology. We were poised for huge growth after all (aka our stock value shot through the roof.) The new managers we brought in needed to build out new teams to grow fast, fast, fast.

I agree. We should have had a cleansing cycle during the financial meltdown and cleared off all the madness. Instead money was printed and the party had restarted with even more stupidity.