Selling your work is distinct from simplicity. Despite the headline, the article is mostly arguing that how well you promote your work is the most important metric when it comes to promotions. This jives with my personal experience & advice from managers.

There is another facet to it as well, if it really makes sense to solve it via code or could it be more effective to handle with a manual process.

The hard part is that its a cyclic problem, you learn the importance of simplicity only by observing how complexity may not always be adding value. As a principal or staff if you suggest the engineers to simplify things, they may even see it as a missed opportunity for promotion.

I was promoted for getting rid of multiple services in favor of a small compact implementation.

I also promote and advocate for people who push for simple solutions with as little infrastructure as possible.

I've been promoted several times for adding business value, complex or simple in implementation.

Saving every team from doing X manually, saving so and so many engineer hours per year. At cost Y per year instead in one team. The higher X and lower Y the better.

Backups did not exist. Now they do and work every time.

I wrote the top customer appreciated feature, associated with an increase with X increase in whatever metric.

"It was really hard" shouldn't come into it, or not as much by far.

Hopefully those people who write simple code become founders

As a /former/ EM at an almost-household-name-tech-company, I can explain.

First of all, unless you're at a tiny startup (where quality of engineering isn't even on the horizon), you don't really get promoted by your manager. You get promoted by your manager's manager. Your manager simply "proposes" your promotion, almost as an idea.

Obviously your EM doesn't wanna propose ideas that will be indefensible, so the decision to propose you is a function of roughly four variables:

0. How consistently you've shipped stuff. It can be the most complex, terrible, haphazardly put together piece of shit, implemented in 6000-line functions, but if it ships when you said it would ship, and the feature works on launch -- really works, without causing incidents and headaches over the next two weeks, you're golden

1. How much effort you made in terms of energy exertion. This is usually counted in hours of work. You're a lot more likely to get promoted if you spend 16 hours at the office, even if 15 of those are just watching mountain bike review videos in a small tab opened on the side, with your noise-canceling headphones on

2. How much enthusiasm / good intent / positivity you exert. Engineers who are "excited" about the company and the privilege of having a job in it and are demonstrating creative thinking in the interest of "changing the world" (read: "increasing shareholder value") are more likely to get proposed for promotion than those who know better

3. How much everyone around you likes you. The proverbial "soft skills". If everyone around you says "that person is incredible, I love working with that person, they're so smart / hard-working / nice / pleasant", both in public and in private, you're much easier to promote

With rare exceptions, your direct manager probably understands pretty well who's actually doing what, how, when, and how much, in terms of substance and not fluff. But their manager is too far removed from it all. Their manager, in fact, likely wants to make sure there's no favoritism or anything funky going on, so when your manager proposes you for promotion, their manager wants to see objectively measurable stats, proving that you deserve the promotion.

It's really difficult (read: impossible) for your manager's manager to tell an easy project from a challenging project made easy by you being so competent. Your manager's manager wants a war story, with dramatic character development, and an unlikely victory by the protagonist, against all the odds. Yes, during public Q&As they will say that they prefer you work smart, not hard. That it is foolish to measure programmer productivity by lines of code written or number of hours spent with noise-canceling headphones on at the office premises. What they won't mention is that they simply have no other way of measuring programmer productivity. Go ahead, ask them during the next all-hands. You'll get nothing of substance. "Here at ACME, we trust your manager", they will say.

So.

When your manager walks into that 1:1 with their boss, their boss wants to hear that you have, single-handedly, written gigalines of code, 16 hours a day, clicked <3 on every CTO message in the Engineering channel on Slack, and managed to do so without making everyone else in the company hate you.

Nobody who controls your promotion ever actually reads your code, or understands your solutions. Nobody ever loads up your architecture diagram or your implementation when discussing your promotion. Something to keep in mind. People in a position to give out "career rewards" are too busy, distracted, and uninvested in you personally to pay attention to anything other than quick, easily observable and defensible impressions.

* in idiotic organizations.

I've was promoted for producing a significantly simplified replacement for an existing system that was critical. it happened because the culture rewards engineering excellence.

Refreshingly non-slop write-up, nice!

One angle is also... when you hear: "well yes you delivered on time and it works, but this is because it was an easy task"

Run!

I went to town on this in a blog a few years back "The Common Sense Guide to Not fucking up Your Business or Organization." <https://rodyne.com/?p=2024> as the action described in the original article is usually one of the first clues that something is wrong. I've seen many a good person leave companies and IT budgets subsequently balloon out of control with a completely laissez-faire attitude by senior management. I wish more CEO's would pick up on this stupidity.