5 ms·
I'm seeing this in action now, the difference between the backend code and the frontend code is stark and the backend code isn't up to my standard either (and m
by noir_lord 6y ago
I'm seeing this in action now, the difference between the backend code and the frontend code is stark and the backend code isn't up to my standard either (and my standards aren't that high, I know I'm merely competent for many places).
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.
- soneca 6y agoShould I assume from your comment that you never saw code worth improving other than those written by JavaScript developers?
- noir_lord 6y agoNo.
- robertlagrant 6y agoAh, pointless exclusion of the middle.
- edoceo 6y agoHello fellow "merely competent" engineer. I recommend we both remove "merely" from our title. Inexperience grows from the bottom, I've gotten "better" by simply being too stubborn to get worse. Keep up the mediocre work!
- donw 6y ago> Inexperience grows from the bottom, I've gotten "better" by simply being too stubborn to get worse. That is quite possibly one of the best quotes I have heard on how to approach discipline in engineering.
- systemvoltage 6y agoI don't understand, can you please explain? > 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.
- btschaegg 6y agoI read it as "refusing to get worse". Which implies that your environmnent is getting worse, making you better by comparison. I'm not sure I agree, but I can understand the sentiment.
- watermelon59 6y ago> 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 agoAll 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.
- btschaegg 6y agoI agree about (and am frustrated by) everything you said here, but: It's not just "the web side of things". Which makes it even more scary.