I guess I took a very common path for my generation. I got my first computer when I was 14, and like almost everyone else I started playing video games. First game I got really stuck on was Quake 3 and I fell in love with the Map Editor. Being creative and using it as an outlet to fuel the game you love was amazing. So I started to edit some scripts for the maps to build launchpads, doors and stuff you needed. Then I wanted to share those maps I tried to learn HTML to build a web-interface that gets loaded from the CD and people could select the maps they wanted to install. It was not great at all, but I had a ton of fun at what I was doing.
Then I moved on to develop a browser game with a friend and just play around with new tech. But I actually never learned proper programming until I started University. I liked putting together graphics and scripts to build things, but programming was super abstract. We started in Java, and to this day, I don’t really like it at all.
From the technologies I work with the most, it’s definitely Vue. Like Laravel in the early days, I saw this was going to be amazing. I had the same feeling for Vue. I joined the journey very early on, by pushing for it to be used in our product. To see where Vue is today is just incredibly exciting. I like the maturity it brings to the table. A seasoned and steady evolution that does not feel like hunting trends, but more following a natural progression of technology.
I know most of the Core Members by now, and all of those people are just incredible individuals that have a great mindset that allows to let this project grow in a thoughtful way, by focusing on what does the community need, and not by following personal needs.
That all said, I know what a small window into technologies out there I have. What I am constantly impressed by technical developments that happen far away from my day-to-day work of web applications. People that use technology to tackle real-world problems, saving the planet, improve the quality of life; that’s what really impresses me over and over.
Vision - I always need a vision. What is the goal, and WHY does it need to be built. Then I like to break down the parts of the feature alongside a clear architectural concept.
Architecture - To reach this concept, there is a lot of messing around necessary. Sometimes, I try out crazy ideas to just check if it could be done. Simplicity is the biggest focus there, to be honest.
Proof of concept - I try to build a working proof of concept as fast as possible to discover flaws in my plans very early on.
Improve and Stabilize - Once something is working I want to improve on the most important parts and make sure they work. Here I think it’s important to focus again on the original vision to not get sidetracked and end up gold plating parts of the solution that bring no value to the feature, besides satisfying my technical experimenting.
Testing - Before anything goes into production, I need tests. Of course Test Driven Development is the best way to go, but honestly…. It does not work every time. I have established certain ground rules and know where I am going to be able to build tests before the implementation. So often I switch from the tests-after-implementation to a test-driven-development flow during the project.
Shipping it to production - This needs to be automated. I can’t stress this enough. I don’t trust myself being able to remember all steps of releasing code to production, so I automate it. That’s also why testing is so important. Otherwise, automation can go horribly wrong. To summarize all that I said in two points.
Planning, then Continuous Delivery and Development.
Currently I actually step away from being an individual contributor, but trying to help others to achieve their full potential as an engineering manager. I love working with people and talking about tech, and if I can help others being successful and become better than I am, that is perfect and a great motivation. The biggest challenge in this process is to not share solutions, but help people reaching those on their own. This needs a lot of rethinking and learning.
That is definitely Codeship. I joined the startup very early and was able to contribute to a tool in the developer cosmos to enable others. There are especially parts of the application I poured a lot of heart and brain in. For example, we had a page that was critical for our users, and it just didn’t work properly. So I completely re-architected how the page works in a short amount of time and rebuilt it from scratch. And all the major issues we faced were gone. I was incredibly proud of that achievement and it changed how I work.
The thing I was most proud of in my early career was an application I built with a designer friend of mine for the David Copperfield Museum. The little boy in Austria building something for a client in the states was pretty exciting. The cool part was, it was a fully working web application to manage all the requisites and stuff.
The UI was top notch and needed to work perfectly on the iPad. That was the first generation of iPads back then, so that was a challenge regarding performance. But I built the whole data layer and model and UI. In all honesty, when I started on this project, the requirements were completely out of my comfort level, but I learned a ton during this project and if for sure changed my career in the way that I found my love to build applications more than websites.
Simple Problem-Solving - We now teach people to solve problem X by using solution Y. Eventually, any problem can be solved with any technology. What we don’t teach people is to take a step back, grab a piece of paper, and try to think the problem through; detached from the technology you are going to use to solve it.
It’s an invaluable skill to be able to break down a problem in small pieces as you fully understand it. Often, the solution is simple, or at least once the complex problem is broken into small steps, the small solutions will be simple.
There are too many to count. Trying to innovate, will inevitably face you with countless challenges. How to solve, what no one has solved before? I guess I answered that in the previous section.
Eventually, many of the challenges we face are Infrastructure related having to do with Docker, Kubernetes and other things, I personally understand too little to talk about. What I and my team will focus on is bringing whatever we need to the user with a big focus on UX. Our goal is to not let the tech dictate how the user should eventually use something, but what is the UX we want to provide.