Being language/framework/technology agnostic
I’ve always used .NET ecosystem during my career. I’ve started with ASP.NET Web Forms, then it has been ASP.NET MVC, more and more architectural patterns that one way or another were using .NET as backend choice to go. C# is a great language for some reasons that I’ve experienced during different projects and .NET ecosystem has been one of the flagship ecosystems out there.
But the main catch was different for me. Apart from the established status amongst technologies, I’ve always admired the change .NET ecosystem went through the last 6 years. I was inspired by how visionary it was to aim .NET to run in any OS, when traditionally every sense of direction was suggesting the opposite. I remember spinning up one of the preview 0.x versions of .NET Core for a hobby project, which I was trying to create a sentiment map of states on US presidential candidates during 2016 elections based on live tweet streams. I was immediately caught on the idea that I could just run every component of my application on Linux, which was opening up another world while still being able to use programming language and framework I feel comfortable at (Also, I’m not a big fan of Python on Windows and I am a big fan of Windows Subsytem for Linux).
I’ve always kept an eye on progress of .NET Core, then later .NET 5. I’ve always picked them to be the choice of runtime whenever I can. They’ve done a tremendous job with open sourcing it and putting amazing people behind the wheel to govern the direction of it. That’s why, today, the difference between how good .NET Framework and .NET 5 is ridiculously positive.
Based on all these reasoning above, you can say it was the trivial choice for me all the time to work on .NET ecosystem as a software developer and later as an engineering manager. Exactly, I just went with the obvious.
With all being said, I believe that what makes a software developer great is their knowledge of fundamental concepts, rather than their sole knowledge of a language or a framework. You probably must have a go-to choice when it comes to your toolset, but also you’ve got to be able to interchange between them. Mainly because, there’s not one technology fixes all the problems and all trade-offs. Different frameworks, technologies and languages are focusing to solve specific problems and they’re probably not the best choice for some other problems that other frameworks are aiming to solve primarily.
Also, it’s because I believe there’s a distinction between concepts and implementations. Or let’s say, in a significant engineering experience, I strongly believe you have to know what’s a conceptual choice and what’s a specific implementation choice. You also need to be aware of there can be n different ways to implement the same concept and n, usually, is a large number.
Let’s make this statement a bit more concrete, to be able to make things easier: Barrier algorithms in parallel programming. Each framework that aims to be present in parallel programming space come with their own implementation of barriers and yet, you can still find yourself writing your own implementation. Why? Well, because maybe .NET Framework team had different constraints in mind while they were writing their barrier algorithm than the constraints you have to solve your problem. As problems grow more sophisticated, you’ll find yourself in a situation where made-for-generic-use solutions won’t fit your situation and that’s just fine.
Back to main thread on concepts and implementations: I believe it makes a difference to be able to judge the differences between those n implementations of the 1 concept you’re going for. Because when you need to use a concept to solve a specific problem, you probably have 1 or 2 of those n implementations that has the same constraints and context of you have with your problem. You have to find that one to be able to pick the solution that’ll fit perfectly or good enough. Or alternatively, you have to be able to judge that all n implementations are actually not solving your problem, so you need to implement your own version of the concept you’re going for. So it’s also a bit about going above/through abstractions whenever you can. It makes you understand core concepts better and build a stronger core knowledge of how things work fundamentally. Eventually, I believe that makes you a better engineer or a better tech leader of any levels.
I think that is also true for the programming languages, frameworks or technologies. Experiencing many of them should provide you enough opportunities to be building a knowledge to see through their strong and weak points. It’ll push you in the direction to build a knowledge of software engineering, where it is not depending on one language/framework or the other but it’s depending on fundamental knowledge of concepts.
That was something I wanted to test myself at for a long time. I often thought I’ve built my knowledge this way as I move forward in my career. But obviously, I needed to prove this to myself: Just pick a completely strange stack and go figure out about how to build software as efficiently and scalable as I’m able to do in .NET/C# ecosystem. I’ve come close to doing it couple of times during previous years but never did it.
You can always do this on a hobby project basis, but I never seem to build a pressure cooker environment for my hobby projects, where constraints create an environment to make learning curve very steep. I also didn’t wanted to do this while I was an individual contributor in my career because I thought I was on a place where it would set the feeling of progress in my career backwards. Obviously now that I work as an engineering manager, it feels more comfortable to initiate this change in my career.
I’ll finally be able to do this, in a professional context. Very excited about this new chapter of my career and the feeling of “throw it at me, I’ll do my best to figure it out”.
