The Curse of Over-engineering

We have two half days (affectionately known as Freaky Fridays) at work a month, where we get to work on our own projects or explore something new. Yesterday was dedicated to exploring Angular 2.

I thought that it might be a good opportunity to test it out in a real-world application – my Flashcards app to help me learn Swedish vocabulary.

The syntax isn’t too dissimilar from AngularJS, but rather is abstracted in more boilerplate code. Getting a basic app going, by following the Quickstart Guide, wasn’t too difficult.

“Look at where you have to be.”

Then, there was a knock at the door. It was Earl, the Grim Reaper of Over-Engineering. He asked me to remember that I am a software engineer and that everything has to be TIP TOP from build one.

So, the curse kicked in and I started scrambling to get the basic setup working with Webpack. I tried cramming in a Webpack tutorial, alongside the Angular 2 tutorial. Soon, it just became about cursing the day Webpack was built and racing through Stackoverflow, hoping someone else wrote something to make everything PERFECT now.

10 minutes before the end of the day, I realized… wait.

The goal was to learn Angular 2 and use it to build an app.

That’s it.

I told Earl that there was another engineer across the street, about to do something simple. He scurried away.

I gutted out the Webpack configuration and stuck with the lite-server package suggested in the Quickstart guide.

Moral of the story: fuck Earl and fuck over-engineering.


Learning How to Work in a Team

I am working on a new feature for one of our microservices. It’s about a medium-sized T-shirt that involves working with AngularJS’s ui-router, working with new API endpoints, and writing some CSS from scratch. I’m excited! And a little daunted…

To work against being overwhelmed and becoming unproductive, I focused on tackling the hardest part first – the routing and views. I knew that I was going to work with ui-router, so I read through a few tutorials and brushed up on routing in AngularJS.

I then put together quickly some mock views to connect to the new states and routes. This felt better than starting to code markup and styling, I had to remove the unknown first.

The tutorials only got me so far, so I stopped and thought about it. I did some searches on Google. After a few iterations on this cycle, I reached out to a coworker. Instead of telling him it’s broke give me the codes!, I explained what I had done, what I was trying to achieve, and what wasn’t happening as I expected. Rather than him coming to help me google, it turned into a discussion about patterns, structuring code, and a brief pair-programming to get something working quickly. I even got some praise that my initial concept is good and that I should just find the right balance, between sound design and time spent on the solution.

I thought of this article after the whole discussion with my coworker.