posted in Technology
"Code was never the hard part" is an insult to all programmers
cross-posted from: programming.dev/post/54810980
blog.senko.net/code-was-never-the-hard-part-is-an-insult-to-all-programmers
Senko Rašić"Code was never the hard part" is an insult to all programmersThe software development profession is in the midst of upheaval. Nobody knows how the AI revolution will play out in the end, but it is c...Replying to @FoxtrotDeltaTango@sh.itjust.works
“Code was never the hard part” is probably made up by someone who never had to program anything serious.
Replying to @Treczoks@lemmy.world
“Writting the code was never the hard part”
It’s figuring out in detail what the program is suppose to do (i.e. Requirements), how it can and should do it given the technical constraints of the available deployment environment and performance & reliability requirements (i.e. Technical Analysis) and how it all gets structured from the highest level to the lowest level so that bugs are minimized, performance is suitable with the appropriate margin to absorb expect unexpected problems and costs for maintenance and future requirements implementation are low (i.e. from Technical Architecture and Systems Design down to Software Design) that are hard.
And I say this as somebody who has done all of those professionally, plus the coding (oh, so, so much coding) for systems of all kinds and sizes in various countries and industries, including some mission critical high performance distributed systems (which if they failed would have cost millions of $$$ in lost business income).
Fly by the seat of their pants coders who have never worked in a properly professional environment have no fucking clue just how much more there is to it than “coding” to go from no software at all to “reliable and robust software system that serves existing business needs”.
A lot of “coders” are like I was in the beginning of my career: they think they’re the shit, know nothing but a very limited range of work environments which they think “that’s how things are done” when those environments are actually, amateur hour, every hour of every day, every day of the month, every month of the year - they’re basically at the peak point of the Dunning-Krugger curve for software development knowledge.
Replying to @Aceticon@lemmy.dbzer0.com
For me, that is all integrated part of “programming”. You missed the documenting the code part, but i consider this as an oversight.
Replying to @Treczoks@lemmy.world
It says a lot that you think a coding good practice like “documenting things in code” which is at the level of using descriptive variable and function names, should be in the same bucket as structural non-coding processes (which are often entire professionions or very senior professional branches) like Requirements Analysis or Technical Architecture, both highly-complex things (the latter being the very top in seniority of the technical career track) which are non-existent in a formal sense in improvisational (read: amateur as fuck) “programming” companies.
You’re making my point on the whole Dunning-Krugger thing.
Replying to @Aceticon@lemmy.dbzer0.com
Not only in code. Documentation for the end user (or at least halfway there, the final document is done by a separate department), is important, too.
There is a reason that my job description is “Embedded Systems Architect”. But I see this complete packet as “programming”.
Replying to @Treczoks@lemmy.world
Interesting thing I see is that LLM slop generators are actually quite efficient at generating documentation, both for the end users and for developers, and like human generated slop-docs, the more cycles you put into review and refinement of them (both human guided and LLM self-review/refinement) the better quality you get out. Investing even half the person-hours in LLM generated documentation generates higher quality, more complete, better organized and more readable documentation for me than “working with a team” of writers who all have to meet and re-meet and explain and re-explain ad-nauseum until we’re all sick of the process and late for delivery of the documentation products.
When this documentation investment is made in the code, some remarkable things come out like: a project co-developed with Claude in Python took 10 interactive days to make. At the end, the Python was performing fine but a little on the noticeably slow side, so the LLM was told “do it again in Go” and 3 days later with very minimal prompting, the whole thing was re-implemented in Go, running 10x faster, and flawlessly performing the same functions which were developed in Python in 10 days - I believe precisely because a significant part of the Python project was: documentation of requirements, design specifications and automated tests.