As of 5 January 2020 I have been working for Entelect for 5 years, which means if I exclude my time at the company’s boot camp I have more than 5 years of experience. In some circles, people would consider that to be somewhat significant, but I do still believe it pales in comparison to some of the people I worked with when I started. Even though I feel the amount of experience I have to not be that vast, I have some level of professional experience with the following technologies and I deem myself relatively confident doing at least some basic form of feature development for each:

• ASP.NET MVC
• ASP.NET WebAPI
• WCF
• Android
• iOS
• Spring Boot

The majority of my experience, however, lies in predominantly .NET technologies. I used .NET for about 4 years, some time which was spent working on an Android app as well. The last year I’ve been predominantly focused on an iOS app with a Spring Boot backend. This very likely means that I still have a long way to go with some of these technologies, but I feel I’ve gotten enough exposure now to be able to hold an opinion on these technologies and compare it to my experience using other stacks. I will add the following disclaimer though: these views are very likely to be opinionated and not fully formed, but I still felt it important to put down some thoughts based on some of the struggles I’ve faced at work.

This will also be a little more of a story I’m telling rather than highlighting pros and cons. I’ll be highlighting the things that stood out for me and why I liked/disliked the situation I found myself in.

First contact

My very first contact with programming was somewhat unique in South Africa. The high school I went to were one of what I believed to be only a handful of schools that taught Information Technology using Java as the programming language of choice. We initially used Ready to Program with Java as a very lightweight IDE, but later switched to using NetBeans as our IDE of choice. The main motivator was that it allowed us to use it’s GUI building tools for our projects.

Jump forward a few years to university and I had my first contact with C# as well. I have vague memories of using Visual Studio 2008 during the time, but it was relatively brief before we switched over to 2012. The majority of my subjects were still preferring Java, but we had no contact with how to pull in external dependencies or even better package up our solutions. I took part in the 2014 Entelect Challenge where I had built a bot in Java. I had struggled a lot figuring out how to get a basic project setup with Maven, but looking back I suspect it was nothing other than just bundling everything into the same package and submitting it as is.

Throughout boot camp, our tools consisted of more “professional-grade” like Jetbrains IntelliJ IDEA and Visual Studio. I initially had hopes to be put onto a Java project, because one of my lifelong dreams had been to work with my cousin and he was one of the best Java developers I knew of. When I got the news I’d be joining a C# project I was mortified. Luckily I changed my mindset to rather see it as a learning opportunity because the team I joined ended up providing me with an amazing mentor.

The thing that stood out a lot for me was how well Visual Studio functioned as an IDE. Boot camp hat taught me how obscure working with a Java project can be, mostly because of how obscure the tonnes and tonnes of XML configuration was. Now I do know that the csproj files used in Visual Studio also consists of XML, but Microsoft had ensured that there was a heck of a lot of tooling available that my GUI reliant mind could grasp. Even today I find the GUI tooling in IntelliJ IDEA to be lacking, but it is likely something obvious that I’m missing somewhere.

Amazing language

I know I’m also comparing C# against Java as if they are interchangeable with the frameworks they are used in, but the reality is that a Spring environment favours Java and a .NET environment favours C#. Now the biggest draw for me towards C# is what Unity does with it. Becoming quite fluent with the syntax of C# had meant I didn’t have to spend more time than necessary figuring out what to do. I do realise it might be a little menial, but switching between Swift and Kotlin these days sometimes leaves me scratching my head for a few minutes over why something isn’t working.

Game development isn’t the only thing that entices me to believe C# is an amazing language. Here is a list of some small features that I like:

• Generics on primitive types
• Custom struct types
• unsafe programming
• Extension methods

This list constitutes only a small amount of features in the language that I like. There are other languages like Kotlin and Swift that provide some better features, but they also lack certain features at times.

The big plus with the ability to write unsafe code in C# is how I use it in Unity. Games tend to be very dependent on performance-critical code and the team at Unity has proved that C# can be used as a tool to write code that performs at native speeds. I’ve written about it a lot, but if you’re interested in reading more go look up the Data-Oriented Tech Stack (DOTS for short) Unity had built. It has blown my mind to see what they can achieve by leveraging an existing piece of technology to create some amazing demos.

Simple tools

This last point has been somewhat of a thorn in my side recently. I’ve been very frustrated with how certain environments configure what has to be built and what has to be copied as a raw file dependency, but nothing has matched the ease with what I can achieve in Visual Studio or Rider.

This doesn’t mean I’m saying that the tools I’ve used for other things are complete trash, but rather that I just prefer something that works a little more convention-based. Add to that some of these tools feel like they’re trying to do a whole lot more than just one thing which makes trying to understand what is going on a hell of a lot more complex.

I have two examples of what I’m talking about, one based off the iOS app written in Swift I’m currently working on and the other based off of the web service we’ve built using Spring Boot with Kotlin.

Before I jump in I’ll just preface this with a quote from my cousin while I was discussing some of my headaches with him:

The extra power of having something fully customizable is almost never worth the maintenance cost… - Matt van der Westhuizen

iOS & Swift

Xcode is an absolute beast of an IDE. It’s UI seems very arcane and it can sometimes be very difficult to figure out where the hell you need to make a configuration change for something. Add to that only introducing 1st class citizen support for something like dependency management in the 11 version of Xcode and my attitude quickly turns sour.

We’ve been using Cocoapods for our dependency management and I’ve been appalled at how difficult it is to get everything integrated and working. Add to the mix that Cocoapods tends to embed itself quite deep into your project and my headaches start getting worse and worse.

I love that Swift is a native language, but when I start breaking up a project into modules and I simply can’t manage to do so it’s left a very sour taste in my mouth. I’m hoping it’s mostly because I’m dumb, but my experience with .NET has made breaking pieces of functionality into a little library a much simpler task compared to what I had to go through in Xcode.

Spring Boot & Kotlin

Right out the gate I’ll open up and say we’re using Gradle in this application. My experience with it has mostly considered it a necessary evil for Android development, but truth be told this was long before Kotlin was the de facto language for Android development. With this, we’ve moved to use Kotlin Script as our domain-specific language (DSL) as well.

Now my experience is limited here, but I was trying to correlate what dependencies were installed from where and what transitive dependencies were pulled in as a result of that. I’m not sure if this was because of the lack of code completion in our build-scripts or something else, but it just wasn’t immediately obvious to me from just looking at the list to see what’s going on.

I had also spaced on the fact that Gradle is something of a Maven wrapper so I could’ve gone and used the MVN Repository, but I couldn’t find any indication in my fancy JetBrains IDE that would’ve pointed me in that direction. When I think about it though the world of Spring and dependency management is complex in my experience. I wouldn’t be surprised that I might be missing a plug-in or something, but it still leaves me frustrated that I had to take quite the detour to get the information I need.

Keep it simple, stupid

Comparing the experience to NuGet and how nicely it’s integrated into both Visual Studio and Rider I just can’t help to be in love with .NET. I like how NuGet is a separate tool from MSBuild which makes diagnosing problems a whole lot easier. Having some solid GUI tools available has also gone quite the distance towards my satisfaction, because I don’t always have to be fully clued up with each keyword means and what it does.

Now I’m not arguing against complex build & dependency management tools like Gradle, but the truth is for my needs I’d rather opt for simplicity over flexibility. The main motivator is merely related to the type of development I mostly find myself doing. I’d like to know that when I open up a project I can read through everything myself and have a pretty good idea of what’s going on. I don’t want to find that some assumption I’m making based on something very reasonable to be invalidated because of some deeply embedded nuance in how the tooling had been customized.

It’s lead me to embrace what my cousin mentioned and I’m constantly weighing the complexity of something up with the usability for the team. If the balance sways more to one side than the other I’d rather defer the decision to some later time where I’d hopefully be able to make a more informed decision. Sadly some of these tool decisions have to be made upfront and it’s only months later that you start running into issues.

Conclusion

I fully understand people are unique and that everybody’s mileage may vary, but these are some of the reasons I’m absolutely in love with .NET and it’s most definitely spoiled how I approach development in some aspects. I’m constantly learning and getting exposure in other tech stacks is insightful, but it’s also showing me more and more that I prefer a specific piece of technology over the other. It does mean that while I might prefer something I can’t expect others to just follow suit. My current team had no experience in .NET when we started on the project, so we opted to use what they were comfortable with. It just so happens that the time I’ve spent ramping up on some of these technology choices had solidified some of my preferences a little more.