I liked the article so I wanted to give you some feedback. Hope it is useful to you!

- I don't think the definitions of error and failure are 100% correct as stated. Looking at the IEEE definition that you reference, I interpret error meaning the difference between the value that is stored in the program, and the correct/intended value. For example if we expect to have a value of 100, but in fact have 110, the error is 10. I don't think that whether the value is observed or not is what categorizes it as either an error or a failure. If I run my program in the debugger and find that a value is off from what it is supposed to be, does that shift it from an error to a failure?

- One point I think you should have leaned more into is how language constructs and tools can help prevent failures, or cause more of them if they are bad. You bring up the point with Haskell and Rust, and how they systematically reduce the number of faults a programmer can make. You also bring up the point of Exceptions introducing a lot of complexity. I think these two examples are great individually. I think putting them together and comparing them would have been powerful. Maybe a section that argues why Rust omitting exceptions makes it a better language. - A side note since I also hate exceptions: did you know that the most common (and accepted?) way to communicate exceptions in C# is via doc comments written manually by humans. Good luck statically analyzing that!

- A lot of the text revolves around the terms error, failure, and fault and how people use these in communication. Often with different ideas of what the words mean. Even the titles (jokingly? "correctingly"?) reference this. Even with the definition at the start, the ambiguity of these terms was not dispelled. I think a major part of that was the text using the terms like you defined them, and also the common "misunderstood" versions of the terms. I think a strategy you could have deployed here is to use less overloaded words throughout the article and sticking to those throughout the article. For example (without saying these are the best terms for the job), instead of fault, error, and failure, using defect, deviation, and detected problem.

- A note on the writing style. Many words are quoted, and many sentences use parenthesis to further explain something. At least to me, these things make the text a bit jumpy when overused. I would try to rewrite sentences that end with a parenthesis by asking myself "what is missing in the sentence so I don't need to resort to parenthesis?". Don't be afraid to break a long sentence into many!

Hope my comments come of as sincere, if not then that's on me! Good luck with your continued writing.

> A side note since I also hate exceptions: did you know that the most common (and accepted?) way to communicate exceptions in C# is via doc comments written manually by humans. Good luck statically analyzing that!

Java having checked exceptions is the primary reason I’m sticking with that language. Many libraries don’t use them, unfortunately, but an application that embraces them systematically is bliss in terms of error handling, because at any place in the code you always know exactly what can fail for what non-bug reasons.

They had the right idea but implemented it poorly (overly verbose to work with, as is much of java). The end result were people taking too many shortcuts.

It is funny: usually, Java is used as a prime example why checked exceptions are bad.

Constructive feedback is always appreciated!

The only thing I'll comment on is the IEEE stuff. I was taught these terms in a university course on fault tolerance. You'll find slides from various courses using them like this or similar if you search on Google, and that particular IEEE standard was mentioned as the source (I never personally read it). I have read a later standard that rather than defining error specifically, mentions all the various ways in which the term is used.

The thing is, the actual standard is irrelevant, it wasn't meant as an appeal to authority. Rather, it's a source of 3 related terms (fault/error/failure) that can be used to refer to the 3 distinct ideas discussed throughout the post.

Your suggestions for alternative names are just as valuable and just as useless, neither the ones in the standard nor your own are generally agreed upon. My hope was that by using a somewhat common triple I would have avoided pointless discussion on the terms themselves, rather than the ideas discussed in the post.

As this hackernews comment section demonstrates, I was all for naught ;)

> did you know that the most common (and accepted?) way to communicate exceptions in C# is via doc comments written manually by humans.

Well, the accepted way to communicate them in Python is "we don't". I think C++ follows that same principle, but the ecosystem is extremely disconnected, so YMMV.

Java tried to do a new and very good thing by forcing the documentation of the exceptions. But since generics sucked for the first ~20 years of the language, and nobody still decided to apply them to the exceptions, it got bad results that discouraged anybody else from trying.

I think for dynamic languages exceptions are just a fact of life and it doesn't really make much sense to worry about them, you can't rely on the type system to remind the programmer of all the cases they need to handle.

So thinking in terms of failure handling is the way to go.

There is a cost in trying to force the language to find bugs for you. More is not always better. Unlike a linter, ignoring false positives from a compiler requires more work to work around them.

Not having exceptions in the language creates a tradeoff as well. This may lead to either ignoring errors or adding non-linear boilerplate between where the issue is detected and where the code can handle it, negatively impacting readability and refactoring.

Yup, see the section on handling failures in the post. Though note that I use "exceptions" to refer to a very particular language feature, rather than the mechanism. Rust panics and Go panics work like exceptions but are meant to be used differently. Panics are good as are exceptions when used like panics.

I've been using this as my standard font for maybe 1-2 years now (no, I am not joking). While I don't think that the font is any more legible than other fonts, the quirkiness and the character of the font makes it rather enjoyable to look at.

If legibility is an issue then I would seriously recommend increasing the font size, I think that will do much more than choice of "most optimal" font. And if increased font size makes your code "harder to read", consider that someone else might be unable to use a smaller font and will be forced to read code with a larger font size.

Daily driver for me as well, but only for terminal. People laugh sometimes while pair programming, but usually by the end they begin to really like it. Can't use anything else at this point.

I have a similar feeling. For some work I need to focus, but the "why don't we scrap this idea for one that does the same thing in 1/10 the code"-moments have mostly been in and between meetings and office chatter.

> The only solution is for the regulator, in this case the central banks, to issue guidance for the banks to create credit for only new productive investments, whether that be new housing, factories, machinery, or firms, because those are not inflationary and increase the size of the GDP pie.

I struggle to see exactly what you are advocating for. If a family wants to buy a house, they will generally have to take out a loan to cover the upfront cost and pay off the loan over a long period of time. However, the loan is not a "productive investment" (no new assets are being created, only traded) and as such the central bank should regulate normal banks to not be allowed to issue loans for existing houses.

Without the ability to take out a loan for a house, I think we can all see how no normal family without 20-40 years of combined salary payments would be able to afford a house. Is this in line with what you are suggesting, or is it something else?

I'm not trying to be asinine, this is just my interpretation of your suggestion and I am trying to understand what you are suggesting.

I have one example and an anti-example. Both are related to algorithms and computer science.

A) Packing a binary tree into an array. Anyone that has attended an algorithms course has likely created a binary tree with nodes, leaf nodes, left and right child etc. Seen the pine-tree like sketch with a larger example where each node except the leaf nodes have a left and right child. So how do you pack this tree into an array and traverse it efficiently?

Well you turn it 90 degrees side-ways, slightly shift all nodes on the same level so that none align and put them into an array by going from leftmost to rightmost. (or other way depending on if you shifted 90 degrees or -90 degrees). Congrats, you've packed nodes into an array. How do you traverse it? Our root node is at index 1 and if you packed the array correctly then `idx = (idx * 2) + 1` will move down one side and `idx = (idx * 2) + 0` moves down the other. I don't have a good visual explanation of this but you can think of the integer/index as a bit-sequence describing when in the tree a left vs. right path was taken (with the exception of the root node).

B) Anti-example: Ford Fulkerson algorithm for finding shortest paths between all nodes in a graph. The algorithm is basically just three for-loops stacked on top of each other, but I still can't grasp why it works. Something with dynamic programming and incrementally building on prior established intermediate paths. The algorithm is truly the product of a beautiful mind.

A) I've seen this before but I've never thought of the "index as a bit-sequence describing when in the tree a left vs. right path was taken" before! This is a very nice intuitive explanation that'll really help in describing this to others.

B) Did you mean Floyd-Warshall's?

On B) yes, of course. Aaagh, all these algorithms and their indistinguishable names!

This summer I read "On Writing Well" by William Zissner which was an eye opener for me. I'm far from an expert in writing clear texts, but I am definitely noticing more text which are just... big balls of blurb that don't actually say anything. All because of that book.

It sounds dumb, but this year it clicked for me how big of a difference a poorly written text compares to a well written text.

Hope your training pays off, itsmemattchung!

Zinsser's "On Writing Well" is one of my favorite books, I like how clear and concise its prose is.

I got Joseph M. William's "Style: Toward Clarity and Grace" recommended [1] so you might be interested in it. I read the introduction (I'm planning to read it this year) and with the few examples the author presents it sells the idea that prose doesn't need to be utterly complex to communicate ideas and concepts succinctly and clearly.

[1]: https://news.ycombinator.com/item?id=33601492

This is the first book I recommend to anyone who wants to improve their writing. With Minto's Pyramid Principle as a follow-on.

My top 3: 1/ Edit ruthlessly. Every single word is reduced to its simplest form and pulls its weight--it has a damn good reason for being there. 2/ Aspire to write at a third-grade reading level. Readers prefer simple writing even when reading deeply technical content. 3/ Start your most important conclusions up front, not at the end. You're not writing The Sixth Sense. Do your reader a favor and tell them the big reveal first. You can then follow through and persuade the reader why your conclusions are right.

Bottom Line Up Front and "Anything worth reading is 10% of the first draft," are the two hardest procedural skills in writing.

It's just so much experience to avoid those mistakes.

The definition of working with people vs. working with things doesn't seem obvious to me. As a software engineer I am working a lot with my computer. Therefore I must be working with things! But... I am just as much working with my soft skills. Scrum retros, talking to stakeholders, discussions on design with fellow engineers, testing with end-users. Some days I don't spend even a minute working with "things".

I don't think the distinction of working with people vs working with things is clear enough to say wheter my job means I am doing the one or the other. So how could the participants in the study do the same? I'm assuming there are lots of occupations in this grey zone and even situations where in one company the same occupation is considered working with people while in another company it would be considered working with things.

I can see multiple issues the study runs into which would be interesting to see how/if it answers. A) Does it measure peoples perception of wheter they work with people or thing? B) Do the authors make their own interpretation of which occupations lands in which category? How do they then eliminate their own biases in what working with that occupation means? C) Did the authors observe the participants and make a judgement call based on their day-to-day activity? This would likely be the most accurate, but I can't imagine they did this because of the sheer cost of such an experiment.

I think it’s pretty clear to me. I am much happier to be quietly doing research, writing code, testing, writing documentation, fixing bugs, writing emails, etc. Now stick me in a meeting and I soon become very unhappy. Why? Because I’m really not interested in listening to people complain about stuff unrelated to my tasks or giving updates about random stuff or whatever.

Now I don’t mind socializing with people at work and making a bit of small talk but I have zero interest in the sort of collaborative work that involves daily meetings. I’m far more productive when I can be left alone to focus on the task and it drives me crazy when people constantly interrupt me.

Here I would find some support for the parents point: There is a lot of room for interpretation.

To me, writing an email can be the most intense "working with people" thing, more so than any amount of small talk or doing manual labor with people. The amount of stress that goes into a hard to write email – mostly because it will also be a hard to read email and then also the anticipation of some sort of unpleasant reaction – and the amount of time you have to wallow in that stress, rivals few other social interactions in its intensity.

See, I find writing an email to be a totally straightforward, impersonal task. Like writing code, but in English rather than a programming language. Just the facts, no sugar-coating or other nonsense!

Then you end up on the job market.

I know the emails they’re talking about. They’re not as simple as writing the facts. Writing an extremely complex technical email in jargon and ways for people who aren’t familiar with any of it - even slightly - and explaining each detail concretely is quite the process.

It’s annoying when I have to write a 6,000 word email that is easily misunderstood because most others barely have an idea of the subject matter but it happens more often than I’d like to say.

Tbh - I find the emails pointless but this is what happens in low trust (dysfunctional) organizations.

It depends on the quality of the meetings. My last job I hated them for all the reasons you said. My current job they are enjoyable and productive. That's because the agenda is a "living" document that anyone can edit during the week, and the meetings stop when we've nothing left to discuss or need to get back to work

That's true. At my last job the meetings basically served as a way for the manager to broadcast stuff that could've just been sent out in an email and then collect updates on what everyone has been working on which also could be done with email. There was almost no back-and-forth to it at all, yet the damn thing took 2 hours per week. A huge waste of time!

A bricklayer works with things. Daycare staff work with people. These are very clear-cut.

Then there are a lot of points along that continuum -- nurses and HR reps work mostly with people. Economists a little of both. Software engineers and carpenters mostly with things.

We may not agree on a complete ordering but we will get reasonably close to each other, I suppose.

Yeah, I guess my point is that the categorization "prefer working with people" vs "prefer working with things" seems very weird. If I was a solo IT-entrepeneur I would likely work a lot with both! It does not even seem to be a scale between working more with things or more with people if you ask me.

And if there is so much grey zone that is open to interpretation, wouldn't that mean the study is rather measuring ones own perception of what they are working with?

Neithey daycare or bricklaying is something people often choose as their profession - ratger more like they end up doing because of a lack of options. Of course women would prefer bricklaying less as they are generally weaker. Daycare is a good luck call for getting hired as a man in the first place.

Some might say that both the patients and their colleagues are people!

Are you serious? Nurses are not secretaries. They work with people. Just because they have to fill forms, it doesn't give away the fact that their primary job is to tend/care people, help in operations, etc... mostly interacting with people.

An accountant can stay deep down in quicken for days, and it is ok. Just because they interact occasionally with an client, doesn't make them a people's job.

On the other hand, most Sales job are all about people.

I've spent at 10 days a few years ago working in a medical team in an hospital assisting nurses. They have a lot of workflow stuff to follow but that doesn't mean they chose this job for this reason and they mostly hate it. And they are still running left and right for patients all day. Plus their desktop is usually not hidden in an office but in a counter at the center of the service where they multitask between doing the paperwork and talking to patients/visitors/other members of the medical or technical teams

>As a software engineer I am working a lot with my computer. Therefore I must be working with things! But... I am just as much working with my soft skills. Scrum retros, talking to stakeholders, discussions on design with fellow engineers, testing with end-users. Some days I don't spend even a minute working with "things".

Yes but did you join the profession for the Scrum meetings or for the programming?

Third option: money

(speaking for myself, it was programming; never thought would get paid so much to do what I already love doing)

It's one of these "I know it when I see it" things. I don't think a definition is necessary, but if you need one - how about:

When you're working how often are you thinking about other person's state of mind vs a state of some inanimate (or abstract) object?

Ultimately almost all the jobs are done in groups, including stuff like coal mining. But people aren't your focus there.

> As a software engineer I am working a lot with my computer.

And with ChatGPT coming up we all will have soon to resort to a mixture of arguing, begging and threatening to make computers do what we want.

software is an industry that supports both types of workers, and you probably can pick out amongst your working group which ones are the people who prefer things vs people. your job may ask you to do soft work, but that doesn’t mean you prefer it

I know some of my friends who would never like to work with people through things (like computers or the Internet). They prefer to have a real office or retail with actual persons around them and don't like working in solitude physically (and a co-working does not cut it for them).

This is a comment only an engineer could come up with. It's not a "grey zone" ffs. You compare talking to people in order to do your job with teaching a class of pubescent kids or wiping old people's asses. Those are not even remotely comparable.

It sounds to me like you did a full rewrite by replacing the app piece by piece, sprint by sprint, releasing changes quite often and bringing that value all the way to the user. I think that is really clever.

My impression from others in this thread is that they mean "start from scratch and build until features are on-par with current product" when they say full rewrite.

Your version of full rewrite seems like it is generally applicable, but I have very little faith in the latter approach.

Maybe it's because I live in Sweden but I know a lot of people in the company that I work at that work between 50-90%. I myself plan to go down to 80% sometime in the near-ish future (current plan is 2025). Definitely not the norm tough.

My understanding, as a Swedish native, is that income from labour is taxed rather high (i think 70%+ for income over a certain amount). However, capital gains are taxed comparatively low. The two most common ways tax either 30% of the profit, or 1-3% of the annual total value (ish, I don't know the exact numbers and they are probably changing from year to year).

How the incentives play out you have to ask someone else about tough ;)

Edit: Got curious and looked up income tax. Turns out I was slightly wrong, Income is regularly taxed around 55% for really high income, but if you also count in VAT ("moms" in swedish) you get ~70% taxation.

It is pretty interesting to see, though. Sweden has a lot of "old money" and they seem to quite happy letting then keep it.

The Swedish welfare state involved a lot of compromise and give and take. The system benefits workers in some areas and capital owners in others.

Top marginal rate of tax paid by the employer is 55.5%. Employer pays some payroll taxes too but those usually aren’t included when comparing income tax. As a rule of thumb it costs the employer $1.50 to pay someone $1

You can't add 55+25 like that; VAT is 25 % of the 45 % left over. So maximum total marginal tax rate is 66.25 %

> I think that would start to create some social nudging functions (i.e. payment for Healthcare) while being a bit more fair (i.e. service quality sometimes proportional to money put in).

An interesting definition of “fair” - in Sweden the principle is equal health care prioritized according to who needs or benefits most from the care, not how much you pay. If you see it from that point of view, tax is not a transaction where you pay for the services you receive. You pay for the society you receive, which includes people in general being more healthy, not just yourself.

Most people would reject the idea that someone works hard all of their life gets the same healthcare that someone who does nothing.

Most people are somewhere in the middle, but there absolutely are people do nothing and people who are always being constructive, some in powerful ways.

A society in which 100% of resources would be allocated in that manner (basically communist) would completely fall apart.

I think 'same treatment Healthcare' is actually a bit of a hard-socialist idea that happened to make it's way through society historically (because it needed to have some socialization) but that will ultimately fail, it's on the edge in Canada right now as they are discussion private options.

In much the same way I think fully-private healthcare is a failure.

For the later (fully private) we have to understand the mechanisms are not the same as for regular products or even food etc. - there are existential issues which create gigantic asymmetries. So there must be heavy regulation and likely socialization in certain aspects.

But the converse is still true: 'everyone the same' is a disaster for most of the economy, it's also maybe not such a good idea for healthcare.

FYI - in Sweden the are Private Clinics.

In Canada, where I am from, we have pretty crazy laws, some of those most limiting in the world.

It's illegal to provide private services for all but a minority of issues.

Just consider that: a mechanic can fix your Mazerati, but it's illegal for them to fix your arm.

In practice - there is filtering. 'Important People' somehow manage to get good access, like Sports Stars, politicians. Actual Doctors/Hospitals are not owned by the government (as they are in UK) so they are selective, but the billing rates are theoretically the same.

On the other end, you may or may not get the surgery depending on if you're an alcoholic/smoker etc..

Due to all of this there are very, very weird asymmetries in Healthcare all over the place, notably Doctor's guilds controlling access to their domain, pricing insanity in the US for actual services, insane drug prices due to IP laws and lobbying, inability of governments to innovate effectively. One weird artifact of the later is how much we have to depend on the advancements of other nations.

The NGO style they have in the US is an interesting model as well.

> The argument most often used is 'But I Get Good Services' - which I'm suspicious of because 1) well, you could just keep the money and spend on the services you want, instead of the services the state chooses for you

I'm honestly baffled anyone seriously thinks that. It takes a minimum of reflection on all of the services provided by a functioning state and their role in society to realise that is just highly impractical. You get economies of scale, you get people who can't afford "services" who can not die, you get social mobility, happiness (if the workers servicing the ones that can afford services are unhappy slaves, that would impact service), etc.

> there's incredible efficiency in private institutions. I don't see any government in the world ever making a good 'Spotify'. Despite it's flaws, it's nice to have 'music when I want it'.

There's incredible efficiency in public institutions too, they just optimise for different things. One for money, the other for reach, impact, accountability. Despite it's flaws, it's nice to have healthcare when you need it without fear of bankruptcy.

I'm baffled that anyone still believes governments provide truly efficient services in any capacity, for anything at all?

The only areas in which it's ostensibly 'more efficient' are where there are natural monopolies and market conditions that make it impossible to do otherwise, and so we accept socialized intervention.

In most cases, we only socialize 'when necessary' - not the other way around.

"There's incredible efficiency in public institutions too, they just optimise for different things. One for money, the other for reach, impact, accountability." - I can hardly believe anyone could think that. That's what they put on paper, generally not what they do.

Both public and private organizations are fighting for their own institutional survival and power - it's just the mechanisms of influence are different: one gets money from taxpayers with some kind of 'oversight' which is not necessarily responsive to needs, the other, lives or dies on whether or not the provide value to people for a given price (aside form private monopolies).

It takes a 'minimum of reflection' to realize this as we have unlimited practical evidence for it ... were this to be even remotely true, then everything would be socialized as a 'matter of scale and efficiency'. We would be inexorably pulled in that direction - and yet - basically few things are, except maybe Healthcare in the US, as one of those markets that 'requires more social intervention' but for which there is currently very little.

Which governments invent the iPhone? (or could ever?). Hint: it's not a technology, it's a product which requires a product/market orientation, the ability to shift nimbly in innumerable areas of specialty, that no government has ever exhibited any capacity for - except - during wartime. When did they develop Web Analytics? Networking equipment? Effective merchandising mix even for things like groceries which is what give us the amazing variety and quality of products and produce we have? Farming equipment, processes, resources? Search Engines? Automobiles? Music streaming service? Chip designs? Video Games? Superhero Films? Toys? Makeup? Clothing? IoT Products? Furniture, lighting, tools? Construction equipment? Giant supply chains for all of those? Distribution chains? Financial services for investment banking? Retail? Commercial?

This list is really long.

I mean, it all could be done by an elected committee, but in most cases, not nearly as well.

In 1920 - yes - I can kind of understand it; 'on paper' of we merely had the government take over all of the auto-manufacturing plants, we could theoretically reduce costs by 10% by clearing out management, and, reducing profit taking! Citizens Unite! ... but it would not have been good for the future.

After a century of experimentation with all of that, we have some good data.

The government of Canada, in 2022 can't get my Health Records online.

They have spent $800 Million (>10x over budget) on an in-house payroll service for their employees that does not work. That's a lot of money, and it's the tip of the iceberg.

Where is the inquiry?

Obviously governments are necessary for enforcing basic regulatory requirements all over the place as it would not be efficient for us to have private practice to do that, but it depends on the situation. (For example, I wonder if 'rating agencies' need either to be socialized or to have extra careful oversight?)

Some public services with natural monopolies (roads, energy transport) obviously must be socialized in some way, because we can't have 10 different competing electricity grids and/or 'toll roads everywhere'. But of course, government generally does not actually 'build roads' - they contract that out to competitive bids, hopefully with oversight. That would be absurd.

Case and Point for the 'Governments are Better' enthusiasts - in which countries are the roads actually built by government employees? And have a better situation overall? I'll bet nowhere, because it makes no sense at all - even in an industry that is 'very large' with ostensibly a lot of room for 'scale' ... private contractors do the actual road construction.

'Pure R&D' is generally impossible in private markets outside of companies that are 'swimming in profits' (aka Google, MSFT) and even then it's not very pure, which is why higher education has to be strongly associated with government.

Basic education, regulatory considerations, strategic investments of scale impossible by private markets alone (aka chip fabs), investments in markets which are political in nature (weapons systems, space systems, some large energy projects), in which there are other, existential considerations/inelastic situations that combine to warp outcomes (aka Healthcare) there have to be interventions.

In most but not all cases, we have socialization because of necessity not because there are advantages, and vast majority of currently private markets would not benefit from being socialized.

Finally ... maybe this is mostly moot - I'll bet (but I'm not sure, correct me if I'm wrong) that most of the extra taxation in Sweden goes mostly to redistribution type expense, aka paternity leave, retirement, welfare services etc. which are all very expensive, and that Gov. Sweden is probably not directly doing a lot of market oriented things anyhow. I mean, they're not making furniture, coffee, or Music services ...