i am a software engineer with 12+ years of experience in the industry, where i have been working as a developer, lead developer, technical team lead and software architect. i am passionate about my profession, which is why i enjoy continuous learning and practice.
i learned creating good software the hard way.
mistakes have been made
-
in 2007 i built websites by writing inline css in html in php in js in html in a php file. it was ajax, well sorta :-).
-
in 2008 i was working on a company cms that added parameters to sql queries via string concatenation and very poor sanitization. it obviously got hacked at some point, leading to a disaster for the company.
-
in 2010 i wrote my own orm and it didn’t support lazy loading. i think you can imagine what the performance was like. i learned a lot doing it, but that’s the only positive aspect i can think of.
-
in 2011 i was maintaining a prototype-turned-production incident management system for public transport. it was stuffed with commented out code and i was afraid to delete it for weeks. gosh, i should have deleted it right away. it was in this project that i learned to feel more comfortable throwing code away.
-
in 2012 i wrote a 3-figure page long scope statement that got signed by the customer. turned out it was as worthy as a toilet paper just a few days later.
-
in 2013 i attempted to use an extensive, heavy-weight, standardized data-transfer model as the internal model of an application in which the database technology was already decided. not only was the database a bad fit and chosen way too early, it was also a terrible idea to use this transfer-model as the internal model. it would have been ok to keep a copy of the messages, but the business rules should have been based on a separate simplified internal model.
-
in 2014 i developed an enterprise web application in a tdd style using mainly integrated tests that used an embedded database. the tests were nicely decoupled from the structure of the code, but at one point the commit suite took more than 10 minutes to complete. colleagues started to skip running the tests. it was in this moment i knew i never wanted a commit suite run longer than 1 or 2 minutes, but i prefer seconds.
-
in 2018 i was working on a project where annotations were heavily used to accomplish all sorts of things: generate code, map data, inject dependencies, validate, route requests, and much more. You can do almost anything using annotations these days, and they do a fantastic job in making the common case easy. it’s just that i have not yet found the application that only consists of common cases.