Times are changing in scary and horrible ways. Some say coding, together with many other human burdens, will be completely solved in just a matter of time. Even if that were the case, did painters stop painting after photography came about? Painting by hand is still enjoyed by many and people love to master it.
Here are some cool activities you can practice as a developer to keep enjoying your craft and getting better at it.
That's it! Thanks for reading. Just remember to try learning new stuff all the time and never stop doing it. Doesn't have to be useful. AI can do the useful stuff now, so you're free to focus on the useless.
Code is mostly text, master the art of editing text files. emacs and vim are the most daunting ones to learn but it's nice to know the basics or to just get a feel of both.
You are free to master the art of editing text files in VSCode, this is no place for editor wars: just master your chosen and try the others for fun and to develop empathy.
One day you'll have to edit some horribly big file at work. There are few solid options, including writing a primitive parser and have some python code do it. Sometimes you might just be able to edit the file using a bespoke combination of editor shortcuts, which will also impress your colleagues and peers.
The other benefit is that the faster you are at editing files and less you think about it the more you can focus on code. No, really, knowledge of editors gives you knowledge of which refactors are easy. Is it easy to look up all instances of this and edit them?
Take your time to read some entire manpage, even if some details aren't clear. Sometimes you'll learn about some interesting details that will get stuck to your brain forever, and you get used to "RTFM" and similar.
Going straight to the manual is often the fastest way to learn something! Manual reading is also essential for the next point,
Take your time to document what your stuff does. It doesn't have to be verbose, just like most manuals you've read aren't.
To be honest some of them are actually almost cryptic, and that's where the true art lies: writing just enough.
I really enjoy writing markdown-ish notes in Typst because they get compiled to nice looking PDFs with little effort.
Like APIs and requirements. If you've read and written a lot of documentation you know how important it is that an API is well designed and does what you need it to. You'd also call a bug whenever the program doesn't do what the spec and documentation said: when these are lacking, it's hard to define what a bug is and what should be done about it.
When a user reports an issue in many interacting programs maintained by different teams this becomes important in deciding who's at fault and where the issue should be fixed. Always know and stand your ground.
Contracts and APIs are everywhere. The type of a function is a contract. Libraries provide APIs in code. Programs interact via other APIs, like REST. Operating systems provide APIs, POSIX being a very popular one. At pretty much every level there is a lot of pondering available, but they're all manifestations of the general art of providing the best primitives to do what needs to be done and within the particular constraints of the problem.
One of the most promising areas in the field of API design is avoiding to write code to call the API when the APIs is defined well enough. It then becomes possible to generate the API calling code automatically for users. The C ABI is an extreme example of a known API to call functions that compilers and operating systems are aware of, so you mostly don't have to, but other notable examples are protobuf for binary data and openapi for REST apis.
Something really boring and formal but that you're able to follow through and implement flawlessly. Implement some protocol or file format you find cute from scratch if you feel like. One day you might be able to pick up a very old and crazy project you made because you wrote such a good spec. People at work will love your foresight and attention to detail. Your clients will be happy.
Because times are changing and DevOps is evolving. Don't get hacked. Be very afraid and look up what you are doing.
Ensuring you won't get hacked when you self-host the backend of a grocery shopping list app is an important learning experience, and maintaining a homebrew system a Sisyphean task.
It's very time consuming to get a self-hosted setup to a reliable state (i.e. 5 consecutive movie nights that didn't turn into troubleshooting session), but as prices for consumer hardware is hiking it seems wise to do it!
Writing software for a customer who's practically forced to use it at this point is one thing. Convincing friends and family to use your selfhosted stuff is another; you somehow need to beat big corporations in convenience.
You'll learn how hard these companies are actually fighting to make computers worse for everyone and your life miserable, just so you can pay a subscription service instead of selfhosting.
Your family loves it. How about the open web? 99% of the traffic you'll get will be bots and AI scrapers. Leave a port open for one minute and everyone with a Shodan subscription will be notified. Leaving your cute pi-hole with port 53 exposed? You are now infrastructure for DNS amplification attacks.
AI is so much better and faster than you at doing everything. So why should you do any of the above? Yeah you might get a little wiser from reading a manual, but Bob created 5 "market disrupting" applications in a single morning with his assistant. You'd call it "slop", abeit impressive, briefly think of how little effort Bob had to put it for the monumental result, maybe how you could've done it better if you didn't spend all your time reading a manual, and call it a day.
This is not the same feeling you had when reading a man page. Or a dictionary for that matter. You know someone put very expensive human hours into writing the manual, hours they could've spent with family or friends. At the time no one could delegate their assistant to do it, and even slavery was mostly abolished in the places people wrote linux manuals.
You know how tedious it is to write a manual because you wrote a few yourself.
Eh, no. Horrible, sloppy software existed way before AI came to light. People can really fuck up. Most horrible software was created commercially, and open source's insane success in the industry is a testament of this. Some might argue that "slop" is just the apotheosis of "enshittification", a term coined by Cory Doctorow of EEF to describe the decline in quality of services offered by two-sided markets (platforms connecting vendors, clients, and ripping off both). Whatever you do with AI, you pay a bill to an AI company, whose interest is just making you pay more bills.
Don't get me wrong, I believe there are tasks that AIs can do really well and that humans do not benefit from. Some people in hacking and cybersecurity, two things that sound very exciting but are actually abysmally boring, quickly automated the abysmally boring parts of their jobs: now AI scours codebases for bugs and reverse engineers binaries. This crowd also cares little about methods and a lot about results, as hackers trying to hack your company won't have moral obligations or standards.