Those are rookie numbers. With a little Kubernetes, we can get them way up.
So much of the incentive structure in software companies is to ship new features. Maintaining existing ones or fixing bugs is a career dead end for software engineers and managers. No wonder so much stuff is broken and slow.
Call me cynical, but from a dollars point of view this seems to be what customers want.
I do agree when we see broken outcomes (e.g. us healthcare, us public transit, etc) it’s good to go back to incentives to understand why things haven’t gotten better.
When perf time comes around, everybody knows the deal. Shipping a new feature is a much easier sell than a bug fix and looking like a hero for fixing a bug instead of preventing one is easier anyways.
I agree. I have to really fight people when I try to write robust software. "Why are you writing a proper parser when a hacky regex that I thought about for 2 seconds worked the one time I tested it? You're wasting time."
They don't understand that I'm not wasting time, I'm just choosing to spend a little bit of time earlier, because I don't like spending a lot of time later when debugging why everything broke.
The problem with a careful but non-methodical approach is that it requires the programmer to correctly determine the stability value of their design. We often overestimate the importance of architecture on stability, or worse, architect something that is harder to maintain than the naive solution.
With buggy ship-it-now software you have a known bounded risk - bugs will occur in some cases but the software will ship and the bugs can be fixed because it’s simple.
With prematurely architected software the risk is unbounded - the project may get bogged down indefinitely in its own complexity without shipping.
The inverse extreme can also be a problem, of course A project that is maintained for a long time on the naive implementation will also become unmaintainable. However, this will be due to _known_ architecture problems encountered during maintenance. These problems can be addressed in a relatively bounded amount of time. They are also quantifiable and thus explainable to management.
The specific case of building a proper parser doesn't take that much longer if you know what you're doing, and it also enables lots of wonderful quality of life features for end users through additional opportunities for automation and contextualization that can be surfaced.
Though, given the constant incentive to never learn how to write a proper parser does mean that practically nobody knows how to do it, and so it will always look & feel like an unbounded science project, and thus rarely done.
Infinitely recursive MVP'ing is a race to the bottom.
Particularly regarding parsing: Here's an excerpt from an interview with Anders Hjelsberg I heard recently. He's the creator of the Turbo Pascal compiler and later on of the creators of C#.
Sriram: I think there is some, we're going to talk later about things like GitHub co-pilot, we're dealing with different kinds of code reuse, but I do think there's a little bit of romance in the, for example, I idol you and folks like John Carmack. John Carmack noodling away and trying to make sure every instruction and memory access is aligned on some cash line. The amazing thing is, even today, if you look at AI at the heart of it, you have matrix multiplication and doing things with floating point numbers. Some of these things really tend to matter, which on the theme of optimization, tell us a story of Turbo Pascal 2 and you discovering hash tables because it's legendary.
Anders: [laughs] It is a funny story. You have to remember here that I am self-taught in the art of writing compilers. Now, I have since discovered and read a lot of the literature, but at the time, I was just coding away and doing it the best way I knew how. When you create a compiler, one of the things you have to create is simple tables, or they're not necessarily tables. They could be linked list, they could be whatever, but you have to look up names. When you're trying to compile a code that tries to assign one to X, well, you have to figure out where is X? What memory address have I associated with X? You have to look it up the declaration of X.
In Turbo Pascal 1.0, the first version of Turbo Pascal, all of the variable declarations were just kept on a linked list because that much I knew, but of course, searching linked lists is not particularly efficient when they get large. For really large functions, that would just take an awfully long time. Then, well, maybe you could try first go by first letter, and then have 26 linked lists or whatever, and that could help a little bit. Then I remember reading the literature about these things called hash tables actually in this book by Niklaus Wirth, Algorithms +, what is it? Yes, Algorithms + Data Structures = Programs.
A great book. He explains hash tables and I go, "Oh my God, that's amazing. I got to go try this." I went and implemented it and boom, the compiler went twice as fast. There's Turbo Pascal version 2.0.
[laughter]
Aarthi: Awesome.
Anders: There's a good reason to sell upgrades.
```
Do you really need a proper parser to sell 1.0? A literal compiler project did not fail due to the lack of a "proper" parser (though it can be argued that the lookup table is after the parsing stage; obviously there was not a strong distinction in the Turbo Pascal implementation between tokenization and compilation).
> With buggy ship-it-now software you have a known bounded risk
How would be the cost of bugs be known and bounded? A race condition in the code might not bother anyone ever in practice, or it might break down the whole system right as the most important investor decides to dogfood the product. In one case the bug can cause zero harm, and in the other might ruin the whole company.
How much was the "known and bounded risk" of shipping a buggy transactional model to the British Post Office? [1] It is "just" a buggy database, yet it cost many lives and sent many people to prison wrongfully.
> the bugs can be fixed because it’s simple.
Maybe? Have you tried in practice? Sometimes a buggy implementation forces you into a pathway where you need to spend inordinate amount of effort to get to a non-buggy solution. (This is the idea behind the term "technical debt".) Very often this effort is more than what you would need to do to just do it correctly the first time.
There are more choices than "ship-it-quickly and fix bugs later" and "over-engineer something complicated that ships later".
There are _lots_ of good practices which reduce the (potential) bug count without making things more complicated -- indeed, good practices serve to reduce complexity in design and architecture. Selecting the right data structures and algorithms, server-side validation, making proper use of your language's type system, choosing the correct type of database, writing some unit/integration/system tests, use caching judiciously, I could go on.
That was to make the point very clear. Twh270 is correct. There's a whole spectrum of robustness. It's a constant fight to push towards the robust end no matter where you are on the spectrum.
The other big one I constantly fight have to fight for is using type annotations in Python. It's a total no brainer and definitely not an extreme end of the spectrum. I'm not advocating formal software verification.
>The problem with a careful but non-methodical approach is that it requires the programmer to correctly determine the stability value of their design. We often overestimate the importance of architecture on stability, or worse, architect something that is harder to maintain than the naive solution
There is EXACT SAME PROBLEM with choosing to cut engineering tho. And the cost of getting it wrong is far higher.
If you catch a problem early, well you just wasted the amount of time you tried to save.
If QA catches the problem before you get it to the client, that's 2-3x the cost right there. 5-10x when it gets caught on production. 20 to near unbound when it causes some long standing issue that's noticed too late
>With buggy ship-it-now software you have a known bounded risk - bugs will occur in some cases but the software will ship and the bugs can be fixed because it’s simple.
>With prematurely architected software the risk is unbounded - the project may get bogged down indefinitely in its own complexity without shipping.
Not every software is a startup. If you have a requirements, first verify that they make sense in wider scope, then implement carefully while caring about potential edge cases. Not even handling them just making sure that they error out instead of propagate potentially invalid data further. That doesn't cost you even 2x the productivity.
> The inverse extreme can also be a problem, of course A project that is maintained for a long time on the naive implementation will also become unmaintainable. However, this will be due to _known_ architecture problems encountered during maintenance. These problems can be addressed in a relatively bounded amount of time. They are also quantifiable and thus explainable to management.
In vast majority of cases those end up as pieces of spaghetti legacy code that are worked around by the rest of the org, not fixed. "Fixing it later" is more and more and more expensive the longer it is in production and the more code grows around it.
Nowadays, I'm maximizing my salary, and the way to do that is please management by shipping features. There's no incentive to add tests or refactor code, and I'm not going to win this battle. That being said, over the years I've learned to appreciate the point for shipping fast. Sometimes it's the right thing to do, it's always a tradeoff.
> So much of the incentive structure in software companies is to ship new features. Maintaining existing ones or fixing bugs is a career dead end
Highly dependent on where you work and what you consider a "dead end". You can't possibly be talking about becoming unemployable in the industry nor even a pay cut. The situation for senior devs is the opposite, actually. Maintenance is the long tail of every project. If you're not doing that, you're not really working in software.
There is something like a paradox of automation at play, too. Both business and programmers are aligned on not wanting drudgery, but this means that a) we undervalue first-order work, and b) our automation reach often exceeds our grasp (k8s being an excellent example). Perhaps my thinking is colored by my recent read of Patrick O'Brian's excellent "Master and Commander" series of historical novels, about early 18th century English sailing ships, but the lack of automation is part of the romance - just to get from "here" to "there" required enormous effort. And who knows? Maybe if we take that approach we can press people into the software service by force, just like in the good old days!
> about early 18th century English sailing ships, but the lack of automation is part of the romance
The highly hierarchical and structured command structure of a ship means that autonomous and intelligent human beings each make autonomous and intelligent decisions on the best course of action in a way that doesn't require constant and immediate upper layer attention all the time.
The more limited amount of human beings required to upkeep a ship those days are mainly because of manpower shortage and cost reasons, not because the removed humans were "worse" at doing such operations.
Those automation flows are in my opinion the same thing, they're replacing things because of manpower shortages or high costs of the previous thing, not because they're better.
Dude on HN was describing the other day how they’re moving to use an AI to generate a list of cars with specific features in their inventory and how this was a great part of the AI future.
But as we see frequently even on the most sophisticated AIs, they get shit wrong… a lot.
So this company decided to replace an actually working, guaranteed to produce proper results filtering system with a guaranteed to not produce proper results an unknown amount of the time, and the feeling was that this was good business direction.
People don't want buzzwords, people want promotions, bonuses, and recognition. It turns out that producing working software is not the optimal way to obtain those things at a lot of companies.
And how do you get said promotions, bonuses and recognition? By introducing change. And what change is easiest? One that relies on established ground of buzzwords.
The helicopter view says that I need to implement my change and move on before the shit hits the fan. The next person to take over will blame everything on "the previous guy", quite rightly, but I won't care as I'll have taken my promotion and be to busy blaming everything at the new company on the previous guy.
This is the real “safety” problem with AI. Since it’s so good at generating convincingly wrong answers, eventually we are going to build it into all sorts of mission critical systems and and everything from finance to healthcare will start to accumulate sophisticated, non deterministic failures over time. Like a trojan horse or a perhaps a civilization-level virus.
For one person, at one point in time, sure, even though it'd be a quite complex one. But with an AI used by a thousand companies to replace one team member each, they're replacing a thousand of different "reward functions" with just one across all of them. A huge advantage of humanity is that we have different people, from different cultural and social backgrounds, all with social and personal norms and values that vary over time for each and every person, and telling an AI "imitate a pirate" or "answer without any biases" is not going to replace that.
It will be interesting to see. People are already involved in business-critical processes, and they have a far-from-100% success rate. You can see this with self-driving cars; 0.00001% of the time, they decide to swerve into oncoming traffic for no reason. But they can't get drunk! So whether or not that's a win is something that only time can tell. (People will be outraged, because no person would ever do what the AI did, but what matters are the numbers in aggregate. One could also argue; why should I have to put up with this when I never drink and drive? It's a good point and involves philosophical discussions about free will and all that.)
I guarantee people will be mad when an AI chatbot denies their insurance or customer service claim. But I have a friend who works in customer service and it feels like half her job is correcting the mistakes other customer service agents made. If the first line support was AI, would it change much, other than not paying people to make a bunch of mistakes?
Again, it's going to be painful while we try it out and get the data. It feels like it's going to be worse, and individual anecdotes will make each fuckup seem even worse than it is. But it seems inevitable that we're going to get the data. The only way to get VC writing software right now seems to be by tying your company to AI. That means a lot of experiments are about to leak out into the world. We'll learn a lot.
That's the great part about AI, because computers don't make mistakes, you can launder whatever biases you want through an objective and rational computer.
This is such an excellent way of concisely expressing a major fallacy I see whenever I talk about AI/modeling/etc. (I.e. “it isn’t racist it’s just numbers” and other nonsensical takes). I’m borrowing this language for the future.
That's a hopefully fixable organization problem. I think the closest we should let AI get to judicial decisions is suggested ranges. There still needs to be a person a decision traces back to, who's not just passing through what the computer says.
Ha. Human problems never get fixed, just moved around. There's nothing new to help get the racism or of the justice system - a core piece of the problem is that there are only disincentives for mercy and no checks whatsoever on individual biases. We still have a racist system in the US sixty years after the civil rights movement, and I don't see anything changing that anytime soon.
Tech problems sometimes get fixed, and occasionally either eliminate a class of human problems or create new ones. It's the only thing that changes... Rejecting tech wholesale means embracing the status quo.
There should absolutely be a human where the buck stops. But... "fixing an organisation" involves calling people racist. Then screwing their careers. That should carry a heavy emotional burden. It should involve anger and pushback.
"Some weights in an algorithm are wrong" seems a much less fraught problem.
We already have this today when anti-theft alarms go off at stores as you exit with your paid purchase. You're presumed guilty because someone didn't disable the tag since the robot can't be wrong.
> People will be outraged, because no person would ever do what the AI did, but _what matters are the numbers in aggregate._
That is an opinion, not objective fact.
If Grandma June accidentally hits the accelerator, jumps the curb and kills a kindergartener, we can throw her in prison. She is held accountable for her actions.
If Grandma June is sitting in her "self-driving" car and it spontaneously accelerates, jumps the curb and kills a kindergartener, what can we do? Who is held accountable?
Something something "fix the problem, not the blame", but accountability is part of fixing a problem. Improving numbers in the aggregate is good, but it is not (and should not be) the sole matter in discussion.
That is a strange example, because usually we don’t put people in prison for accidents unless there is specific type of gross negligence (e.g., drunk driving) or malicious disregard for life and safety.
> Anderson decided to plead guilty to vehicular homicide because she did not want the family of Karla Campos to endure a trial.
Maybe the woman knew that it would be revealed that she was drunk or had been told that she didn’t have the capability any more to drive safely, but she did it anyway. Without knowing all the facts, pleading guilty for an accident seems like a bizarre choice.
This is really not the dilemma it is often portrayed as. You can extend this problem to any instance where a man-made inanimate object kills someone, which we have centuries of precedent for. If a bridge collapses and crushes a schoolbus full of children it's not like we throw our hands up in confusion - there is a very developed legal process that will determine the whos and whats of accountability and punishment.
It isn't a new problem, it's something that every court handles on a daily basis. Rebar or autoregression, the core legal elements are the same.
We can try to provide decent transportation infrastructure with feasible alternatives to driving so that Grandma June doesn't have to operate a 2 ton death machine to live her life, but maybe that's getting offtopic.
Cherrypicked raw death counts are a lobbyist measuring scheme, not social science.
For example, if self-driving cars end up being prone to hitting children darting out on to city streets in new and unpredictable ways, then you have created impediments to the growth and development of children that did not previously exist. Would this be balanced by enhanced safety in other situations? Maybe.
These are complex topics like whether and how long schools should have stayed closed during COVID. Balancing the death and disability effects largely falling on adults vs. the educational interests of children.
That's true but humans are, or at least should be, accountable. When the AIs start making/contributing to impactful decision it will be hard to determine who to consider accountable for them (if something bad happens as a result).
Or, more mundanely, automated customer support systems that just cannot handle lots of edge cases. And they'll have shut off all the "escalate to a human" paths since most of the mainstream paths work ok-ish.
I'm pretty sure this doesn't generalize that well. I would say that people who don't use every day the product they are buying prefer buzzwords, but it's less true for people who actually use it.
The working list probably requires paying someone to keep it up to date. So the company is saving money by not needing that person with something customers may not notice is a degradation, at least not enough to switch companies.
I'm quite surprised how we still don't have fixed quality data formats that anyone can easily transform into every possible thing. Accountants should be analyzing records not maintaining them?
What many people don't seem to want to hear is that most "ML" problems are simple ML problems. LLMs are a neat advancement and a great tool in a variety of applications but for most applications they introduce a great deal of uncertainty and often at significant cost.
They're a good complement to great design and infrastructure but you're fooling yourself if you think they're a replacement.
I'm not sure it's exactly "what customers want" so much as it is the sweet-spot or intersection of the two curves: "what customers want" with "how much cost and risk owners and managers are willing to put in up front"
Add on top of that the perception that users need "wow" factor for everything. We can't ever have a full page refresh, even for something as simple as a blog or a storefront, despite most users being oblivious to when those take place. Everything's got to be flashy and overly designed. If it doesn't look like The Google designed it, then no one will use it!!! /s
> Call me cynical, but from a dollars point of view this seems to be what customers want.
I'm right there with you, except I don't give "customers" that much credit.
Most people left to their own devices (ie, not brainwashed by marketing) will just stick with "good enough." But it's less fun (and less profitable) to fix and maintain old code, so companies induce "demand" by marketing. And if you're a company who decides to do the adult thing and not play that game, you'll be creamed by the ones that do.
>Maintaining existing ones or fixing bugs is a career dead end for software engineers and managers
Strong disagree. This may be the case at certain "tech" companies, but I grew my career into CTO through maintaining existing systems and fixing bugs (and through doing the things no one else wanted to do). Amongst my fellow members of the particular CTO club I'm in, I'd say about 1/4 to 1/3rd followed a similar path.
There is a related way you can limit your career though, by becoming an expert on a non-critical system and limiting your focus solely to it. Many engineers take that path because it feels safe and offers job security, but it will limit upward mobility options.
Haha yeah. Kubernetes on Azure for bonus points. Not only do you waste more time, you also pay more and are recommended to get an expensive certificate.
Maybe that’s a good business idea: solely focus on bug fixes for clients so their “rockstars” can architect their way into more bugs that need fixing. Since the business’s employees I are only focused on bugs, and not features, they’re not leaving tech debt in their wake.
it's my strategy since I become bored with tech. I don't have passion or urge to create new useless software. There are many young or naive or plainly stupid which do. But I still have skills and insight to cover their asses when they corner themselves and are too busy with next fad and there are bugs to be fixed in yesterday's crapware... and I'm only 40..
> Those are rookie numbers. With a little Kubernetes, we can get them way up.
I used to be a frontend developer, but now my problems include `Error: mkdir /bitnami/postgresql/data: permission denied`.
All I wanted was to have a Persistent Volume Claim on my Postgres container that is part of a new dev environment I'm setting up. The other one worked, and still works fine.
Fucking hell, I've just blown another day because I'm dealing with over engineered crap.
We are on AWS, and a Postgres database that is primarily in one region, and read only in a second? That should be Aurora, and 15 lines of CloudFormation/CDK/whatever.
But that's too easy and reliable, who would need an SRE and an architect then? Instead we have multiple RDS instances, and a regularly failing PG Logical installation which requires an engineer constantly checking in on it because it silently fails and you only find out when storage starts burning out fast.
There is no feedback loop to let leadership know that they are spending hundreds of thousands over the odds for an unreliable system, and architects who seem to fail to admit someone made a misjudged call a couple of years ago.
I don't know what the solution is, but currently it's just some shitty old boys club.
Yes, they also picked Kubernetes but decided to install their own instance on AWS. Why the hell are we in a managed eco system and trying to build it in the worst way possible? Everything crashes on a regular basis.
Just today we had a call with devs that wanted to run k8s (managed by us) on client's stuff (when we generally got few VMs and cranky security guys any time we needed some traffic passed thru).
To run app that's like 3 containers with services, a queue, and a database. Took a second to explain that overhead, added management, and sheer paperwork to run it on client's infrastructure is absolutely not worth saving them like... a day or two making a bit more complex deploy script.
I've spent the last two days working with (not-Kubernetes) virtualisation software that has serious, workflow-breaking bugs from... uploading and removing regular files, of a format it expects. In some random-aaS frontend I could expect that, but this is systems stuff.
> Call me cynical, but from a dollars point of view this seems to be what customers want.
Since when have the wants of customers been the driving factor behind business decisions? There is a downstream effect, sure, as long as there is competition, but businesses are controlled by petty little weirdos with short attention spans like Elon Musk.
> The problems most often experienced by the participants included: "the system was slow," "the system froze temporarily," "the system crashed," "it is difficult to find things." The participants had backgrounds such as student, accountant, consultant, but several of them actually worked in the IT industry.
Finally, a chance to say what I really think about computers!
I feel that the majority of time working with computers is not actually computing numbers (addition, subtraction, multiplication) but LOGISTICS.
Logging into systems, Moving data around in memory and between servers, into registers for a function call, to and from a REST API, installing packages, finding dependencies, chaining together library functions.
+1. So often we conceptualize in terms of tasks, phases, states, processes. And then ultimately you discover it is all about data flow, an rarely about the algorithm.
> I feel that the majority of time working with computers is not actually computing numbers (addition, subtraction, multiplication) but LOGISTICS.
I think this was figured out in the 50's, when IBM started making mainframes for businesses - made for data processing and management rather than crunching numbers which was the focus of machines made at universities.
Also, in norwegian and I guess other european languages. We call them, directly translated, "data machines" rather than computers.
In Dutch the word is "computer" also, but English is the bastard child between Dutch and French while Dutch is already a bit of a bastard child from German.
I was confident that at least the germans would back me here, after all they got words like taschenrechner. But according to my dictionary they call it computer. Danish seems like 30% english nowadays, so I can't count on them. At least swedes call it "dator" which I guess is in the right spirit.
Rich Hickey actually has spoken about this on numerous occasions! So much of what we really do in programming is move data around, why not have data as first-class citizen in your programming?
I am working on an idea for programming that the primitive is literally moving things around in a grid. In a spreadsheet the formula is hidden behind a cell. And in most programming languages we write instructions and the state is implied - you don't see the state unless the program writes it out. In this design you see the state and all objects at all times. The idea is that the instruction is generated from the movement.
Try clicking "100" and move it into the JSON below.
At the moment I've implemented movement and JSON -> table. You can move things between fields in the JSON. You can rewind states of the top grid by clicking the instruction.
The plan is to put operations and API calls on the screen so you can move things into them, and their results shall go back into the grid.
Well, in Clojure at least, data is a generic thing you structure your program around, and is not hidden inside a class coupled to behavior. This is safely enabled by immutable values as a default. The standard library and ecosystem consists of generic functions operating on that immutable data. This is very liberating as you do not run into a combinatorial explosion of incompatible types that need to be marshaled to work together.
Generally you have 3 kinds of things in Clojure: associations (maps), sets (uniqueness), and order (lists/vectors).
I'd say the opposite - OOP is the paradigm that does the most to hide your data, hiding it within these encapsulated actors where you can't access it directly or even see what and where you have.
I would have thought that encapsulation hides the way data is processed, stored, and moved around. But the data itself is always available in my experience.
Suppose the data is in a private field of an object deep in the object graph. How do you get it? You can't, by design - that object's public interface may expose some aspects of the data, but you're not meant to access the actual raw data.
Not just computers. Life is mostly just moving things around. From the highest levels like shipping and waste management down to the lowest levels like data processing. Once you have what you need in the right place, in most cases, the job is nearly done.
The corollary is that if you get smarter about how you move things around, you can make serious efficiency improvements.
Your thinking reminds me of the work of a friend of mine. He's an AWS consultant and builds thing like AWS thinks you should. Some of the things he comes up with, chaining services together, with a sprinkle of lambda functions, it's Rube Goldberg machines all the way down.
A user logs in to a javascript app, hosted in an S3 bucket, authentication is handled by Cognito, the user gets a upload form, once their files is uploaded to S3, a lambda triggers an ECS container to spin up, some processing, output is sent to SQS where a service hosted on EKS picks up the processed data .... AND SO ON.
Exactly the term I had in mind: Rube Goldberg. And it gets so much worse than the examples you've given. Trying to shoehorn all the leaky abstractions together across the dozens or hundreds of pieces of technology I use every day from different vendors and open-source projects, with each interaction having hundreds of arcane failure modes, is absolutely soul-sucking. I'm impressed by the people who still do it, regardless of how much they earn for doing so.
On another context, you have some processed data on the backend, and an infinitely customizable software system on the frontend... How do you keep them both in sync?
And yeah, it is by converting your data into a programing language; parsing it again; resolving incompatibilities; turning it into the presentation language; letting the user interact with the presentation representation; converting it back into the programing language; sending it back into the backend... But then you don't want a round trip on every single interaction, so you convert your backend code into the frontend language, so it deals directly with the presentation code... and it goes on.
Oh, on the backend side you have an application and a data layer, both using different languages and data representation; so you do all that dance again there... Oh, and now we want several independent layers between those too, so be prepared to do all of that again and again.
At some point we decided on the wrong abstractions for our mainstream architectures.
100% this. I always dabbled as a dev since becoming fascinated with coding and computing as a kid in the 90s.
Went into a career in audio engineering in my 20s and switched to development about 4 years ago.
People ask how I found the switch and the truth is that it was very simple. The main principle of audio engineering is ‘signal’ flow, replace the word ‘signal’ with ‘data’ and you’re like 90% of the way there.
Follow the data, all we are doing is moving it around and manipulating it here and there. No different to a raw stem from the DI of a guitar passing through a big old analogue console.
Getting up to the point of doing the thing usually takes more time than the thing itself. that’s true in a lot of endeavors. Are you in a physical factory assembling product? The production and assembly time end to end is often a fraction of the time and effort spent putting everything in place to run the assembly.
Is that why whenever I see some roadwork or construction getting done in a big city, all the workers are just standing around, chatting? They're waiting for the construction materials to arrive?
i work in a courthouse, they had to use all versions of IE and firefox due to unmaintained application locks
the lack of subtle ergonomics make people do more work on computer than on paper
if you remember the old electronic calculator versus abacus, it's the same logic, or lack thereof, by the time you've changed context (session expired ? how to change app, how to change tab, gathered data from the client, tried filling it 7 times in various forms, your 1960 self is already finished filling in the form with a smile)
As performance of a system is being optimized, the relative size of un-optimizable parts goes up.
Sure, your banking app crashes sometimes and annoys you. How about you delete it and instead take a bus to a postal office to pay your bills this way - no annoying apps involved, it will just take 1h instead of 1m.
> Sure, your banking app crashes sometimes and annoys you. How about you delete it and instead take a bus to a postal office to pay your bills this way - no annoying apps involved, it will just take 1h instead of 1m.
Huh? Have ever actually paid a bill without using a computer? It doesn't work like you describe at all (unless you live in a really rural area or you're deliberately trying to make it difficult for yourself). Here's how it works:
1. Get a bill in the mail.
2. Open it, and write a check for the amount.
3. Put the check in the envelope, stick a stamp on that, and then put it all in your home's mailbox.
4. The mailman comes and picks it up, and it goes where it needs to go.
In some countries bills need to be paid at any bank or at the post office, you can't mail a check. The bill basically has a bar code that that the bank scans, and you pay in cash. (Or you can scan it at your bank's ATM and deduct it from your account).
I live in the suburbs of a large city in the US and I have to physically go to the post office whenever I mail something. My neighborhood has a weird matrix of mailboxes with no way to indicate to the postman that he needs to take something. So I have to drive to a post office every time I want to send mail. We even tried leaving a note in the box and that did not work. It doesn't take an hour but probably 20 minutes round trip.
And this is why I do not fear unemployment or AI. There will always be work for someone who can be asked to build over complicated software and debug it.
Washing machines and fridges freed up a ton of time for people. Maybe computers as well, then again maybe they just entertain.
My personal anecdata, I was recently investigating some page load timeouts for my client and this lead me down a rabbit hole which in the end meant moving a WHERE clause from outer query to an inner one and sped up the query 100k times.
Based on slow query log stats it eliminated 25h of human waiting per day.
I see this too. We now have dedicated programmers to maintain a program that was supposed to save time.
Well that program(and a few others) made it so instead of having 120 (real) engineers, we have 7 engineers. The cost saving is real, it allows greater complexity, and the maintainer can add upgrades and work on other things as the program matures.
I’d be very upset if my dishwasher broke every 5th time I used it. And in that scenario I’d much rather wash the dishes by hand.
Probably the same for my clothes vs. the washer.
If it takes 10 minutes to boot my computer, log into 10 SSOs with two factor, and install 57 updates, at what point do I start keeping graph paper and a desktop calculator to track my sales instead of using excel?
I have to say ChatGPT has turned a lot of micro-obstacles into problems that only last a couple of seconds. Stuff like "what's the command to turn a folder of pngs into a video" I can Just Do in seconds with a zsh alias set up to query it from the terminal.
Then there's stuff like "I don't understand this error message, give me pointers?" and it can be quite useful in that regard too. I still validate but I guess long term I can stay in flow way more consistently.
The biggest objection I hear to chatgpt as an assistant is that "you can't know if it gives you a truthful statement." That's true but it's also nowhere near a show-stopper. Just requires critical thinking in each scenario. People who don't use it have a tendency towards black-and-white thinking about its utility. I find that people who are skeptical of it initially who observe my workflow tend to 'get' what it's really useful for, after a short while.
This is honestly a good question to ask at times. I remember back when I was trying to get into weight lifting. I was searching for apps and tools that would help me track milestones and progress, setting up routines and all that. I remember going through some options, then making a spreadsheet, and refining the spreadsheet and just hating the whole process.
So then I opened a notebook and just wrote down my lifts for the day. At the top I wrote my 1 rep maximums for the big 4 lifts and had a page for my program that denoted the rep#/set#/1RM% and done.
What did it lack? Maybe some categorizing or search tools. Maybe some graphing to visualize progress over large spans of time? Well I don't need any of that. What matters is what I'm doing now.
There's probably several examples of things like that. I can't count the number of times I've tried using organizers for things like groceries or maintenance that have me spending more time fiddling with settings and formats than just doing the task. At my job I create a new text file daily to note what I worked on and shit that came up. I date it and save it to a directory and just use grep to recall info when I need to look back over large spans. No awkward TODO lists or planner apps. No updates or UI changes. No subscription fees or "Share" buttons.
Sometimes, asking how much time you save with a computer/app/whatever is the right thing.
Probably true. However, I interact with a bunch of broken systems all around me, in the real world, all the time. I'd also wager that I waste far more than 20% of my time on some of them.
Development teams, that include users, know about the issues. In the face of deadlines and budgets the team keeps opting to let little niggles slip in because they aren't a big enough deal to justify schedule disruptions or using developer time. All these little quirks add up to a shit UX.
The users filed the bug and the devs recorded the story, but management shot it down. Incentives.
This is killing me about my current job. I want to fix so many things, but the culture here is don't rock the boat (nationwide, not just this company).
Just today a colleague was reviewing a PR. I left a comment saying that I deleted a few template files that were no longer in use but I noticed them while working through the ticket. The PR had 6 different comments on it asking "Why was this deleted" for every single file that I deleted. I hope it's a language barrier thing with this one particular person, but I don't know.
We have retrospectives and talk a lot about making time to refactor as a part of sprint tickets and doing better within the system we have and then this crap comes up. So now I need to go write another ticket, bypass all of the refinement rituals (which nobody likes when I do that) and add the ticket to the sprint, just to delete these few unused files that git says haven't been touched in 7 years? Wtf guys.
The hard part of software is, always has been, and always will be, people, not code.
My Nest Thermostat was an example where I lost time.
Sure I didn't have to walk down the stairs to change the temperature a few times, but as the Thermostat started to bug out, I spent hours trying to fix it. I lost more time than I ever saved.
> Sure I didn't have to walk down the stairs to change the temperature a few times, but as the Thermostat started to bug out, I spent hours trying to fix it. I lost more time than I ever saved.
I've got an Ecobee, and I've never had a problem. The main reason was (unlike the Nest, at least at the time) it's fully functional in offline mode (schedules and everything). I've since learned that HVAC people typically dislike Nests, though I don't remember the reasons (and they are fine with Ecobees).
I'm not sure exactly what your problem with your Nest was, but they just didn't seem very reliable to me when I looked at them. Too much silicon valley in them: not prioritizing robustness, weird features that sound cool but just lead to an inscrutable device with a mind of its own, an over-reliance on the internet, etc.
After much research, my conclusion is that my HVAC system didn't have one of the wires connected, Common, C. This was not a problem until some update that caused the rest of the wires to be insufficient to recharge completely.
Over the next year or so, the battery was killed.
Who knows though. It was fine for the first few years, aside from when my power company overrode my settings on hot days and my kid had a life threatening fever.
> After much research, my conclusion is that my HVAC system didn't have one of the wires connected, Common, C. This was not a problem until some update that caused the rest of the wires to be insufficient to recharge completely.
My Ecobee doesn't have a battery at all, so that's something I had to deal with immediately upon installation. Luckily, I had an unused wire going to my own thermostat that I could repurpose. I believe it also came with a kit that would allow it to use a nonstandard signaling protocol so it could get needed power even if I didn't have an extra wire.
I'm kind of puzzled why a Nest would even have a battery. Just a kludge to allow unreliable installation in places that don't have the proper wiring?
One of the things I hate about modern software/product engineering is the over-reliance on updates and the mindset that aggressively obsoleting "old" versions. It creates a huge amount of unreliability and wasted time. IMHO, updates break things as much as they fix them.
> Who knows though. It was fine for the first few years, aside from when my power company overrode my settings on hot days and my kid had a life threatening fever.
Could they do that through the Nest, or did they have a separate cutout on the AC?
My home has a remote operated cutout, which I'd assumed wad inactive until I randomly read by bill very carefully and realized it was active even though I never signed up for it (apparently the previous homeowner had it active, and that carried forward to my account).
The Nest never made sense to me. An offline $20 digital thermostat can program a weekly schedule and requires 1 minute of maintenance per year (swap the backup battery). Never had to deal with a crash, fear of data exfiltration, or that some underlying SAAS would shutdown.
I spent a couple weeks on the "learning" setting before I just disabled that. It was almost never right, and I knew I could set it to exactly the right temperatures on a known schedule. We almost never have to touch that dial.
I'm having the same problem with android phone's brightness as well. I've stubbornly left it auto-adjusting, and about once a week I have to drag it from almost the bottom to almost the top again. I don't know why it thinks that's an appropriate setting because it never has been.
As a devops engineer, 100% of my time is wasted on computer problems. I increase my efficiency further by following instructions to the letter: this allows me to also waste multiple 10s of %s of other people's time too.
As a mathematician turned software engineer, dev ops and build systems are the bane of my existence. Every time I need to do that work, I want to quit.
The fact that I “can’t just X” but need to use some convoluted build system with details hidden somewhere as if it was arcane magic is beyond me.
Alas, lots of devops feel like they're cleverer than they are. I certainly did when I was younger.
The sign of seniority in a devops engineer is removing code, breaking down complexity, and being able to design simple, standalone services at a useful level of granularity. Sorry to hear you've not been around those people enough.
For what it is worth, even senior devops end up building convoluted crap too, but often this is because the organisation demands it. People don't recognise the hidden costs of complexity, in build or operation. Cleverness is often complexity, and promoting those kinds of solutions means creating the environment for "10x" engineers. People come to rely upon them because investing too deeply in learning about other people's complex legacies is almosy never worth it.
At AWS we are expected to do our own dev-ops, even if you are at a larger project with with some dev-ops engineer, you still need to do your own dev ops for many things.
CDK with TypeScript is actually pretty nice to work with, I like the compiler errors, having some type system, and managing my infra via code. My issue is with other systems. In all honesty, our customers have better build tools than we do.
On the contrary, it is much more efficient. One size doesn't fit all. The bad systems die when that's possible. When there is only one, a problem becomes a bottleneck.
When I started as an IT manager at a small events firm in 1997, I had 40 hours of work every week, just keeping things alive. By the end in 2013, things just ran smoothly, and I waited for something to break.
Windows got reliable between Windows 97 and Windows 7, servers got reliable, networks got reliable... everything stopped breaking.
There's no way 20% of peoples time is wasted on borked computers, that's a whole day every work week.
My MBP is currently running at ~800 MHz; it will be until about October or November, when I feel the coming chill of winter upon my skin. macOS thermally throttles the chip down, even if the chip is not actually that hot: the CPU is only ~65℃. But the surface temp on the keyboard is 109℉. All I can guess is that even though there's plenty of thermal headroom at the chip, you'd roast the user's hands if you attempted to use it. The fans cannot move the heat away from the CPU and out the back sufficiently fast, and too much ends up bleeding out the keyboard.
But now you have a 2.4GHz i9 limited to 800 MHz. During a meeting, it can't really do anything else, VC eats the available compute.
This is pathetic. Perhaps IT is different where you are, but my IT is out to lunch. IT is "hand new hire a new MBP" and … that's it? Unless a literal hole ended up in it¹, they're not going to replace it, ever.
Spolsky wrote that one of the "rules" for SWE firms was "Do you use the best tools money can buy?" — he wrote that that was table stakes, and if you're not doing it, you're nuts. He wrote that in 2000, nearly twenty-three years ago.
But tech cos love the MBP; IT teams only want to support one model of machine, regardless of how much of a lie that is (there are multiple models of a MBP deployed over time in a company) or how ill-suited a MBP is for the task at hand.
Absolutely I'm losing at least 20% if not more waiting multiple seconds for keyboard input to show up. Being unable to look things up during meetings, meaning mistakes get made, begetting more meetings.
¹Hmm. HMM.
Then there's the keyboard. The display cable connection. It goes on and on…
Macbooks had absolutely atrocious performance once the CPU heated up, masked by turboing extremely quickly to make short bursts of performance feel responsive. This was made worse by Apple's absolutely terrible cooling design. Their user-hostile form-over-function designs are also typically Apple. They made great devices for quick demos, but terrible professional workstations.
I actually suspect Apple sabotaged their own Intel-based products when M1 was on the horizon to make performance look better in comparison. Their attempt to basically passively cool an i3 that had a thermal output that clearly couldn't be cooled in such a way can only be described as either intentional or incompetence somewhere in the chain.
With the new ARM chips, things have changed for Apple. Their cooling solution is still worse than the competition, but their excellent CPUs don't need nearly as much cooling. The GPU sucks, but that doesn't matter for most productive use by using hardware acceleration (in select applications, for select formats). You're not going to be doing CAD work on a Macbook Air anyway.
The sad truth is that Apple's competitors are doing worse these days. AMD is doing relatively well, beating Apple in most benchmarks, but with lower performance per watt in the end. Intel is still trying to compensate for their inferior CPU designs by squeezing more power into their silicon, leading to impressive numbers for anyone hooking their computer up to the wall, but terrible battery life if you try to use that performance in a laptop.
I expect AMD to eventually get competitive based on the direction their mobile CPUs and GPUs are taking, but they still lack the production capacity to make a dent in the laptop space.
What I don't understand is why even people working in the office all day every day end up with laptops hooked up to docks and dongles. Even the excellent Macbooks get beaten hands down for cheap by normal desktop components that are available prebuilt with excellent warranty and on-site service for very similar prices. Just use a desktop! You don't have to pick between top-of-the-line laptops and bargain bin desktops!
> What I don't understand is why even people working in the office all day every day end up with laptops hooked up to docks and dongles.
I just need to connect one USB-C cable to get all the devices when I'm at my desk, and I still have my main machine with me in meetings or anywhere else. I also have a dev machine I can ssh into for any heavy process. That does mean I can't work without internet (well at least I can't program), but in practice it's not a problem, and I actually like this setup, at least more than the alternatives I can think of.
Intel deserves a lot of blame for the last few x86 MacBooks too. The TDPs on those i9s are completely imaginary. Out to lunch. If one were to, say, design a cooling system based on the specs and then receive a production sample that ran twice as hot at half the speed, one would have to do things like downclock it below a gigahertz to avoid burning the user's hands off. That entire generation of Intel chips was a trash fire that demanded a whole car radiator to stay cool just to provide two hours of battery life if you were lucky.
Intel's cooling specs certainly aren't great, but Apple did mess with the power profiles a LOT. People also often misread the TDP numbers (it's for describing the thermal load of a certain performance threshold, NOT the maximum power output of the chip) and that doesn't help..
I completely agree that Intel's chips were consuming way more power than they had any right to, but Apple knew that when they were designing their computers, and they also had complete control over the performance characteristics, so they could've compensated (or picked more appropriate chips).
AMD's Ryzen was the proof that Intel's designs were flawed. I suspect that AMD's impressive Ryzen performance spooked Intel and they responded by making their existing designs faster by just pumping more power through them.
275 comments
[ 2.4 ms ] story [ 278 ms ] threadSo much of the incentive structure in software companies is to ship new features. Maintaining existing ones or fixing bugs is a career dead end for software engineers and managers. No wonder so much stuff is broken and slow.
Call me cynical, but from a dollars point of view this seems to be what customers want.
When perf time comes around, everybody knows the deal. Shipping a new feature is a much easier sell than a bug fix and looking like a hero for fixing a bug instead of preventing one is easier anyways.
They don't understand that I'm not wasting time, I'm just choosing to spend a little bit of time earlier, because I don't like spending a lot of time later when debugging why everything broke.
Shoddy code only happens in "the production is on actual fire, not manager-imagined fire" fixes and not for long.
With buggy ship-it-now software you have a known bounded risk - bugs will occur in some cases but the software will ship and the bugs can be fixed because it’s simple.
With prematurely architected software the risk is unbounded - the project may get bogged down indefinitely in its own complexity without shipping.
The inverse extreme can also be a problem, of course A project that is maintained for a long time on the naive implementation will also become unmaintainable. However, this will be due to _known_ architecture problems encountered during maintenance. These problems can be addressed in a relatively bounded amount of time. They are also quantifiable and thus explainable to management.
Though, given the constant incentive to never learn how to write a proper parser does mean that practically nobody knows how to do it, and so it will always look & feel like an unbounded science project, and thus rarely done.
Infinitely recursive MVP'ing is a race to the bottom.
https://www.aarthiandsriram.com/p/our-dream-conversation-and...
``` Turbo Pascal 2 and Hash Tables
Sriram: I think there is some, we're going to talk later about things like GitHub co-pilot, we're dealing with different kinds of code reuse, but I do think there's a little bit of romance in the, for example, I idol you and folks like John Carmack. John Carmack noodling away and trying to make sure every instruction and memory access is aligned on some cash line. The amazing thing is, even today, if you look at AI at the heart of it, you have matrix multiplication and doing things with floating point numbers. Some of these things really tend to matter, which on the theme of optimization, tell us a story of Turbo Pascal 2 and you discovering hash tables because it's legendary.
Anders: [laughs] It is a funny story. You have to remember here that I am self-taught in the art of writing compilers. Now, I have since discovered and read a lot of the literature, but at the time, I was just coding away and doing it the best way I knew how. When you create a compiler, one of the things you have to create is simple tables, or they're not necessarily tables. They could be linked list, they could be whatever, but you have to look up names. When you're trying to compile a code that tries to assign one to X, well, you have to figure out where is X? What memory address have I associated with X? You have to look it up the declaration of X.
In Turbo Pascal 1.0, the first version of Turbo Pascal, all of the variable declarations were just kept on a linked list because that much I knew, but of course, searching linked lists is not particularly efficient when they get large. For really large functions, that would just take an awfully long time. Then, well, maybe you could try first go by first letter, and then have 26 linked lists or whatever, and that could help a little bit. Then I remember reading the literature about these things called hash tables actually in this book by Niklaus Wirth, Algorithms +, what is it? Yes, Algorithms + Data Structures = Programs.
A great book. He explains hash tables and I go, "Oh my God, that's amazing. I got to go try this." I went and implemented it and boom, the compiler went twice as fast. There's Turbo Pascal version 2.0.
[laughter]
Aarthi: Awesome.
Anders: There's a good reason to sell upgrades. ```
Do you really need a proper parser to sell 1.0? A literal compiler project did not fail due to the lack of a "proper" parser (though it can be argued that the lookup table is after the parsing stage; obviously there was not a strong distinction in the Turbo Pascal implementation between tokenization and compilation).
How would be the cost of bugs be known and bounded? A race condition in the code might not bother anyone ever in practice, or it might break down the whole system right as the most important investor decides to dogfood the product. In one case the bug can cause zero harm, and in the other might ruin the whole company.
How much was the "known and bounded risk" of shipping a buggy transactional model to the British Post Office? [1] It is "just" a buggy database, yet it cost many lives and sent many people to prison wrongfully.
> the bugs can be fixed because it’s simple.
Maybe? Have you tried in practice? Sometimes a buggy implementation forces you into a pathway where you need to spend inordinate amount of effort to get to a non-buggy solution. (This is the idea behind the term "technical debt".) Very often this effort is more than what you would need to do to just do it correctly the first time.
1: https://en.wikipedia.org/wiki/British_Post_Office_scandal
There are _lots_ of good practices which reduce the (potential) bug count without making things more complicated -- indeed, good practices serve to reduce complexity in design and architecture. Selecting the right data structures and algorithms, server-side validation, making proper use of your language's type system, choosing the correct type of database, writing some unit/integration/system tests, use caching judiciously, I could go on.
It is abundantly clear that GP is roughly describing two ends of a spectrum, not enumerating every possible option.
The other big one I constantly fight have to fight for is using type annotations in Python. It's a total no brainer and definitely not an extreme end of the spectrum. I'm not advocating formal software verification.
There is EXACT SAME PROBLEM with choosing to cut engineering tho. And the cost of getting it wrong is far higher.
If you catch a problem early, well you just wasted the amount of time you tried to save.
If QA catches the problem before you get it to the client, that's 2-3x the cost right there. 5-10x when it gets caught on production. 20 to near unbound when it causes some long standing issue that's noticed too late
>With buggy ship-it-now software you have a known bounded risk - bugs will occur in some cases but the software will ship and the bugs can be fixed because it’s simple.
>With prematurely architected software the risk is unbounded - the project may get bogged down indefinitely in its own complexity without shipping.
Not every software is a startup. If you have a requirements, first verify that they make sense in wider scope, then implement carefully while caring about potential edge cases. Not even handling them just making sure that they error out instead of propagate potentially invalid data further. That doesn't cost you even 2x the productivity.
> The inverse extreme can also be a problem, of course A project that is maintained for a long time on the naive implementation will also become unmaintainable. However, this will be due to _known_ architecture problems encountered during maintenance. These problems can be addressed in a relatively bounded amount of time. They are also quantifiable and thus explainable to management.
In vast majority of cases those end up as pieces of spaghetti legacy code that are worked around by the rest of the org, not fixed. "Fixing it later" is more and more and more expensive the longer it is in production and the more code grows around it.
Highly dependent on where you work and what you consider a "dead end". You can't possibly be talking about becoming unemployable in the industry nor even a pay cut. The situation for senior devs is the opposite, actually. Maintenance is the long tail of every project. If you're not doing that, you're not really working in software.
The highly hierarchical and structured command structure of a ship means that autonomous and intelligent human beings each make autonomous and intelligent decisions on the best course of action in a way that doesn't require constant and immediate upper layer attention all the time.
The more limited amount of human beings required to upkeep a ship those days are mainly because of manpower shortage and cost reasons, not because the removed humans were "worse" at doing such operations.
Those automation flows are in my opinion the same thing, they're replacing things because of manpower shortages or high costs of the previous thing, not because they're better.
But as we see frequently even on the most sophisticated AIs, they get shit wrong… a lot.
So this company decided to replace an actually working, guaranteed to produce proper results filtering system with a guaranteed to not produce proper results an unknown amount of the time, and the feeling was that this was good business direction.
People want buzzwords, not working software.
https://kevinkruse.com/the-ceo-and-the-three-envelopes/
Some VCs and the like aren't interested if your company isn't hitting those buzzwords.
Humans learn over time.
Humans have social pressures.
Humans have explanatory rather than merely predictive models about what they do.
Deviations by humans from expected standard behavior often produce better rather than worse results.
The list goes on.
I guarantee people will be mad when an AI chatbot denies their insurance or customer service claim. But I have a friend who works in customer service and it feels like half her job is correcting the mistakes other customer service agents made. If the first line support was AI, would it change much, other than not paying people to make a bunch of mistakes?
Again, it's going to be painful while we try it out and get the data. It feels like it's going to be worse, and individual anecdotes will make each fuckup seem even worse than it is. But it seems inevitable that we're going to get the data. The only way to get VC writing software right now seems to be by tying your company to AI. That means a lot of experiments are about to leak out into the world. We'll learn a lot.
Tech problems sometimes get fixed, and occasionally either eliminate a class of human problems or create new ones. It's the only thing that changes... Rejecting tech wholesale means embracing the status quo.
"Some weights in an algorithm are wrong" seems a much less fraught problem.
That is an opinion, not objective fact.
If Grandma June accidentally hits the accelerator, jumps the curb and kills a kindergartener, we can throw her in prison. She is held accountable for her actions.
https://www.upi.com/Top_News/US/2011/01/25/Woman-83-gets-3-y...
If Grandma June is sitting in her "self-driving" car and it spontaneously accelerates, jumps the curb and kills a kindergartener, what can we do? Who is held accountable?
Something something "fix the problem, not the blame", but accountability is part of fixing a problem. Improving numbers in the aggregate is good, but it is not (and should not be) the sole matter in discussion.
https://en.wikipedia.org/wiki/The_Ones_Who_Walk_Away_from_Om...
> Anderson decided to plead guilty to vehicular homicide because she did not want the family of Karla Campos to endure a trial.
Maybe the woman knew that it would be revealed that she was drunk or had been told that she didn’t have the capability any more to drive safely, but she did it anyway. Without knowing all the facts, pleading guilty for an accident seems like a bizarre choice.
It isn't a new problem, it's something that every court handles on a daily basis. Rebar or autoregression, the core legal elements are the same.
For example, if self-driving cars end up being prone to hitting children darting out on to city streets in new and unpredictable ways, then you have created impediments to the growth and development of children that did not previously exist. Would this be balanced by enhanced safety in other situations? Maybe.
These are complex topics like whether and how long schools should have stayed closed during COVID. Balancing the death and disability effects largely falling on adults vs. the educational interests of children.
The unitless number for driving into oncoming traffic wasn't supposed to be a real stat.
This expectation causes a lot of other problems, and will cause problems here too.
It's not dissimilar at all, just significantly faster and now in the hands of anyone with a laptop.
I'm pretty sure this doesn't generalize that well. I would say that people who don't use every day the product they are buying prefer buzzwords, but it's less true for people who actually use it.
I’m part of their largest customers and I have only 300 invoices a year. I’m still stunned how people can mess up like this.
They're a good complement to great design and infrastructure but you're fooling yourself if you think they're a replacement.
What percentage of software (in dollars) is purchased by people who are not going to be the ones using it?
I suspect the answer is the overwhelming majority. It is how software monstrosities like Concur can exist and be ubiquitous.
I'm right there with you, except I don't give "customers" that much credit.
Most people left to their own devices (ie, not brainwashed by marketing) will just stick with "good enough." But it's less fun (and less profitable) to fix and maintain old code, so companies induce "demand" by marketing. And if you're a company who decides to do the adult thing and not play that game, you'll be creamed by the ones that do.
Strong disagree. This may be the case at certain "tech" companies, but I grew my career into CTO through maintaining existing systems and fixing bugs (and through doing the things no one else wanted to do). Amongst my fellow members of the particular CTO club I'm in, I'd say about 1/4 to 1/3rd followed a similar path.
There is a related way you can limit your career though, by becoming an expert on a non-critical system and limiting your focus solely to it. Many engineers take that path because it feels safe and offers job security, but it will limit upward mobility options.
I used to be a frontend developer, but now my problems include `Error: mkdir /bitnami/postgresql/data: permission denied`.
All I wanted was to have a Persistent Volume Claim on my Postgres container that is part of a new dev environment I'm setting up. The other one worked, and still works fine.
I make a living dealing with computer problems.
We are on AWS, and a Postgres database that is primarily in one region, and read only in a second? That should be Aurora, and 15 lines of CloudFormation/CDK/whatever.
But that's too easy and reliable, who would need an SRE and an architect then? Instead we have multiple RDS instances, and a regularly failing PG Logical installation which requires an engineer constantly checking in on it because it silently fails and you only find out when storage starts burning out fast.
There is no feedback loop to let leadership know that they are spending hundreds of thousands over the odds for an unreliable system, and architects who seem to fail to admit someone made a misjudged call a couple of years ago.
I don't know what the solution is, but currently it's just some shitty old boys club.
Yes, they also picked Kubernetes but decided to install their own instance on AWS. Why the hell are we in a managed eco system and trying to build it in the worst way possible? Everything crashes on a regular basis.
Many people have tried to have an OS and pretty much all except MS, Apple and Google have failed at the consumer level.
To run app that's like 3 containers with services, a queue, and a database. Took a second to explain that overhead, added management, and sheer paperwork to run it on client's infrastructure is absolutely not worth saving them like... a day or two making a bit more complex deploy script.
:(.
Since when have the wants of customers been the driving factor behind business decisions? There is a downstream effect, sure, as long as there is competition, but businesses are controlled by petty little weirdos with short attention spans like Elon Musk.
Does this make me more or less cynical than you?
> The problems most often experienced by the participants included: "the system was slow," "the system froze temporarily," "the system crashed," "it is difficult to find things." The participants had backgrounds such as student, accountant, consultant, but several of them actually worked in the IT industry.
I feel that the majority of time working with computers is not actually computing numbers (addition, subtraction, multiplication) but LOGISTICS.
Logging into systems, Moving data around in memory and between servers, into registers for a function call, to and from a REST API, installing packages, finding dependencies, chaining together library functions.
I think this was figured out in the 50's, when IBM started making mainframes for businesses - made for data processing and management rather than crunching numbers which was the focus of machines made at universities.
Also, in norwegian and I guess other european languages. We call them, directly translated, "data machines" rather than computers.
¯\_(ツ)_/¯
It's interesting that Norwegian and Swedish are putting the emphasis on data instead.
I am working on an idea for programming that the primitive is literally moving things around in a grid. In a spreadsheet the formula is hidden behind a cell. And in most programming languages we write instructions and the state is implied - you don't see the state unless the program writes it out. In this design you see the state and all objects at all times. The idea is that the instruction is generated from the movement.
https://replit.com/@Chronological/DynamicTables
Try clicking "100" and move it into the JSON below.
At the moment I've implemented movement and JSON -> table. You can move things between fields in the JSON. You can rewind states of the top grid by clicking the instruction.
The plan is to put operations and API calls on the screen so you can move things into them, and their results shall go back into the grid.
Generally you have 3 kinds of things in Clojure: associations (maps), sets (uniqueness), and order (lists/vectors).
I, too, am a fan, especially in data intense applications, where a clear / decoupled data model and aggressive compiler solve many headaches.
The corollary is that if you get smarter about how you move things around, you can make serious efficiency improvements.
A user logs in to a javascript app, hosted in an S3 bucket, authentication is handled by Cognito, the user gets a upload form, once their files is uploaded to S3, a lambda triggers an ECS container to spin up, some processing, output is sent to SQS where a service hosted on EKS picks up the processed data .... AND SO ON.
Rube Goldberg machines, all of it.
On another context, you have some processed data on the backend, and an infinitely customizable software system on the frontend... How do you keep them both in sync?
And yeah, it is by converting your data into a programing language; parsing it again; resolving incompatibilities; turning it into the presentation language; letting the user interact with the presentation representation; converting it back into the programing language; sending it back into the backend... But then you don't want a round trip on every single interaction, so you convert your backend code into the frontend language, so it deals directly with the presentation code... and it goes on.
Oh, on the backend side you have an application and a data layer, both using different languages and data representation; so you do all that dance again there... Oh, and now we want several independent layers between those too, so be prepared to do all of that again and again.
At some point we decided on the wrong abstractions for our mainstream architectures.
Went into a career in audio engineering in my 20s and switched to development about 4 years ago.
People ask how I found the switch and the truth is that it was very simple. The main principle of audio engineering is ‘signal’ flow, replace the word ‘signal’ with ‘data’ and you’re like 90% of the way there.
Follow the data, all we are doing is moving it around and manipulating it here and there. No different to a raw stem from the DI of a guitar passing through a big old analogue console.
i work in a courthouse, they had to use all versions of IE and firefox due to unmaintained application locks
the lack of subtle ergonomics make people do more work on computer than on paper
if you remember the old electronic calculator versus abacus, it's the same logic, or lack thereof, by the time you've changed context (session expired ? how to change app, how to change tab, gathered data from the client, tried filling it 7 times in various forms, your 1960 self is already finished filling in the form with a smile)
there's probably a greenspun variant for this
As performance of a system is being optimized, the relative size of un-optimizable parts goes up.
Sure, your banking app crashes sometimes and annoys you. How about you delete it and instead take a bus to a postal office to pay your bills this way - no annoying apps involved, it will just take 1h instead of 1m.
Huh? Have ever actually paid a bill without using a computer? It doesn't work like you describe at all (unless you live in a really rural area or you're deliberately trying to make it difficult for yourself). Here's how it works:
1. Get a bill in the mail.
2. Open it, and write a check for the amount.
3. Put the check in the envelope, stick a stamp on that, and then put it all in your home's mailbox.
4. The mailman comes and picks it up, and it goes where it needs to go.
No buses, no trips to the post office required.
In some countries bills need to be paid at any bank or at the post office, you can't mail a check. The bill basically has a bar code that that the bank scans, and you pay in cash. (Or you can scan it at your bank's ATM and deduct it from your account).
What's with the profanity? You obviously know what I'm talking about.
We have them in the US, and it's a wonderful technology that would apparently save globalreset an hour-long trip to the bank.
Original study published here: “Frustration: Still a Common User Experience” https://dl.acm.org/doi/10.1145/3582432
Washing machines and fridges freed up a ton of time for people. Maybe computers as well, then again maybe they just entertain.
My personal anecdata, I was recently investigating some page load timeouts for my client and this lead me down a rabbit hole which in the end meant moving a WHERE clause from outer query to an inner one and sped up the query 100k times.
Based on slow query log stats it eliminated 25h of human waiting per day.
Well that program(and a few others) made it so instead of having 120 (real) engineers, we have 7 engineers. The cost saving is real, it allows greater complexity, and the maintainer can add upgrades and work on other things as the program matures.
Unbelievable amounts, both in speed of processing and communication, and in lack of error.
Probably the same for my clothes vs. the washer.
If it takes 10 minutes to boot my computer, log into 10 SSOs with two factor, and install 57 updates, at what point do I start keeping graph paper and a desktop calculator to track my sales instead of using excel?
And there need to be enough of you for a market.
Then there's stuff like "I don't understand this error message, give me pointers?" and it can be quite useful in that regard too. I still validate but I guess long term I can stay in flow way more consistently.
The biggest objection I hear to chatgpt as an assistant is that "you can't know if it gives you a truthful statement." That's true but it's also nowhere near a show-stopper. Just requires critical thinking in each scenario. People who don't use it have a tendency towards black-and-white thinking about its utility. I find that people who are skeptical of it initially who observe my workflow tend to 'get' what it's really useful for, after a short while.
This is honestly a good question to ask at times. I remember back when I was trying to get into weight lifting. I was searching for apps and tools that would help me track milestones and progress, setting up routines and all that. I remember going through some options, then making a spreadsheet, and refining the spreadsheet and just hating the whole process.
So then I opened a notebook and just wrote down my lifts for the day. At the top I wrote my 1 rep maximums for the big 4 lifts and had a page for my program that denoted the rep#/set#/1RM% and done.
What did it lack? Maybe some categorizing or search tools. Maybe some graphing to visualize progress over large spans of time? Well I don't need any of that. What matters is what I'm doing now.
There's probably several examples of things like that. I can't count the number of times I've tried using organizers for things like groceries or maintenance that have me spending more time fiddling with settings and formats than just doing the task. At my job I create a new text file daily to note what I worked on and shit that came up. I date it and save it to a directory and just use grep to recall info when I need to look back over large spans. No awkward TODO lists or planner apps. No updates or UI changes. No subscription fees or "Share" buttons.
Sometimes, asking how much time you save with a computer/app/whatever is the right thing.
It's called cutting edge because when you use it you bleed.
The users filed the bug and the devs recorded the story, but management shot it down. Incentives.
Not only that, after a while those UX warts are now embedded as part of someone's workflow and can't be changed.
as usual, elevant XKCD: https://xkcd.com/1172/
This is killing me about my current job. I want to fix so many things, but the culture here is don't rock the boat (nationwide, not just this company).
Just today a colleague was reviewing a PR. I left a comment saying that I deleted a few template files that were no longer in use but I noticed them while working through the ticket. The PR had 6 different comments on it asking "Why was this deleted" for every single file that I deleted. I hope it's a language barrier thing with this one particular person, but I don't know.
We have retrospectives and talk a lot about making time to refactor as a part of sprint tickets and doing better within the system we have and then this crap comes up. So now I need to go write another ticket, bypass all of the refinement rituals (which nobody likes when I do that) and add the ticket to the sprint, just to delete these few unused files that git says haven't been touched in 7 years? Wtf guys.
The hard part of software is, always has been, and always will be, people, not code.
Sure I didn't have to walk down the stairs to change the temperature a few times, but as the Thermostat started to bug out, I spent hours trying to fix it. I lost more time than I ever saved.
I've got an Ecobee, and I've never had a problem. The main reason was (unlike the Nest, at least at the time) it's fully functional in offline mode (schedules and everything). I've since learned that HVAC people typically dislike Nests, though I don't remember the reasons (and they are fine with Ecobees).
I'm not sure exactly what your problem with your Nest was, but they just didn't seem very reliable to me when I looked at them. Too much silicon valley in them: not prioritizing robustness, weird features that sound cool but just lead to an inscrutable device with a mind of its own, an over-reliance on the internet, etc.
Over the next year or so, the battery was killed.
Who knows though. It was fine for the first few years, aside from when my power company overrode my settings on hot days and my kid had a life threatening fever.
My Ecobee doesn't have a battery at all, so that's something I had to deal with immediately upon installation. Luckily, I had an unused wire going to my own thermostat that I could repurpose. I believe it also came with a kit that would allow it to use a nonstandard signaling protocol so it could get needed power even if I didn't have an extra wire.
I'm kind of puzzled why a Nest would even have a battery. Just a kludge to allow unreliable installation in places that don't have the proper wiring?
One of the things I hate about modern software/product engineering is the over-reliance on updates and the mindset that aggressively obsoleting "old" versions. It creates a huge amount of unreliability and wasted time. IMHO, updates break things as much as they fix them.
> Who knows though. It was fine for the first few years, aside from when my power company overrode my settings on hot days and my kid had a life threatening fever.
Could they do that through the Nest, or did they have a separate cutout on the AC?
My home has a remote operated cutout, which I'd assumed wad inactive until I randomly read by bill very carefully and realized it was active even though I never signed up for it (apparently the previous homeowner had it active, and that carried forward to my account).
I'm having the same problem with android phone's brightness as well. I've stubbornly left it auto-adjusting, and about once a week I have to drag it from almost the bottom to almost the top again. I don't know why it thinks that's an appropriate setting because it never has been.
The 10x programmer is real.
The fact that I “can’t just X” but need to use some convoluted build system with details hidden somewhere as if it was arcane magic is beyond me.
The sign of seniority in a devops engineer is removing code, breaking down complexity, and being able to design simple, standalone services at a useful level of granularity. Sorry to hear you've not been around those people enough.
For what it is worth, even senior devops end up building convoluted crap too, but often this is because the organisation demands it. People don't recognise the hidden costs of complexity, in build or operation. Cleverness is often complexity, and promoting those kinds of solutions means creating the environment for "10x" engineers. People come to rely upon them because investing too deeply in learning about other people's complex legacies is almosy never worth it.
CDK with TypeScript is actually pretty nice to work with, I like the compiler errors, having some type system, and managing my infra via code. My issue is with other systems. In all honesty, our customers have better build tools than we do.
This industry is built on lack of effectiveness.
We've built a few complex, production ready OSes,
with bilion programming language and compilers,
with a few web browsers,
with X drivers for everything (graphics, network, sound).
Basically everything a few times
Just to display funny cats in web browser
That's a very good idea. Really.
In tirannies there's only one thing of each. When that thing breaks, you're sorely out of luck.
People associate diversity with justice. But diversity is in fact your plan B, or C...
Cough, they mean Microsoft Teams, SharePoint, Azure AD, Internet Explorer Edge and Windows 10/11 problems because the rest works fine, no?
Windows got reliable between Windows 97 and Windows 7, servers got reliable, networks got reliable... everything stopped breaking.
There's no way 20% of peoples time is wasted on borked computers, that's a whole day every work week.
But now you have a 2.4GHz i9 limited to 800 MHz. During a meeting, it can't really do anything else, VC eats the available compute.
This is pathetic. Perhaps IT is different where you are, but my IT is out to lunch. IT is "hand new hire a new MBP" and … that's it? Unless a literal hole ended up in it¹, they're not going to replace it, ever.
Spolsky wrote that one of the "rules" for SWE firms was "Do you use the best tools money can buy?" — he wrote that that was table stakes, and if you're not doing it, you're nuts. He wrote that in 2000, nearly twenty-three years ago.
But tech cos love the MBP; IT teams only want to support one model of machine, regardless of how much of a lie that is (there are multiple models of a MBP deployed over time in a company) or how ill-suited a MBP is for the task at hand.
Absolutely I'm losing at least 20% if not more waiting multiple seconds for keyboard input to show up. Being unable to look things up during meetings, meaning mistakes get made, begetting more meetings.
¹Hmm. HMM.
Then there's the keyboard. The display cable connection. It goes on and on…
I actually suspect Apple sabotaged their own Intel-based products when M1 was on the horizon to make performance look better in comparison. Their attempt to basically passively cool an i3 that had a thermal output that clearly couldn't be cooled in such a way can only be described as either intentional or incompetence somewhere in the chain.
With the new ARM chips, things have changed for Apple. Their cooling solution is still worse than the competition, but their excellent CPUs don't need nearly as much cooling. The GPU sucks, but that doesn't matter for most productive use by using hardware acceleration (in select applications, for select formats). You're not going to be doing CAD work on a Macbook Air anyway.
The sad truth is that Apple's competitors are doing worse these days. AMD is doing relatively well, beating Apple in most benchmarks, but with lower performance per watt in the end. Intel is still trying to compensate for their inferior CPU designs by squeezing more power into their silicon, leading to impressive numbers for anyone hooking their computer up to the wall, but terrible battery life if you try to use that performance in a laptop.
I expect AMD to eventually get competitive based on the direction their mobile CPUs and GPUs are taking, but they still lack the production capacity to make a dent in the laptop space.
What I don't understand is why even people working in the office all day every day end up with laptops hooked up to docks and dongles. Even the excellent Macbooks get beaten hands down for cheap by normal desktop components that are available prebuilt with excellent warranty and on-site service for very similar prices. Just use a desktop! You don't have to pick between top-of-the-line laptops and bargain bin desktops!
I just need to connect one USB-C cable to get all the devices when I'm at my desk, and I still have my main machine with me in meetings or anywhere else. I also have a dev machine I can ssh into for any heavy process. That does mean I can't work without internet (well at least I can't program), but in practice it's not a problem, and I actually like this setup, at least more than the alternatives I can think of.
I completely agree that Intel's chips were consuming way more power than they had any right to, but Apple knew that when they were designing their computers, and they also had complete control over the performance characteristics, so they could've compensated (or picked more appropriate chips).
AMD's Ryzen was the proof that Intel's designs were flawed. I suspect that AMD's impressive Ryzen performance spooked Intel and they responded by making their existing designs faster by just pumping more power through them.
IMHO, Window XP and Windows 7 were peak Windows reliability. It's been downhill from there.
And I don't think their definition of "wasted time" is just "borked computers," they also seem to include things like slowness and bad UX.