To add some more context to your comment. One of the big attacks was in 2021 with the Kaseya ransomware attack that caused one of the larger grocers (coop) to essentially be unable to operate. Made national news as they had to give away product for free in some places.
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.
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.
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.
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.
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?
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.
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.
Cool project!