First job, support technician on a years work experience from college. That was the year the great storm brought down trees and power cables over half of southern England. The office where I was working was without power for three days. Boss still insisted that I came into work (a journey of several miles over roads which only passable on foot) to "provide support" for users who were not there on computers which were unusable.

Happy days.

Maybe they were trying to keep you employed/paid.

We had a slowdown in a manufacturing warehouse due to a computer issue. In order for us to get paid, they had us work to peel stickers from and wipe marker off of the previously used plastic bags so they could be reused. It would have been more efficient to just use new bags, but they could only justify paying us if we were doing something.

The inverse of this is also useful:

// Dear maintainer,

// The code which follows was hacked together under desperate pressure.

// It's not smart. // It's not doing anything really subtle. // It's the only thing we could get to work in the time.

// If you want to chuck it and replace it, you absolutely should.

Hey, that one I actually can replace with self-documenting code! Oh joy!

It's useful, until you realize you have this on 90% of your code.

That's when a full rebuild can be justified.

I'm doing that atm, but I think my predecessor lacked the humility to admit that his code was bad, which is how it went up to 150K of code that basically concatenates XML, converts it to JSON and concatenates HTML on the front-end from the result.

Best: if it's complicated, it's wrong.

Worst: almost no business deliverable is one tenth as important as the people telling you to give up your time, strength and sanity in order to achieve it will tell you that it is.

I’m always amazed by how irrelevant the objectives produced by business planning processes can be. It’s so common to hear things like, “yes, we know this won’t ever end up in a product, but it’s in our objectives, so we have to focus on it”. The task was leviathan and impossibly complex, so it doesn’t get accomplished, and then every quarter the goals focus on a smaller piece of this until the group delivers some result, which is celebrated internally but now obviously irrelevant to the business, so everybody gets laid off, except the people that set the objectives in the first place. Yeah, you can easily pour your life into something that is completely meaningless, even to the company that is paying you to do it.

Words which serve no purpose have no place on the page. But purpose varies with context.

If you're writing a guide to a new API, or a functional specification, then it pays to be as direct as possible. But if you seek to engage or enrage, to persuade, to illustrate why something taken as good is unmitigated folly, or just give people a reason to come back and read more of your text, then you may need more than a long, drab procession of purely functional sentences.

There is more to eating (and cooking) than the simple absorption of nutrients, and there is more to reading (and writing) than the simple absorption of facts. Unadorned simplicity is not automatically good. I've never managed to get past the first chapter of any Hemingway novel. Hell, the only Hemingway short story I've finished is that one that's six words long. I'd rather read Charles Dickens than Richard Ford, any day of the week. Give me the baroque and the beautiful, not something that's been stamped out by a soulless writing machine.

This debate over the "directness" of modern writing really seems to be unique to 21st century English. We have a very direct and prosal language and a culture which places efficiency above all else.

Neither is bad, but our writing style is really interesting.

There's a much quoted aphorism with regard to getting feed back on fiction:

"If five people tell you there's a problem, they're almost certainly right. If they tell you how to fix it they're almost certainly wrong."

Getting feedback from the compiler is like this in spades.

While the act of trying to change, or even understand code which you wrote a while ago, will very likely to reveal it to be overly-engineered, incomplete, confusing, or some combination of all of these, it's very unlikely to come with a message saying, "And if you change it like this, all of these problems will go away."

You only get that by reading design advice and trying to apply it to your own work, and by looking at code which turns out to be better than yours and working out where the differences lie.

As others have said, I wouldn't worry about C++ going anywhere soon. The sheer amount of historic code out there, and the difficulty of replacing that code with any of the potential alternatives mean the language is still likely to have decades of life in it, even if it did not continue to change and evolve.

Whether a change to more C++ development will be good for either you or your team is a more open question. I was primarily a C# developer and got into C++ because I ended up in a company where it was being used and had to be supported. I have never coded in Swift and have done almost nothing with objective C, so I will not comment on them. I have been coding periodically in C++ for the past five years, and to me it always feels slower, more difficult and less enjoyable to write something in C++ than to do the same thing in C#

It is true that C++ is a powerful and flexible language and there are places where you will be hard pressed to find anything that works as well as it in terms of raw performance or fine grained control. But because of its age, many features which can be taken for granted in a language like C# have had to bolted on to C++ and lots of those bolts look ugly. There is also a lot in the language, and if you're going to use a language feature then it really helps to understand it in depth, because its depressingly easy to write code that is badly wrong in ways which will not be easy or quick to detect.

If your team's need for C++ support is going to be a long term thing (ie they're still going to be needing you to work on this stuff a year or more from now) then it may be worth their time and yours bringing you in to work on the language. If not, you may well cost more in terms of what it takes to get you up to speed than the benefit once you are fully productive. (This, of course, will vary depending on many factors such as the quality of the code base, the range of language features it happens to employ, the amount of support you can expect from your co-workers and how competent you are at learning a new language. These are things that only you and your team are able to decide.)

That only works if the user of the software has freedom of choice over the software they use. For the majority of commercial software sales that is not the case. Commercial software is overwhelmingly brought by companies who dictate to their staff what software they must work with.

And the companies which shell out the big bucks to keep terrible software products shambling along for year after year don't really do it because they hate they staff and want to screw up their happiness and productivity, although it can often seem like that. They do it because either there isn't anything else which does the thing they need to keep doing their business, or becuse they have so much past history and experience of using that product that it would be ridiculously expensive and dangerous to change or because they believe that the pain of supporting fifty different users using thirty different incompatible pieces of software to do the same job is worse than the pain of having all those users screwed up at the same time by an upgrade that goes bad.

None of which are unreasonable positions to take and all of which push the responsibility for improving the situtaion back to where it belongs: the writers and suppliers of the upgrade. Upgrades should adopt a hippocratic principle: the change that YOU make to the system which I have paid for and which I rely on to do my job should not suddenly impossible costs or make it impossible me to use it to do something that I was doing yesterday.

And that, in turn, is not going to happen, unless and until customers (both commercial and private) have the right to compensation for lost time and earning imposed by changes which benefit nobody except the software vendor.