Current design philosophy is that the user should be presented with fewer options, fewer ways to do things. Users shouldn't be empowered to created what they want, but should be "guided" into building what we (software designers) think they should have. That is almost verbatim from our company's product and C level officers and is echoed without deviation by product owners and strategists in our company. Holy crap what a bunch of presumptuous, arrogant, idiots. That holier than thou attitude promotes disdain for the customer: "the customer doesn't know better, so let's prevent them from doing it any way but X." The focus is entirely on what's easier for us, not what helps the user solve their problems. That's not a service oriented anymore, that just a bunch of pretentious dickheads that are on the road to losing customers.

Test coverage percentage mandates.

I keep waiting for somebody, anybody to say they're best all nighter wasn't spent coding.

I don't have a cs degree (my degree is in aerospace engineering). However, I think the question is valid for any degree. The answer depends on the field. When sitting in on interviews over the years, the type of degree for programming jobs never seemed that important if there were experience involved. So, if the job description required 2 yrs exp. in X, then that experience trumped the degree type. If the job was for a junior dev right out of college, then degree type becomes one of the most important factors. So, for that first job, it's important that you've got a degree (any degree) because it shows that you can accomplish that chunk of work. Having a cs degree at that point does provide a distinct advantage over those with medieval romantic french poetry degrees. That's the game, and don't fret if 95% of the material you study in college you never use again. The point of studying it wasn't to use it immediately (go learn a trade if that's your bent), it was to both test you and to expose you to specialties that you might want to do later.

Company is replacing "[insert software tool here]" with one that is "better", that "helps us scale", etc. Coincidentally, this always happens when the management muckety muck in charge of that area is replaced by someone from outside the company. While new ideas are good and sometimes needed, I honestly have not ever seen any manager in that position do anything but a "replace what you have with what I used at my last company" exercise. Every day that goes by lowers my expectations of any management figure or exercise. After 3 decades, you'd think those expectations would be low enough to not be surprised anymore. And yet, that's not the case.

WisdomTeeth--;
WisdomTeeth--;

mild rant. Android phone updated last night. Phone rings this morning. Swiping right to answer does not work. After putting glasses on, I can read the miniscule "swipe up..." text. OK, they put some words on there, not their fault I tried to answer the phone without glasses. But, why the world change how the phone gets answered? What it really a problem? I've already discovered a new one: reaching into my pocket to get out ringing phone caused an accidental swipe up so the call was answered before I got to look at the caller id info. Just another thing changed that wasn't broken to begin with. And no, I could not find a setting to change it back.

The software eng. pendulum will swing away from scrum/agile nonsense after years of those things contributing mostly inferior half baked beta software to customers. Unfortunately, it will swing too far the other way but will somehow also manage to claim roots in the musings of Demming and Japanese auto manufacturing when Leave it to Beaver was still a hot TV hit. In other words, the org charts will have different titles, and different buzz words will be used, but developers will still have archetypal pointy haired bosses.

Fixed a high priority bug today just prior to release. There was 100% test coverage. The tests pass both before and after the change. The product behavior is correct now where it wasn't before. Just one more reminder that test coverage does not equate to either quality or correctness. Tests are alarms (at best), and quality of tests are no better an any chunk of code. All tests have costs, but not all have value. All reasons why I am skeptical of the value of code coverage, TDD, or anything that posits that "all tests are good".

The emphasis on "team" to the exclusion of the individual (thanks in no small part to Scrum) is destroying the software developer career. It's a pendulum. There are always team/company goals AND personal goals. However, these days, the rhetoric is ALL about the team: everybody on a team has the same title, get rid of people who don't conform to some "collaborative", "open space", "colocated" ideal, etc. OKRs are entirely about giving everybody the exact same goals. I remember sitting down with managers throughout my career to talk about where I want to be in a year. What skills I wanted to explore. There were no guarantees, but the generally accepted idea was that nurturing the employee helped retain the employee. Now, there is only the idea that every developer should have the same "T-shaped" skillset, that all team members are the same, that all teams are interchangeable, that all developers are nameless cogs. It is demoralizing. If I were to give any advice to those looking to enter the industry as a developer right now, it would be "Don't". Because you will be told that being a "hero" is a bad thing. In what other industry does management tell its producers that they don't want people to go "above and beyond", and that if they do, they won't get credit for it because the credit always belongs to everybody.

IMHO, the material design floating button (just like the one used here) is horrible. Why would a control ever hide the content behind it such that the user must move the content. I dislike it intensely and think it is just really bad ux.

The new Android messages color changes using Google material design 2 looks like the Easter Bunny shat all over my phone.

The term "technical debt" is poorly used. I hear folks of all stripes and roles proudly proclaim that they've "reduced technical debt" in some way. It's used as a catch all to describe some kind of supposedly beneficial change. I think it's just more software process word salad. Mostly because there seems to be some assumption that "Yay, that stuff that was changed is no longer a problem" when odds are that it will be changed again before too long for more "technical debt reduction". Software changes over time because the requirements change over time. I don't see the need for the phrase at all, and I think using it gives some false sense of accomplishment when really the constant change of code is the normal state.

Dev management high muckety muck: "Even though I never speak to or communicate with any of you personally, my Jira charts indicate that you are sub optimal." Absentee managers can't help but be dickheads.

I don't care for Slack. There's nothing wrong with Slack. I just don't find a need for it when I already had email + IM. You know what I hate, though. People who show up one day and force Slack down the throat of an organization because "collaboration". Now, every day I hear "I didn't see that. Oh, you put in on Slack? Which channel?", "I put in on Slack", "I don't ever check my email, I just have Slack open", "Instead of filling up your inbox, I'm going to post this on 15 different slack channels" (which is why I have all the channels muted). All from people who can't type 10 words in a row without an emoji.

During a period when devs had been told "The board has been promised that we are improving quality, so you must not do anything but write unit tests", I wrote a unit test that compares the number of system colors in .NET to a constant. It's still running today (a couple of years later).

Head of PM and head of UI/UX at my company today expressed to me that they are going to change how user created content is displayed because they know what looks better. I don't think they understand what user created content actually is. I can't believe these people are in charge of anything. I swear they just belong to a club of management types that read the same blogs and follow each other from job to job destroying everything in their wake like a locust swarm.

MVP = Mediocrity Via Procrastination

Me: By mandating code coverage pct. (very high ones) and integration test coverage pct. you are building an ever growing Rube Goldberg machine that you will end up spending most of your time fixing rather than working on the actual product.

Them: (Staring and whispering in the background). Wow, you must be stupid. This is how you created quality software.

...time passes and now most time is sucked into figuring out why all branches have failing integration tests all the time.

Me: I told you so. I've seen it multiple times. How about doing it differently?

Them: (staring and whispering in background). You are stupid. This is exactly how quality software is built. We know what we are doing. You must like waterfall.