Everyone says developers think a lot, and they do, but the problem is... sometimes we think too much. I had a couple cases of that this week, one of which involved me learning some regex that was TOTALLY unnecessary, but a good learning experience, and I found a cool regex checker.
Let's dive right in!
Over-engineering
We've all heard the term over-engineering, but turns out it's actually a real thing. I've noticed a few examples of me doing this recently, both in actually development and outside of work.
Here's a funny example.
I was laying in bed and realized I was tired of having to get up and cross the room to turn off my bedroom ceiling lights, and I honestly didn't even love rolling over to turn off the lamp. It felt like too much work to hit a button to turn things off, so I bought smart lights.
Not only did I set them up... I went all in. I replaced my bedroom lamp AND ceiling lights with the new smart bulbs. And that was kinda great! Now I could just shout "hey Alexa, turn off my bedroom lights". But then I quickly got tired of doing that and wished there was a button on the side of my bed I could push to tell Alexa to turn off the lights.
And that was the moment I realized I'd come full circle... I was right back where I started. Classic example of implementing a new feature because you think it solve a problem, but it just creates new problems and that feature was actually a red herring distracting you from either a deeper problem, or a totally non-existant one!
I installed smart lights in my living room too and have found it much more helpful, and also very cool looking with special effects that change colors.
I did something similar to this at work recently where I realized the problem was that we needed some characters replaced so that a didn't turn into %20.
My mind got busy with coming up with a solution for replacing characters and learning regex, but really all I needed to do was find a library that already encoded and decoded URI text :)
One step back even more, I realized I wasn't even thinking through how the text was getting encoded to start with and why it needed decoding. It wasn't until a senior developer asked me that I realized I was doing my classic smart light situation! I was scratching an itch, without realizing what was causing the itch.
So I'm going to work on spending more time sitting and thinking before jumping in and adding features that I think solve the problem. Some of this comes with time, because I think that's what makes a developer experienced — being able to think through a problem rather than just code something that makes a change. That's important too, but as I grow, I want to be better about thinking through the problem first.
Here's how I plan to do that.
🙋♀️ Ask more questions. I feel like I get really excited when I think I can just start coding to solve something, but I wanna do a better job about asking more questions and getting clarification on issues before diving right in.
💻 Think like the computer. Before I even architect a solution, I want to think through why the computer is doing what it's doing. Often this is necessary to solve a bug, but I'm realizing sometimes it's not and when you skip over this, you miss other things that might be impacted as a result of your code change.
🚶♀️ Walk. The. Eff. Away. It's really hard for me to step away from something when I'm in a zone. I just wanna solve it! I need to get into a better practice of not working for more than about 60 minutes in a deeply focused state, and then being okay with breaking that to walk around, get some air and new perspective, and then come back.
Top comments (0)