To be honest, it was with much trepidation that I started on the first of May, but as it turns out, for all the wrong reasons. Comfort zones are a real thing, and most people are averse to change. I don't count myself as being among them, but sometimes it's not your decision. So I was totally unprepared for how stale I had become while being stuck on a project that was, when I started on it, already out of date with current .NET and ASP tech.
Unfortunately, a company uses you where they need you, and despite efforts and requests for other projects, I was the team lead for ZapZap's API for almost two years. I didn't realize what a blessing the executive whims would be, being axed from the project through the contract termination. So finally there's some new work, new technologies and new platforms to look forward too. But it hasn't been easy.
Microsoft has moved MVC and ASP into completely different spaces recently, with Owin self-hosting for example, and the WebAPI stuff. I had not had the chance to look at these given the limited time I have at home, so ramping up on a new project, on new tech, within two weeks (the ever present two-week sprint targets) was a real challenge. And also very unfair, but trail by fire is the only trail I know, and it's the only trail I've ever had. I surely can't claim to have ever had a relaxing day at work.
So now we're into the third week, and things are settled. The project template, established by the .NET tech lead, is becoming more familiar, and since troubleshooting some issues with Owin and self-hosting for integration tests, things have become more familiar and the conceptual picture more detailed. So what about all this then? Well, there are a couple of things I encountered here. One is the "turn-key" solution attitude, which I think is ill-advised, and over complicates matters significantly. Each project is different, and each project's solution should be too. I've had to remove more from the template than I added to complete the requirements. The other is statements like "Oh this is code-first, like everything should be". That's a pretty reckless statement in my opinion. In fact, for the project I'm currently on I have no control over the database, rather it's an entity that I simply integrate with. Running EF code-first in this scenario is actually rather silly.
But there has been some good things too. Since this is a new project, we don't have a unit-test backlog, so we can keep our code coverage up. We can employ SOLID principles from the start, and not have to deal with very extensive surgery to correct issues in the code-base. In fact, this is the first time I'm starting on a new project. It's a totally alien concept for me since I've always had to deal with refactoring on every single task, which it's probably one of my strongest skills. I hope that it doesn't now become stale as a result!
Since the launch of the new ND this year, there’s been a lot of heated discussion about the car. It’s had such a polarizing effect, even between stout supporters of the previous models on the miata.net forums to such an extent that they had to aggressively moderate the thread for a while.