Ask Slashdot: What Are Some Developer Secrets That Could Sink Your Business?

snydeq writes: In today's tech world, the developer is king -- and we know it. But if you're letting us reign over your app dev strategy, you might be in for some surprises, thanks to what we aren't saying, writes an anonymous developer in a roundup of developer secrets that could sink the business. "The truth is, we developers aren't always straight with you. We have a few secrets we like to keep for ourselves. The fact that we don't tell you everything is understandable. You're the boss, after all. Do you tell your boss everything? If you're the CEO, do you loop in the board on every decision? So don't be so surprised when we do it." What possible damaging programming dirt are you keeping the lid on? Some of the points the developer mentions in his/her report include: "Your technical debt is a lot bigger than you think," "We're infatuated with our own code," and "We'd rather build than maintain." If you can think of any others not mentioned in the report, we're all ears! This may be a good time to check the "Post Anonymously" box before you submit your comment.

Comments

The libraries we choose

[Shotgun]

We don't choose libraries and architectures necessarily because they are the best for your business. Sometimes, it is because they are hot in the market and we want professional experience to put on our resumes.

Oh, yeah. And we are keeping our resumes updated.

Re: The libraries we choose

[KGIII]

I was expecting the first post to be something like, "If I told you, it wouldn't be a secret!"

Re:The libraries we choose

[Anonymous Coward]

And sometimes those "hot" libraries will sink your business because they're not mature, and sometimes those libraries are just a wrapper over a another library, and the "new" library is nothing but a package of the previous library.

Take for instance Javascript and jQuery. There is nothing that jQuery does that native Javascript doesn't do, however many people use jQuery (which is a large CPU-heavy library) to do things that can be done in fewer lines of straight javascript. Why load this enormous library just do do that damn letterbox effect that takes 8 lines.

One needs to make sure they need most of the tools in the library toolbox before they can justify using it, and sometimes it may be better off going to the what that library pulls in.

Take libRetro. All these pirate emulator devices use it. Don't use it. Because the libraries of emulators it use are not only out of date, but frequently incorrectly licensed. If you need a SNES emulator to re-release your 1994 game under Steam (Hello Bubsy) you might actually be releasing a version that is worse than the original because the emulator quality is bad. There's a recent bug (last 4 weeks) that was discovered in all emulators. Too bad many emulators forked from Higan/BSNES and SNES9X and other developers are so old that these patches will never reach them.

This is just an example of a recent thing.

Re:The libraries we choose

[Anonymous Coward]

Take for instance Javascript and jQuery. . There is nothing that jQuery does that native Javascript doesn't do,...

Uh, isn't that true of any native library? Most C and C++ libraries don't do anything you couldn't do yourself... but the point is they did it already so you don't have to reinvent the wheel. The point of a library isn't to necessarily do something you couldn't do before, but to help you save development time (which can also include getting higher performance in some cases than someone who isn't as experienced at optimization).

The rest of that sentence after what was quoted just amounts to complaining people use the wrong tool sometimes and that is true regardless of whether the tool came from a library or something they spun themselves.

One needs to make sure they need most of the tools in the library toolbox before they can justify using it,

This really depends on your constrains and even what language you're using. Plenty of languages will load or pull in only what you use, so it doesn't matter how much stuff there is you don't use. Even if it pulls in a lot of cruft, there are projects where the load time and/or memory usage is nowhere near the main constraint on costs or lack of benefits. There is nothing magical about getting more benefits from using more than half a library, it comes down to the value of what you do use verse the cost of doing things that way.

Re: The libraries we choose

[davester666]

What about "If I told you, then you would replace me with a cheap Indian programmer."

Re:The libraries we choose

[TheRaven64]

Uh, isn't that true of any native library? Most C and C++ libraries don't do anything you couldn't do yourself

You've selectively quoted him. The full complaint was:

many people use jQuery (which is a large CPU-heavy library) to do things that can be done in fewer lines of straight javascript

Why use a library and 10 lines of library calls to do something that you could do in 5 lines of code? You should use libraries when the cost of reimplementing the functionality is higher than the cost of using the library.

Re:The libraries we choose

[Anonymous Coward]

There is nothing that jQuery does that native Javascript doesn't do, however many people use jQuery (which is a large CPU-heavy library) to do things that can be done in fewer lines of straight javascript.

It's even worse than that. Try searching sites like stackoverflow for things that can be done with CSS. 80% of the answers is to use Javascript, and then gives an example using jQuery.

Re: The libraries we choose

[Chris Mattern]

Or "If I told you, you'd refuse to believe me and then fire me for being insubordinate."

Re:The libraries we choose

[jittles]

We don't choose libraries and architectures necessarily because they are the best for your business. Sometimes, it is because they are hot in the market and we want professional experience to put on our resumes.

Oh, yeah. And we are keeping our resumes updated.

And I would reject your submissions in code review every time. People like you drive me nuts. Do that in your free time or don't do it at all. If you can't argue a valid reason to use whatever library or architecture you've added, then I won't let you add it to version control. I'm about to lecture someone today for doing just that on a project that I hadn't been paying attention to.

Re:The libraries we choose

[bluefoxlucid]

While jQuery is kind of crap, you'll have a hard time explaining why.

A lot of things done right are done with more code, not less. Instrumentation and framework, encapsulation, things that make your program maintainable and segment it into logical pieces all have some programmatic overhead. Only an immature programmer would pre-optimize by throwing away the maintainability of the codebase to save a few lines of code.

Psst... Don't tell anyone

[LynnwoodRooster]

But we're trying to move from C to Rust...

Russia.

[Spy Handler]

Sometimes developers meet with Russians. This could sink your business if CNN finds out.

Re:Russia.

[Swave An deBwoner]

Most of the developers I work with are rushin'. "What's the hurry?" I keep asking them, but they just keep coding.

We put everything in AWS

[Anonymous Coward]

Once upon a time everything was in a colo facility. Then they decided to rewrite the application we use to do everything. They put it in AWS. All of it. They they spent several man-years writing a bunch of automation between the various modular bits using Amazon's APIs.

Imagine the surprise from the beancounters when the thing they deployed took way longer than they said it would, cost a lot more than estimated, and has more than 3 times the opex costs compared to what we used to pay for hosting it ourselves, and now it's in AWS with no way to get it out without breaking all the automation that so much time was invested in writing.

Re:We put everything in AWS

[Narcocide]

I've seen this with every single attempt to use AWS for cost savings.

Re:We put everything in AWS

[TheRaven64]

It can be for cost savings if you have highly bursty workloads. If you need N machines for your peak loads but 0.1N machines most of the time, then something like AWS and only paying for 0.1N machines except during demand spikes is a lot cheaper than hosting N machines yourself. If you have a consistent workload, hosting your own machines is probably noticeably cheaper.

The schedule ain't gonna happen

[Snotnose]

Tallest nail gets hammered, keep my mouth shut hoping someone else takes the fall for being late. True story. Some 20 years ago I worked on Globalstar. The software was a good year late, we all knew it, but management a couple layers up didn't. They were launching a bunch of Globalstar satellites on a Russian rocket. There were 4 teams of us, all knew we were a year behind, sitting in a large conference room with a live link to the launch. Some 90 seconds in the rocket plowed into Russian real estate. We all looked at each other, breathed a sigh of relief, looked sad to our manager's managers, and went home knowing we were good with our 50 hour work weeks for another year.

Re:The schedule ain't gonna happen

[Michael Woodhams]

I heard a similar story about the Hubble Space Telescope, from one of the lead scientists. All the teams were way behind schedule. All the teams knew that the other teams were behind. So they all pretended for as long as possible they were on time, until one team had to admit that they needed more time. At that point, all the rest of the teams got the time they needed without any blame for delaying the project.

Also I was told there were major quality issues with soldering on they main computer boards. These problems were only caught and fixed because of the launch delay after the Challenger accident.

This is all from decades old memory, so add grains of salt.

Re:The schedule ain't gonna happen

[Anonymous Coward]

AKA Schedule Chicken. Though hoping the other team crashes and burns first is usually a metaphor...

https://en.wikipedia.org/wiki/Schedule_chicken

What a bunch of Bullocks

[Puff_Of_Hot_Air]

I note the "insightful" article is written by an anonymous author, as I wouldn't want my name tarnished with this steaming pile either. There is nothing of value here. Nothing. I note that "syndeq" simply spams articles from this CIO website, driving traffic there I suppose. Slashdot is a waste of time these days. I still come here out of habit, but it's a habit I need to kick.

Re: What a bunch of Bullocks

[KGIII]

I have been on /., for a long time. This is actually my second account, as I lost the email associated with the first one and forgot my password.

Why do I mention that? Slashdot has never been good. No, it really hasn't. That's kinda why I like it. Hell, we don't even get much goatse spam anymore.

I am on mobile, so search for 'VMware' on here. Go back and read the comments in the first article. Yup... We've never, ever, been good. If you don't want to search, the comments declared virtualization would never work, catch on, and that it was easier to dual boot. Keep in mind that these same people are the same people who submit articles to the firehose.

No, we've never been good.

Re: What a bunch of Bullocks

[DivineKnight]

Fair enough. For your viewing pleasure, I direct you to Corsair's support site (https://support.corsair.com/), and the pleasant fire that is growing there (front row seats if you have filed some tickets / RMAs with them before), as it appears that they have either lost the password portion of the accounts database and a fair portion of the ticket database, or they are being very selective about how quickly they restore / upgrade them.

Re: What a bunch of Bullocks

[rtb61]

You most certainly will never solve the worlds problems on /. all you do is exchange new and interesting ideas with some of the other /.ers. Apart from the regular infestations of public relations trolls, marketdroids, from the major companies and politicians, it is remains pretty light (they do seem to realise even if people agree with their marketing, they will be trolled and their product denigrated when they are detected). Seriously still way better than say Reddit, now there is a popularity contest, the comments you see modded up most, 'i agree', 'great idea', 'me too', et al you get the gist, where as well thought out and written comments get modded down just because. As a forum /. is better than most and there are some that are so much worse (to pick on Reddit again, you browse a bit a your kind a whole bunch of stuff with zero comments, way more than half, they might not be doing all that well).

Re: What a bunch of Bullocks

[Keith_Beef]

Trying to create an account there:

The following errors occurred. Please fix them, then resubmit: 010

What a helpful message! ;-)

Re: What a bunch of Bullocks

[DivineKnight]

I believe this fulfills the practical part of what this /. posting is about, now onto the theoretical. ;-)

Re: What a bunch of Bullocks

[KGIII]

Maybe - but I think you may have rose colored glasses.

I am on the full site. Read the comments on this thread:

Link.

You can pretty much skim them. I can also find a whole lot more threads, just like that. Hell, it's threads like that which have kept me coming back for years.

Backdoor

[Anonymous Coward]

Our server has a backdoor letting you submit arbitrary code that gets compiled and executed. We use it to fix things directly in production since everything is a mess and things break all the time. You don't even need to log in, just hit the right URL and you are in. I can't understand how this hasn't been used by a disgruntled employee to delete the entire DB or something like that. By the way, this is not a worthless startup, it's a hundred million dollar revenue per year operation.

Re:Backdoor

[Rei]

Wow... this wins the thread.
Just... bravo.

Re:Backdoor

[bigman2003]

Ha ha...I had a backdoor like this at my old job.

I created it about 15 years ago, when security was different. It would allow me to upload new code and have it working immediately- so I didn't need to login to a server, go through the dev->test->production cycle.

I got screwed over on that job and left about 3 years ago- not happy at all.

I spent about a week planning the complete destruction.

Then I realized I would spend the next 10 years watching my back, because eventually someone would figure it out.

I sent an email to an old co-worker and said, "Hey...you need to block this backdoor."

It was more for my own good than theirs. Very glad it is gone.

Remember that awesome support you were getting?

[ma1wrbu5tr]

Remember that awesome support you were getting along with your stable product? We laid off half our staff and didn't tell any customers leading to poorly maintained code and outsourced support techs who could barely speak English and had little to no training. Enjoy!

The biggest secret

[Major Blud]

You know what I don't tell my boss? That we use systemd.

Already know the fix but I like to travel

[seoras]

As a young engineer in my first job I was the point man for a new technology in our company called ISDN.
Back in the early 90's each country had it's own flavour of ISDN for market protectionism or just to be different.
Our product started offering an ISDN interface as well as the other older comms interfaces (X25 etc).
I was at the "bored" stage with the dev work when a nice little bug started breaking things among our European customers.
I could have simply stuck a 3.5" floppy in the post (this is pre-internet) but since I'd never been to Switzerland, Munch (in Sept), Paris, etc, etc I was eager to travel.
What made this ruse even sweeter was that when I got on site I'd pretend to debug for a 1/2 hour, then switch floppy discs, and -hey presto- it all worked perfectly.
Each time I the toast of the office I was visiting, as well as our company sales team golden boy, rewarded by being taken out for a nice meal and drinks as a thank you.
If I'd just stuck the floppy in the post it just wouldn't have had the same effect nor would I have seen some nice parts of Europe or tasted their fine cuisine.

Re:Already know the fix but I like to travel

[Anonymous Coward]

I could do that install of our custom database base remotely, but, sometimes, I like to travel.

I need to be onsite to properly install the patch, but I don't want to miss my kid's birthday. I will "try all day" to install the patch remotely and discover sometime tomorrow that the customer "has a nonstandard configuration," which requires me to be at their site next week (not now).

BTW, for several years I spent about 60% of my time outside of my local city. I was given a generous expense account and put up in decent hotels. Each "day" on a client's site was an automatic 8 billable hours, plus time for pre- and post-visit memos. I did much of my coding on the plane. I always volunteered to "sacrifice" to make the trip so spare others that "hardship." My high billable hours was one factor in getting promoted. The previous person in that position had traveled very little, but the internet came along just in time. I was able to up my travel time to over 80% with corresponding benefits while managing the team through email and rudimentary document sharing. It also enabled me to avoid much of the office politics and bickering. I got to know the clients well (mainly by spending expense account money on them, or letting them spend theirs on me). When the inevitable periodic downsizing purges occurred, no one dared fire me because the clients would be upset.

I left that job to start my own company. My first client was my old bosses who wanted me to do basically what I was doing, but they paid me twice as much as my previous salary in consulting fees for doing even less work.

I am deeply appreciative of the opportunity. I got thrown into troubleshooting the most difficult problems, so, while I usually worked less, sometimes it was quite challenging which kept my skills sharp. I got a chance to see the world, and accrued lots of travel mileage and hotel points which I later used to take the family on vacations I could never have afforded otherwise .I had lots of down time in hotel rooms to study new coding languages, techniques, and time to build my own library of music and digital processing apps, some of which I still use today.

Re:Dear clients:

[Rei]

Where I am, our code doesn't work with newer versions of a dependency library. Two developers have tried to work around the incompatibility, and failed. So until we can scrounge together enough time to redevelop the frontend from scratch, we're stuck installing old versions of the library, and just hoping that no OS changes render older versions of the library inoperable - otherwise we won't be able to upgrade OSes either.

That said, this doesn't fit the topic, because our boss knows all of this. We keep our boss well in the loop. He used to work as a programmer the software, and still does some work on it from time to time. That's IMHO how it should be.

Things work best when workers aren't afraid of their boss. I hate Machiavellian workplaces.

Re:How are these "secrets"???

[MtHuurne]

I'd file the first two under "things managers don't want to hear" rather than "developer secrets":

Managers want to have estimates for their planning, so they pressure developers to make estimates based on sometimes very incomplete information. The best way I found of dealing with this is to make an estimate for the work of investigating how long the actual work will take and only add the actual work to the planning after that investigation has completed.

When it comes to technical debt, in my experience it is often the developer pressuring the manager to give them time to do something about it and the manager wanting to postpone it in favor of feature development. Some of that pressure is justifiable, as polishing code can be a huge time sink and doesn't always repay itself. But in my experience developers don't shy away from talking about technical debt.

When it comes to building vs maintaining, I don't think it's the case that every developer prefers to build. However, there are different people who do well at different stages of a project's life cycle: some people are good at building new software from scratch, others are good at adapting and improving existing software. Instead of rewriting a project every few years just to keep the builders happy, I'd suggest moving them to a new (sub)project.

The other "secrets" shouldn't be secrets to any manager who understands software development. Developers are people too: they like playing with shiny new toys, they have strong opinions (sometimes warranted, sometimes not) and they may not see the big picture since they're focused on their specialty.

I have way less secrets than they.

[Qbertino]

I don't know about you guys, but I have always had way less secrets than they.
And I smell a dying project from 10 miles away and turn around and tell it to my peers and boss, straight to their faces.

"This is going to fail at stage so-and-so/in x weeks/months time because of a,b, and c.
If we want to prevent this, we have to do x,y and z."

Straight forward.

90% of problems I've had along these lines way because of bosses, PMs and whatnot not being honest with me. Or to stupdi/dumb/out of their depth to get a hold on the problem and deliver on their end.

Likewise, every time my PMs and bosses were honest with me, I had their back.

Need politics rather than tech solutions? I'll give you a technical buzzword ridden writeup/analysis that will get you anything.
Need nice and shiny things that move and people can click on? Consider it done.
Need to blow up that boring data with some nifty grafics and impressive spreadsheets? Done.
Need a devils advocate to point out where the problem is? I'll speak up with a techie voice in the grand meeting and all will shush and hear the clarions call.
Need me to pick the hot coals out of the fire with the customers IT dept? No problem, give me a first phone number and I won't stop calling until I got the exact right guy on the other end. And 10 minutes in we'll be the very best buddies.

I'm honest and straight forward, just about always. Be honest with me. If you're not, f*ck you and the horse you rode in on. I'm out and I hope your whole product/project/whatever goes down in a ball of flame. You can use me for politics, but you have to fill me in and I must see where the game is headed. But play me because you think I'm some replacable suit and not the guy actually buidling your actual product and I'm out and I won't have you on any project in any meaningful position ever again - you have proven your incompetence as PM/Boss/CEO.

That's basically the principle I live by doing this IT/development stuff, ever since. I'm the straight forward type, and sometimes people/bosses have taken advantage of that or just didn't catch the drift. But I'm getting better at noticing it.

Lot's of bullshit and stupidity in the web/agency camp, tough space to navigate in the honesty dept. The biggest problem always is when they don't know what they want, but for some bizar reason know when it needs to be finished and how much it may cost. Including a never ending stream of last-minute changes.

So, no, not any real secrets that can sink your business. Actually, more than once my product was mission critical and made the business possible in the first place.

Re:Build rather than maintain

[Snotnose]

I don't recall anyone patting me on the back for carrying a coworker's old code through several years of releases.

Years ago a co-worker's daughter drowned in their swimming pool. Made the local news and everything. I'm gonna call him Frank cuz his name wasn't Frank.

We were a 4 man team (yeah man, no females involved). A couple years before 2 of us worked under Frank, he was a great boss. Due to the company's matrix management system Frank worked for, oh hell, Bob. So, uh, Frank and Bob were a level above me, and we had an Indian dude who had been there about 3 months before, um, Frank's daughter died.

Frank was a hell of a contributor. Until his daughter drowned. Then he was a worthless pile of crap. I hate to say it, but his goal in life was to use a shovel to fill in that swimming pool. Know what? The 3 of us carried him. Frank did maybe 1/3 of his workload, the other 3 of us covered for him. Our immediate boss knew what was going on, and also knew Frank was a damned good engineer.. This went on for a good year, then 2 things happened. First, he filled that pool and started turning into a good engineer again. Second, I did the dumbest thing I've ever done and left that company for a startup.

Re:Be ruthless kids.

[Darinbob]

Just say that you worked on Big Iron and everyone knows there will have been plenty of Rust.

Re:Psst... Don't tell anyone

[flopsquad]

Dev: "Bless me Father, for I have sinned. I've been keeping terrible developer secrets. All our 'in-game footage' that supposedly shows off the new engine? Entirely pre-rendered."

Rev: "Go on."

Dev: "And I've been secretly coding everything in Rust, even though I promised the CTO I'd use a 'real man's language, like C.'"

Rev: "I see."

Dev: "And most of the day I'm not even coding. I'm posting on Slashdot and playing that mobile game from the Schwarzenegger commercials."

Rev: "Hmm."

Dev: "I lied on my resume; I said I worked for Google as a senior developer, but it was really a call center job with a company called 'Googe' that produces fake semen for German fetish parties."

Rev: "What sort of fucked up calls you must've... **AHEM** My child, these are grave sins to be sure, but anything can be forgiven by the generous mercy of --"

Dev: "I work on systemd in my spare time."

Rev: "I COMMAND THEE LEAVE, SATAN!"

Resume Padding

[Tablizer]

Were are a relatively small shop, and those devs with influence convinced management to switch to what seems the entire Microsoft stack, with service layers on top of service layers, and other middle-man gizmos. It's as if they get points for every service and service layer on the MS brochure they use. Pokesoft: gotta install em all! If you add a new column to a table, you have to update something like 17 spots. Dagwood wouldn't even eat this thing.

They are kicking KISS/YAGNI right in the balls. Either I don't get something, or they are trying to pad their resumes with enough gizmo experience to move on to Big Pay, leaving us suckers to babysit their bloated orphans.

When you lay off Joe, you doomed Joe's app

[Jeremi]

Remember the original Tron movie, where the software programs all looked just like the person who created them, except with neon duct tape on their clothes?

There's a lot of truth to that. The design of a piece of software will inevitably reflect the way its author thinks, his views about what the problem-space is and which techniques and engineering tradeoffs are appropriate, and the designer's own unique approach to problem-solving.

Moreover, the designer of the software is the person who has the most invested in that software's success, and thus the most motivation to keep its quality as high he is capable of -- other people may work on the codebase as well, but they are only step-parents, who may do a good enough job to keep things working (as far as customers can tell), but won't necessarily go the extra mile to make the software really shine, because hey, it's not their baby. To them, everything about the software looks like a bit of a mess, mainly because it wasn't implemented the way they would have done it. So why would they spend any more time on it than they have to?

So, when management decided to lay off Joe because they thought that with the app feature-complete they didn't need him anymore, they were unknowingly signing the death warrant for Joe's app at the same time. It won't die right away, since other programmers can come in, fix bugs, and add the occasional minor feature, but every time someone does that, the integrity and reliability of the codebase suffers a bit more, as the new developer's approach is different from Joe's approach, and thus the new code doesn't fit quite right with the old code. Eventually, development of the codebase slows to a near-halt, as the time, effort, and risk of making any further significant changes starts to outweigh the benefits that could be secured by making the changes. In another year or three, the app will be effectively dead, and the company will have to hire another Joe to write new software from scratch.

TL;DR: Programmers are not interchangeable parts.

Re:Build rather than maintain

[Anonymous Coward]

Frank was a hell of a contributor. Until his daughter drowned. Then he was a worthless pile of crap. I hate to say it, but his goal in life was to use a shovel to fill in that swimming pool. Know what? The 3 of us carried him. Frank did maybe 1/3 of his workload, the other 3 of us covered for him. Our immediate boss knew what was going on, and also knew Frank was a damned good engineer.. This went on for a good year, then 2 things happened. First, he filled that pool and started turning into a good engineer again.

The message I'm receiving here is Frank needed time off for family leave, your worthless fucking company wouldn't give it, your worthless fucking country didn't have any kind of social safety net to allow Frank to quit so he could grieve properly, and you worthless excuse for a person won't even acknowledge these things. Your society is shit, and you are shit. Fuck you.

It's Very Simple! Hygene!

[mallyn]

Where I worked once, some of the developers had a very effective weapon.

Hygene.

Simple. They forget to take a shower for three weeks prior to the code review meeting with management and program management.

The managers will keep that meeting very short and won't bother to ask the important questions.

Re:Y38

[behrooz0az]

If only it were that simple.
I really envy you for never having had dealt with anything more 'complex' than that.

"I'm working on it now..."

[corychristison]

"I'm working on it now... Should be ready next week!"

*Alt+Tab back to Firefox with Slashdot open*

Germans get all the best fetish parties...

[TiggertheMad]

Dev: "I lied on my resume; I said I worked for Google as a senior developer, but it was really a call center job with a company called 'Googe' that produces fake semen for German fetish parties."

So....is this product, is is available for import?

Re:Germans get all the best fetish parties...

[crtreece]

Import? You can get it on amazon, multiple brands from multiple vendors. Bad Dragon, and others, make adult toys that shoot the stuff out. From the description

• Resembles the look, feel, and scent of authentic semen
• It is white, creamy, and musky
• Non-staining, it stays slick and cleans up easily

Time off - not necessarily

[Bruce66423]

Once the initial shock is over, having a place of work to go to and someone other than family to spend time with may well be the support the guy needed. That the others in his group took the load sounds absolutely right - though management might have been more willing to reduce the load.

Re:Psst... Don't tell anyone

[TheRaven64]

This is exactly the sort of negativity which shows how the open source community is abusive and unable to cope when a great new idea comes along that throws away all those bad concepts in Unix, just because we're right and you're wrong.

Nonsense. Compare the reaction to systemd with the reaction to launchd (XNU) or SMF (Solaris). Most people who have had contact with either of the latter regard them as imperfect but significant improvements on what was there previously and, if they're using systems that don't ship with them wish that they did (or, ideally, something taking the good ideas from them each and combining them, leaving the bad ideas behind). No one is complaining about replacing traditional UNIX tools with something better, they're complaining about replacing stuff that mostly works with something that throws all of the last few decades of software engineering away.

Re:Build rather than maintain

[SuiteSisterMary]

Or, alternatively, the company recognized that he was a mess due to the death of his daughter, and didn't fire him for the drop in productivity.

In addition, his co-workers also recognized this, and carried his workload while he processed his grief.

I don't see anything in the parent post indicating that either the company or the poster had a problem with any of this; indeed, the poster says that they made a mistake when they left that company.