Why I think SystemD is acting like a bully

It's seems that I post only to complain about Systemd. I have tons of other articles in draft but only the ones about systemd drives me hard enough to complete them and post them. My other post on SystemD took some time longer but this was written in record time.. So much so that I write as a form of release or therapy in the face of all the roadblocks systemd has put between me and what I want to accomplish.
Systemd is a way their developers of saying to all the guys who have been doing Linux longer than them, "Sorry, what you knew then, is worth nothing now. We are the next generation and we are changing the game." Typical talk from the young who thinks they know it all. It gets worse when you think they are also saying, "We saw something better and we are doing it that way." when what they really saw was Linux through a terminal session in Windows or a Mac. The behavior of pushing people up the stairs, even when you don't really know whats at the top. All they see is light but it could just as well be a cliff.
While the dev seemed to claim they were seeing the light, it's that odd that one of the main things systemd did was blind others to what it was doing by making other people jump hoops through journalctl. It kicked syslog to the curb even though it didn't do everything syslog did. Being opaque was the order of the day.
Systemd is a solution looking for a problem. Rather than building a layer on top of work done before, they decided to start over, which was ok but then said "It's my way or the highway." and "We'll redo the tools you made before but they'll only work with our stuff, our way." It doesn't necessarily improve anything, only just for completeness of control when it's just masking "I can't be bothered interfacing with anyone else's stuff". Systemd has a bully mentality and it probably rubbed off from the people who developed it. It also has a Windows mentality of "(more) complexity is the solution" and "security is what we do later".  Which telling of where the developers get their ideas from.
Basically, RedHat, who is funding this realizing this or not, gains the most. They can't control Linus and his kernel team. So, why not build a wall around the kernel and forcing everybody to go thru systemd to get daily things done. Linus can do what he wants in the kernel, RedHat controls the doors leading to the kernel. And a knock-on effect for them is more people require retraining because all that knowledge accumulated is worth less now with systemd.
Let's get this straight, systemd works when it gets out of the way, like in desktop distros. I run Mageia and it's wonderful. I don't have to deal with it directly. But when it makes previously simple tasks complicated forcefully, then we have a problem. If it changes stuff while I am configuring other things and claims "but I told you so in the logs that you have to enter 4 parameters to make it readable", we have a problem. Look, things aren't perfect and improvements are always welcome. And Linux people love to learn new stuff. But it's hard to compare when the first thing done is say "I'm the only one competing." And being forced to learn is always a turn-off.
But I guess we are living in times when bullying is ok.

Top 5 mistakes new programmers make while developing

Is programming an art or science? While numerous proofs can be made on programming languages on their properties, which puts it in the realm of science, inspiration is the source to a program that can be described as elegant as well as efficient.
Being such so, in the early years, programming is often a singular pursuit that offers great satisfaction. As a programmer matures and Interest become Vocation, the nature of programming changes. What was a lone effort is now collaborative. And while there was none in the past, deadlines constantly looms high over the programmer. This change has led many programmers down the same path of discovery and maturity. Some become disillusioned, others trudge on and often making the same mistakes those ahead of them.
Being a programmer myself, I am also guilty of some of the following mistakes. In no particular order,

1. Trying to fix the problem on their own. A remnant of the lone programmer mindset or the advent of the 'lone programmer against the world' world view. Often followed by the belief that nobody else can help or solve the problem but themselves. This despite knowing well someone else has walked along the path before they did. Solution: a. Always repeat to yourself: This is not a unique problem. Someone else has solved it or solved something similar to it. Look for that solution. b. Talk to someone. Sometime the act of telling someone one provides another perspective.  
2. Dismissing bugs as 'small' in front of others. Those 'small bugs' can get very big. Treat all bugs the same or through the same process.
3. Going down a rabbit hole. That is hyper-focusing on one issue which create more problems or needs changes elsewhere. Which goes recursively until a few hours is lost. Solution: Mandatory breaks where you stop thinking about the problem and have something to eat OR talk to someone about the problem and what you are doing.
4. Not familiar with the production OS platform and not giving a care. Assuming just because it runs on platform, it must on the other. Followed by the attitude that because it doesn't, it's the platform's fault. The big picture: The customer doesn't care. All they want to see is that it's done and running. While the platform developers are at fault, you still have to care for the target's platform. What other services does it offer?  Hoe do I use them. Classic example: while a lot know about ssh, not many have used scp despite both using the same platform and technologies
5. Assuming the most technical/complicated solution is the right one to match the difficulty of the bug. Because only such a solution is 'worthy' of this bug. In reality, the best solution is often the simplest. Wield Occam's Razor wisely and the path to the solution will present itself.