Key & Peele — Substitute Teacher
And you end up watching and re-watching some of your favorite Key & Peele comedy sketches.
A great start to the day, I suppose.
“Hey, let’s use Framework X that was just released a few weeks ago. I read that it’s much faster than what we’re using now.” - RockstarDev2015
“Oh, but did you see the recent benchmarks against Library Z. It didn’t look that great at all.” - I_Am_Ninja
We would have probably started and / or participated in similar conversations when deciding on solutions to use in our product’s technology stack.
But let’s face it, are these really the type of questions that should dominate the discussion surrounding the topic of which technologies we should adopt for our product?
Sure, they are important points to consider, but my concern with these types of questions is that they are often asked in the absence of context pertaining to the product we’re building. …
I was first introduced to the world of Test-Driven Development through Obey the Testing Goat — a fun read and I highly recommended it if you haven’t read it yet. This concept of first writing tests based on real world scenarios of how he or she may use our application before implementing the actual logic to get those tests passing got me really intrigued.
In theory, it was perfect.
Business and product people would be assured that user stories can and will be handled correctly by the system. …
You’re the popular figure on the Internet now and frankly, I felt rather unsure when I was first introduced to you. Your style seemed quirky, especially how you seemingly went against the holy grail of engineering advice, encouraging us to break the principle of maintaining a separation of concerns.
Strangely, our initial interactions went well, in fact, a little too perfect I must say. It was easy adapting to this unconventional style you call JSX, and I started to see the additional values you provided through multiple lifecycle hooks.
But alas, as our relationship grew deeper, I fell into my comfort zone and ended up dropping the ball on several occasions. I drew upon my experience with others and tried applying the same principles to you, and that was a foolish decision since everyone operates in a different manner. …
The hardest part about software engineering is not writing code. It’s the ability to look at each problem with a fresh perspective, independent of solutions you have implemented in the past.
This is, by far, the most important lesson I’ve learnt while working with a bunch of mad chill, crazy smart people who love their craft.
When faced with a problem, it’s inevitable that we may get stuck in a rut and start seeing old problems and offering old solutions which may not ideal in the current context.
To understand why this happens, we’ll take a quick segue into neuropsychology.
Whenever a problem is presented to us, our left brains are automatically engaged and we start recalling the solutions that are familiar to us. …
It’s been 14 months since I first started working with Angular and in recent times, I find myself moving away from this framework.
Now, I don’t necessarily agree that one framework and / or library is inherently better than the next. Every product has its own set of challenges, every team has its own unique dynamics and these, I believe, should form the basis for choosing a right set of tools to help craft an ideal solution for the task at hand.
Therefore, this is not intended to be another one of those articles that tell you not to use a particular technology. Instead, I’m just sharing some of the painful problems I’ve faced which encouraged me to seek out alternatives to Angular. …