Almost the same specs, but the one in the startup had better scalability and fewer serious bugs...
So, spend 10-50x less and get higher quality?
Worst is I now consider case b) quite lean and efficient compared to what I see tech consultancies doing towards public sector, banks, etc...
-- 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.
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
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.
What absolutely does not mean that teams are useless. But that choosing the correct size and composition for them is one of the most important decisions for a project (right there with "are we solving the correct problem?"). And "more is better" is a completely wrong way to decide on it.
Also, this doesn't make that one developer a "rockstar" or whatever else you call it.
Same goes for "rockstars", only its easier not to "lose your groove" if there are fewer people pinging you. You still run the real risk of two "rockstars" playing out of sync, and causing a mighty mess down the line.
I've seen 5-person teams of raw bootcamp grads run rings around conventional dev teams with a broader experience base, repeatedly. Part of it is that there are no bullshit status games going on when everyone knows everyone else is just as in the dark as they are, but (in my view) an equally large factor is that the grad teams know they're going to have to learn whatever tools the problem needs. A more tenured team is far more likely to waste time on trying to build java in python, or fighting over not being able to use their favourite libraries.
But then there's also the wider situational context: an environment that has 100+ developers in a big company will have governance tarpits and coordination overheads they almost certainly haven't measured the cost of; 10x wouldn't surprise me at all just from those two factors.
Grad teams in the same org are more likely to have standalone, lower-risk projects to work on so they're going to be more insulated from those effects.
Every more junior person on a project is going to be less efficient than a senior person but they need to level up and go through the apprenticeship phases to become a senior person.
Very small companies or teams can tactically choose to pay more and only hire top talent but most places will need to develop internal talent due to budget, recruiting, or bus factor (business resiliency) constraints.
20 developers is a lot, but could in theory be worthwhile. I'd really try to get all 20 be very-effective ones and structure the responsibilities and communication so that they don't get bogged down. If you do it a naive way, and aren't lucky, it'd be easy for 20 1x..10x developers to become 0.01x developers.
Or, if you get people who just want to call themselves a "dev" and grind concrete task assignments in a straightforward way, then I think you either need to be doing something bog-standard and naturally amendable to just going through the motions (e.g., scalable Web CRUD, or yet another forum/chat app), or you need a brilliant approach to structuring the work.
The 'good' (whatever that means) devs will waste more of their time hacking around the above... so more devs are added to compensate... repeat a few times: Fred's prophecy becomes manifest.
The problem is the velocity hit you take by doing this is its own risk that's not tracked in the same way predictability and bus factor are. I'll bet one of the core reasons OpenAI was able to release a ChatGPT style product so much faster than Google, despite Google coming up with the fundamental Transformer breakthroughs, is this difference in velocity. And when a startup begins to erode a calcified, highly redundant larger company, then the larger company has the risk of becoming irrelevant along with all of its internal redundancy.
I think there's a better way to think about risk here.
There's lower risk with the predictable team. Those are so common, especially in established business, that we can even treat this as the default state.
If you so wish, you can take on more risk and seriously slim down and get work done faster. And it will almost certainly be faster on a large enough time scale, but because it's less predictable, you're now playing schedule chicken.
The kind of risk that you bring up, risk of being less risky and going slower . . . is really just opportunity cost. And it's ok to take that on as a tradeoff for something else, too, if you do it with eyes wide open.
Risk is not a thing to be avoided. It is a thing to harness to gain an edge on competition. After all, without risk there is no profit.
Yep, this is known as McNamara Fallacy - https://en.m.wikipedia.org/wiki/McNamara_fallacy
Mythical man month in play. In my experience, teams working on a single project peak at around 3-4 people, depending on how well you can silo the responsibilities. You can have 200 developers on a massive project, but the planners need to be able to silo the pieces off properly and define interfaces very well early on, which requires a massive planning phase. That usually doesn't happen the way people want it to either.
https://en.wikipedia.org/wiki/The_Mythical_Man-Month
Currently on my team, we have one guy responsible for the schema, back end webapis and automation. Another guy does exclusively UI, those are the two main people. We have another guy responsible for auth and misc stuff and the third guy is a full stack that came in after major development was complete who can add features pretty quickly. We have a completely separate team that handles billing operations/applications of 2 people. Our team members communicate directly with business for requirements and understanding their needs, so nothing gets convoluted passing information down through middle channels.
It's not the only way to do it, but it works pretty well for us. We write all the programming required for operations of a pretty complex medical company. This was a complete Greenfield project and we have about 10 major and minor applications so far. We also have to adapt to incoming partner companies who have their own special needs and changing regulations, so the system and team is very flexible. We're about 4 years in and we had a working system up and running from "File -> New" after about 6 months. All this during COVID.
Another problem with big companies that I've seen is that everything is done by committee and about 10 people need to sign off on any little thing. It turns into an administrative nightmare.
The Microsoft Band golfing on device UI was built by 1 developer in 2 or 3 months.
The entire notification experience was 2 or 3 developers on and off again for the product's lifecycle.
The onscreen keyboard was a couple ML engineers and a software engineer for a few months.
The runtime it ran on was ~8 engineers, including all drivers, board bring ups, custom file system, everything.
Small teams can do amazing things, but they rely on good leadership and on every member on the team being able to pull their own weight. We had 1 person design+code the entire file system, and as you mention, that put the bus factor at 1.
One theory is: If you have just a little too many developers (redundancy), they become bored and find ways to introduce auxiliary complexities to keep things interesting, thus things explode to 100 developers being needed...
That is, the first project wasn't 15x as productive so much because the developers were so (intrinsically) -- or even when they were objectively all above average. But because beyond a certain optimal team size, per-developer productivity drops substantially -- even plummets precipitously (due to the factors articulated in TMM: communication, politics, etc).
Plus there's a huge survivorship / selective bias example involved here (we're not look at pairings of other projects where the smaller team failed, even with better developers, because it was just too small, etc). I also suspect that if one were on the "inside" of both projects (which of course no one was) one would see a host of other factors involved (from knowledge of the requirements to market conditions, etc) not visible to an outsider.
We can definitely see how anecdotes like these help promulgate the 10x myth at least. People hear about the fates of the respective teams and think "Of course, it's because those developers were individually that much more productive. I better start making my interview process 10x more difficult now ..."
(BTW, no need to drill down on what I just said about the "10x myth", please. It's not that awesome developers don't exist or aren't important. It's just that for a whole lot of reasons, it is both incredibly overhyped, and objectively wrong in its fundamentals -- especially when we look at the original studies whence it supposedly derived).
This is why I say "rockstar" is a synonym for mug. Why won't they pay those 6 developer 10-50x more?
I've seen it many times. Young developers working their bottoms off, creating a product that makes millions only to earn average developer salary and then being laid off when company gets new investment round.
At the same time, through progressive taxation, taxman takes (depending on the country) majority of earnings, so you won't be able to amass capital to start your own business.
This is the way how the rich captured the means of production (developers) in wage slavery.
You won't make it, unless gatekeepers let you.
I spent a decade in the public sector of Denmark and I've since got into helping non-SWE startups transition into enterprise organisations as far as digitalisation goes. So I've seen quite a lot of this. I've also had the pleasure to be on basically every sides of the table, from developer, architect, manager to buyer and consultant. I think it's always down to the business processes and the management.
Sure "rockstars" are a thing in SWE, I'm frankly one of them. However I don't think the difference between a 10x and a 1x/rockstar/whatever buzzword developer is necessarily too much about our technical abilities or talent. In my opinion it's often mainly defined by your organisational prowess. If you're the type of developer who can get things done, make an impact and create business value, you're going to be given a lot of freedom and you're eventually going to settle into "rockstar" roles. This is soooo much easier in smaller organisations where the restrictions you face on how you can work are often small-non-existant. Maybe you're even going to build some of the restrictions yourself, by defining how your organisations wants to lint, which techs you want to use and so on.
As things grow, more and more people are going to enter the work processes. Some of them are going to be hired to work on the work processes themselves, and eventually you're going to end up with this quagmire of bullshit red-tape. It's there with good intentions, of course it is, nobody goes to work meaning to make the world a worse place, but all the control and the business intelligence is usually an illusion of sorts. At least in my experience. Now, if you have good managers they'll build teams and manage the processes in a way that doesn't get too much in the way, but over the years, you're going to have a lot of bad managers involved in the processes. You're likely also going to work for an organisation where upper management doesn't care about digitalisation, at least not really, despite the fact that 90% of their work force is on a computer 8 hours a day. So eventually you're going to end up with an environment where it's hard to get things done.
What is worse, often the best developers. The people who are able to deliver a lot of visible business value, are going to be plucked by management in attempts to try and use them to make other developers produce more value. Meaning that many organisations tie their best development resources up in advisory roles and waste them away in endless meetings.
So it's not that those 6 developers are necessarily better than the 100. It's that sometimes, a team of 6 developers get to do more actual work than 100 developers combined do in a year.
Obviously that's only part of it. There is a whole range of other things that impact why big organisations suck. Because the quality of the 6 man team isn't necessarily on par with the 100+ developer team if you look at the application at scale over a decade. At least not in my experience. This might not matter when you're small, but it will matter when you're IBM because a few bad years will wreck your reputation for decades.
> So, spend 10-50x less and get higher quality?
You're never going to convince businesses that it's less risky to buy from a small company. It's not like CEOs are stupid. They might not care about IT too much, and they certainly hate it when IBM fails to deliver on time and that it'll cost extra to get the thing to actually work. But they do know that it will eventually work when they go to the 100+ developer company. They don't necessarily know this when they go to the 6 man team.
In fact, one of the primary reasons you hear so much more about the 100+ developer teams is because often the small startup will simply go bankrupt when the contract fails. I'm currently working on fixing one such thing, I can't tell you much more than that, but lets just say, that the 100+ developer company would've been the wiser option.
Now, sometimes you do get the better quality, the faster deliverance and the better product form the 6 developer startup, so it's not like you're wrong either. It's just that most decision makers hates risk.
ps. Sorry IBM.
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.
The main obstacle to this IMO is poor leadership attitudes & practices. This article's author said it best in another post:
"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."
Stars are a thing, they are way beyond what the average dev can ever accomplish and they would only be held back by a team. They should be catered to and really be accountable to nobody as far as technical decisions go. Their time and energy is just too precious to be spent soothing your fragile egos. And that's not just my opinion either. That's why companies have positions like fellow, distinguished, etc.
The whole "rock-stars are toxic" is just the inability of some people to accept their limitations. Most of us are nobodies, easily replaceable code monkeys who will never accomplish anything of note. If you're of the opinion that a nice personality somehow is worth more than being excellent you are lying to yourself first and foremost. And you're not that nice anyway since you are willing to spend your time digging through stars' closets in the hope of finding any skeleton to bring them down.
Being agreeable only qualifies you to easily being worked in what are essentially sweatshops who produce crap, the subject of the article. Take note though that said sweatshops would not exist without the stars that CREATED this industry. Never in a million years, you and your team of "nice" people would have produced any of the foundations of current IT.
Same thing with math academy honestly.
There are 10 types of people in the world . . .
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.
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.
not really sure if this is helpful, but i see this take way too often on here. i’m convinced people who say this about the film and media industry don’t go out of their way to find good movies and listen to good music because the amount of high quality, hard to find stuff being made today is honestly amazing.
Well, sure, but to the contrary: DC has had a much harder time imitating Marvel's success, even with great IP. Universal tried to create the "Dark Universe." And even Marvel is having trouble cranking out the hits with the middling success of Ant-Man Quantumania, Thor: Love and Thunder, and Wakanda Forever.
I suspect making these things more streamlined and more of a flat cultural paste through the Disney Machine is a part of the lower outcomes.
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.
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.
To piggyback on this, I see many coders of this level of talent in many different fields all working on their own projects that are sponsored by Patreon or similar, rather than taking traditional employment with companies in general.
I much prefer ninja, rockstar, magician, sorcerer, codebro, gnarly dude, big daddy for loop, Little Bobby Tables, SSHelley and Nadine.
Nadine doesn’t have a buzzword she’s just really good with Kubernetes.
Anything but 10x-er.
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.
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).
I think there are plenty of examples of amazing software coming out of small teams or even single developers and plenty of examples of large corporations producing garbage with huge teams.
> we want to do things right in a way that will be robust long-term.
If you don't have the right people that know what "right" is and have seen projects through the long term then this is often used as an excuse to over-engineer and do work nobody cares about. At least that's my experience.
Never seen a place with worst technical debt, complexity and just difficult to work in.
I am convinced that commodification is what is actually causing all the issues we are seeing.
A bunch of mediocre developers getting in the way and creating complexity without any creativity, out of the box thinking or even holistic view of the system.
But management wants more people so that everybody can leave and not holding the company hostage.
Guess what? It is only worse. Very few people can actually make progress and those people are constrained by the whole team around them.
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.
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.
Was is painful, tedious and boring?. It was, also.
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.
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.
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.
There are intense opportunities today like they were in the past. But they are hard, like it was hard in the past.
Some of those jobs surely had creative aspects to them … far more creative than the recent YAWS (yet another website) using ASWF (another shiny web framework) with all the bells and whistles included.
Employers don't want rockstars, they want underpaid, overworked workers.
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.
Things that some people enjoyed using and other people enjoyed creating.
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?
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.
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.
i hired this person from HN "who wants to be hired." they still (to this day) add a post to the monthly thread.
I guess they were a rock star in the "Led Zepplin trashing a hotel room" sense.
Now it makes sense
Not that you can't work as an independent "creative" in programming though.
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.
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.
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.
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.
she showed me the very nice hotel that they would be putting me up at until I found a place. no hurry really. one of my new coworkers was still there after a few months.
we went back to the office for tastings. coffee. wine. beer. whiskey. it was important that they knew my tastes and would have my preferred food and drink on hand.
i know that was the point - but I certainly felt like a rock star.
I once got flown out to Shanghai from NYC, all expenses paid for 3 nights to interview for the China operations of an European tech company.
I guess everything is now different with remote work but before the pandemic companies, especially your prospective manager, would go out of their way to make you feel good if they really wanted you. Those were the places you wanted to work, even if the salary was higher somewhere else, because you knew you would be privileged and respected before even stepping in the door. That meant getting more resources, having more leeway and freedom to do what you want.
I also get the feeling hackers and "creative programmers" are not as valued as much in today's market. Managers want "I" shaped as opposed to "T" shaped hires.
Any sources for this claim?
https://news.ycombinator.com/item?id=36377805
Ok technically 10 days, but still.
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.
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.
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.
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.
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.
I’ve been making this point for years. I think it’s telling that other nearby disciplines are bifurcated. Electrical engineers vs electricians. Architects vs builders. Etc. The virtues of a good electrician are that they’re reliable, have good customer service and they work efficiently. A good building company can bring a building up in time and in budget. But beautiful architecture work doesn’t share those values. The best architecture is bold and creative, and still has people talking years later.
I think this split already exists in programming. We just don’t admit it to ourselves. It’s different work inventing React vs using it to make a website. Inventing react, or rust, or redis requires considered boldness. It takes time to nurture the right insights to make it right. In contrast, the virtues of a good web consultancy team look more like the virtues of an electrician: Good customer service. Clear estimations. Work delivered on time & on budget.
But we’re so enamoured with the idea of ourselves as “elite hackers” that clock in / clock out programmers can’t give up the mantle. I get it. But it’s stupid. There’s no point evaluating candidates on their ability to reimplement a btree from scratch if their job is to style buttons. You’re evaluating people for a different job. Test their software estimation skills. Their social skills. Ask about workflow and productivity.
Essays like this one ask “where did all the hackers go?”. They’re still around, they’re just harder to find now. They went into weird crypto projects. Llama.cpp. Obsessive database projects like scylladb. They’re inventing rust, and finding security vulnerabilities in io_uring for that sweet Google bug bounty money. They’re in the demoscene or making programmatic art for burning man.
Do you need real hackers at your company? It depends. Are you making an apartment building (on time, on budget) or the Sydney Opera House - which is iconic now, but was almost never finished because of delays and creative disagreements? They aren’t the same kind of work.
Damn, that burns. It’s true though.
> Two, the software talent market is bifurcated. There is basically commodity development of crud apps, and technically complex novel development.
This I think is the source of most of the wheel invention. Someone pays a good deal of money for 'talent' they do not actually require, and they end up working at cross purposes. Assign someone with cleverness to work on a crud app, and they're bound to try to reinvent something, if not to keep their resume fresh, at least to fight the boredom.
But it's not bifurcation, it's trifurcation. It's not build or invent, it's build, buy, or invent. We are too many of us writing applications that were never really needed in the first place. Not for any single reason, but a whole host of them, from empire building, to rent seeking from people who could have made a tool that adapted well to customers, but saw much more money in keeping them engaged with you instead of operating on their own steam. Open source is also driven by a lot of motivations, but 'your own steam' is a pretty compelling one.
https://en.wikipedia.org/wiki/Winner-take-all_market
I agree with bullet points about keeping it simple and not using crap tech for your MVP.
It also exists in a much more banal state lower down the ladder. I have friends who landed in the low end of the developer market. They literally cannot do most of the work I do. They don't understand DB isolation levels, they don't have the skills to design systems around eventual consistency, they are not familiar with basic distributed system problems like clock drift, etc. I'm not even an infrastructure engineer, this is just stuff I and my coworkers need to get through our days to ship product code.
Could my friends do this stuff? If they applied themselves, sure! But they're not going to. It's also not enough to learn on the job. We occasionally hire someone who doesn't actually have the skillset and they usually flounder.
"Knowledge worker productivity is the biggest of the 21st century management challenges." - Peter Drucker (the founder of modern management)
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.
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.
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...
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
Some industries you either are the top 0.01% and make millions; in some industries being average means a decent living.
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
Like other sports, it's fun enough that many play it for free at local tournaments, and some families can afford pay expensive flights and stay abroad.
I recall meeting with sportsmen and travellers who do months-long trips across continents. Half of them were pensioneers and just one single guy was a 34-yo die-hard traveller riding a bike across Eurasia for its own sake. Others were professionals, and they'd say they'd been preparing the travel for 2 years, seeking sponsors -- some in equipment, some in money, -- and signing contracts and clarifying sponsorship activity details -- photos here, report and booklet there, etc.
This contrasted a lot with our IT industry "let's do it for fun or learning" spirit.
Makes it much more difficult to parse when you say "either" but only provide one half of that statement.
Why is it they can follow a recipe to kind of make a mint birthday cake but they can't point at a picture of a cake on a picture menu and say "that one!"
Sometimes I think they don't actually know what they want before they start. And as the script evolves, like finger painting, they start to kind of like the blobs ...
But, I dont work at a software company. I just work at an enterprise with a large IT department.
They point at the picture of the birthday cake, and they receive an apple pie and cannot figure out why. You have to read the documentation to understand that standing on one foot while pointing makes a difference.
Declarative tools are easier when you understand the domain. Otherwise, problems arise because small changes in the requirements can result in huge changes in the outcome.
They could. They just don't want to, because it's not as sexy as writing code. If you can't do it in Python, from scratch (lol with a lot of modules and very little exception handling), it's clearly inferior and a waste of time to learn. Their intent is to write code, not get things done!
They don't learn how to write shell scripts either. I'm sure they will go their entire lives without ever reading the man page. But will read a million bad blog posts about Python and take from them the worst conventions from mediocre programmers trying to get eyeballs on ads.
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.
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.
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 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.
I'm hoping higher interest rates may revive the older style: https://news.ycombinator.com/item?id=34565816
Don't know how many musicians you know, just ask one...
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.
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.
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 different software and call that "better". Even though it's doing about the same thing as before, less efficiently.
Nothing personal, but you are who I'm talking about when I say nerds who just like to build toys in the sandbox. I don't think you intend on improving technology, or making a better product, as much as chasing that tickled feeling of sitting and writing. It's just amazing to me that people still get paid very well for effectively writing a copy of a copy of a book, while most fiction writers barely scrape by. You'd think the people paying us would just use the last book and not pay you to write it again, or demand it be better. But we're all fine with photocopied monotony.
> 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.
> 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.
"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.
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.
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.
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.
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.
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.
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.
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.
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.
> 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.
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.
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!
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.
Not my area of expertise at all but, 35 engineers for WhatsApp sounds like a lot
Regarding WhatsApp, I would say that 35 engineers is OK. Not so much, but not so few also.
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.
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.
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.
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.
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.
If you want a different view on your code: write one. Code is the model. Presentation of code in an editing UI is the view.
Tools like gofmt normalize the model so that it's easier to build a view that re-represents it.
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.
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.
I do wonder sometimes if there's something about living in SF or NY that makes you forget how tiny your perspective actually is.
> we prevent any Taylor Swifts from ascending
So... success?