4 ms·

> That or they use something but clearly don't understand the thing they are using. You know, I feel like this has bled into backend development too. And it's

> That or they use something but clearly don't understand the thing they are using. 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.

noir_lord 6y ago
All of this. 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.
spacemanmatt 6y ago
I have been working with a guy who constantly avoids popular libraries. Constantly. And his product is constantly more accurate (factored, few bugs) and then he can document it without referring to any outside sources. It's pretty good discipline to write things yourself and only grow into libraries when you have proven you know what you need.
- noir_lord 6y ago
  That is where the nuance lies, in not reaching immediately for a library when you have a problem, explore the problem until you understand the solution then you know if the library is a good fit or not. 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.

noir_lord 6y ago

All of this. 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.

spacemanmatt 6y ago

I have been working with a guy who constantly avoids popular libraries. Constantly. And his product is constantly more accurate (factored, few bugs) and then he can document it without referring to any outside sources. It's pretty good discipline to write things yourself and only grow into libraries when you have proven you know what you need.

noir_lord 6y ago
That is where the nuance lies, in not reaching immediately for a library when you have a problem, explore the problem until you understand the solution then you know if the library is a good fit or not. 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.