Got some, shall we say… “pointers” about how we could improve the code-base we’re working on at work.
As much as it hurts my ego to hear someone making suggested improvements without fully taking into consideration the context in which that code was originally written (learning the service the code was interacting with, under pressure to deliver it by a given deadlines, etc.), I’ll admit on the whole the feedback is fair enough. I know there are times where I tend to gloss over the finer details of the code I write as part of a team. And that I treat things like sufficient observability metrics, proper naming, and decent logging, to be mere afterthoughts over getting the code to actually work and moving on to the next task. I’ll try to do better there.
There’s one thing I will make a comment on. A few suggestions were of using shared utilities, like core libraries managed centrally, for things that were written in the moment. Here’s the thing about shared utilities: I won’t be aware of, or forget about, their existence unless I have a hand in writing them. You can do things like announce them in Slack, but unless I have an opportunity to start using them right there at that moment — an opportunity that rarely comes up — I’ll eventually forget about them and just fall back to plowing through in my own way. Getting me to review to them will probably work (or, more likely, forcing me to review them; keeping up with code reviews is another thing I’m pretty terrible at).
Anyway, I think my ego’s sufficiently soothed now. I’ll start writing up tickets to get these fixed.