New Frameworks Aren’t Better, You Are
I started off my career coding in a Microsoft shop. C#, .NET, even a lot of really old Classic ASP. I remember taking applications that were actively being used internally and implementing inheritance— just for fun. Just to learn and apply it. I was thrown into the fire and very much learned as I went along.
Every day was a learning experience. I actively was seeking wisdom from Pluralsight, books and anything I could get my hands on that would make me better. Somewhere along the way, I became proficient. A few years of successful projects later and I was the lead and very confident in the technology. I knew more than enough to get my day job done.
Sure, there were things I wasn’t comfortable with yet. I never had to mess with much front end. We never took the time to implement unit tests. There wasn’t much of a build process. As a small team we did enough to get things done, but didn’t have time to mess with things that didn’t immediately impact the bottom line.
Shiny New Technology
The day eventually came that seems inevitable these days: time to build a MEAN stack application. As a much more experienced developer, I was up and running in the MEAN stack immediately and I felt fairly proficient in a matter of weeks.
Not only was I feeling proficient, but I was loving it! “Node.js is so much better!” I would exclaim. I just didn’t know what I was missing over in .NET land all this time. Node.js was such a better technology. It makes things so easy. I spent plenty of time researching best practices. I was surprised at how quickly I was up and running compared to first learning .NET.
“Node.js is so much better!”
I even implemented a unit testing framework for the first time, it was so easy in Node.js! Those build processes I avoided for so many years were nice and simple to setup, so I set that up too. I spent a couple years in the MEAN stack and was significantly more productive and created significantly better products.
I was more than happy in MEAN land until I needed to go back home to where I started. I needed another .NET app. I hadn’t really looked back after switching to the MEAN stack, and I knew a lot had changed in the .NET world. Open source, .NET Core and more caused me to do a little research again before diving in.
Similar to the way I approached the MEAN stack, I started researching best practices in .NET. I knew most of them, after all I had worked here for years. Nonetheless, I started looking up things like unit tests and build processes and guess what? “.NET is so much better!” I exclaimed.
“.NET is so much better!”
These improvements had nothing to do with .NET Core or anything that wasn’t available to me back in the day. I simply never took the time to look it up. I was all too comfortable with the way things were. I became too confident in my day to day skills to keep the learning process I had established in the early days up.
The Confidence Problem
There’s an inherent danger in becoming too confident in day to day activities. Remember when you first learned to drive? I’ll bet you were pretty careful. You’re moving close to a ton at 65 miles per hour. It’s a scary thing when you really think about it. But after a while, you get used to it. It’s a part of life, it’s second nature.
The problem with getting too comfortable with the day to day is that it causes you to lose focus. You stop learning and improving. Over-confident drivers are some of the most dangerous drivers on the road. Similarly, over-confident programmers are robbing themselves and their company/project of the very best they have to offer.
Am I saying to stick with only one technology and never change anything? Absolutely not. The move to the MEAN stack was the best thing we could have done. However, don’t let the shininess of that new technology or framework fool you into thinking it can help you more than you can help yourself.
My suggestion? Spend some time researching the language/framework you are currently working on. The one that you’re an “expert” at. Sure, you’ll have to skip over some basic knowledge you’re already familiar with. Depending on your skill level, you may have to do some extra digging. But I guarantee there’s something out there that can improve your process and your skill level.
Don’t just default to running to the technology that looks better, you’re better.