It finally hit me the other day.
I'm working on an IoT project for a late-stage ALS patient. The setup is that he has a tablet he controls with his eye movements, and he wants to be able to control furnishings in his room without relying on anyone else.
I set up a socket connection between his tablet and the Raspberry Pi. From there it was a simple matter of using GPIO to turn a lamp or fan on or off. I did the whole thing in C, even the socket programming on the Pi.
As I was finishing up the main control of the program on the Pi I realized that I need to be more certain of this than anything I've ever done before.
If something breaks, the client may be forced to go days without being able to turn his room light on, or his fan off.
Understand he is totally trapped in his own body so it's not like he can simply turn the fan off. The nursing staff are not particularly helpful and his wife is tied up a lot with work and their two small children so she can't spend all day every day doting on him.
Think of how annoying it is when you're trying to sleep and someone turns the light on in your room; now imagine you can't turn it off yourself, and it would take you about twenty minutes to tell someone to turn it off -- that is once you get their attention, again without being able to move any part of your body except your eyes.
As programmers and devs, it's a skill to do thorough testing and iron-out all the bugs. It is an entirely different experience when your client will be depending on what you're doing to drastically improve his quality of life, by being able to control his comfort level directly without relying on others -- that is, to do the simplest of tasks that we all take for granted.
Giving this man some independence back to his life is a huge honor; however, it carries the burden of knowing that I need to be damned confident in what I am doing, and that I have designed the system to recover from any catastrophe as quickly as possible.

In case you were wondering how I did it all: The Pi launches a wrapper for the socket connection on boot.
The wrapper launches the actual socket connection in a child process, then waits for it to exit. When the socket connection exits, the wrapper analyzes the cause for the exit.
If the socket connection exited safely -- by passing a special command from the tablet to the Pi -- then the wrapper exits the main function, which allows updating the Pi. If the socket connection exited unexpectedly, then the Pi reboots automatically -- which is the fastest way to return functionality and to safeguard against any resource leaks.
The socket program itself launches its own child process, which is an executable on the Pi. The data sent by the tablet is the name of the executable on the Pi. This allows a dynamic number of programs that can be controlled from the tablet, without having to reprogram the Pi, except for loding the executable onto it. If this child of the socket program fails, it will not disrupt its parent process, which is the socket program itself.

Fuck this client's IT department. They're a bunch of Microsoft asslickers.

How am I supposed to push code to your self-hosted GitLab instance if you restrict me to Citrix RDP????? No OpenVPN access because I'm on Linux?? Seriously? Because I am not using any of your laptops?

FUCK YOU DUMBASSES, I COULD DO A BETTER JOB THAN YOU AND I JUST PLAY WITH LINUX.

When I said I only needed terminal access I would have never imagined they were thinking of Putty inside an RDP. What a steaming shit.

Oh you guys don't have a secret management service as any enterprise should? Oh I cannot add a secret management service as part of the solution I am building for you guys because "Hurr Durr yOu HaVe NoT pUt ThIs In ThE pRoJeCt PrOpOsAl sO nO"

Fuck you guys. You guys only don't want to move to the cloud to not lose your jobs. I would be far more productive than relying on you pieces of dumbassery.

They are all having each others back in using shit technology and practices.

I knew this might be an issue, but really Linux just sucks balls. It may not be Linux's fault, but the user experience could be a fuck ton better.

Spent 1.5 hours trying to get mint installed on second drive. It works fine if you don't want to do anything with it.

As you can probably surmise I died on getting the gpu driver installed. Just starts to a black screen. No amount of juggling is helping. It just refuses to show the screen with an nvidia driver installed. What is worse is that settings that might help are not set. Like nomodeset in grub. If you know some drivers fuck up the grub interface then add nomodeset and not leave it up to the user to "figure this shit out". Because users are tired of figuring this shit out.

Really really fucking disappointed. I thought to myself: lets install steam and see how it does. The reality: fucking stuck for 1.5 hours on trying to boot into x with graphics acceleration and failing.

Many of you hate on windows, but one thing it has going for it. It doesn't do fucked up shit like this. It has failsafes that try and account for this.

Fuck you linux. You need to fucking grow up and stop relying on users to fix every damn thing in the command line. Go back to server where you belong.

I know I will get the "I told you so" messages, but guess what? The computer I got doesn't come preinstalled with windows. You have to pay to get it. At this point windows is the only fucking viable solution to make my shit work.

Nvidia, go die in a fire bitch. Fix your fucking Linux support you worthless shit heads.

This has been a rant brought to you by "the pain of others". I hope you enjoyed the experience.

PS, I love you all. Even the "I told you so" bitches.

Here comes lots of random pieces of advice...

Ain't no shortcuts.

Be prepared, becoming a good programmer (there are lots of shitty programmers, not so many good ones) takes lots of pain, frustration, and failure. It's going to suck for awhile. There will be false starts. At some point you will question whether you are cut out for it or not. Embrace the struggle -- if you aren't failing, you aren't learning.

Remember that in 2021 being a programmer is just as much (maybe even moreso) about picking up new things on the fly as it is about your crystalized knowledge. I don't want someone who has all the core features of some language memorized, I want someone who can learn new things quickly. Everything is open book all the time. I have to look up pretty basic stuff all the time, it's just that it takes me like twelve seconds to look it up and digest it.

Build, build, build, build, build. At least while you are learning, you should always be working on a project. Don't worry about how big the project is, small is fine.

Remember that programming is a tool, not the end goal in and of itself. Nobody gives a shit how good a carpenter is at using some specialized saw, they care about what the carpenter can build with that specialized saw.

Plan your build. This is a VERY important part of the process that newer devs/programmers like to skip. You are always free to change the plan, but you should have a plan going on. Don't store your plan in your head. If you plan exists only in your head you are doing it wrong. Write that shit down! If you create a solid development process, the cognitive overhead for any project goes way down.

Don't fall into the trap of comparing yourself to others, especially to the experts you are learning from. They are good because they have done the thing that you are struggling with at least a thousand times.

Don't fall into the trap of comparing yourself today to yourself yesterday. This will make it seem like you haven't learned anything and aren't on the move. Compare yourself to yourself last week, last month, last year.

Have experienced programmers review your code. Don't be afraid to ask, most of us really really enjoy this (if it makes you feel any better about the "inconvenience", it will take a mid-level waaaaay less time to review your code that it took for you to write it, and a senior dev even less time than that). You will hate it, it will suck having someone seem like they are just ripping your code apart, but it will make you so much better so much faster than just relying on your own internal knowledge.

When you start to be able to put the pieces together, stay humble. I've seen countless devs with a year of experience start to get a big head and talk like they know shit. Don't keep your mouth closed, but as a newer dev if you are talking noise instead of asking questions there is no way I will think you are ready to have the Jr./Associate/Whatever removed from your title.

Don't ever. Ever. Ever. Criticize someone else's preferred tools. Tooling is so far down the list of what makes a good programmer. This is another thing newer devs have a tendency to do, thinking that their tool chain is the only way to do it. Definitely recommend to people alternatives to check out. A senior dev using Notepad++, a terminal window, and a compiler from 1977 is probably better than you are with the newest shiniest IDE.

Don't be a dick about terminology/vocabulary. Different words mean different things to different people in different organizations. If what you call GNU/Linux somebody else just calls Linux, let it go man! You understand what they mean, and if you don't it's your job to figure out what they mean, not tell them the right way to say it.

One analogy I like to make is that becoming a programmer is a lot like becoming a chef. You don't become a chef by following recipes (i.e. just following tutorials and walk-throughs). You become a chef by learning about different ingredients, learning about different cooking techniques, learning about different styles of cuisine, and (this is the important part), learning how to put together ingredients, techniques, and cuisines in ways that no one has ever showed you about before.

When the guy you are relying on to do an export for an app during a MISSION CRITICAL downtime exports the wrong data and drops offline... Then you find his number in an email... then you find out he is driving somewhere and will not be back at his computer for 30 minutes...

Thanks for staying up with me @joeygreen

It's been a good month where honestly I had nothing to rant about. Pretty much doing my own project setting up ELK.

But last few days I had to return to the reality called teammates....

It where it ok... I mentored one of them, then did the code review yesterday

And that's when the shit hit the fan.

I told them to do X but then they did Y instead thinking that they were smart.

In hindsight they seem to have no idea wtf they were doing, inexperienced and couldn't even use console.log and JSON.stringify to debug object states...

Which course now reminded what's wrong with this team, you got people jumping around stacks and projects so they're all mediocre on all of them. Rather than having specific people being good at one of them (aka more experienced than a noob).

And if course this morning, manager asked me to look into something on a program I haven't support in a while (there are a free people that are more experienced and know the current state better). And he said this is quick and urgent... And actually when he said that I'm like uh.... don't think so....

And last thing is we had to rerun a report in production so needed the shipper ten to do it. Asked them look yesterday, users were waiting.

Today... Still not done. And well I actually can run the report myself locally.. takes 5mins but in production they need to reload the data but that should take at most 20mins... Either way... Nothing was done.

Oh and I just remembered I raised a request to it SA group to have some not script installed... That not done either.

And this is why relying on others it at least these people is a bad idea..... Unless your are capable of firing them...

I'm starting to gain a dislike for OOP.

I think classes make it easy for me to think of the entities of a problem and translate them into code.

But when you to attempt to test classes, that's when shit hits the fan.

In my opinion, it is pointless to test classes. If you ever seen test code for a class, you'll notice that it's usually horrible and long.

The reason for this is that usually some methods depend on other methods to be called first.

This results in the usual monolithic test that calls every goddamn method on the class.

You might say "ok, break the test into smaller parts". Ok. But the result of that attempt is even worse, because you end up with several big tests cases and a lot of duplicate code, because of the dependency of some methods on others.

The real solution to this is to make the classes be just glue: they should delegate arguments onto functions that reside on its own file, and, maybe afterwards emit events if you are using events.

But they shouldn't have too much test code classes though. The test code for classes should be running a simple example flow, but never doing any assertions other than expecting no exceptions.

For the most part, you'd be relying on the unit testing that is done for each delegated function.

If you take any single function you'll see that it's extremely easy to write tests for it. In fact, you can have the test right next to the fuction, like <module>.xyz <module>.test.xyz

So I don't think classes shouldn't be used at all, they should just be glue.

As you do normal usage of this software this way, when a bug is discovered you'll notice that the fix and testing code for this bug is very usually applied to the delegated functions instead of being a problem of classes.

I think classes by themselves sound sane in paper, but in practice they turn into a huge fucking messes that become impossible to understand or test.

How can something like traditional classes not get chaotic when a single class can have x attributes and y methods. The complexity grows exponentially. And sometimes more attributes and methods are added.

Someone might say "well, it's just the nature of problems. Problems can have a lot of variables".

Yeah, but cramming all of that complexity into a single 200 lines class is insanity.