Good times create weak men (2019)
tonsky.me
tonsky.me
Because of the mythical man-month.
Apple's operating systems have grown from just iOS/macOS to include ipadOS, watchOS, tvOS, visionOS, audioOS with a myriad of new capabilities. They are also behind the scenes migrating a lot of older Objective-C code to multi-platform SwiftUI which explains why Music.app in particular has seen so many regressions.
Now their development teams have grown but not proportional to the overall scope. And that's not going to change because teams simply can't scale linearly for ever and Apple likes smaller teams. So there are inevitably going to be far more times where quality ebbs and flows as priority shifts.
But hey that answer is only a paragraph and not a provocative answer about society collapsing, men getting weaker or some other incoherent nonsense.
Its wasteful and sloppy ultimately and makes it hard to be familiar with their actual range of products in tangible way
Shareholders: I would prefer to not watch my kid die of leukemia. And it would be nice not to have to replace my dishwasher every three years. And while we are at it...
First, to make it easier to reason about, assume that with any given thing, what you go along with becomes commonplace and is done by everyone, all the time -- and if you resist, it is not done by anyone. (On smaller scales, especially 1-on-1 relationships, this might be literally true, so)
So, for example, you can increase profits a bit by making your website take 2 seconds longer to load for the benefit of JavaScript fuckery. Never mind privacy, just load times. Now, in the universe where everyone mirrors your actions, now every website you load takes 2 seconds longer to load. In some cases that means going from 20 seconds to 22, so no big deal... but HN goes from 0.1s to 2.1s, hah. Can you imagine how much time that would take up, for maybe not even that big amount money, that can't buy you time?
Or advertising, propaganda, etc. Yeah, you can sell your thing for more, or to people who don't really need it or would be better off without it... but unless you have a huge corporation, you don't even have that many products, yet now you live in a world full of advertising, and the pollution, waste of energy, and bad choices of people you love, or maybe people who end up hurting you because of the shit choices they made based on propaganda.
You can make "sponsored content", sure. But now philosophy and deep thought are dead, because everybody else is lacing whatever they say with a nod to some sponsor.
I really wish I could describe what feels like this hugely important thing that is kind of invisible to us, because we have nothing to compare it to, or the time or resources to carve out a large enough space in which to be different and then compare the results. If we only could see (I can't, it's more like a hunch, something I can't put my finger on but also not shake off) how all these things add up, with a kind of bird's eye view...
I imagine it would look like a local optimum, right next to a HUGE optimum. Like thirsty people fighting over a stone to suck on, next to a lake with clear, fresh water, unbeknownst to them.
I just cannot fucking prove it and that hurts :/
This is what government is for. Should be for: should be doing.
I don't mean at the micro-level of regulating website loading times: that would be ludicrous. I mean at the macro-level of guiding society away from harmful equilibria. I can't suggest policies which will accomplish all of these, and reasonable people can disagree about implementations. That's OK: so long as we are aligned on that purpose we can iterate on attempted solutions. With that said, here are some harmful equilibria to address, and at least a top-level approach to take, or goal to set:
- Carbon (and other pollution and waste) taxes which internalize costs that are currently born by everyone, in order to profit a few.
- Privacy protections which make business-models built around surveillance and micro-targeted advertising impossible.
- Corporate governance and financial market models which discourage short-term "line goes up" thinking.
- Tax structures and business regulations which encourage research and development instead of stock buy-backs, and increasing workers' wages instead of executive compensation.
I'd bet that at least a couple of those would improve website loading times, too.
Stop taking away my skills. I have to relearn everything all the time, for no damn reason.
And get off my lawn.
So that people who have bought an iPhone and buying a Mac for the first time can change their computer settings in the same way they are used to on their phone.
It’s as if knowing how to use Apple products efficiently has developed into requiring a very specific domain knowledge, and Apple continues to develop for these pseudo experts that know the quirks rather than improving the intuitiveness and usability for those less familiar.
And it makes a ton of money!
I agree with all the complaints about the state of a lot of software today but users don’t care enough to start boycotting companies that make apps in Electron. Until they do shareholders won’t give a toss.
If the average person understood how shit tier software is today, they would care.
Nobody likes dropping a couple Gs on a new laptop because the software has become so utterly shitty that their 2 year old I7 and GTX 3090 with 32 gigs of ram can no longer run a web browser.
I think if the general public knew that their stuff getting super slow super fast was a product of software rather than hardware degradation, theyd definitely care.
But my point is this: they don’t.
This a byproduct of a much larger issue that affects all faculties, not just the tech sector. This won't change unless we as a nation choose a different economic model.
The thing that capitalists get wrong is to simply project the present into the future, forever.
Let's say you get 30% returns in 10 years, that is 2.65% interest. But we might be talking about a one time investment that only existed for those ten years. What happens before and after can diverge arbitrarily. Meanwhile a capitalist would just keep projecting 2.65% interest into all eternity, giving ridiculous numbers within 1000 years.
The thing about simple interest is that it gets consumed. No exponential growth necessary.
It's interesting that Orwell got this one wrong: turns out that endless war isn't necessary as a sink for meaningless production after all. We can do that just fine on our own.
Meanwhile Russia can't generate domestic demand. They got their GDP growth from their war industry.
Its not only possible, its happened multiple times, but downplaying it (Syria recently) or outright pretending it wasn't happening when both sides were fully aware (Korean war air combat) have been part of managing escalation risk.
Since then U.S. waging wars and launder money out of pockets of tax payers into conflict zones it created and back into its own industrial military complex. Here is some punchy whataboutism for your, deal with it.
> War is a way of shattering to pieces, or pouring into the stratosphere, or sinking in the depths of the sea, materials which might otherwise be used to make the masses too comfortable, and hence, in the long run, too intelligent.
-- George Orwell
> Every gun that is made, every warship launched, every rocket fired signifies, in the final sense, a theft from those who hunger and are not fed, those who are cold and are not clothed.
> This world in arms is not spending money alone. It is spending the sweat of its laborers, the genius of its scientists, the hopes of its children. The cost of one modern heavy bomber is this: a modern brick school in more than 30 cities. It is two electric power plants, each serving a town of 60,000 population. It is two fine, fully equipped hospitals. It is some fifty miles of concrete pavement. We pay for a single fighter plane with a half million bushels of wheat. We pay for a single destroyer with new homes that could have housed more than 8,000 people.
> This is, I repeat, the best way of life to be found on the road the world has been taking. This is not a way of life at all, in any true sense. Under the cloud of threatening war, it is humanity hanging from a cross of iron.
-- Dwight Eisenhower, https://www.americanrhetoric.com/speeches/dwighteisenhowercr...
With all that said, I think the corps are happy to have both. All the appearances of new New NEW and for anyone who’s paying attention, we will upgrade when necessary. But in between are a bunch of people who can scrape up 2k for a new phone every year. Like buying a Cadillac when you can’t afford a house.
Nope, it was the three camera lenses. Oooh. I liked me some photography.
> But hey that answer is only a paragraph and not a provocative answer about society collapsing, men getting weaker or some other incoherent nonsense.
But The Mythical Man Month is about communication/knowledge transfer, just like the linked article and it’s video.
You also said a some regular stuff about teams and schedule pressure that weren’t novel at the time of The Mythical Man Month.
e: I understand not liking the style of blow’s doomsaying, or titling a blog post with a reference to a meme that gets some people salty. But those aren’t the thesis of either piece.
The Mythical Man-Month has more than 1 theme.
And this article isn't about communication and knowledge transfer, it's about the evils of abstraction. I'm not sold on the idea that layers of abstraction are always going to be problematic—most of civilization is built on layers upon layers of abstraction, with different people specializing in different layers. That makes things less simple than they were before the layers were added, sure, but it doesn't inherently make everything worse.
After 100 years, a 0.5% efficiency or emissions reduction gain on the internal combustion engine costs likely as much as the first 20-50 years of exponential gains made. And so Volkswagen cheats.
Moores law is strained so we do wild branch prediction to meet the expectations and eventually roll back entire processor generations with mitigations. But executives got their bonus already at that point
The enshittification is built into our world as a result.
Sorry, but this is objectively not true, having been subscribed to Apple Music for years prior to SwiftUI. It was always extremely bad relative to Spotify and the first regressions started when Apple dropped the standard iTunes UI in favor of embedded webviews.
And to be clear, the issue wasn't "web tech is bad", it was that Apple Music design team has been rudderless and disorganized for years.
> "That’s different. This western-front business couldn’t be done again, not for a long time. The young men think they could do it but they couldn’t. They could fight the first Marne again but not this. This took religion and years of plenty and tremendous sureties and the exact relation that existed between the classes. The Russians and Italians weren’t any good on this front. You had to have a whole-souled sentimental equipment going back further than you could remember. You had to remember Christmas, and postcards of the Crown Prince and his fiancée, and little cafés in Valence and beer gardens in Unter den Linden and weddings at the mairie, and going to the Derby, and your grandfather’s whiskers."
> “General Grant invented this kind of battle at Petersburg in sixty- five.”
> “No, he didn’t — he just invented mass butchery. This kind of battle was invented by Lewis Carroll and Jules Verne and whoever wrote Undine, and country deacons bowling and marraines in Marseilles and girls seduced in the back lanes of Wurtemburg and Westphalia. Why, this was a love battle — there was a century of middle-class love spent here. This was the last love battle.”
[1] https://www.goodreads.com/quotes/9044972-see-that-little-str...
If he is correct, then it refutes the proposition that prosperous societies are "soft".
I think there's an additional aspect, though: insufficient supply of "people who care" coupled with compensation levels attracting too many people who don't. That maps better to the weird title, I suppose.
You can care as much as you want, but if the people responsible for making the final decisions and cutting your paycheck don't care, your ability to write good software in that place is limited.
Down your road lies early burnout.
You can argue that's, "not true Agile," but then... what is? The process being forced upon developers the world over or the ideal version you have in mind?
I agree, as described, it generally leads folks to burnout. And anecdotally it seems most organizations are fine with that.
On the other hand, the way the term "agile" is used now really has no relation to anything in the agile manifesto.
And this is in part due to ignorance (people adopting agile trusting that their "scrum certified" trainers know what agile is instead of just ... reading the short manifesto), in part due to how (intentionally) vague agile is, and in part due to complacency of the people who _do_ know what agile is not pushing back more against the idiocy.
I don't think you can blame people who happen to have actually some clue as to what agile was supposed to be repeatedly complain that the crap which most organisations implement and call "agile" has nothing to do with agile.
I like terrible analogies so here is one:
It's akin to finding a paint bucket in the building supply store marked "red paint" and finding it filled with blue paint, and then when you go to the store to complain, they say: "but this _is_ red paint, you will find the same colour paint in these buckets in _every_ store". Then when you do a bit of research you realise that the only reason this happened is because people who really liked to paint walls blue heard about "the red paint craze" and started calling blue pain red to avoid having to change the colour of their walls.
Why should we stand for this utter nonsense?
My comment has the flavour of a, "no true scotsman," situation but it's not necessarily, in my view, a matter of calling a spade a spade.
The problem is that the spirit of the manifesto is a socialist one which runs counter to how capital runs businesses. The manifesto says "we," meaning the developers doing the work, should prefer customer collaboration over negotiating contracts. However most developers in most companies do not have the power to enforce this preference. The executives, founders, and managers sign the contracts. The developers are hired to write the software. There is no negotiation: your team doesn't meet their deadlines people will start getting fired or the business will go under.
"Business people and developers must work together daily," they sure do. Every stand up, every morning, to tell the manager/lead what you did yesterday, what you got stuck on, what you're going to do today. "But that's not how it should be," well... again, what should it be? The manifesto isn't prescriptive about this. Agile-as-practiced is what we observe teams and companies doing out there. This is often how it's done.
Individuals and interactions over processes and tools? What part of agile-as-practiced isn't about processes and tools? Capitalists love processes and tools ever since they brought their own clocks and bells into their factories and started docking people's wages when they didn't show up for work on time. Planning poker, retrospective meetings, kanban boards... all processes and tools.
No businesses I've heard about or worked at have enabled developers to self-organize. This, again, would be anathema to how capitalists expect to run businesses.
The other problem with the manifesto is that it's starting to show it's age. "The most efficient and effective method of conveying information to and within a development team is face-to-face conversation," is a good way to ensure that your later maintainers have no idea how the software works anymore... and hasn't been true for decades: most of Linux and much OSS is developed by remote teams who've never met face to face. Writing is generally considered the best way to pass on information and it has been quite effective for a good portion of human civilization.
We have carpenters under capitalism and the companies hiring them don't force them into stand-ups every morning with some guy who has never nailed two pieces of wood together who insists on following a rigid process of chopping up the work of framing a house into sprints, user stories and story points.
I actually don't work as a programmer anymore (instead as a security consultant) and suffer no micromanagement (in fact, almost no management at all). I think this is just a unique nonsense which has developed around the practice of programming.
Genuinely whether I am working on a project individually or as a team, myself and my teammates get complete freedom of how we go about doing our work as long as we uphold certain standards and produce certain deliverables. This definitely seems possible in the world of software development.
Begone with the naysayers that keep deriding our objectively pure implementation of AGILE.
Okay, okay, I can't anymore, its too much, I agree.
So how about we just fight fire with fire. I propose a new religion named JOUST.
I don't have the energy or time to invent more than the name. Use AI to create the system. Start amplifying the signal that JOUST is the new AGILE and soon, we will have a new word for micromanagement.
I have seen two distinct implementations of AGILE and neither has left me thinking that anything was gained.
I also have a deep resentment for the word sprint. Sprint means go at the fastest possible pace, yet there is no downtime in between sprints?
Bad analogies are great. Show me a cheetah that sprints 5 days a week for 9 hours a day with 2 days of "rest" in between.
Always has been. There's nothing wrong with the manifesto as some food for thought. But the moment people started calling their development process "agile" we were all fucked. It became a brand.
The core con of agile is that there is something under the covers as long as we push beyond doing it wrong.
There is no there there.
The manifesto says: Along all the dimensions that exist in software development, here are four dimensions where the common practice in 2001 are wrong. Any other meaning is invented while interpreting scripture.
This is essentially what my sibling comment boils down to! Kudos for putting it more succinctly than I.
"Making the team more responsive to changes" so they can start "delivering increased volume of (often poorly specified, decided on the last minute outside of quarterly planning ceremonies because it will make the engineering middle manager look good to the CTO) work" has been my experience with agile everywhere I've done it.
Why would any publicly traded business pick a development model that _decreases_ the volume of changes?
Agile is about being responsive to changes. And yeah, the bad specifications are included. Anybody that makes it about volume of work is dishonest (but I do agree that's the norm).
We should not let dishonest people bastardize our language to the point we can't communicate. And the most obvious way to fight back is to call them on their lies.
(And yeah, it's implicit but it's very clear that agile is supposed to decrease the volume of work. You can't decide to optimize for something else and not suffer there.)
To you and me, yes, that's a true statement. To the business, it's not. Being "responsive to change" means we're constantly polishing the turds the CTO-adjacent crowd has laid, and we do no service to ourselves by pretending otherwise, or trying to reclaim the language of "agile".
You seem to have an emotional issue linking those concepts. They are all different things. But yeah, lying about what you do is harmful too. The top management not wanting to solve real problems or making real products is about as bad as any other kind of management failure.
Hey, I wanted to thank you for this comment. I was really tilted yesterday about adjacent issues and was inadvertently bringing that here. Your comment made me take a step back, look at what I was posting, and stop posting while I was emotional.
Thank you.
If you hire the best in a narrow sense, you get people who find problems where others wouldn't. That's fine in theory but it becomes downright crippling if these people don't understand where their output falls in terms of the final value delivered to customers.
You end up with organizations where precious little ships, and it's usually a crappy product because every team was convinced their little nugget needed to be perfect, and eventually market forces forced them to shove all their half-polished nuggets into a ball of filth.
Normally managers are supposed to be a counter for that, but at engineering driven orgs they just get sucked into the games too.
I don't think there's a specific number that makes a software team suddenly "too big", but you can clearly see how different the dynamic is when you're in a team that's too big
So you could argue that Linux in reality is developed by only a handful. The orbiting thousands of developers is the force multiplier. Once in a while someone drenched in the culture slowly dissipates to the inner circle. That's how it survives. By way of a strong culture. The downside is that it can also be a bit unforgiving.
Linus style of project leadership is quite well known, but the guy has very good taste and is in it for the long run. That's the secret to making it all work. That, and the luck of being at the right place at the right time.
I figured none of these things stopped me from paying them, so they have no reason to fix them.
But like the PDF with the HTML on it--no one even looked at the output. No developer, no QA, no test users. Or if they did, they didn't care. They just shipped it.
I'd have been embarrassed, but since having a dev fix it would apparently be a net loss to the company, it would have been wrong to do.
And you're right, most companies tier their application importance. "Does the business die if this doesn't work" gets the top tier. "Does it make us money" comes next. Then after that point the amount of oxygen left in the room starts dropping significantly.
And you think "Well, if I was working on that low tier project, I would want to do a good job". And that's the thing, if you start doing good work there, you're going to get yanked off that team and moved up to something more important. You end up with either a dead sea effect on unimportant projects, or so little time for them it cannot possibly be polished.
I _wish_ the quality were better, but I can totally see why "good enough" is king, especially when times are good.
Introducing bug fixes may ship additional bugs. That's a real risk.
The scale of the system needed to get you and your luggage flying overseas in an economically viable way says a lot about how amazing the current system is. But sure, complain about HTML tags being printed and assume you could do better.
I appreciate the scale of the system. If your argument is that such a large system cannot be more bug-free than it is, we can just agree to disagree.
But if you're saying it's not worth it financially to fix these bugs, then we can at least agree with that.
Fast forward a few centuries, everything is being automated, and what happens...
Or it was fixed, but not commited
The fix wasn't the right fix, or applied to the right place, because the bug report was bad
The fix worked on the tester's device
It worked, but was broken by another fix
It wasn't checked again after it was 'fixed'
etc
There is more software being produced now, all the time, then there ever has been before. It just has to be good enough. There are javascript errors on the page? But does it mostly work? Then just forget about it. The whole thing will get rewritten anyway next year and then there will be new bugs to ignore. That JIRA backlog will never go away.
This may sound pessimistic but I'm just being pragmatic. Software has bugs, and now all around us there is a crap-ton of software all the time. It just has to be good enough. Or even 'barely good enough' will do in a lot of cases. This is how the world works because producing perfect software is ridiculously expensive.
By your dint of logic, we could have just stopped programming tomorrow altogether and most of the things would be just fine, and we could spend all this huge amount of human effort on something else (something presumably more important). That'd be quite pragmatic, wouldn't it? So why do we not?
Even if you dont want to release an upgrade, the layer below that you rely on still will, and then you'll have to keep up.
Docker is really useful though. It let's you run a completely different set of software than your os stack without the overhead of virtualisation. I find it very useful and I learned programming with basic and 6502 assembler so I have no problem understanding all the abstraction layers down to metal.
As for electron it's just a Web browser packaged as an app.
In general I agree that "good times create weak people (not just men)" But I very much doubt we can blame the current state of software quality on "good times".
Perhaps some of it can be blamed on the fact we didn't really have to optimise a lot of software for performance because new faster hardware would become available like clockwork.
But the main problem of today's software quality is not slowness, but as the author shows, crappy ui design and implementation. I have my own theory why that is.
Its "agile". Yes, there is good stuff in agile, but designing the UI for an app the user interacts with all the time should be properly designed from the start with a lit of forethought. Not split into 2 week long sprints and 3 day long features people are pushed to undervalue time required for.
If we do that, this is the result. If you're a startup running out of cash go for agile. Of you're making devops tools go for agile, but for the UI design? No way.
Anecdotal experience/rant: UX designers seem to increase complexity (maybe to justify their position?) of apps, rather than simplifying. And often "common sense" loses in favor of an over engineered solution.
Lets say you have a population of 1,000 people and 1 doctor.
Then lets say you increase the amount of doctors to 3, but by that time your population is 5,000. Yea, you have more doctors than ever, but you also have more problems than ever. And we also see in the medical community more people want more treatment for more things. More staff, less time.
It is really easy as the end user to say "Oh, I could have made this much more simple for my workflow". But that's the thing, it's your workflow, you have no idea if that's the average users workflow. You have no idea if the 3% of the customers that pay by far the most money have a different workflow.
Complexity typically increases and keeps increasing till market saturation occurs. It's very unlikely we're anywhere close in software saturation (hell this could involve near complete replacement of people in most jobs). Competition means even if you want a simple app, another 'simple' app but with more features is apt to out compete you.
As for Electron, I don't need to install one browser alongside each app.
Electron isn't the problem here. And neither is JavaScript (well, TypeScript--JS itself isn't great). If anything is, a combination of competence and scheduling are the culprits.
It is not an accident that Swing only survives as toolkit for developer tooling, and Java is mostly relevant on the server.
Even on Android, the devices are more beefy than iDevices for a reason.
The better approach is to put out something crappy as fast as possible and then ask real users for feedback. Iterate on this every 2 weeks until it's good enough.
That video and Casey Muratori's "The Thirty Million Line Problem" video
Similar theme, and really a call to action.
We, as an industry, need to fight entropy and chaos. Not through regulation or authoritarianism, just every one of us needs to take the responsibility and try to make things better
i don't say that to suggest it's unimpressive, but rather to point out that adopting his methodology of avoiding anything resembling modern languages and tooling comes at a cost. the cost includes a huge hit to productivity. if everyone built games the way these two suggest, there would be orders of magnitude fewer of games available. if everyone built software the way these two suggest, there would be orders of magnitude less software available. i'm sure they would be fine with that outcome. the rest of the world probably would not.
Your point still stands (there's research floating around proving it) but Blow isn't the best example.
The point being made is that your increased speed to market comes at a cost
Yes there are many applications that probably just don't need to exist but you can make a living cranking out
Not everyone should do any one thing all the time. But we have to be careful not to always discard hard work in favor of speed and convenience.
Jon Blow and Casey Muratori are reminding people to take responsibility for what we're doing. Learn how things work and be ambitious.
And that’s sad."
2019, but it still checks out.
For balance, he does make a good point about the upper limit of complexity and how hard it is to transfer the knowledge required to the next person doing the job. Perhaps if we normalized documenting everything to the point where someone new could just pick it up by reading the docs as well as get the time from the company to actually do it, there might be more incentives to keep things simpler.
Look, I complain about software quality probably more than most, but it's good to remember that it's more of an emotional issue rather than an objective one. I did not find his arguments about programmer productivity convincing. As a whole, software is doing what it's supposed to and, besides, it could have always been worse.
For the software argument, you don't need to know how to write a compiler or how the language itself was built to code any more. And that's fine.
The block of knowledge required to do software dev has simply shifted. Instead of low level, it's mid to high level.
About the software being bad part, I wouldn't really say it's on the devs. But rather as things became more cog in the machine, deadlines and rush work became The norm. Even if it's bad, it's expected to finish something by the marketing departments launch.
See cyberpunk on first release, clearly not ready at all, despite everyone working overtime for over a year. Yet, it was still released. It's not like the game devs didn't care, but rather what are they gonna do about it? Their all real option was to soften the blow as much as they feasibly could.
In contrast, there are certainly platforms where reliability directly affects revenue. They prioritize stability and speed, proving that near-perfection is possible when it's a priority. Finance, for example, has a fair amount of these.
This article simply highlights a common modern business strategy: understanding and leveraging user tolerance to prioritize resources effectively.
Edit: However, I will concede that I think nuclear annihilation is more likely. So in that case you would be correct by accident
Is that true?
What is the total number of cities today in a world of 8+ billion?
No cities in Australia were built on ruined former cities .. cities such as Dublin and London appear to have been continuously cities since their founding.
It's an interesting claim, is it one that you can back with any data?
[1] Pretty much the only things that survived were the tower of London and a few streets around The Cathedral of St Bartholomew the Great near Smithfield Market which most people even in London don't know about even though hundreds of people pass just one street away every day https://en.wikipedia.org/wiki/St_Bartholomew-the-Great
[2] https://www.london-fire.gov.uk/museum/history-and-stories/th...
I don't know what the natives in Australia did. however I can report without looking that if they had the numbers to build cities they would be about where the current cities are.
The "Great Fire of London" took out a large chunk of the city which allowed for a clean slate redesign and rebuild of a district - it didn't wipe out the entire city, modern London is vast compared to the original Londinium Fort.
The original quote, as given, was that most cities in the world were built on the implied total ruin of prior cities - I'd argue that relatively few cities (not most) were built on the smoking ruins of near total destruction (74 cities at least in Japan fit the bill, along with roughly that number in Europe) with most having a more organic growth based on a long series of partial rebuilding of districts in rotation.
Thank you for your advice - I did once work on digitising a few hundred years worth of city records some 40 years ago.
No, seriously, there's a saying that if construction engineers built buildings the way software engineers do, thousands of people would die each day because of buildings collapsing without any reason. Even if you build on the ruins of an old city, you still have to dig a hole that's deep enough (securing archaeological remains if necessary), create a stable surface with concrete piles or similar, and then you build a new building. You don't just stack miscellaneous boxes one on top of each other like in this XKCD (https://xkcd.com/2347/) and hope that they don't fall down...
I guess we're still in the earlier ages of software development.
To a large extent, I think the money to be made in Tech after 2009 has attracted kids to CS who in another time would have majored in business. The only saving grace is that the popularity of CS as a major seems to be drawing in talented women and minorities who haven't been exposed to programming.
99% of these "macho" people are just normal dudes who are pumped to the gills with propaganda. They have a pathetic need to convince as many people as possible that:
1. They aren't pathetic
2. You are.
It has as much depth as talking to an edgy teenage boy.
It's hard for me to imagine how times could get any worse. Maybe some Stalin-like mass purges of intellectuals...
I implore you to study a lot of history from all over the world. History you like, history you don't like. History of democracy, history of authoritarians. History of kings and of the elected.
And I'm saying this because while things may be bad for you, in general they are better for more people than ever. There is no bottom to worse, it can always get so much more worse than you can imagine, and that's even at the point where you believe it cannot possibly get worse.
It really does require understanding how things to go bad to make a world that gets better.
After leaving crypto, I saw opportunities dry up, people seemed to pull out of my projects for no reason, friends/colleagues I worked with closely for over 2 years stopped answering my texts, also for no reason. I also got fired for no reason after the boss had been praising my work for 6 months straight. Just a lot of weird stuff. Not sure if it's because cryptocurrency sector has stigma behind it or because of something more sinister.
Anyway, it's a mistake to think that things are good for everyone. There is a lot of nasty stuff going on behind the scenes. Many people's good fortune is built directly on the back of the suffering of others, often without them realizing.
Well, this could be part of the problem. The average person looks at this and associates it with a scam.
>After leaving crypto, I saw opportunities dry up, people seemed to pull out of my projects for no reason
I wouldn't say for no reason, SBF did a really good job of making anything even close to the coin world completely and totally toxic.
>Anyway, it's a mistake to think that things are good for everyone
I never said that exactly... I said on average things are getting better and just because you're having a bad day it is not a legitimate excuse to elect the next hitler and burn the world down. Making things worse is easy, making things better is extremely hard.
"How many?"
"Eight. I have eight bosses, Bob!"
Legacy Java Enterprise Edition projects are at the top of that list, and they keep coming back and haunt you years later.
The other problem is that C/C++ and Python have terrible build systems. I respect CMake, because it works, but the DSL and documentation is terrible. Using raw make is awful, because you need to generate dependencies.
Many of the bugs we see today in software are related to glitches caused by some deep framework, library or engine issue which most developers cannot make sense of and tend to hack around instead of fixing the root issue. When I started my coding career, most bugs were pretty obvious and easy to reproduce; some feature either worked or it didn't work. Nowadays, a lot of the bugs manifest themselves as vulnerabilities, strange flickering, state not being saved correctly or rolling back, app slowing down to a crawl after prolonged use, or weird issues that seem to rarely happen and are difficult to reproduce.
iOS has a feature called "Focus." Focus enables you to create different views of your home and lock screens and silence/allow calls and notifications.
iOS also has a basic automation framework called "Shortcuts" that lets you build workflows that trigger based on a variety of conditions.
two of these conditions is being able to trigger a shortcut when you start or end a workout on Apple Watch or when you start a drive.
These shortcuts fire maybe 30% of the time. When it doesn't work, it doesn't tell you anything about why it failed to trigger.
Every time this happens, I want to trade all of my Apple shit for Android and Windows kit. I almost did that today, even.
I would rather use software that doesn't have features than use software that does...but they don't work.
I frequently use timers to make sure I don't overcook the spaghetti or beans ("Ok Google, set a timer for X minutes"), and it works about 80% of the time, only to betray you with direst consequence.
And it's not that it's just not hearing me; it'll register the instruction and show confirmation on the screen, but then no timer actually starts.
Python is a great language to write things in. It's super popular and always getting new features. But it is one of the worst languages for people who aren't the developer to try to run what the developer wrote. It is just implicitly assumed these days that the system python install simply won't be able to install or run the dependencies the developer used. But it's not just dependency hell of a normal type. In python you need a dependency manager manager (conda/poetry/pyenv to a lesser extent) to set up the container in which you'll use your actual dependency manager in isolation (pip, pypi, etc) to try to set up the depencies needed for the python script(s) to run. An even within the multiple layers of management overhead python changes from version to version (even minor version sometimes) and a python script written 10 years ago won't actually run today and vice versa.
Perl is notoriously not a great language to write (and maintain) things in. It also no longer popular and doesn't get lots of new features. But it is one of the best languages for people who aren't developers to run what the developers wrote. The system perl on your distro will be able to install the dependencies without breaking anything and run the script, usually from disto repositories, but at worst from cpan which is universal. A perl script written today can be run on a system perl install from a decade ago and vice versa.
I mean, yeah, Amazon was never known for producing quality software. Yet, I insist, the task is SO trivial, it's so impossible to fail that it only demonstrates how bad people understand or control their tool.
Twitter newly rebuilt UI takes 7 * longer to load first tweet, giving you essentially the same stuff but much later and with much more effort:
I don't have numbers, but I've heard Gmail rewrite also made it much slower with no apparent new functions. It's still pretty drastic if you put GMail next to Fastmail, or Twitter next to Tweetdeck, both of which didn't get any full rewrites in the last decade, so you can see how fast even Web UI could be if we weren't constantly climbing up the abstraction ladder.
Docker and Electron are the most hyped new technologies of the last five years. Both are not about improving things, figuring out complexity or reducing it. Both are just compromised attempts to hide accumulated complexity from developers because it became impossible to deal with."
If you can't figure out docker and how it simplifies things, you aren't ready to write shitty think-pieces. As if manually installing things across 40 people's workstations is simpler?
It is really not that hard and shows a lack of experience and resistance to adopting new techniques, which is BAD for a SWE.
If you can't figure out Docker, you're pathetic.
---
Also hate the "Good times create weak men..." because it is implies an "unlike me" that I find very cringe.
I was free to use whatever I wanted to build apps. One of these makes over £150k annually, another one is has 700+ internal users.
My tech stack and process was the following: -Python-Flask backend -Object oriented plain vanilla JS frontend with Redux state management (yes, it works without React) -MySQL db -Docker -Good enough documentation to be able to hand it over at any point of time if necessary -Test cases for critical things -Deployed everything to an on-premise server with using WinSCP
I really enjoyed the whole process as I only had to focus on the actual business problem and very actively worked together with the stake holders. The results: bug free apps that I rarely have to touch; great satisfaction and feedback from both clients and internal users; short product to "market" time.
Recently I joined the company's dev team. Mate, it's hell. We have to use React for even an app that has a login page, upload page and report page. The db is Snowflake that makes everything freakin' slow. We have mindlessly have to follow the company guidelines to pass all the "cloud gates" before we can go live. We have to pass Snyk, Sonarqube, use Azure Dev Ops, dev-qa-prod environment, 80% test coverage, less than 3% code duplication (nobody cares if it screws up readability); use Jfrog and god knows what, there are 15 different criteria that we have to pass.
The result: extremely sluggish development; slow application; the whole thing can break at 10 times more places; and it does break; the process seems more important than the actual app that we are building; user satisfaction is awful; no time for running experiments or deeply explore the problem.
We add such a complexity to so tiny apps that I could build over 1-2 weekends that it suffocates the application itself.
I'm looking for the way out, I'm sure there are better places but I'm really thinking about setting up my own company where I could use more common sense. If it's a large app then let's follow a strict process but when it's almost like a toy project then let's keep it simple and only invest in sensible amount of energy.
I've seen here the post about John Carmack notes what he accomplished on a single day, I have never got close to that but I was so productive, adding multiple features on a single day and that made me so satisfied. And now it's all about the "gates".
Anyone got a link?
Common sense doesn't get customers. This at the end of the day is what matters. Not code correctness. Not perfection in the functions. Not how fast the application boots up/loads/executes.
Will anybody pay you for it and ever use it is the selection function that really matters.
These big companies have the users. The big companies also have insane rules (mostly to protect themselves from the massive number of incompetents they've hired). Welcome to the trap of modern software.
It probably is to them. You might be forgetting that large companies also have large exposure to liability, and so are more risk averse. The processes might have been put in place to reduce risk of such exposures, like security holes that leak customer details. If such large companies were populated only with good developers then these processes might be a waste of time, but how likely is that?
though it's a true saying.
the art of making software that works is truly, LOST.
yeah, paychecks are nice. but damn ... nothing works anymore.
all the big major tech companies with all their leetcode engineers can't make stuff that's simple and works.
the middle layer of tech companies is even worse. e.g at $job we can't even make search controls that work
on consumer apps - bugs everywhere. look at an app like hinge -- that can't sync your unread messages with a badge. such a simple problem.
I don't think it ever existed.
Kids these days... Back in my day nothing f*ing worked and we liked it!
I'd like to load up a PC with Win 3.1 and some of the apps back then and let people today use it. Not only would you realize how much software sucked back then, but it required rebooting the entire PC to get the thing functioning again.
Is that so? Elon has always been promising much, but rarely delivering.
Elon over-promises on deadlines, but he always delivers.
there are lots of valid criticisms of musk but thats just a cheap shot
> The Hyperloop concept has been promoted by Musk and SpaceX, and other companies or organizations have been encouraged to collaborate and develop the technology.[9] Hardt Hyperloop demonstrated a Hyperloop lane switch without moving components in the infrastructure in June 2019 at its test site in Delft, The Netherlands.[10] Technical University of Munich Hyperloop set the hyperloop speed record of 463 km/h (288 mph) in July 2019[11][12] at the pod design competition hosted by SpaceX in Hawthorne, California.[13] Virgin Hyperloop conducted the first human trial in November 2020 at its test site in Las Vegas, reaching a top speed of 172 km/h (107 mph).[14] Swisspod Technologies unveiled a 1:12 scale testing facility in a circular shape to simulate an "infinite" hyperloop trajectory in July 2021 on the EPFL campus at Lausanne, Switzerland.[15]
> In 2023 the European Committee for Electrotechnical Standardization released the first technical standard for hyperloop systems.[16]