To be perfectly honest, it wasn’t planned at all. I wanted to become an art director and work with design. But the school I wanted to go to required you to be 25 years old, and have 5 years of work experience, and I was only 19 or 20. So I got a job as a sailmaker apprentice as I did quite a bit of sail racing back then.
However, a few months into that career my brother asked me to help him out by building some HTML pages for a project he was working on. So I did. And that project, after a few interesting twists and turns, turned into a startup that hired me as a junior dev. However, by that time, the project had turned from a sail racing news application into online sports betting application.
For most of my developer life, I have not had a fancy dev environment. I travel quite a lot and speak to a lot of conferences, so I try to make due with a great laptop. I don’t even plug it in to an external screen in most cases. Instead, I want to make sure that I am as efficient on my laptop as I can be. Moving between a laptop keyboard, screen, external monitors and keyboards, etc is just too much of a shift for me. I’d rather just be really efficient with the set up that I will always have at hand. At the moment, the laptop is a generation 1 Surface Book with an i7 and 16Gb or RAM.
On the other hand, I recently decided to set up a desktop at home. So when I’m working from home, I’m currently using a desktop PC running Windows 10. It is hooked up to a 43” ultra-wide monitor (3840x1200 resolution) and a wireless Surface keyboard and mouse.
Moving to the desktop has made a huge impact on the way I look at my hardware to be honest. The power I get out of it is just so much more than I can ever get from a laptop. So now I try to use that when working as much as I can, as it is a lot more fun when stuff is really fast.
If we are going to go really geeky and look at the specs, it’s not massively impressive, but it works. It’s an 8-core i9 9900K, 32Gb RAM, a 512Gb m2 HDD, and a GTX 1060 graphics card.
That is somewhat a tricky question to answer for me. I have worked on so many different things over the years, using many different technologies. In general, I have stuck to Microsoft as my platform for different reasons, but within that space, there are lots of different things you can do. I have done a lot of web development using ASP.NET, both WebForms, and MVC, but I have also worked a lot with Silverlight (rest in peace) and WPF, and even some WCF.
So if I had to choose a stack as my favorite, it wouldn’t be the simplest thing to be honest. There is so much cool stuff out there. But if you forced me to choose, I would probably choose .NET Core, running on Azure, fronted by a TypeScript based SPA built using Angular.
This is going to sound really boring, I know, but I have to say .NET Core. There is so much stuff coming out of that right now. And it’s not just a lot of stuff, it is a lot of useful stuff that I can take to clients and actually use.
Being a Microsoft developer has changed so much in the last few years. It has gone from working with all of these somewhat proprietary things into working on all these fast-paced open-source things. The tooling is changing, the way we get updates and new stuff is changing, the way we can interact with the teams building our frameworks is changing. It is just an interesting time. I never thought I would spend as much time in a terminal as I am right now. I have always claimed that graphical interfaces are superior, and even if I still believe in a lot of cases, using the terminal in the way that I can now with Microsoft stuff is pretty nice.
My workflow is very much a “hack it together and make sure it works and then refine” kind of a thing. I like getting the problem in front of me and then hacking together a solution that proves that it works. After that has been proven, I then refactor it a few times to get it to code that is easy to understand and maintain.
I’ve rarely worked on projects where I have had clear specifications on what to build. Most of the time I work on solving a problem in some way, without any clear definition of how to do it.
I think the way I work is partly shaped by the types of projects I’ve worked on, and I have for some reason often ended up on projects that didn’t have a clear solution or a clear path, and with that background, I am mostly focused on making sure it can be done and works, before I start making it pretty and shiny.
That doesn’t mean that I hack together something and just deploy it. It just means that I generally start out with a PoC that verifies that my thinking around the problem is correct and that my solution to the complicated parts work before I focus on production quality. This means that I very early on can switch direction if it doesn’t work. It also means that I can give other members of my team access to early, but potentially unstable bits so that they can carry on while I improve and stabilize the implementation. Something that seems to be really helpful in a lot of scenarios when other team members depend on your code.
I’m currently deep into learning Docker and Kubernetes. I don’t really know why I found that to be the most interesting thing I have seen in a long time. It feels like something that more Ops related people would be interested in, but for some reason, there was something that caught my eye and got me very curious and interested.
To be honest, those technologies are probably the first things that have made me really wanting to sit around and play with my computer in a long time. My interest in software development comes and goes to be honest. The older I get, the less time I spend at my computer. But yeah, Docker and Kubernetes have got me back to the screen.
That is another one of those really hard to answer questions. Weirdly enough, I think it is one of the Frankenstein applications I built while I lived in New Zealand.
It was a kiosk application for selling tickets to events around New Zealand. It had a few different hardware things like a ticket printer and a credit card reader, and it integrated with a few different serviced. All in all, it wasn’t a very cool project as such, but I had to get it built in less than 3 weeks, which was very interesting. Not to mention some very awkward technical limitations that made me do some things that most people probably would consider insane. Things like creating a single-threaded app pool for a WCF service to handle the fact that I was hosting a non-multithreaded ActiveX control inside it for example.
The solution was really a Frankenstein application with a huge amount of quirky fixes to solve the technical limitations. But in the end, it was delivered in less than 3 weeks, in time for the client to get it out into the public, selling tickets for an important event.
It might not have been the most beautiful code, I can admit to that, and it had some very interesting solutions. However, even with some ridiculous limitations that were enforced by some of the hardware, it managed to get the job done and solved my client’s problem. And in the end, that is all that matters to the client, and to me. I do this to help people solve problems they can’t solve themselves.
That most of us are employed to solve business problems, not deliver code. There is a huge difference. Yes, the code solves the problem, but the business rarely cares about the code. They care about solving a problem.
Unfortunately, that part often gets lost when it comes to developers. We often focus on how cool our code is, or what cool frameworks and patterns we use. But in the end, all of that is just there to solve a “real” problem. Using fancy patterns and good practices might make our lives as developers easier by reducing issues and making the code maintainable, but in the end, they are just a tool to solve business-related problems.
Right now I’m at the start of creating a larger microservices solution for a client. However, we decided for different reasons to move from Node and TypeScript to .NET Core and C#. A move that will prove very useful in the long run, however, right now it is a bit of an interesting challenge.
Technically it isn’t that complicated, but there is always that time issue. There is a bit too much to do, and not enough time to do it in. It is very hard to explain to the business people how important the foundation is, and how much time it takes to make that part solid.
Adding a lot of developers to a solution like this, with a lot of decoupled services, before the foundation and shared functionality has been properly implemented causes a lot of interesting technical problems. Especially in the shared areas that are slowly being built at the same time as the service that build on top of it are being built.
Personally I always want to try and set aside enough time up front with some really good developers and have them set up the shared parts of the code base while fleshing out the first service that uses the shared code. This allows them not only to make sure the shared parts are there in working order when the rest of the team comes in, but it also creates a blueprint for the “new” developers to follow.
I don’t really have a repo ora tool or anything to plug, so I would rather plug a suggestion. I suggest trying something new whenever you can. Recently this has meant moving out of my comfort zone of using Visual Studio, and picking up VS Code, the “proper” terminal, Linux through Windows Subsystem for Linux and working with tools I have never used. I still use .NET Core and C#, but doing it using new tools is quite an eye-opener. Seeing things from other perspectives not only teaches us new things, but it also questions the things we normally do. For me, this has, for example, made me question the use of a lot of built-in “magical” functionality in Visual Studio, and instead, look at how to achieve the same result using other tools. Something that has been very interesting and challenging. Visual Studio has some pretty awesome “magic”.