This page was last updated on March 10th, 2020(UTC) and it is currently May 30th, 2023(UTC).
That means this page is 3 years, 81 days, 14 hours, 21 minutes and 15 seconds old. Please keep that in mind.
I figured since I'm starting to feel it, now would be a good time to talk about it (what it is and how to get past it). First, soime context: this tutorial is something that I've been writing off and on for over a year. I've just recently picked it back up again, and skimmed over the tutorials, and I'm about to address classes (last leasson I wrote was merely DOS specific stuff for creating an LFB, for context.

Programmer depression isn't depression, per se, but just what we call it, because we're more or less in the dumps when it happens. It's not something that is avoidable, nor is it really a tangible issue. Surely this applies to alot of others as well. The main effect is that you feel burned out or bummed out, and it just becomes really, really easy to intentionally become worthless. Take my situation for example, I'm coding this tutorial, which I seriously doubt anyone is actually going to read to the end, I'm doing this all myself, and it's alot of work and I'm falling behind on things in life that have more meaning to me personally than sitting her explaining how proramming works to people who aren't likely to read until the end: My girlfriend just bought me a PS4 game that she wants me to play, I've largely been ignoring the news while nCov-2019 (AKA "Kung Flu") is now confirmed to be relatively close to me, I'm having trouble controlling the temperatures around my equipment (including the server you're most likely reading this from), and the list goes on. The plain and simple is: I could be doing other things, but here I am working on something that isn't likely to mean much to anyone, not even myself, all because I thought, just maybe, that one of these times the people who say they want to learn from me will actually not quit after I've invested so much time in them (the whole reason I wrote this tutorial was so I could say "just go ahead and read what I wrote and give me feedback if you don't understand", because I've spent so much time trying to correct things from other tutorials and trying to remove misconceptions). While this is more about tutorial writing, this same issue applies to programming, and this is what we mean by "Programmer Depression."

Fundamentally, the concern is that what you're doing ultimately isn't going to matter in the big scheme of things. While this is common with existential nihilism, even those who don't subscribe to that mentality ultimately do with programming, especially because of this small fancy word: "Deprecation." What it ultimately means is that something you use and need in your program has become viewed as bad practice or bad to use, which is especially difficult if you're a lone developer, but even in a corporate setting with a bunch of other developers, you'll feel it too (but to a much lesser degree, I'm sure). Programming isn't difficult, but it is still alot of work.i So, this idea that something you make or write being so fragile that it could become worthless before you're even finished with it, let alone 20 or 30 years down the line, tends to really, really get to you. And when you have enough distractions, it becomes easy to just scrap a project. Don't get me wrong, programming is really fun and entertaining, but this comes from the rewarding experience of making something with value, which, as you surely noticed, isn't always reliable.

Now, like any problem, once you've identified the source, you can start working on a solution to it. Fundamentally, you have to be able to reproduce an issue to solve it, else you'll be chasing ghosts. Firstly, we need to address the elephant in the room: deprecation is a huge issue, and the average person in the industry at this point is looking to collect a paycheck, not be a hobbyist, and large amounts of people are ignoring deprecation warnings anyway (deprecated code often becomes "removed", which means your program quits working if linked at runtime, or it becomes uncompilable if linked at compile time). Programmer depression is most strongly a problem because of this, as well as the huge saturation in the market (because programming is easier than people want you to think, which people probably make it sound hard to make themselves look good and to try to cut down on the saturation). Now if you're reading this because of my tutorial (God, I have to finish writing it and also go through it again to make sure my breaks didn't ruin everyhthing), you'll quickly discover this is the reason why I chose DOS. The end problem with deprecation, too, is that it's not always predictable. The problem with gets() it's pretty obvious: there's no way to prevent the natural security hole from it, but things like conio.h becoming deprecated (and not even officially, mind you, likely due to conflicting function names and maybe it's origins) shuold have been a shocker to everyone. I can imagine ncurses becomming deprecated and/or abandoned as well, at some point (tbh, DOSBox is starting to look dead, but I have hopes, 'cause it's all I got left for this issue when it comes to this tutorial).

Unfortunately, making anything that's useful on a practical level isn't going to maintain that usefulness in an emulator, but a game would. Pushing DOSBox for my tutorial means that, as long as DOSBox exists and is focused on making DOS games playable on modern hardware, everything made for it will, too, because it's very job is keeping deprecated code alive. The downside is, new bells and whistles are not likely to be available, but that's perfect for a tutorial or maybe even a game. Another option is to write code that sacrifices speed and resources to add enough abstraction that you can make it work with any interface, provided you're willing to constantly update the abstractions (I've tried this approach, and it can be a lot of work if you're not careful, but once you get enough experience you should mostly be fine). Unfortunately, things like C++ have actual programming language constructs becoming deprecated (and they encourage you to use really complicated constrructs which, in turn will likely become deprecated), which is not something you can solve via abstraction. While I don't go into structs in my tutorial, but classes, I do recommend that if you like the object oriented approach, you try emulating the behavior using structs and just use C instead of C++ or some other language, because ISO isn't wanting to change C much, and C will ultimately always be the glue between all the programming languages.

Lastly, you get worn out easily. Unless you're in a profesisonal setting, accept that you're going to take breaks. This is why you need to use what I said above, because you're going to need to take those breaks if you're doing large projects all by yourself. You can't pass up on life because of some project that you can't even know wether or not will actually mean anything in the big scheme of things. Do what you need from the get-go, assuming you're going to be taking extended breaks, because you're going to completely abandon projects if you don't. Know how and when to say "I'm not coding today" and be pepared for it. Don't let your projects drag you down, and don't beat yourself into a corner where you invested too much into something, but also don't allow the natural tendancies to feel things are worthless to keep you from doing great things.