Just a regular Joe.

  • 1 Post
  • 540 Comments
Joined 3 years ago
cake
Cake day: July 7th, 2023

help-circle
  • Many people have “itches to scratch” and some interest in development but little time to learn, so AI coding tools will allow them to scratch many of those itches without paying $ to others or investing that time (for better or for worse). Even as an experienced (but no longer full time) coder, I use it to scratch itches when I don’t have the time/lust.

    Often enough, you’ll find some customizable app that does 90% of what you want, with a bunch of features you don’t care about. Writing personalized apps is a cool new thing, giving you exactly the functionality that you want. Many times these will be based on OSS or open libraries, which the AI just glues together.

    Will this personalized development result in new quality OSS apps, though? I doubt it. We also don’t really need more sloppy code on github.


    There are a lot of personal apps that just happen to have an OSS license… and then there are OSS projects, built and maintained as OSS community projects. It takes dedication to run a real OSS project, build a community, handle issues, websites, etc.

    Will AI coding tools assist developers of real OSS projects? Sure… many are already using it to varying degrees. We’ll increasingly see it being used to find and fix bugs and security issues ahead of time - security researchers & blackhats are already having a field day.




  • And yet, agentic coding is here, and is not going away.

    There has been and will always be those interested in understanding and learning more, along with those who prefer to invest the bare minimum.

    There will be good software created by people using it, along with plenty of crap, with organizations and individuals paying for both. Similar to today.

    As for a lack of learning/skill development due to AI … it’s a challenge for sure, but such challenges are nothing new.

    In the end, code has been a convenient medium to express software/system design, but it’s not the design itself. People think, learn and understand differently to each other, and it might just be that code takes a back seat to other design mediums going forward.



  • There is plenty of consumer hardware that is supported on Linux, or will be as soon as a kernel developer gets their hands on it, reverse engineers the protocol if necessary, and adds support. For things like keyboards, there are often proprietary extensions (eg. for built-in displays, macros, etc.). It pays to check for Linux support before buying hardware though. Sometimes it’s not the kernel drivers, but supporting software (eg. Steam input) that might not support it.

    First class vendor support for Linux is more common for niche/premium hardware designed in the west, than cheap chinese knockoffs that follow it. Long term customer support is not their strong suit.








  • Don’t bet on it. Senior devs tend to know there is complexity and pitfalls over time, and hope that by using library X (or following pattern Y) they can future proof the product. So instead of writing 50 lines of self-contained code + tests, some people will happily write 60 lines of integration code + tests, and pull in a dozen dependencies.

    However: With appropriate interfaces and a little forethought, you can start with the simple solution and extend it or complement it with libraries or needed abstractions down the road if and when the need arises.

    Another bug-bear of mine is being asked to review/run over-engineered one-off programs (eg. simple ETL scripts). I remember replacing about 1000 lines of java (many years ago) with a 20 line python script, and passive-aggressively asking the senior developer to review the new script.