Reflections

After an unexpected debugging session, some thoughts on APIs, similar endpoints, swagger, and an ugly DevOps fail.

Funny how a little due diligence mixes so well with a healthy interest in avoiding unnecessary future work.

I heard a story recently, where a team was asked, after spending months adding a set of features to a codebase, to remove a specific feature from very early on in the project, right before the release date. Other features had been built around it and on top of it. Without necessarily even intending too, the devs that came after that code was written would’ve had to understand it in order to add to it. I don’t know what the outcome was, but that’s not an easy ask. ...

When what we’re trying to accomplish fails, the extra knowledge and clarity we get just by making the attempt is a win all by itself.

When our code isn’t clicking, negativity can quickly overshadow all the positive. That’s when we need to remember our victories!

Refactoring code is part of the dev life, and can even help keep the code healthy, but going too far can do more harm than good. Ever after a decade of writing code, I still have to remind myself from time to time!

One of the biggest struggles I have with programming is knowing when to ask for help. A little struggle is necessary for growth, but when am I just wasting time when I could be learning from others?

Seeing my full-time job as a long-term contract has helped me improve and contribute, without taking things personally or falling into complacency.

When I was less skilled as a developer, it was enough to just stay afloat, learning what I needed for the current day or project. As my skill and confidence grows, I’ve come to appreciate the extra things in life - like a decent set of docs.

Does the mere thought of explaining your code cause anxiety? Be confident! We should all understand what we’re writing and why. It’s an opportunity (for everyone) to learn!