Mastodawn

Leo Ré Jorge Jun 5

RE: https://social.treehouse.systems/@wwahammy/116695372319811855

This!! I am yelling this too!!

And it’s yet another one of the things where now when I yell it, I have to specify that it’s something I’ve been telling students and companies alike since long before the release of GPT, because otherwise people assume it’s just a reaction to gen AI:

“Generating code is by •far• the easiest part of programming.”

“No matter the source, don’t let code into your project unless you understand what it does.”

“Programming languages exist for humans to communicate with other humans. Code does not just make machines go; it encodes and reifies human mental models. Good code communicates •intent•; very bad code has no coherent intent at all.”

and so on

Shannon Clark Jun 5

@inthehands Yup. 100% this.

When I manage developers (and when I talk with people about careers in development) I explain that communication within your team IS the job. The lines of code is the easy stuff - the conversations about what to code, who should do what/when, the approach to take, how to test it, how to verify it, how to deploy it with limited risk (and how to recover if a problem shows in up production etc)

All that IS the job. The code is the easiest bit. The communication is key

Shannon Clark Jun 5

@inthehands all processes within a development team - meetings, code reviews, source code management tools etc - they are all there to facilitate communication. In places they are there to force conversation (with locks or merge conflicts).

Clear communication - clear presentation of ideas/options - clear documentation (before code is written as well as after) IS the job.

It is one reason why the best technologists I have ever worked with tend to have been PHILOSOPHY majors not CS majors

Shannon Clark Jun 5

@inthehands learning a specific language, or library, or tool - that easy.

Learning how to work well with others. How to break complicated ideas down into a clearly thought out process - that's hard. And that's the job of developers, managers and teams - to turn a list of goals and a vision of what could be into the iterative steps to take whatever existing systems you have to fulfill that vision (and to continue to provide the value your systems offer)

Jeff Grigg Jun 5

@Rycaut @inthehands

Yes, that's the job of *HUMANS*.

We employ humans to do this work.

Because if it could be done with predictable algorithms, then we would have automated it.

🟥 Eveline Sulman 🇳🇱🇪🇺🇺🇦Jun 6

@Rycaut @inthehands sounds familiar. I always have to tell my colleagues that answering e-mails and consulting colleagues IS their job, not something that disturbs their job...

Shannon Clark Jun 7

@EvelineSulman @inthehands yes. And this is where I also disagree with some folks about the value of those mythical “10x” engineers who just want to write code but never want to talk with colleagues, check in their code with empty or one line descriptions “fixed bugs” or “added machine learning” and otherwise don’t work with the team.

They almost always are a bigger risk than reward - when they leave their code is typically nearly impossible for anyone else to maintain and often is a black box

Shannon Clark Jun 7

@EvelineSulman @inthehands the real superstar developers are the folks who not only write good code but also write great descriptions, mentor others on their code, collaborate with the team and teach new and old developers new tricks and skills. I’ve know some folks like this - they were incredible managers, brilliant technologists and left their teams and the company as a whole stronger and more resilient because while they were good they also played well with others and raised everyone up

In principle I like this.

But in practice. -even before AI - how often did you use a library (paid or open source) that you just trusted worked?

Did you understand every single line of all its dependencies?

Paul Cantrell Jun 5

@vashbear
It’s a good question. The maxim does not apply to the transitive closure of all dependencies! It applies to code you are bringing into your •own• project (and thus taking on the responsibility of maintaining). To introduce a dependency is to delegate responsibility for understanding and maintaining that particular code to other people, which is a form of trust. Of course trust is no guarantee of anything, and trust can be broken and can be misplaced, but trust is still necessary — both to have computing to have a society.

Jeff Grigg Jun 5

@inthehands @vashbear

OK, for those who do responsible "due diligence" work on all the third party libraries you add, include, and update, …

What about your tool/languages libraries?

What about the operating system itself?

Remember: "Operating Systems" started out as "Here are some useful library routines that others wrote, and we all share."

Tall Simon Jun 5

@JeffGrigg @inthehands @vashbear

I'm also amused when I solve a problem with core OS tools and calls, often with little effort above reading the docs and understanding the underlying model.

There's always someone who needs an epipen, though, after I use m4.

I do see where the micro-kernel people are coming from.

We had a koan in one group: "You must know how to write a binary search. You must never write a binary search."

Jeff Grigg Jun 5

@TallSimon @inthehands @vashbear

Yes! Exactly!

Not long ago, I was "handed" AI generated JavaScript to decode and unzip the data returned by a web service.

The code did not work.

So I worked on it a bit, and got it working.

Due to limitations of the vendor tooling, it still did not really work well.

"To heck with it!" I said, and redid it with a simple Unix/Linux command line, using only the standard tools.

…

Jeff Grigg Jun 5

@TallSimon @inthehands @vashbear

And not only did it work better, it was easy to leverage it from "Do this one call." to "Call all the services for all of these items, format all the responses, and put them in well named files for later use."

Barely a handful of small bash scripts.

Talya (she/her) 🏳️‍⚧️✡️Jun 5

@inthehands @vashbear i mean presumably this rule also applies to dependencies, in that you need to understand why you're putting that dependency in and what influence it'll have on your project, even if you don't then open the black box that is the dependency's own code to figure that part out.

@inthehands I was asked to estimate the time to build a small program to reformat data and do a little math on it. The math part turns it from an uncontrolled utility to something that falls under our software QA process. The coding might take a week or two but the full process takes months: use case, needs analysis, software grading form (is it safety-related or not), requirements, design, spec, [code gets written here], user's manual including technical basis (what math is it doing, why, and how), Controlled Software Installation Form (formal request to IT to install the software in our production environment), acceptance and installation test plan and test reports, user qualification card and training materials, software release form (to formally allow people to use it for doing engineering work).

I'm sure I've missed some parts of the process but that's what we go through for every release of engineering analysis software (needs assessment and grading form are only done once). Updates are not as onerous as the initial release but it's still a lot of reading, writing, revising, technical review, and manager approval. Some people might think this is overkill but each part of the process demonstrates we know what we're doing and we're doing it correctly over the long term (documentation is retained "for the life of the facility" which is estimated at 60-80 years.)

Coding is easy compared to documenting your models, writing test cases and documentation of what each test is testing and what the acceptance criteria is, traning materials, etc. We should have a written record of every piece of analysis software we've ever used in production. Other reactor vendors have had to rerun analyses from the 80s based on regulator questions and long-term software lifecycle management is vital to keeping us honest and out of trouble.

Yes it's tedious work and yes; sometimes you have to review or revise some grotty piece of F66 code that nobody wants to rewrite, but it beats the hell out of high velocity web development. You learn interesting new science and you have time to actually take care of the entire software system. You avoid a lot of development churn and cowboy antics ("Let's port everything to Rust! Now Zig! Now Haskell!") It's not for everyone but I'm comfortable with it. The process is heavyweight but we remember what happens when you don't have good V&V, training, docs, and use cases - people die and you get to explain your software to Congress https://www.govinfo.gov/content/pkg/CHRG-108hhrg89216/pdf/CHRG-108hhrg89216.pdf

@inthehands I try to not write code which is going to have to be used and maintained by others... It's often not a gift to them!

Gildilinie Gremlin 🏳️‍⚧️Jun 5

@inthehands yea every time i think about an LLM "agent" writing high-level code that no one but a machine will see I'm like. what the fuck

@inthehands "but the intent is in the spec now, one abstraction layer up"

I heard this more than once now and I honestly don't know how to explain the difference to anyone who doesn't already see the qualitative difference between a compiler and an LLM

@tkissing @inthehands Fuck whoever coined the term „spec driven development” with the thorniest log mother nature is capable of producing!

It’s an open mockery of people that care and a testament to stupidity.

There’s no abstraction layer, there’s a highly sensitive to inputs monstrosity that humans tuned to produce the type of chaos humans evolved to pretend is controllable.

@inthehands I have similar thoughts about rewrites. As controversial as they are, the main benefit is regaining understanding of the codebase.

But now people are seemingly rewriting stuff with LLMs, and result is pretty much the opposite - you lose any understanding of the codebase.

It's just madness at this point.

Tijgertje1987 Jun 5

@siwek @inthehands
Yeah full rewrites are generally a bad idea

As a contractor I often port legacy code and even in that field I rarely recommend a rewrite.
Unless the code is such a big mess that a rewrite is safer and faster

[email protected]Jun 5

@inthehands @glynmoody @wwahammy No. Generating code is by far the worst part of programming you can apply to your junior workforce and the prime reason that programming as a skill will rapidly decline.

Mike McCaffrey Jun 5

@inthehands Plus, code is already how humans tell computers what we want them to do. All they've done is turned it into a game of telephone.

Wish the sun to stand still 🌞Jun 5

@inthehands Yes, and my experience on Linux says that the leanest GUI environments are the most brittle.

Every line is a liability until some line is crossed and the system cannot mediate bad inputs.

Boyd Stephen Smith Jr.Jun 5

@inthehands "Programs must be written for people to read, and only incidentally for machines to execute." - Harold Abelson

David Smith Jun 5

@BoydStephenSmithJr @inthehands It's interesting and instructive to try to derive this.

My code is read in earnest by maybe, let's say 10k people, and run by about 2 billion. So a shallow analysis would suggest that for this to be true, we need to derive about 200,000x more value from reading than from running.

However!

Many of those people who read it then go on to change parts of it, which creates a feedback effect where the 10k influence the 2B.

Difficult to figure out where crossover is.

Paul Cantrell Jun 5

@Catfish_Man @BoydStephenSmithJr
Yeah, trying to model this quantitatively goes into a bunch of deep holes very fast, full of counterfactuals and hard-to-measure cognitive effects. How do the benefits of writing for readability (or costs of non-readability) accumulate over time? Forget the constants; what kind of •curve• is that? What is the effect on the •author• of these things — not just their efficiency, but their thought process, their ability to solve the problem? What are the social effects on team cohesion, code attracting contributors? How does this change “black swan” events in the form of rare but catastrophic failures of code? etc.

I like the quote as a subjective statement, a statement of values — and I’ll leave it there.

Boyd Stephen Smith Jr.Jun 18

@inthehands @Catfish_Man I think it's not about the reader:runner ratio. That's a red herring.

It's about the writer:reader ratio and minimizing effort. It's the same reason that one-to-one email conversation is fine in TOFU format, but mass email discussion (whether you use mailing list software or not) is best done with the context above the new information, either has a single group or, if there's multiple trains of discussion going on, the "interleaved" style.

If your software is ever going to have more people reading it than writing it, reading it should be easier than writing it. (And, if you are ever going to get more writers, you will have more readers than writers [potentially MANY more].)

David Smith Jun 18

@BoydStephenSmithJr @inthehands

Gotta say I don't buy this argument. The red herring is the idea that the developers of the code are the only ones with an interest in it. Different code produces different results for end users, and we have a tremendous responsibility to them.

Focusing on readability is often (usually? always?) still the right thing to do, but it's *for* them.

Paul Cantrell Jun 18

@Catfish_Man @BoydStephenSmithJr

This is the thing. And there’s lots of stuff that is for all humans affected by the software in the long term that is only immediately visible to the developer. So we ask questions like:

- Does this code help us understand what it actually does?
- …what its makers •intended• for it to do?
- Does help its makers •think• about both those things? About mismatches, hidden assumptions, unforeseen consequences?
- Does it lend itself to future change, flexibility?
- etc

“Readability” is both a shorthand and a reasonable starting place for all of the above. It’s a way to refocus on the humans.

Paul Cantrell Jun 18

@Catfish_Man @BoydStephenSmithJr

I do agree with Boyd that much depends on the life and context of the code. Data analysis that needs to work once under author supervision has different code readability + quality needs than, say, an OS kernel.

John Colagioia Jun 5

@inthehands My current line for this in discussions is that code is the necessary evil in the system. The work is to understand people and help them, but you can't ship caring...

Paul Cantrell Jun 5

@jcolag
Yup. I believe I have even used the phrase “code is sort of a necessary evil” with students.