[billllll]

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.

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

[bob1029]

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.

[Solvency]

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.

[poslathian]

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.

[majormajor]

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]

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]

Just curious, what is the ratio of employee cost vs server cost for the team under you?

[majormajor]

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.

[turtledragonfly]

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

[feoren]

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.

[thr_ddv]

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.

[rockstar-guy-23]

Appreciate the candor. But we're all just here to get our fill, baby. B)

I only rockstar when my incentive structure has an unbounded ceiling. If you're paying me a salary, plus meager bonus, plus some bennies, plus some lottery tickets -- you're gonna get me at my 40-60%. Just enough to be above average.

Throw in some profit-sharing, and now we're talking, baby. What ever happened to that? Share some of the pie and I'll jump as high as you need me to.

Anything else is just foolish!

[apsurd]

Why is it foolish? I get the cynical attitude around not feeling like you're being taken advantage of; feeling like a fool. Is that the core reason? It's the sentiment (nothing wrong with that)

I ask because while I don't reject this position, isn't there something to be said for intrinsic vs extrinsic motivation: one's internal notion of excellence, pride, discipline, respect, mastery, craft, grit... insert various honoring-self words.

Seems precarious to me, to let external dictate ones concept of value. Btw, I suffer from "doing my best" so that's why I'm curious, I am not shilling for BigCo.

[rockstar-guy-23]

You bring up good points. And like all good points, they stand off to the side and proclaim nothing -- or atleast not enough that it's easy to refute them. So the only guiding light left is our values -- and what we personally believe.

I do not have notions of excellence, pride, discipline, respect, mastery, craft, grit, or anything of higher substance inside of me. At one point in my life, I'm sure I did, but they have been beaten out of me. Some have been taken advantage of by the ulterior motives of others; and some have simply not been conducive to achieving my goals (i.e. having fun, putting bread on the table, not ending up in the streets, living a leisurely and relaxed life, etc.).

In another vein, one could make the argument that the precarious thing is to tie one's intrinsic motivations -- those little devils inside of us -- onto a "job." That job will one day end, and you will have to find another as an effective outlet for those little devils; otherwise depression and all sorts of psychological illness will start encroaching. If one wishes to keep one's values strong, why make them dependent on uncontrollable things? Unless you are independently wealthy (if that is the case, I can offer nothing), there will be times you will be required to make sacrifice of your values to "get the job done." You will have to be sloppy, amateur, lazy, selfish, and maybe even villainous to do what needs to be done. At that point, you can hold strong and suffer the consequences, or you can relent, tell yourself you are temporarily setting aside higher ideals (it never is temporary), get the job done... and suffer the consequences.

Tying your soul, your essence to such a thing is precarious. Putting your heart into things that will require you to abdicate your integrity is foolish. You will end up hurt, broken, and missing pieces of yourself. It is better, and more sustainable, to save that sort of thing to matters that aren't directly related to your survival. Otherwise, to charge steadfastly into what one knows will be suffering is noble, but foolish.

[manicennui]

I think I'm falling for you.

[apsurd]

This is a really helpful reply. Thank you. Some thoughts:

Excellence is not in contrast to fun, leisure, and relaxation; it's made that way via Capitalism and hustle culture.

> In another vein, one could make the argument that the precarious thing is to tie one's intrinsic motivations -- those little devils inside of us -- onto a "job."

Well said. I suppose it does take more energy, effort and soul really, to constantly decouple one's job from identity and worth. That one's internal values _ought_ to permeate through one's life "authentically" is certainly easier said than done.

Thanks again for responding in earnest. I'm convinced lol.

[nathants]

amen. first rule of economics. incentives drive behavior.

to ignore incentives is folly. they drive the behavior of others around you as well.

bad incentives lead to endless kingdom building and mediocrity. good incentives lead to a brighter future.

[mjr00]

"Talentless hacks" is a bit too far, but it's very true that over the past decade, software development has been flooded with people who don't care about software development: people who never touched a desktop computer until university, where they only went into CS because they knew a $150k starting salary at a cushy job was waiting on the other side.

Nothing wrong with them doing this, of course. And they're very smart people. But you really can tell the difference between "software developer who takes pride in their work and wants to build something great" versus "software developer who wants to pay their bills". It's the difference between the developer who responds to a packaging problem by learning their build and dependency management system inside out to understand what's going on, versus the developer who copies and pastes from SO/ChatGPT until it works for some reason and moves on with their life.

Granted, not all software development companies deserve the former. But a tightly focused startup with 50 developers from the former category can absolutely dominate the market, at least until they get acquired, as we've seen so many times before: e.g. WhatsApp, Instagram, OpenAI.

[mindentropy]

>Nothing wrong with them doing this, of course. And they're very smart people.

On what basis are they smart?

[anthomtb]

Two weeks? You're the CTO and had a rockstar programmer sitting next to you. Why didn't it take one?

[Solvency]

Since when is the CTO expected to be to be a rockstar programmer? CTOs communicate technology matters to the board that they are beholden to. And they manage the technology teams within a small region towards the top of their departments pyramid.

These are different skills and responsibilities from being an elite rockstar developer.

[indymike]

CTO here. I spend little time with the board, and most of my time with customers and employees figuring out how to use tech to make life better (and make more money) for those customers and employees. I do a good job, the main interaction I have with the board is, "Good job, have more options and a raise... and the valuation of your shares has doubled." The other interaction: "Help us go raise some money." I do a bad job, and the interaction will be, "we need a new CTO".

Oh, and I still code. Because I like to code. A lot.

[Conscat]

It's not that uncommon for the CTO of a small startup to personally develop a huge portion of the technology.

[muh_gradle]

Why hire these people then

[lukebitts]

It's always so funny seeing these kinds of comments from throwaway accounts

[eterm]

Not so funny: someone wrote a tool which attributes throwaways with alarming accuracy.

[swores]

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

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]

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/

[swores]

Ah, I wonder if any other people have made similar for private use...

[metalforever]

The comment mirrors my experience in the industry over a long period.

[HeyLaughingBoy]

They're not wrong, though.

[thr_ddv]

Because I'd sink the company I'm golden hand cuffed to if I said what I think about the engineers I have to manage. But I do think I'll be bringing in SAP timesheets to share my pain with everyone:

> We need to keep track of the time your spending on your opex KIPs. We can't pay your expected bonus if you don't.

[apsurd]

you're the CTO of a company mostly composed of talentless hack engineers that can't code their way out of a paper bag? You're literally the apex engineering lead; that's so... sad. Do something about it.

[majormajor]

So as cto did you just totally screw up at hiring, or were you brought in later but somehow don't have authority or ability to fix anything??

IME when I've seen a "1/10th engineer" it's almost always been a total management failure.

[thr_ddv]

The budget I have for hiring is tiny and no one on the board believes 10x engineers exist. The choise is between not shipping anything at all or having to deal with said talentless hacks who happen to know more than me about tool X but otherwise slow development to a crawl.

Turns out reading HN comments is not a good way to run a company. Who would have thought?

[majormajor]

I mean I also sure hope nobody is reading your comments to learn about running a company! They'd learn about "not answering the question," though, I guess.

Remind me, whose job is it to convince other execs and the board of the most appropriate talent strategy? Maybe lesson 1 here is "if you're running a company and don't trust your CTO, look for a new one"?

[jstarfish]

It sounds like you hired a personal mercenary, not a 10x engineer. Everybody is more productive when they ignore the rules everyone else is expected to follow.

There's probably nothing wrong with your existing team except it being too large and democratic. One guy can bounce ideas around in his head faster than a dozen negotiating them with each other. I've seen teams like yours, and IME the issue isn't always incompetence, sometimes each of them thinks they're the rockstar. Anytime one of them doesn't get their way, they jam everything up for everyone else.

We've become too democratic as a whole. Nobody follows orders from above; everybody expects to have a say in things they don't even have a stake in. Whenever you get to hiring again, try stacking your team with 2-4 ex-military types and see how it works out for you (it works well for UPS well beyond that scale). You don't get bleeding-edge experience (and never a 10x-er), but you get tax breaks, competence, obedience, people trained to work as a cohesive unit, and you can wave the flag and call yourself a patriot (which helps with government contracts if that's your business).

[muh_gradle]

> Turns out reading HN comments is not a good way to run a company. Who would have thought?

Literally everyone thought this, and probably even the talentless hacks that you hired. Strange that you had to create a throwaway account to figure this one out.

[sumeno]

Sounds like the company needs a new CTO if all your engineers are talentless hacks

[chinchilla2020]

this is satire, right?