This is good (from @shriramk): https://mastodon.social/@shriramk/110040524796761802
The skill of recognizing and diagnosing broken code only becomes •more• important in the face of LLM code generators.
This is good (from @shriramk): https://mastodon.social/@shriramk/110040524796761802
The skill of recognizing and diagnosing broken code only becomes •more• important in the face of LLM code generators.
@schrotie
The two hardest problems in computer science are yourself and other people.
@inthehands Put another way: projects don't fail because of our struggles with writing code but because of our struggles with communicating with people.
Any experienced programmer worth their salt will tell you that •producing• code — learning syntax, finding examples, combining them, adding behaviors, adding complexity — is the •easy• part of programming.
The hard part: “How can it break? How will it surprise us? How will it change? Does it •really• accomplish our goal? What •is• our goal? Are we all even imagining the same goal? Do we understand each other? Will the next person to work on this understand it? Should we even build this?”
@inthehands this is the part of software engineering i see most missing from teams as my career progresses. Its also the most critical. An eng team does not exist to be told what to do by non technical people. The eng team’s job is to provide feedback, feasibility, and enrich the original idea in a way that could only be done by people with engineering experience. Really enjoying your thoughtful posts 👌🏼
How does this software impact people? Its users? Its stakeholders? Its maintainers, current and future? Society? Especially the most vulnerable?
Yes, coders have a part in all of these questions above! We are often the first to see crucial details, often the first to have a sense of the •reality• of the whole system (as opposed to our wishful imaginings of it). There is no such thing as “just coding;” all actions have consequences.
My “hard part” list ended only because of the post size limit; it goes on, of course.
From @h_albermann: “Are we solving the right problem?” And would solving a slightly different problem simplify things? Reduce risk? Open doors? How will we measure, reflect on, reassess these answers as we build?
From @awwaiid: “How can I get rid of this?” How can I split it? Abstract it? How can we prepare for future change? But not over-prepare? What kind of flexibility should we invest in? Leave room for?
A thought exercise:
Which of the problems in the post above does AI code generation make easier? faster?
Which does it not help?
Which might it exacerbate?
@endocrimes sums up all the above and more quite beautifully with this post:
https://toot.cat/@endocrimes/110071997616681139
@mapcar @adamhill @endocrimes
Ha, well, •this• pianist doesn’t spend hours practicing scales — which probably explains my middling technique!
Regardless, I think you’re on the money with the last part: anything AI can automate by turning the web into boilerplate is probably ought to be a new language or library abstraction. I have longer thoughts on this I’m going to post at some point.
@inthehands @adamhill @endocrimes And while I do understand that many programmers do not really control their tools and environments, I cannot help but thinking that if your programming language has so much bolierplate that you need an AI to help write that, perhaps you should consider using another language.
@inthehands @adamhill @endocrimes I really agree with this. Many, also programmers, see programming as puzzle solving which is a very wrong frame of mind for the activity. Programming is much better understood as a journey of learning, as Danielle is also saying.
@inthehands @adamhill @endocrimes Equally wrong, even dangerousluý so, is the idea that AI will help by taking away the boring parts of programming. First of all, that is unlikely to be true, humans will be left with the debugging, the getting the code to work, which is *not* the fun part. Secondly, I deeply believe that there is a value, even in the boring. Even the best pianist will spend hours daily, practicing scales.
@inthehands Unroll please —> @mastoreaderio
@jonnypencils@mastodon.socialyou don’t need the unroll; there’s a link to the (fuller, revised) blog post at the start!
@cybeardjm @badrihippo
Yup. And then comes one of the Big Lessons of being on a software team: realizing that you, too, sit between the chair and the keyboard. Oof.
@badrihippo The French acronym was PCC (Problème entre la Chaise et le Clavier)
@cybeardjm haha I'm going to start using that phrase now 😂
@inthehands @schrotie Don't know if it was used outside France, but when I was @ MSFT in the 90s, we called (some) users (even inside our teams) the "problem that exists between the chair and the keyboard"
@cybeardjm @badrihippo
YOUNG SEEKER: What is the purpose of life?
OLD SAGE ENGINEER: We’re here to be each other’s problems
@inthehands @badrihippo As a French Tech Lead, with all my problems due to localization, naming conventions in OS and so on, I probably was the problem for the US dev/mktg team...
GNU social JP is a social network, courtesy of GNU social JP管理人. It runs on GNU social, version 2.0.2-dev, available under the GNU Affero General Public License.
All GNU social JP content and data are available under the Creative Commons Attribution 3.0 license.