OTOH, I was hired by an enterprise that was many months into a giant backend rewrite. After wrapping my head around the many plans, I realized they were rewriting Django, badly. One weekend I prototyped the whole thing… in Django. It worked. It met the specs. It was a CRUD app with a REST API.
I came in to work Monday morning, showed it off, and inadvertently triggered a firestorm. Later my boss told me not to do that again because it caused havoc with schedules and such.
So I quit and found a better job. Sometimes the new guy can make a better version themselves over the weekend, not because they’re a supergenius, but because they’re not hampered by 47 teams all trying to get their stamp on the project.
(In before “prime example of overconfidence!”: feel free to doubt. It was a CRUD app with a handful of models on a PostgreSQL backend. They were writing a new Python web framework to serve it, complete with their own ORM and forms library and validation library. Not because the existing ones wouldn’t work, mind you, but more out of not realizing that all these problems were already sufficiently solved for their requirements.)
In the beginning of my career, I've been once told by my senior management that I should never again:
1. Optimize things so that they work 10 000 times faster because it makes us look incompetent (must be done slowly to show gradual progress).
2. Brag about such optimization (to stakeholders) without first synchronizing this with them (so they can brag proportionally to their pay rate :) ).
This is the prime example of Law 1 of Robert Greene's "The 48 Laws of Power": "Never Outshine the Master."
The core principle is to always make those above you - your bosses, mentors, or superiors feel comfortably superior.
If you display your talents too aggressively, you risk triggering their deep-seated insecurities, which can lead them to sabotage your career or remove you from your position.
Galileo Galilei handled this really well. When he discovered the moons of Jupiter he strategically named them after the ruling Medici family.
By making the discovery about their greatness rather than his own intellect, he secured their lifelong patronage.
However, if your superior is a "fading star" or is clearly about to fall, you do not need to be merciful. In these cases, it may be strategic to outshine them to hasten their downfall and position yourself as the natural successor.
Sure it has been codified into a "law" but really this is just basic social skills / emotional intelligence which engineers on the spectrum struggle with.
If you've spent any time in a large enough organization you realize quickly that hierarchies form based on status, power and influence & not necessarily technical merit. No it's not "the best person for the job" that rises up and tells you what to do.
Casually solving a problem that required a lot of resources and personnel has big implications in the power dynamics of the org. This is like setting off a nuke. You don't just do this unless you are prepared for the blow back or can easily consolidate attention & influence in the immediate aftermath.
Take a look at OpenAI's corporate politics for an example of how this works in practice. All the key talent that defined the company has left or was forced out and will likely languish in whatever ventures they start next, all because they don't understand how humans operate & how to drive change by aligning incentives.
It’s hardly basic social skill. This is an executive management skill set. That’s the advanced game.
The basic social skill is to avoid conflict and seek acceptance. Go along to get along.
One wouldn’t rewrite the app on one’s on recognizance without peer approval first if this is your vibe.
some people discuss these dynamics as sheep versus goats. Social stability was more precious due to scarcity, while goat behavior included 40 armed men killing their rivals with swords (and better if the rivals do not have their own swords). Many, many parallels exist in mammals that live in groups. You might be surprised at the details of how some mammals actually behave in real life!
Competent management says:
"Look how clever we were to hire this person and put them in the right place at the right time! We are now ahead of schedule and are reallocating teams."
There's remarkably little competent management.
My rule had always been "hire people smarter than you and give them everything they need to succeed". Set a clearly defined goal, ensure understanding of the reasons behind it then provide the support the team needs to make it happen.
doesn't even need to be "smarter than you", just realise that as a manager your job is not to build the product, it's to build the environment in which the people building the product can thrive and build the best product they are capable of.
Ditto. And then celebrate them like crazy for every win and give them all the credit, even if you helped. Who wouldn't want to do their absolute best work in an environment like that?
It seems like you are suggesting it is lamentable that a group of people with the analytical intelligence to create a technology that has changed the world, don't have the social intelligence to be irrational when that is called for? Shouldn't we instead hate the game itself and lament that leaders can't behave rationally? In my more frustrated moments I wonder about a world following a disease that eliminated all neurotypical people.
But then he went on to spite the pope for no good reason, leading to all that trouble with the church.
>>> Galileo Galilei handled this really well
Errr… Galileo was asked to write a book discussing both sides of the heliocentric / geocentric debate … and so wrote a book with two characters having a debate while walking in a garden - one named (I paraphrase for effect) “Galileo” and one named “Pope Simplehead”
Needless to say the next twenty years under house arrest gave him a lot of time to think about character names :-)
Thank you Machiavelli
great perspective and wisdom nuggets.
Sounds like when I was asked to give minimum hardware requirements for something doing backend processing (receive text submitted as print jobs, massage, send to printers).
The requirements as they went out were much higher than they needed to be, because I decided telling them that we weren't stressing anything on the obsolete NT desktop repurposed as the test system might not please everyone.
This was the moment I’ve stopped putting any effort in my work.
IMHO I think the best any engineer can do in an org is to ask "what is the highest value problem to solve for the business" and "can I solve it".
"I made this x times better" is not relevant to _most peoples in any org_.
That's the dark secret. Nobody cares how good of an engineer you are _unless there is a fire to put out_. After which you get pat on the back and back to usual business.
There are situations where years of impeccable, high value diligent work is rewarded.
But what is more common is that the rewards go to those who are in politically expedient position to get the rewards. Favourites, culturally aligned folk, etc. And sometimes it's not even about you or your boss, but the politics in the organization at large. "You are not allowed to promote anyone due to budget" is a very common thing.
So I guess what I mean to say is if as an egineer you want to retain your sanity, when at work focus on maximizing business value. If you know a kick-ass solution that is 10000x better than industry standard go with it but know this - nobody will care! Nobody believes _someone in their org_ could have beaten _industry standard_ unless the org is very unique. What you get is small increase in your reputation - and sadly nobody recognizes how hard that was. Maybe you will meet some other engineer at some point who has tackled that same issue - and then you can bond over the solution.
A large part of software ecosystems is about business, politics, and the large scale impact of technology.
Saying this as an IC whose previous tasks at previous employer could have employed _teams_ but since we were allowed to deal with them smartly it was just me.
So if you know a 10000x solution to a problem many people have - that's a good opportunity to consider can it be productized!
The sad corollary to "you will be noticed only if you put out fires" is nobody actually realizes the elegant solution you shipped will stop tons of these fires from happening. Rather the reaction will be "that looked simple and easy so probably is not important".
And on the other hand, the complexifier (you know the type) ships rude goldberg gizmos just waiting to go off-kilter - and then they come in and save the day - and get rewarded. This creates a very strong "emperor has no clothes" syndrome until reality hits the organization really hard in the face. More often than not these horrible solutions are "good enough" and the show just goes on.
Don't take it too seriously! That's what people are like!
> The sad corollary to "you will be noticed only if you put out fires" is nobody actually realizes the elegant solution you shipped will stop tons of these fires from happening. Rather the reaction will be "that looked simple and easy so probably is not important".
Or that reaction is really "that looked simple, easy and like the last 10 "elegant solutions" that caused fires".
Yes! There are also very good reasons for deep skepticism.
Just smear the heck out of them to stakeholders, after implementing something big and climb over these incompetent shmucks and watch their fall
Also make sure to brag using terms that non-technical people can understand and want to hear. Less "we stopped writing an in-house CRUD that was Django but worse" and more "we saved months and increased security by adopting a market leading solution and it works better with AI too".
While probably facetious, those with power (who you aim to smear and replace) will save themselves and work together to fire you ASAP. This is not a winnable battle nor strategy for success, unfortunately.
This 100%. I once got disciplined for insubordination for skip-leveling my "manager" and disregarding their instructions when she started telling people on the team to work on something totally non-critical, when the team had a demo in a few days that wasn't ready yet, with a client that was already unhappy, on an 8 million dollar contract.
I didn't hang around that place long.
Did they know something you didn't know, about that demo/client? i.e. misaligned incentives?
The opposite, they were 12 hours timeshifted and out of the loop managing a side hustle while I was interacting with the client daily.
If I can only go back in time to 2007 :)
See also, test the flammability of every bridge you cross.
Unless you were working at a startup full of very naive people, I gotta say this sounds made up.
If people at startups weren't slightly naive, they wouldn't attempt an endeavour that has such a low success rate :)
This happens all the time.
Basically build vs buy. The problem is on the 'buy' portion of looking at things the company failed. So they took who they had on hand and built something. It took a fresh perspective to say 'hey have you tried this' and looks like they did not want to hear it. I would say the right choice was made to move on.
This is wildly common. At that point they were committed to the wrong path at 'above my pay grade levels'. Once you get that buy in you better do it that way. Most companies will not pivot unless the champion for whatever is going on is removed in some way.
At 'my paygrade' I can prototype tech but I better make a good case why I need everyone else to do it too. If I dont I will be summerly ignored at best, at worst 'the guy with the lets rewrite the system hahahaha' guy. I might even be right about it. But the probelm is a jr level guy is not going to have the political cover to make it happen. Even if they are right.
But if you can get 'the higher ups' to buy in. Then it is quite dramatic how much better somethings putting that sort of tech in. Then other times it can be a total disaster. So you have to pick your hill to die on.
Yes, but that's not what the specific comment I replied to is saying.
It sounds like pure junior dev fantasy that anyone would care beyond whether it meets the explicitly stated requirements.
Any other flourishes that the devs add are going to be unused or ignored, and that definitely includes what the devs think about their own work.
I can relate to this so much. When I was a newly joined Google consultant at a partner firm, we went to their office - some 13 different types of cuisines, different types of game rooms, lounges and what not. A luxury star hotel experience. We were waiting for our meeting on behalf of this one particularly large media client who was bleeding money on Wordpress.
3 engineers arrived - fashionably late. We explained them the situation and all we wanted from them was some GCP offering that would cure our woes and one that would cut our bills. The senior consultant - and presumably the only tech guy (rest seemed to be salesy) wasted our time like a used car salesman - he didn't even understand Google's own product portfolio and recommended us to use something like Spanner - which was totally not the solution to the problem, not to mention, expensive.
My boss and I left the meeting pissed off and he told me - "Neya, you probably know more about the product portfolio than these guys. Let's leave". That weekend, I went with my tried and trusted favorite Db - PostgreSQL - CloudSQL with a custom Elixir middleware based an old CMS I wrote a decade ago. After some trial and error, the solution worked flawlessly (and still does till date on auto-pilot). My client still has the lowest cost in the region - 1/3rd the cost of their competitors...7 years later. Back then, there was no vibe-coding, no AI, no auto-completion. Just pure thinking and experimentation.
All this just to say I agree that the new guy sometimes can make the best solutions to a problem and not always screw up. I always listen to new hires these days (now I'm a fractional / CTO) because you never know who could pull off that 1/3rd cost cutting framework move.
Nice work!
Sometimes those complex solutions are the right tool for the job. And other times, you just need to glue some stuff together, call it good, and start making money.
Experience helps a good engineer know when each approach is appropriate.
Thanks, totally agreed.
Thanks for sharing! Every time I see a post about Elixir and how it Just Works™, I get an urge to learn and build something with it.
One day I'm gonna build some sort of product in Elixir. I was super interested in LiveView when it was announced and I think the component story has gotten a lot better than when I tried back in pre-1.0 days.
This video by Sasa Juric is still the gold standard (imo) of Elixir demos for anyone who hasn't seen it: https://www.youtube.com/watch?v=JvBT4XBdoUE
It’s funny you complain about the sales pitch the guy gave you, but the comment itself sounds like a sales pitch :)
IMHO it sounds more like someone who is proud of solving a problem for very little effort that Google tried to sell a very expensive solution for.
Thank you, that's exactly what I was trying to convey
Hey, really sorry, I'm genuinely not trying to sell anything (I don't have a product to sell...yet). I can see why you might have interpreted like that though. And it's unfortunately too late to edit my comment. I'll try to think less sales-y next time.
I think you need to calibrate your perception of things you read.
> 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.
Oh I have seen this story and was the one who caused this story when I was younger.
In a lot of cases the "new guy" thinks its an easy software and does it on his free time and thinks he did a great job.
In reality the specs are never 100% done correctly. The "new guy" misses some edge cases everybody but him knew because its just company knowledge. A lot of info in the specs was missing since they are not complete and so on.
This over the weekend never works in the long run. The ORM worked for all the happy path and written down cases but then you have cases were the ORM just is not good enough or fast. So you start to add strange code to work around the ORM. The same for the web framework or the validation lib.
To me the author of this comment sounds like the typical "Freelancer" coming in into a company knowing everything better then all the people and then leaving after a few months and now everybody else has to deal with his code.
It swings both ways though. I've seen plenty of older engineers dismiss the "new guys" effort and claim that everything had to be custom written, because there's no way a common framework like Django could cover their use case. The same type of engineer has never once worked with a common framework though, so they don't know what's included nowadays.
Turns out it's a lot easier to build on top of a common framework than do everything from scratch.
Sure I had an older dev do bit masking for a list of 3 options in javascript because he was used to old terminals.
Its something different coming in and changing things here and there but rewriting the hole thing on a weekend is something different.
I was very impressed with vBulletin’s use of bitmasking for permissions (of which there were many possible combinations) when I first encountered it.
Would love an excuse to use it, but one has not come up in like 15 years since, hah.
I think it's safe to say that ORM in Django is, in fact, better in all possible ways than an ORM someone at some company just wrote. Including speed and handling edge cases.
We only know what OP wrote and he doesn't sell himself as a genius but as someone who was competing with really, really bad ideas.
Take this idea and bring your own validation library and forms and UI components to the next job, and you've described what I do. And then you have real lock-in.
Ah, so you’re the one who made that same company’s marketing website!
Hahaha. I'm not above that kind of work. Sometimes having a consistent codebase for both things comes in pretty handy if you need to tie em together or just need to spruce up the CSS every few years.
I don't intentionally make my work hard for anyone else to maintain. I comment and write tests pretty thoroughly in case someone else comes along. Or in case I get woken up at 6am with a bad hangover.
Nah, I gotcha. That makes a lot of sense.
Yeah, that definitely happens.
But I don't think Claude Code is going to prevent an org that thinks they can prompt their way to a replacement for all their SaaS from having internal political bickering that makes them end up with a extra-shitty mega-compromise to try to make all the internal stakeholders happy.
If you've got no vision and no taste, you need to find a vendor who will protect you from screwing up your internal processes and tools.
Internal tools teams have rarely cared much about UX or the day-to-day experience of their poor users. The quick-and-dirty internal-prompt-based one is likely to similarly be unimaginative and unintuitive.
Also, some people want to work on what's already familiar to them. If building a framework from scratch is what appeals to them, they'll do that even if a framework already exists. Busywork to look productive.
> feel free to doubt.
I don't doubt you at all.
I once worked on a project that was a new sign-up process for a large retailer (~90k employees at the time, four figures worth of outlets, quite a few billions in turnover).
There were about 60 people across, I can't even remember, maybe 10 teams that I knew about. One of the managers there assured me that the true participant figure was closer to 160. I was agog.
This project took months, and it had been going for months before I joined. And, as you can imagine, with that many people involved over that sort of timescale, there was turnover: people, sometimes key people, would leave and be replaced - sometimes by others who'd already worked on the project, but sometimes by new people - with the expected disruption that causes.
It was two web pages, plus some back end plumbing across multiple systems.
But, in the grand scheme of things, nothing that complex. I reckon it was a handful of thousands lines of code total across the full stack. I was mostly on the database side and, IIRC, I wrote a few hundred lines of SQL in a couple of stored procedures (wouldn't have been my preferred solution building from scracth but, you know, we weren't, and we had to integrate with a legacy systems that had to keep working as expected).
Overall it took 8 or 9 months from kick off to shipping and I was involved for perhaps 3 months of that towards the end. I was on the call with dozens of other people whilst me and one of the other guys hooked the final pieces together and tested it end to end for the first time... and it worked. There was actual cheering.
Large enterprises are genuinely ridiculous.
I was complaining about SQLAlchemy's insane quirks to a group from my alma mater and one of the grad students said, "Well, the solution to your problem is clear: Write your own ORM." and I had to explain that this startup does not want to get into the ORM-writing business.
I freaking love SQLAlchemy. Those quirks once let me build a sane API on top of a legacy database (ported from Visual FoxPro hourly using a program I also wrote for the task). Some of the fields were values in an XML doc shoved into a DB column because the original programmer thought that was a good idea at the time. I wrote indexes and virtual columns that let other devs query those fields just like everything else.
It has its edge cases, but Alchemy is the greatest thing in the world when you need its exact features.
But yes, I’ve used that line plenty of times: “we’re not in the X-writing business”. I mean, sometimes you can’t help it, but those should be exceedingly rare cases.
I had a similar experience where someone that had prior experience with django while we were using sqlalchemy started to design a django-like ORM on top of sqlalchemy. Of course it took him some time to get working, was a hell to understand and extend and most importantly lacked support for basic features.
Fortunately it was limited to a small isolated service but I can imagine the damage on the long term if you continue that route on what becomes a huge monolith after a few years.
Isn't this agreeing with the parent? If Django were the B2B SaaS product, you didn't vibe-code Django, you just used Django. You aren't responsible for maintaining Django itself.
Django wasn’t the product here, though. I used it as part of the toolkit to “slap something together in one weekend”, and that something was the (actual real life) B2B SaaS product, or at least the user facing interface to it.
It feels like I have worked with you (though obviously not). Had same experiences to the T.
Maybe it's just something that happens to many in web development world, not-invented-here and all...
Rule #1 of power: never outshine the master
I resonate strongly with this story. I’ve seen three people teams get in one month where SAP could not in year, and also let and witnessed incredible number of total fakers in SaaS enterprises.
Big corpo may be too big to fail, not so sure about their whole cohort of partners and fakers.
> Sometimes the new guy can make a better version themselves over the weekend, not because they’re a supergenius, but because they’re not hampered by 47 teams all trying to get their stamp on the project.
In 99.9% of cases what seems to be "the better" version is better only for the "new guy" or rather his ego.
Those 47 teams hampering doesn't necessarily mean a bad thing, and more often than not actually well justified "stamps".
You only understand those things when you turn from the "supergenius" into an owner who have to take care not only of numbers on screen, but also security, interfacing, management and so on.
Or you don't turn into.
Not saying you're wrong in all cases, but there are enough examples of hugely expensive megaprojects which totslly tanked, which would have definitely been much more successful with OPs approach if executed correctly. Not saying they would be done and done within a weekend, that's silly. But the alternative, poorly defined integration interfaces, multiple contractors, multiple stakeholders with conflicting requirements and zero (real) regard for the user is unfortunately fairly common, both in public (city/regional/government) and private bureaucracies.
The examples are legion, and they always seem to have NIH and baroque requirements, and be rather over- than underspecified. I would go so far as to say that these projects are almost never successful (and definitely never on time and budget).
That is often the case, but far from all the time. Other times something is made so needlessly complicated by office politics that it may never get shipped.
Not saying it never happened in history, but most of those "complications" are justified. Being narrowsighted and overfocused does not help to assess it.
Conversely, sometimes when you have 23 people designing something, they can lose track of what they’re trying to accomplish and focus on how they’re trying to accomplish it. It can be an XY problem sort of thing. “How can we get the Redis queue to do an exactly-once insertion into Kafka, if we can’t guarantee exact ordering from the Paxos framework?” “Uh, guys, aren’t we trying to send out the weekly email newsletter to our estimated 500 subscribers?” “Oh, well, I guess we could just use Mailchimp…”
Like I said earlier, it’s ok not to believe me. I don’t particularly mind. But just between us, my solution met every one of the project requirements using COTS parts because they’d made it waaayyyy harder than it needed to me.
Nothing personal, but our conversation reminds me many similar convos I had with developers who thought their product was superiour - but they could see it only from their angle. And it was superiour - but again, only under narrow view.
Good chat. Have a nice day!