That is quite possibly one of the best quotes I have heard on how to approach discipline in engineering.
> Inexperience grows from the bottom
In what way?
> I've gotten "better" by simply being too stubborn to get worse
How does one get better by wanting to get worse?
This makes no sense to me.
I'm not sure I agree, but I can understand the sentiment.
It's not just "the web side of things". Which makes it even more scary.
You know, I feel like this has bled into backend development too. And it's not entirely the fault of engineers... or so I like to think, to excuse myself :P
What worries me a lot is that I find myself being one of those people, not being able to fully help my situation.
It's just... too much. It seems like every few months a new thing pops up and everyone suddenly wants to adopt it. And even if you try and resist it because it's not necessary, someone from above (e.g. CTO) will decide that the whole org has to adopt that and now you're screwed.
In a typical backend application you have to deal with:
- Application framework
- Testing framework
- Logging framework
- Metrics framework
- Tracing
- Visualization tool(s) for the three things above
- CI
Which is already quite a bit, but obviously manageable and you could get pretty knowledgeable on all of that if they stay static.
But hey, now your org has to expose every service on gRPC. Ok, one more thing to tack onto your app...
Now everyone has to expose GraphQL endpoints too!
Oh and next month we're migrating to a new metrics solution. Because. Great, let's throw away all the knowledge built on the old one and scramble to migrate to the new things we don't have time to learn fully.
Alright, now let's start writing new services in this new language.
And now everyone has to throw events on this new message bus thing that some team over there built using Kafka!
Finally, let's move everything off of AWS managed services and onto Kubernetes! Yay!
All of that can easily happen within the span of 2-3 years. And in the meantime you have to deal with on-call rotations, customer issues, implementing new features... and if you're a senior dev you're also busy mentoring folks, going to meetings with other teams, etc etc.
You know what I'm talking about, right? Over time, I feel like it's becoming impossible to achieve mastery of anything. There are way too many things to learn to be able to make sense of the whole, and no time to do deep dives on all of them. And then there's all the new stuff that keeps being adopted.
And then things blow up and they're freaking mysterious and when you finally find out what it was, you realize you'd only have been able to catch that problem beforehand if you'd read the freaking source code for some library you adopted.
It's madness. It's pure hell.
Boy I miss working on low level code.
End rant.
Half my battles with my team are them wanting to pull in dependencies, sometimes it's crazy like a wrapper dependency to pull in a different dependency when it's simpler to just pull in the indirect dependency and use it directly.
It's very much a thing that comes from experience though, when you've been bitten by upstream enough to be a little circumspect about it.
I agree with all of it, particularly "Lets throw away X and switch to Y, we lose all the domain knowledge we have with X but Y others this absolutely tiny marginal improvement, so it's worth it!"
As a lead I spend a lot of time pushing back on adding stuff until someone has made the case why we should add it.
You want to use Y, great - document why you want to add Y, what benefit it brings, who runs Y, where is the code, how many maintainers does it have, is it well tested, if want to remove Y later is it a big job, what does it offer that we can't currently do etc.
It just seems to be the nature of the web side of things, lots of sloppiness.
The devs are smart enough, they just don't think and it shows.
That or they use something but clearly don't understand the thing they are using.
I replaced nearly 500 lines of code with ~60 by taking a bunch of massive conditonals re-ordering them then extracting them into methods and returning on the simple case.
This isn't voodoo, you have to work harder and remember more to do it the wrong way.
Also comments, they don't seem to understand you document why you did the thing, not what you did, what you did is in the code, I don't trust your comments to tell me what you did, I want to know why you did it.
That and general documentation (cross link stuff, link at the top of the class to the documentation in the wiki, update the documentation when you get a ticket that changes the behaviour, write the high level flow in plain english a 10 year old could understand).
rant over.
I actually like my job, the people are lovely and the work is interesting its just frustrating when an ounce of thought saves a pound of cure.