When I was taking my regular walk in the park, I couldn't help but notice how people perform "heel strike" when they jog. It is when the heel of the foot lands first when running. It isn't the most effective way to run, since each leg carries more than twice our body weight when it hits the ground, and when the heel lands force travels up the led and ends near our knees and hips. Long term jogger may find themselves with injuries in these areas. The best form of running on flat pavement, arguably, is a midfoot strike. Where the middle of the foot land first then followed by the heel. It gives the leg muscles time to absorb the force like a spring before they travel up the body.

Considering our ancestors depended on running to survival in the majority of the past 200,000 years. There fore running is and should be instinctive to us, and yet we don't all seem to do it correctly for one reason or another. It just shows even the most basic and essential things in life there's a chance we might not be aware we are not doing it well.

Which made me think, what else could I be doing wrong without realising?

I've been working in the software development field for over six years. It's not a crazy long time compared to people who's been doing this for 30 years. But it is still long enough for me to develop many ineffective habits or misconceptions during this period without realising. Perhaps even those I practice daily at work?

Given how fast everything changes in the digital world, it is a constant battle to stay relevant, not to mention finding the time to perfect or enhance our existing skills. It might even logically make sense to tune down the perfectionist voice in our heads and focus only on getting what's right in front of us, our work, done. There is no time to be steady, methodical and think. But aren't these traits of a good software engineer?

Learn and priorities language specification changes

People are so busy looking at new shiny toys which flood our social feeds each day. Could it be possible that we forgot the more fundamental part of our skills - programming languages?

All the frameworks and libraries are cool, the tools and their plugins are fantastic, and the new theme for the terminal is pretty sick! However, as long as you develop software, programming languages are at the core of what we do. Just like everything else, languages change and evolve over time. I wonder how many people actually follow the new language spec changes and study it properly? It's shameful for me to say that I'm one of these people right now.

There could be many reasons for this, and I think one of the major contributors is the fact most of us don't work in an environment that promotes the importance of language specification changes enough. Instead, skillset and knowledge about frameworks and libraries are more heavily promoted.

Perhaps we should spend more time studying the language specification and understand the limits of the language we use every day. Often, learning the new features and design shift highlights the limitations of the older approach. It helps us to understand the why behind individual language quirks, but more importantly, we will know when "best practices" posted all over the internet stops being true.

I once heard a senior JavaScript developer telling junior devs to never use forEach() in JavaScript due to its "inefficiency". The person isn't wrong, and this performance analysis proves it. The crucial piece of information left out is that we often never loop over arrays with a length of 50 or more. The difference is minuscule with this kind of data set, I mean we are talking about a fraction of a millisecond!

Write our own libraries

Open-source libraries are amazing. They solve the most challenging problems and present them as a nice solution, allowing us to focus on other aspects of our job. JavaScript's package manager reach its one-millionth goal back in Jun 2019. That is a lot of potentials to leverage when it comes to creating applications.

Positives aside, I reckon it is also dangerous to always reach out to these 3rd party libraries whenever there's a problem. Maybe sometimes it is worth implementing a simple and even substandard piece of code instead of pulling down a library from NPM. In many ways, using software other people wrote is a dark path to go down, the more you rely on them, the less you'll learn, your mind gets lazy, and the cycle continues.

I worked in a team a few years back that decided to write a custom rendering library just because it was an interesting experiment. We knew we'd learn something along the way, and that we'll be able to get the job done no matter what. The result was fantastic; every member of the team had a deep understanding of the core rendering logic, fixing bugs and making optimisations couldn't have been easier. Needless to say, I feel like I learned more in that one project than ten projects using an off-the-shelf library.