This is really important. At my first job, in 2010 or so, we were using Servlets. Not just Servlets, but Servlets with some home-rolled shims to make it act like Servlets 1.0 in a distinctly post-1.0 world. Doing pretty much anything in there was slow, and I realized it at the time. So during a hack week I built an MVC layer on top, with routing that didn't involve XML files and just--made it generally better. Or so I thought at the time. To their credit, the team took it seriously and gave it a try, and while in a vacuum it was a better system I hadn't understood how the people on the team thought about web development and it wasn't a better fit for them. They didn't feel like there was a problem, so a solution didn't make sense. It could've been technically amazing (it wasn't, but it was fine), but it didn't solve a real problem, so it was an academic exercise at best.
Other refactors and systemic expansions, like a slot-based system for advertisement placement, worked a lot better, because I'd learned a little about how to dig into what problems actually existed and how they were causing aggravation to people.
> I hadn't understood how the people on the team thought about web development and it wasn't a better fit for them. They didn't feel like there was a problem, so a solution didn't make sense.
There's got to be a limit to this line of justification though. Lots of people have just plain wrong ideas about 'web development', so catering to their ideas doesn't serve anyone well (except, perhaps, those people, who in the short term don't have to learn anything correctly).
A colleague shares stories of his team who don't grasp the difference between GET and POST, don't understand the term idempotency, believe that 'web dev' testing only means 1 thing, etc. There's... 5 of 6 of them, and only one of him, so... much stuff ends up staying 'wrong', and the 'wrongness' in each section of the code ends up compounding 'wrongness' in other systems/features as they're being added. This matches how this team thinks about web/software development. But it's not in any way beneficial.
Oh totally! I firmly agree that at some point you have to pull the ripcord.
The question becomes--where?
This company was incredibly successful up until COVID and is still ticking along, so it's hard to argue. I gather they've done significant work to rebuild the universe in that time, though. I might've just been early.
Where do you think your understanding went wrong initially? You said you realized that doing anything in the old system was slow. Was it not actually slow? Was the slowness not relevant because there weren't actually that many routes? Were your coworkers resigned to having some minimum level of tedium in web development? Or something else?
Oh no, it was slow--but it was slow and they were used to it. (And there were plenty of routes--probably somewhere close to a thousand at the time, in 2011?)
The problem I hadn't fully understood was a mix of the last point you suggested--tedium's just how it is--and a set of libraries built up as coping mechanisms that were intrinsically tied to the servlets process. Not really written to be able to be shimmed into a better world without dragging the whole thing there, and not enough appetite to try for it.
Yeah, totally. And in my experience (on both sides of things), a good junior developer is going to probably realize what sucks well before having a strong understanding of how to make it not suck. The first attempts are probably not going to be perfect (maybe not even good) - but that's the sort of thing folks don't really learn by being told. You have to walk into that screen door a couple times. Which is why hiring junior folks is such an investment.
When I was a non-senior eng., I interacted with plenty of senior engineers, found that I easily possessed the skills to work at their level / do their job.
My company at the time laid off my entire division. I decided it was time, needed a job of course, and so applied for and landed a job as a "senior SWE".
