> Later my boss told me not to do that again because it caused havoc with schedules and such.

Did you talk to anyone about your plans before you brought in the demo or let them know they were solved problems? Often these sorts of reactions come down to your boss not wanting their team to lose their jobs because of the perception that it can all be handled by one person who's happy to work weekends.

I wasn’t politically savvy enough to do that. Honestly, I don’t want to be. The reality was that the project really could have been done in a month by a couple of people. It got turned into an enterprise project with multiple unaligned teams with Gantt charts and milestones and everything.

Again, and I can’t emphasize this enough, for a Django CRUD app. It was a 4 person-week project turned into a major ordeal. No one should have lost their job; they should have been put to work doing the thousand other more productive things they could’ve been doing instead.

> No one should have lost their job; they should have been put to work doing the thousand other more productive things

I think that's exactly why you should have talked to your peers and let them know they were solved problems, unless the overengineering was intentional.

Sometimes you can explain things and not be heard until you demonstrate them. Then they have to accept that you’re not just BSing, that your idea does have at least some merit.

Also, never underestimate an enterprise’s ability to convince itself that it’s too big and complex for off the shelf tools. Sometimes that’s the case. Very often it’s not.

In this case, I’d also watched this all take shape over a couple of months. Being the new person, I assumed it was some necessarily complex beast that was beyond my scrappy experience and calling for Serious Engineering. Once I recognized it for what it was, I knocked out my weekend project shortly afterward because I couldn’t get it out of my head. As much as anything, I had the need to see if it really was as straightforward as I thought it could be. I didn’t sit on my idea for months while they toiled. I watched them toil for months before I understood the core of what they were making.

> Sometimes you can explain things and not be heard until you demonstrate them.

1000%. In my experience this isn't even a "sometimes". It's the opposite. Explaining/arguing in the abstract why a significant directional change is needed has little persuasive power. If you can demo something, you actually have a fighting chance, even if it barely works. It can be a working product, it can be charts, it can be a semi-functional mockup, whatever, but you have to show _something_ that isn't just talking about it. I learned this the hard way after advocating for things and getting shot down too many times.

> Also, never underestimate an enterprise’s ability to convince itself that it’s too big and complex for off the shelf tools. Sometimes that’s the case. Very often it’s not.

Couldn't agree more with this, also. I've seen an astonishing number of homemade job runner systems, homemade message queues, homemade databases, homemade web frameworks, homemade languages, etc.

One can make the argument that this is how technical progress happens, and in some sense, that's true (we wouldn't have a lot of nice things if this never happened), but it's rare. Like, really rare. Most shops would be better served with e.g. Django, Postgres, and HTML, deployed on Heroku (or your Heroku-equivalent of choice) rather than spending hundreds of human-months building "an ad hoc, informally-specified, bug-ridden, slow implementation of half of $COMMON_OFF_THE_SHELF_TECHNOLOGY".

So, I completely agree with you.

Wow, that just gave me a PTSD shudder. I started at one shop and they had a small team continually fighting against their home rolled message queue and task runner. After joining in the fray, asking about a million questions about why this is done like that, etc., I talked them into replacing it with a stock Python Celery setup. The original author of the local version protested, understandably, explaining why it couldn't possibly work.

It worked. It didn't require handholding. It continued working after I left there.

My coworker was a smart guy, but he got it in his head that their specific use case was something that couldn't possibly be served by a COTS project. Turns out, it could, and easily.

This story is more common than any of us would like to admit, myself included.

I can say this with some confidence because as a junior developer, I was often that person, and I didn’t really understand the collective lessons contained within e.g., Rails, Celery, etc.

I was enamored with doing something “cool” and “interesting” and I didn’t realize that this was distinct from and not actually as cool as solving someone else’s problem on time and under budget.

Easier said than done. If a company is in that situation already it's due to a reason. A new middle-manager would have a hard time convincing anyone, let alone a new IC. IMO you just go down with the flow and enjoy your new salary (which should hopefully be higher than the previous one) or start looking for your next gig

And it’s possible that it wouldn’t have mattered anyway.

I got a green light to do an integration in a week alone, which was planned for a team of 5 for half a year. We knew that it cannot be that much. So I delivered…

It was never used. It was purely political. The integration didn’t happen because it was “half a year”, but because middle management didn’t like the idea of integration for political reasons.

> I wasn’t politically savvy enough to do that.

Over the years I’ve come to realize that what people call politics at times is just having interpersonal skills.

In this case, more like common sense.

I mean yeah what did you think politics meant?

> Honestly, I don’t want to be.

I don't get it.

On the other hand, programmers are happy to work with AI, which is incredibly limited and a pale shadow compared to the real "I" in educated and experienced meat brains.

Also, networking - in both space and time (among the living, the latter with the dead, one way from them to us) - is THE gigantic advantage of humans. Not to want to bother with it is an equally gigantic mistake, if you want to use being human to more than a tiny fraction of its potential.

If you are interested in creating solutions and useful systems, "politics", human networking, should be THE number one priority. Long before anything technical.

Important scientists and engineers were great networkers and communicators. They also knew which connections where worth making. Just like in the brain, fewer good connections are better than wildly cross-connecting everything.

What you’re saying is true. Yet, I can only willingly go along with so much terribleness before it hurts my soul. We only have so many days to do things we care about. The thought of throwing away 6 months of them for no defensible reason horrifies me, and I can’t, won’t, participate.

Edit: for a compensating control, I pair with senior leadership I can directly ask about this things. “Hey CTO, is there a reason we’re doing this thing so ass-backward? No? Can I go fix it then? Thanks!” Or, “oh, because we’re stalling to avoid this horrible customer’s demand, and no one’s really going to be working on it as their day job? Sigh, alright, I’ll look the other way.”

I let them be political so that I don’t have to be.

Some people like blowing things up, even if it doesn’t necessarily make sense at the time.

Some people like building things, even if it doesn’t necessarily make sense at the time.

Some people like meeting other people and making money, etc, etc.

Know thyself.

I've been in a similar situation, with a laravel product quoted for over a million and I quoted 40K and did it all.

That did not go down well, even though it was a great product, styled etc. had all the bells and whistles.

> That did not go down well

Enterprise customers are more likely to use a product that they paid $1M over the same product that they "only" paid $40K.

If it was a one-time contract and you get paid for it, what they do next is their problem, not yours.

It was a case of pay $1M and take no responsibility vs. set a budget of 40K and own it internally.

When salesforce leaks your customer's information, whoopsie! not our fault! it's salesforce!

And yet they're far more likely to have the leak. BASICALLY.

In fairness to Salesforce, it was the garbage third party apps in their ecosystem which got compromised and did the leaking, not Salesforce themselves.

you got paid the $40k though?

Nope.

You’re doing God’s work. Don’t let the bastards grind you down. Keep building.

I couldn’t help it if I tried. It’s who I am.

I'm not good at office politics, but I got better at not caring. Understanding what is erroneous stimuli, as an employee you don't have to respond especially if you aren't noticed. This is fairly easy for engineers, even lead engineers. Anywhere there is a buffer between you and other stakeholders.

Occasionally though, I do get thrust into it, mostly during a company pivot about something I wasn't hired to do. All the personalities to manage, I 100% fumble, but still deliver.

Omg! Who the hell cares if the "boss" got a heads up. When I'm in engineering or you're in engineering with me, we party the same way: better is better.

The bosses - hell management's job leading into organizational culture - is to stop politics from derailing good engineering and customer satisfaction.

It's not too tough for me. Now that you know where I stand the other side better get it's act together.

Drowning in politics helps nobody including the boss. It's a net loser.

Now I'm practical and empathetic: a surprise can bring heat. But then you breath and get a grip. Cool. But thereafter the right things better get done. Politics for a day - np - politics sapping know how making cynical SE'S think twice? Never.

I learned a lot from that job, mostly how not to lead people. Subsequent jobs that I’ve been at for longer stints have placed much more emphasis on delivering good work than on building complicated plans to someday hopefully maybe consider delivering good work.

replace your boss

That’s what I did here, by going to a new place that wasn’t fundamentally broken.