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.
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.
That did not go down well, even though it was a great product, styled etc. had all the bells and whistles.
Enterprise customers are more likely to use a product that they paid $1M over the same product that they "only" paid $40K.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Over the years I’ve come to realize that what people call politics at times is just having interpersonal skills.
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.