In my career I have seen almost identical systems being built by a) 6 developers in a startup in 1 year b) 100+ developers in a big company with a much much larger budget in 2 years.<p>Almost the same specs, but the one in the startup had better scalability and fewer serious bugs...<p>So, spend 10-50x less and get higher quality?<p>Worst is I now consider case b) quite lean and efficient compared to what I see tech consultancies doing towards public sector, banks, etc...<p>--
My point being: There definitely IS a room for "rockstars" (don't like that term, but interpret this as developers competent enough to carry a lot of weight on their own and work in a smaller company) to deliver a lot of value.<p>The problem with the model is the lack of predictability (what if the few developers you trust don't deliver), the bus factor if one of the few devs quits, etc<p>In a sense inefficiency is a goal, because otherwise you loose redundancy. It costs a lot to hire 100 to produce the output of 10, but much lower risk.
I think the "rock star" analogy did more damage to our profession than most care to admit. Rock stars get treated a certain way, they are catered to, their egos might get fluffed up, etc. None of those behaviors are compatible with working in software teams, and none of the "best" developers I know want to be treated that way, anyhow.<p>That said, I think this article is essentially correct. I would put it like this: building information machines out of pure information is a creative endeavor. Human performance tends to fall on a bell curve, and IMO it's true for developer output in particular. So if you want to create a hugely valuable solution to a big problem, you should probably hire the best people you can find and organize them in a way that lets them max out their creative power.<p>The main obstacle to this IMO is poor leadership attitudes & practices. This article's author said it best in another post:<p><pre><code> "Boring" is a good strategy if you think the bigger existential risk for your company is that Product & Engineering will [...] fail to ship a reliable product on a reliable schedule. But if you're more afraid of the business risks of shipping average product, at an average cadence, over the course of years, you should consider deviating, at least sometimes, from the playbook whose entire definition is "optimized for safety."
</code></pre>
<a href="https://morepablo.com/2022/04/against-boring.html" rel="nofollow noreferrer">https://morepablo.com/2022/04/against-boring.html</a>
The silly part of this is that the industries he compares software to - music, television, movies - have all been skeletonized and reduced to minimal and repeatable products. Simply looking out the door should be enough to convince you that if you want to bring back the magic, asking to be treated like a television writer isn't the way.<p>Right now the biggest thing bringing down developer wages is the threat of being replaced with an LLM. That's not going to work out in the long run - giving developers productivity increasing tools isn't going to lessen their value. However, it's the most plausible wage suppression hustle for quite some time.<p>Until the limits of LLM generation get tested and felt, the downward pressure on wages is going to continue. Maybe when the first wave of LLM driven startups feel the pain of maintaining code that doesn't have an author, or maybe high profile malicious training data attacks will do it. Even afterwards, the effects of the wage curve being bent downward for a couple years are still going to be there.
Tbh I think it depends where you work. In 1999, if you worked at a Java shop making accounting software or whatever, it wasn't a talents/creative industry.<p>Same thing now days, but replace Java/accounting with React/CRUD. The rockstar code ninja 10x mentality of 2009 is maybe gone for good, but I see more crazy coders doing rockstar level stuff now than ever before. Asahi Linus and alyssa rosenzweig being great examples from the Asahi project, but these people are all over.<p>People talk about the complexity of the infrastructure making it impossible to do everything yourself, but in my experience is exactly the opposite. The degree of abstration, automation, and high-level tools means that you kinda can do everything without knowing too much.
I work at a FAANG company on a project from a recent acquisition. The "narrative" of the startup was much like this article describes; a few rock stars knew everything and delivered sweet features everybody loved. Well, now those rock stars are gone, and we're left to pick up the large tech debt tab left over from their free-wheeling days of fast features and relatively poor documentation, code health, and testing.<p>I get why this happened. A startup has to deliver features now if they want to get acquired. It's a completely different mentality from the one we have now: no worries about funding, and we want to do things right in a way that will be robust long-term. Realistically, this is how it was always going to go down.<p>But I can't say that this is ideal. You don't want a couple rock stars carrying your project if you also want that project to be around in 10 years and can't guarantee that all your rock stars will be dedicated for life. You need somebody else to be able to pick up the torch. You want "commodification" (although I don't think it's a very accurate term; it's actually hard to get this right, not easy, but the alternative is much worse over time).
The grass was always greener in the past / Cualquier Tiempo pasado fue mejor.<p>Pure creative programming work have always been a small subset of programming in general. Were COBOL programmers creative? Data Base programmers? IBM programmers? Those were the majority of software jobs in the past.<p>I have been mostly a pure C,Verilog, VHDL, analog digital electronics -low level engineer for a long time before becoming entrepreneur and using much higher level languages in our company. Was it creative? A lot. I interacted with machines like robots that did things like moving 20 tons or lasers or robots or whatever.<p>Was is painful, tedious and boring?. It was, also.<p>You need to make it rain using active work of whatever is necessary for your job. The fact that something is not "sexy" is a great advantage for a job as it removes most of the competition. Being hard scares most people.<p>The best advice I could give young people is to find hard problems and to find the techniques and tools that could make those problems easier. We use psychology and things like lisp as secret weapons.<p>Thinking in the 35 people that created Facebook is extremely misleading, because fb got extremely lucky, and they were hundreds of thousand of programmers working in other companies. The monetary success of fb has a lot more to do with free money created by central banks than anything the founders created as their technology was easy to replicate but its financing was not.<p>There are intense opportunities today like they were in the past. But they are hard, like it was hard in the past.
Most new software sucks. Nobody is excited by it. Neither users, nor programmers. Rockstars don't work on boring projects.<p>Employers don't want rockstars, they want underpaid, overworked workers.<p>First web browsers were a thing. Napster was a thing. Altavista was a thing. Skype was a thing. One of the first mobile apps (anyone remembers Symbian?) was a thing.<p>Things that some people enjoyed using and other people enjoyed creating.<p>Now, what can excite you as either an user or creator? Your average LOB app? A random chat app that takes ages to start and eats all your computer memory? Uber? Netflix app?
My project manager called me a rock star one time in a kick-off meeting. My fellow programmers never let me live it down – yelling out "rock star!" when they'd see me in the halls, "come on rock star, fix your bug", "I dunno, let's ask the rock star", etc.
i hired a true rockstar once. they were the smartest developer i have ever worked with, ever. this individual could singlehandedly put together massive systems, from technical to design, with confidence and flair.<p>i had to let this person go because they did not know how to work with others. beyond their brilliance, they could simply not empathize with the organization's POV. everything was about them, supporting them, making them feel special, unique, and important.<p>this individual eventually returned the company laptop, which was bent in half. they told me that they had smoked enough DMT to understand that they had created their own god and that if my org needed further investment, to reach out to them.<p>i hired this person from HN "who wants to be hired." they still (to this day) add a post to the monthly thread.
I don't think you'll find metaphorical rock stars working in a team in a salaried job, any more than you'll find actual Taylor Swift doing ten hour shifts in an office building. There's nuance to that though. It's really hard to distinguish yourself working in such an environment, you don't have the time, freedom and energy to do that. And if you can't do that, you won't ever be much of a "rock star".<p>Not that you can't work as an independent "creative" in programming though.<p>I've gotten to a point where I can work on Marginalia Search full time, and live off grants and donations for at least a few years. Dunno if I'm a rock star for it, I don't even have a Wikipedia page, but I at least reckon myself a fairly successful busker.<p>If I don't qualify, then certainly Serenity OS Andreas who made like $300k in a week with his browser shenanigans. Him and a other people far more talented than I am are able to live this way.<p>But it's a weird game. I think it's more or less all about the right sort of visibility. You distinguish yourself working on some large problem in a public fashion, and people inevitably will start throwing money your way; this enables additional work and additional visibility, it gives even more opportunities.<p>While maybe not reaching the John Romero levels of rockstar we had in the '90s, this manner of working is certainly closer to the success of a Taylor Swift than being the most talented developer in the IT department.
In the 1980's, the About box of most applications (Mac and DOS primarily) often listed most of the people who worked on them. Many of the people were also known to others; I usually met many at the precursor to WWDC. It was cool to see your name on something you worked on (I worked on three apps over my two startups, Trapeze, Persuasion, and Deltagraph). Some people got to be pretty rockstar-like (I remember at the first WWDC (not called that yet) in 1986 sitting on a boat with what felt like all the Mac programmers in the world, a whole bunch of us aptly listening to Silicon Beach's Charlie Jackson on how he recorded a cricket for their first game). Because apps and programmers were rare compared to today and something new, you had more of a connection to the people who built things. Today you have no clue and probably don't want to know.
I think the problem with today's software is that there are few amateurs. Most software developers are professionals who get paid by the hour - that rather build something in 5 years then in 5 days because they get paid to do it, they do not hate complexity they embrace it. Something is taking 5 seconds you better make a framework to solve it. Software is everywhere so CEO's will keep paying. The good news is that a teenager can beat a team of 100 engineers. The large team still have an upper hand with their insane marketing budgets though. But who wants to be a developer when you can get famous on Tiktok instead.
I disagree with a lot of this for a few main reasons. And some minor ones<p>Application development technology has considerably improved over time - most applications simply do not need to reinvent the wheel! Yes, over-engineering by designing something that will never see more than 1qps to scale infinitely is bad - I’m sure it happens but I think it’s more a strawman. If you need a simple CRUD application with a good-enough UI you have no need to introduce additional complexity (and potentially maintenance, reliability issues) with custom tooling.<p>Two, the software talent market is bifurcated. There is basically commodity development of crud apps, and technically complex novel development. If you think there are no rockstars you might just be in the commodity development scene. There literally are these so-called “rockstars” being flown into SF to work on new stuff in the ML sphere or into NYC/Chicago to work on bleeding edge performance. Maybe the dissonance here is that the commodity developer market has grown a lot, and that over time some technology (like web applications - a lot harder to do at scale in 2005 vs now) shifts from rockstar to commodity as it matures.<p>Reverting to pets-not-cattle and statefulness can be appropriate at low scale. But honestly this is more of a “choose the right solution to the problem” thing and not a rockstar thing. Following this model as you reach large scale allows for cool production heroism and cowboy coding that makes you feel like a true hacker, but that doesn’t mean your users are getting a more reliable experience, or that your dev time is being spent efficiently.<p>My minor quip is that, I think as you get more experienced what you used to think of as rockstar development just looks routine because you’re better at writing software.<p>Another minor point: you can’t just engender a rockstar culture at a company that hires commodity developers as easily as asserted here. The big thing not mentioned: PAY. Nobody wants to get paid like a commodity developer to have to perform like a rockstar. Being a commodity developer is more chill and there is less day to day risk and stress. Once you start getting towards the bleeding edge or reinventing the wheel your work becomes riskier and requires more mental effort and attention.
This article is all over the place; I got a neck ache trying to follow it. I can't engage all the points, so I'll just address the titular point. The software industry never exhibited the most salient property of talent/creative industries: rockstar economics. And that's a good thing. Otherwise a handful of Carmacks and Deans would rake in all the money, leaving the rest to man the Genius Bar until they got their "big break".<p><a href="https://en.wikipedia.org/wiki/Winner-take-all_market" rel="nofollow noreferrer">https://en.wikipedia.org/wiki/Winner-take-all_market</a><p>I agree with bullet points about keeping it simple and not using crap tech for your MVP.
The playbook works and the more boring the better. If you are doing something on the edges of computing or industry than hooray - you are off the beaten path and it's your time to shine! You can be the one writing the playbook in a retrospective, but please don't try to make a boring application in a boring industry exciting by being unorthodox. I don't want to be excited and interested in how you solved a basic CRUD implementation - I want to intuitively know what it's doing before I even git clone your repository.
The thing I find most sad about articles like this is that it doesn't seem to actually address any of the reasons that it got this way, it blames individuals within the field not a series of MBA graduates telling you what the spec is and hiring 50 people to hit an arbitrary deadline for a software project moving in the wrong direction FAST.<p>It's a false dichotomy to say you only have rock stars and as this person smugly tip toes around "normal people" when in reality you don't need rock stars anymore to make good software and let's be honest... Most rock stars didn't make good software they just make it in a time when software was generally even more crap than it is now.<p>You want to stop suffering among us plebs? Don't advocate for goofy rockstar developer propaganda, advocate for healthy work life balance and reasonable deadlines for things that truly don't matter. Stop letting sales and marketing write your software and stop taking opinions about systems design from your project managers and "technical leads" when they do not work in these systems day to day.<p>If you treat engineers well and respect them before a client who will drop you the moment a new product fits their need then yes you will lose clients from time to time but if you focus on making good software and happy people then you will attract stable clients who do the same and maybe the stock holders at the top don't get the ridiculous return per year that they expect out of more shameless companies but at least you have a half decent chance of sleeping at night...<p>I am well aware that we live in a world where this will be borderline impossible but the first step to solving a problem is admitting it
Not sure If I agree with this article. My experience in the big co is that trying to navigate through large systems with many moving parts and stakeholders and come up with a solution and execute as quickly as you can is very exciting. And you definitely need to be creative to trying to align and solve some many problems in 1 design. It's a very challenging and fun experience
These industries just have a different mechanism, here is an example: the worlds 10,000th best tennis player probably makes $0 dollar from tennis, and the world's top 0.1% of pharmacists make maybe twice as much as the 50th percentile.<p>Some industries you either are the top 0.01% and make millions; in some industries being average means a decent living.<p>Software has long transitioned from one end of that spectrum to something more towards the middle. Super star developers simply aren't productive enough for the demand of software
It's a bit scary how much weight is put upon k8s and terraform and how little actual skills these jobs require. I miss being a sysadmin in this commodity world.
One interesting thing to note: whether you think software should be more like a “talent/creatives” industry, or more like a trade, one thing both of those models have in common is <i>unions</i>.
software as auteur work succeeds when it's entering a vacuum. if you're legit breaking open a field that's never been exposed to it before, sure, go wild. those fields are fewer and far between nowadays<p>unlike creative industries, there's a fuckton of toil work that just needs to be done automating processes. the playbook style excels there, and unlike artistic work there's not really room for memorable standouts that break the rules.<p>music will always have the quality where good novelty is impressive and breaks boundaries. business processes less so. prince can (could) deliver a stellar rendition of purple rain that breaks the bonds between heaven and earth even though you've heard the song before, but ain't nobody delivering a stellar automated check deposit workflow execution that stands out from the rest.<p>commodity services bring commodity work. this is fine. i do not want my mobile check deposit to be a tour de force, i want it to be something i don't give a second thought. there is beauty in the blase' being blase'
The transition from a new growth industry to a mature industry under conditions of nearly interest free loans and low aggregate consumer demand. In this essay, it seems clear that the kinds of designs matter a bit, but lots of companies choose different technologies and practices and survive.<p>The obvious conclusion is that market conditions matter more than the technology stack for a space of "reasonable" choices about it. I expect, until the next big thing hits, the market conditions to be dominated by consolidation. Bitcoin was supposed to bit it, but that was a scam. VR was also a scam (Zuck tried to sell us non-existent real estate), but maybe it'll turn into something more useful soon.
It still is, and like actual "rockstars", the workers are being exploited by ownership that, for some reason, are the only ones who are supposed to profit off of "rock".<p>Don't know how many musicians you know, just ask one...
Software was never really a "creatives" industry, in the way people and articles like this mean. It was, at the dawn of computing, the realm of typists and mathematically inclined women, then slowly through the 70s and 80s, increasingly nerdy men, including the "rockstar" neckbearded ingenious tricksters finding incredibly convoluted ways to save 500 bytes. Besides being "wizards" of a world most people could never understand, you had to actually bend your brain to find solutions to hard problems, because technology was so limited.<p>Now there are no hard problems. Just throw more hardware at it. Just write another CRUD app. Just wrap it in JavaScript. It is commodified because it's now a commodity. Software is ubiquitous and easy. There is no need to be creative, any more than for filing your taxes.<p>The people who like to program are, almost universally, nerds who get off on logic, solving problems, building things. But there aren't really new problems to solve. So they try to re-solve the same problems, over and over, without improving on what came before. Never satisfied. Software will always be the realm of these people that are obsessed with reinventing their toys in a sandbox. So the products will always be kind of toy-like.<p>That's why hardware gets better while software stays about the same. Hardware people can't just play with toys. If the hardware doesn't get better, nobody will buy new hardware, and they'll be out of a job. But people will buy <i>different</i> software and call that "better". Even though it's doing about the same thing as before, less efficiently.
Apologies in advance for being a bit negative. I feel like this sentence is just so revealing:<p>> 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.<p>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.<p>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?<p>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."<p>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.<p>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.
"When WhatsApp was acquired by Facebook, they had 35 engineers. They were able to do this in part because they didn't "follow playbook," and while you probably can't go that extreme..."<p>Not my area of expertise at all but, 35 engineers for WhatsApp sounds like a lot
I think "rock star" is a superficial term which is mostly poking fun at some programmers for having long hair, liking rock music, maybe even owning a guitar.
I almost agree with this guy except when he suggest to use something like Java instead of say Python to be able to scale.<p>Most of the successful tech companies he is referencing are using Python. And no one saw a big successful website/app in java. Most of the time corporate or gouvernement shitty web applications that randomly crash with backtraces when you are using them.
Maybe it's just me but I hate the word "creative". I don't like that engineers are refered to by the same word that describes actors, poets etc. Problem solving is subposed to be rational/unsurprising, most of the time you follow a logical flow and a consistent methodology to come up with solutions that make the most sense. "Innovation" is supposed to be a side effect of that.
I took the "boring tech" stuff differently. I choose technology that makes my <i>production environment</i> boring.<p>Sometimes that means picking technology that is not mainstream. Choosing mainstream technology is one of the best ways to make your production environment decidedly not boring.<p>I would argue Erlang is one of the most boring pieces of tech you can pick. Look at how boring your production systems can get when you choose that.
By the title I thought this would be about the early 80s and e.g. this Electronic Arts ad/poster: <a href="https://bytecellar.com/2009/09/30/i_started_life/" rel="nofollow noreferrer">https://bytecellar.com/2009/09/30/i_started_life/</a>
> Getting flown as an undergrad to SF in 2009 for an interview at Facebook, put in a hotel, served free food, all because you could code? You felt cool<p>Sorry, you drank too much of the kool aid. Let me clear it up for you: you're a cost center that the corp would rather not have.
Industries mature.<p>I kinda thought coding might be immune, because it's about information. But of course, you build on lower levels. Today, you can get outsized returns by applying LLMs to real problems. Also about information.
There's threads of a few interesting ideas in here, unfortunately the presentation teed them up for the current cultural mythos to obliterate them.<p>A number of years ago, the uptight cultural conformity of the valley bubble branded itself with some of the imagery the author attempts to borrow. The collective consciousness hasn't forgotten how that image was power-blasted away. It was done as cover to sneak in a bunch of orthogonal changes while nobody was looking, but that part's neither here nor there. Forget I even mentioned it. The end result is that we're here now and we have the tools to evaporate this article with one shot at 50 paces.
This is written in the style of someone who worships software development, but is not themselves a professional developer and therefore has spent zero time working on a team to build something more complex than, say, a webpage.<p>I recognize the author is a professional developer, and seemingly has worked on teams to build complex things, but it appears as if they forgot how the human machine works, and are now stuck on some kind of nostalgia trip where everyone involved in the process is somehow like them and only able to gain energy through self expression in their software engineering work.<p>I do wonder sometimes if there's something about living in SF or NY that makes you forget how tiny your perspective actually is.