During my career I met different technology stacks and I poke them either as tester (either manual or test automation engineer) or just delivered software (basically didn’t give a damn what technology it is) as manager with the teams I worked with. The list includes php, java .Net and the mixed world of Big Data where everything is there in various quality. During the years I realised that .Net is the stack which gives me the most comparative advantage in my project and happiness in development.
Angular 1.x eased the pain a little bit. Angular 2.x made Typescript default and we were close to what strongly typed languages can give you. But, still, webpack, linters, treeshake, npm hell! and other black magic… not to mention that the landscape changes in every 9-12 months or faster. It is an innovation hot spot and it is natural. But, still a clusterfuck.
Microsoft introduced Blazor in 2018. The promise is that you can use C# at both client and server side. Since .NetCore 3.0 is out I have been working with Blazor Server hosting model. The experience is great! C# is everywhere. I can debug easily my app using Rider (it still lacks proper support for Rider) and no struggle with contracts between JS app and server side. You just can share your domain objects and happiness.
Blazor still lacks features are default in Angular, but guys at Microsoft working hard to make Blazor a very compelling option to anyone.
When I started Digital Library project I gave a chance to the project management services provided by Github and they failed. Mainly because I didn’t know them and didn’t have enough patience to pick up some new knowledge, I wanted to move forward. In the following a few weeks the project got up to speed, so my goal was accomplished, and in my thoughts there was place to integrate something new. During this a few weeks I started to follow Microsoft’s open source projects, especially aspnetcore, dotnet/runtime and entityframeworkcore. As I read their tickets and pull requests I slowly understood how they integrate Github and Azure DevOps Builds. The result is that I put together a test project and tried Github – Azure DevOps integration in the most common scenarios I’m going to use. The result is that, finally, I started to use Github as I originally wanted.
One of the reasons I wanted to run my project fully on Github is self PR. Even though I don’t consider essential being on Github in my career, I’m an engineering manager and not a developer, but still being on Github and being able to display some professionalism might result something positive in the future. The other aspect is that, making your professionals transparent is a responsibility I have to deal with.
The lessons… First, you just have to understand when you are ready to absorb new knowledge, which may result some struggle and not the progress you seek. There is no such thing you are always able to integrate something new in your structured knowledge. This ability can be crippled temporarily by other priorities. In my case the need to be able to move forward was more important.
The other lesson is that you have to be able to define what is important for you. The way I wanted to manage my project was based on an earlier experience (14 developers, 4-6 feature developed in paralell, feature branches and multiple supported versions). My problem space is way simpler, and I was needed some time, and possibly clear head too, to understand it. Again, the need to be able to move forward clouded my judgment.