Courtney Wilburn
Hazel WeaklyThe two hardest problems in Computer Science are
1. Human communication
2. Getting people in tech to believe that human communication is important
ocratato@hazelweakly
I am quite certain that the "Computer Science" qualifier is redundant.
I am quite certain that the "Computer Science" qualifier is redundant.
screwlisp@ocratato
The hardest problems in human communication are cache invalidation and naming things
@hazelweakly
The hardest problems in human communication are cache invalidation and naming things
@hazelweakly
Not a Spring Onion@screwlisp @ocratato @hazelweakly
And off-by-one errors.
@screwlisp @hazelweakly
Yes.
Cache invalidation --> throwing out the things you thought you knew when better evidence to the contrary comes along.
Yes.
Cache invalidation --> throwing out the things you thought you knew when better evidence to the contrary comes along.
Petru Ratiu@ocratato @hazelweakly "Hell is other people"
EndlessMason
Daniel Reeders@ocratato @hazelweakly aye, the certainty is the problem, isn't it.
nadja@hazelweakly The third hardest is I presume then to get people in tech to understand that 90% of all ‘technical’ problems are instead socio-political ones and that neither political nor social problems have technical solutions?
Tyrone Slothrop@dequbed @hazelweakly a lot of people in tech would do well to realize that they’re essentially plumbers and bricklayers, working for a few rich landlords.
@slothrop @hazelweakly and both parts of that. Tech people are *just* plumbers and bricklayers. They help build infrastructure but they're no better than a bricklayer building a bridge.
Kat S@dequbed @slothrop @hazelweakly ...which leads to looking back at the bridges you've built, and hoping they've been used more by good people to do good things, than by any other kind. But also being afraid to look.
derptron@dequbed @slothrop @hazelweakly We are engineers and scientists.
Fuck the haters. ;)
Ain't nothing wrong with being a plumber. The equivalent in IT would probably be the network administrators. Similar levels of education and certification requirements. The plumber is probably more regulated by law, but the expectations are similar.
I really don't understand the human obsession with labeling wide groups of other humans and then group hating on them. It's weird. We're just people.
@crazyeddie @dequbed @slothrop @hazelweakly
They're not saying there is something wrong with being a plumber or a bricklayer. Those are both artisanal professions that build infrastructure, whereas the average software engineer is trained to view themselves more as a capitalist. Of course, we aren't. We are also members of a largely artisanal profession.
iwein@nap @crazyeddie @dequbed @slothrop @hazelweakly i did a double take at "*just* plumbers" as well. (Pretty sure not intended negatively in this case, but could be more positively worded, I think)
Given the right incentives, both plumbers and software engineers can do some very useful stuff, and solve some hairy problems. Also, I met some of the best and most compassionate communicators among craftspeople. Let's celebrate that and let go of the stereotypes!
@iwein @nap @crazyeddie @slothrop @hazelweakly It could, but the programmers that need to see this post are the kinds of programmers that consistently think they're better than plumbers, and often better than blue-collar workers in general. See some of the other replies for examples :)
Mind you, I was a mechanic first, a machining lab tech second and became a programmer third, out of necessity more than free will, and I consider plumbers and bricklayers as much more important than programmers.
Mind you, I was a mechanic first, a machining lab tech second and became a programmer third, out of necessity more than free will, and I consider plumbers and bricklayers as much more important than programmers.
Passenger@dequbed @iwein @nap @crazyeddie @slothrop @hazelweakly
As a data engineer I often self-describe as being basically a plumber.
The difference, I think, is that plumbers actually achieve the holy grail of applying a technical solution to a social problem, specifically the social problem of having poop in the drinking water.
@passenger @iwein @nap @crazyeddie @slothrop @hazelweakly do they though? The solution to the social problem is the result of a lot of people tirelessly working together to keep a lot of infrastructure running that's aggressively hidden from public view. A plumber gives you running water as much as milk comes from the supermarket fridge ^^
Marco van Burgsteden 🍋Plumbers and bricklayers do essential work. The problem with managing sociotechnical systems through the tech/engineering lens is that the ultimate societal goals tend to get lost as the job becomes less and less prioritised by politics and social issues, but more and more by technical optimisations of the system.
So tech ppl need to either start condidering the ethics of choices they make, and involve sociopolitical stakeholders more.
Conversely, political and social issues requiring technical tools to help solve them, should be able to build on the craftsmanship and experience of techies to deliver stuff that works and that can be maintained.
It is hard work to keep these two worlds connected and positively constructive.
Bee O'Problem 
@dequbed @hazelweakly reminds me of someone crowing about how blockchain would magically solve issues of warehouses losing packages. Literally zero awareness of stuff like theft, workers not filling paperwork properly, stuff getting missed on the back of a shelf, boxes falling off of conveyors etc. Warehousing databases don't lose inventory, people do.
Zillion@beeoproblem @dequbed @hazelweakly It's not (entirely) the people, but the system that keeps the people poor enough to steal, too tired and hurried to be careful and to take care of each other and check each other's work, and that prevents fixing the shelves.
Peter 🔻@hazelweakly There's no C in IT
Fabos (not an OS)@hazelweakly human communication is important?!?
@fabos @hazelweakly Not for everyone. There are several greats who found solitude offered them much more. Authors, philosophers, scientists, mathematicians... When you think of a great mind in human history it was probably thus.
Humans rate themselves way too highly.
@crazyeddie @fabos @hazelweakly … might explain why so much of philosophy is so out of touch.
Sure, being able to focus and think things through is valuable, but there’s a reason Einstein said “As far as the laws of mathematics refer to reality, they are not certain; and as far as they are certain, they do not refer to reality.”
@ShadSterling @fabos @hazelweakly I really doubt that's what he had in mind when he said that--seems more like an attempt to relay a fundamental concept of math that most people don't get--but everything is relative, including interpretations.
Nick Silkey 📻 N5ILK 🪓🪵 🪣💧@hazelweakly Business School as well, Hazel! 😉✌️
Francis Cook@hazelweakly can I venture a 3) not every goddamn thing is a tech problem.
GrandTheftUrkel@hazelweakly You forgot:
3. Off-by-one errors
3. Off-by-one errors
Ron Jeffries@hazelweakly got that right!
Matt HallHey... We have the same scars! <3
webshinra@hazelweakly TBH the first problem in any field is always humans.
🩷 Stella @hazelweakly this is basically a generalized form of “reading other people’s code”
🐜@hazelweakly it's worse for me with my disabilities:(
Arnel Šarić Sharan 
@hazelweakly if only in computer science.
Em 
Pseudo NymI thought the two hardest computer science problems were:
1) naming things
2) cache invalidation
3) off by one errors
(To be clear, I fully agree with the "communication" point. Just couldn't pass up the set up for a joke.)
Robert Kist 🇦🇹🇸🇬@pseudonym @hazelweakly I've seen 1 and 2 being caused communication issues, and I'm sure there's probably examples for cache invalidation too, somewhere
jer@hazelweakly
Not having management laying off the interns/juniors.
Not having management laying off the interns/juniors.
linear cannon@hazelweakly i think that might actually just be one problem
deliverator@hazelweakly I fully admit to HATING the mandatory "arts" courses (English lit, sociology, history, etc) I had to do as part of my uni degree. If I were doing it now I would probably have chatgpt'ed my way through most of the essay writing. Which is what I worry is happening with the next generation 😬
I'm at the point in life/career where I realize these were actually really useful.
how do we actually illustrate the value of these subjects to future generations? For me I know part of the issue was time management - trying to focus on reading a book and reflecting on it while also juggling all the "engineering" course work. Separate them into their own year/semester?
Zimmie@deliverator In my engineering degree plan, an engineering ethics course was mandatory. We discussed some high-profile failures like Bhopal and Chornobyl, as well as some lesser-known ones like the Hyatt Regency walkway collapse, the THERAC-25, and the Gimli Glider incident. We also spent significant time on how IBM and other big companies built machines which powered Hitler’s extermination camps.
The programming and IT degrees available at the time didn’t include any ethics courses, which is part of why I’ve never felt people doing either should be called engineers.
@bob_zim yup, definitely part of the whole thing. Canada (or is it just Ontario?) has rules about having "engineer" in a job title. Some people complain about artificial gatekeeping, but words are supposed to have meaning. I don't think we've actually figured out what "software engineering" means, let alone have a means of doing it and validating it.
LovesTha🥧@bob_zim @deliverator my electronic engineering degree barely touched ethics, just as one topic in the "Engineering Management" subject that was a real cakewalk. Computer science didn't mention it.
We also had room for zero things outside of science, which I wish was different. It would have been nice to do some subjects on other topics.
TheMagicalC@bob_zim @deliverator Further, I would say that unless you’re building your software to reliability standards (not goals, standards that you test) then you’re a programmer, not an engineer.
@cwg1231 @deliverator Even then, software is math. Beyond tested reliability, software can be *provably correct*.
@bob_zim @deliverator true. I haven’t played around with any of those cool formally verifiable languages yet, so I wasn’t comfortable asserting that they’re practical for industry use.
@cwg1231 @deliverator The seL4 kernel is pretty widely used (not as common as VxWorks, but it’s up there). It’s mostly C with a little assembly, and most versions are proven correct against a specification in Haskell using Isabelle. It’s a shining example that C code *can be* written correctly, but also of the lengths to which one must go to ensure this correctness.
Newer languages certainly make big parts of the process easier.
@cwg1231 @deliverator It’s just so weird how many software people have never heard of formal verification, and have no idea that you can write software which is provably free of implementation bugs.
On top of this, software doesn’t decay like a bridge! It doesn’t wear out like an engine does. Once it’s correct, it’s correct forever (or at least until the specification changes)! That’s should be huge! To me, the fact this isn’t even widely known—let alone striven for—is a sign of how unserious the software industry at large is.
@deliverator @cwg1231 I guess my point with that digression is that engineering is characterized by exactly two things—ethics and rigor—neither of which is practiced by the overwhelming majority of programmers.
Formal verification isn’t a total solution. A specification can still be bad in plenty of ways, but the software built to meet that specification can be correct. It’s difficult to do, but every real engineering discipline is difficult, and they don’t have correct solutions.
@bob_zim @deliverator excellent points all around. Regarding rigor, something that absolutely needs to enter the public discussion sphere is confidence metrics for probabilistic software (i.e. any machine learning algorithm ever, especially computer vison). Any probabilistic algorithm being marketed without a probability disclosure is wildly irresponsible and should be publicly shamed. I’d go as far as saying probability disclosures ought to be legally mandated, as well as disclosure of the dataset used to produce that measurement.
While software doesn’t decay in the literal sense, it does decay metaphorically. Vulnerabilities are found and need to be patched. Dependencies become deprecated or unmaintained.We run out of seconds since 1 January 1970 countable by a signed 32 bit integer. The left pad incident was a wake-up call for dependency maintenance. I’m vaguely aware of some frameworks for assessing the risk added to your project by a dependency, but I’ve never heard of a dependency being excluded from a project because of its risk. In that sense, we’re still in the fuck around and find out stage of software development. I hope we can change that soon.
skry@hazelweakly 3. Binary thinking
@skry 90% of the responses on this thread exhibit common flaws with binary thinking, e.g. 'those are hard problems for other disciplines too!'
@onekind Binary thinking is so often the elephant in the room. I feel like we need hazard signs in the hallways of tech companies. It’s almost as if duality were a deeper assumption constantly slamming our minds shut.
@skry I mean, yes, it straightforwardly is that and we've known that since the Enlightenment.
But I think you might be using the term binary to mean Manichean instead.
With binary thinking you get binary logic and an enormous array of different positions and claims become possible via the operators techies all treat as second nature — AND, OR, NOT, XOR, etc. The state model is only dualistic if you take it at a single time point and don't relate it to anything else. The moment you do either of those things, you get incredibly complex and diverse possibilities as an emergent property.