I find myself pondering what I want to do when I grow up. It’s an important question, one that should be asked throughout once life. But it’s most probably a question that will never find an answer, since life will change constantly and new obstacles and opportunities will present themselves. So, where do I go from here? Well, if life brings you lemons, make a lemonade. Or don’t. Your choice.

So, still thinking what to do, having not found an exact answer, I figure I’ll tap into the, if I might say so, rather deep well of my software development experience. Having touched upon many different technologies over the years, such as databases, html and CSS, JavaScript and C#, even odder flavors such as Clipper and Dataflex in a distant past, my unquestioned, unchallenged favorite tech is Delphi Pascal.

A bit unknown, uncommon and, perhaps also considered a bit aged, Delphi is to the contrary; A well maintained, modern and powerful programming language with millions of users all over the world. In fact, it is one of the most front line multi-platform development languages out there. And I just love it.

Also, I’m rather good at it. I should be, having used it daily since before it was even Delphi.

I do all my hobby projects using Delphi, I’ve written many different types of apps and IT systems for companies such as SVT (Swedish Public Service Television), TV4, PostNord, Handelsbanken and others. I’ve worked in Delphi teams maintaining software for the manufacturing industry, for the financial industry, for the music industry and even for the food- and candy industry (yes, I made the name of the last one up).

I don’t really know what I’ll do next, but something (apart from coding Delphi and C#) I think I’d be really good at is helping (Delphi) teams get better at developing better code. Code that is cleaner, that has fewer bugs, that are easier to maintain, that reaches the user faster. Helping teams get the glue between users, developers, testers, stake holders and DevOps to stick better.

So, I think, a perfect role for me would be as a developer of a (preferably) Delphi team, or C# team, coding features and fixing bugs like everyone else in the team, but also focus on getting the team to be better at it, to deliver better code and higher quality and to work more efficiently.

As a senior software developer, architect and technical team leader, I draw from 30 years of experience in the IT business. I always focus on the client’s needs and the system’s intended function. Part-taking, objective thinking and discussion are crucial parts of developing software.

Over the years, I’ve collected a large skill set and extensive experience in developing all kinds of software, both large and small. I’ve worked with many tools and techniques, among which I favour Delphi and PostgreSQL, although I am comfortable with many.

I am still and ever hungry for new things, new experiences, challenges and new relationships. I’m still trying to figure out what to do when I grow up.

There’s lots of stuff I really know, some things I have a working knowledge of and other stuff I really don’t have a clue about. Stuff I really know is, for instance, Delphi, PostgreSQL, SQL Server, MySQL, SQLite, PHP, HTML, CSS and JavaScript, GIT, REST servers, APIs, Windows, DOS, Swedish and English.

Things I feel comfortable around, but I don’t use every day are for instance C#, C++, JavaScript, Oracle, NoSQL databases, Objective C, Linux, Android, iOS, OS/X and certificates.

Among the things I don’t know much about but would like to, are blockchain tech, machine code (though I haven’t a clue what I should use it for), Raspberry PI, Spanish and the flux capacitor.

What you really shouldn’t hire me for are things like COBOL programming, brain surgery, rocket science, artwork painting and taxidermy.

One of the things that are high on my list of priorities is the agile development process. Successful software development depends on many things, one of the most important is a strategy. Regardless of if it is bugs or features, you need a plan of attack, and driving and refining that process, be it scrum, kanban or variations, is not quite, but almost, a religious thing to me.

During the last couple of years, I have worked as a scrum team member and I have introduced Scrum to new teams, and that is something that I wouldn’t mind investigating further.

As part of the Scrum methodology, I like to incorporate rules and guidelines for the actual process of developing software. If Scrum or any other project methodology is the framework keeping all the larger bits and pieces working nicely together, these rules and guidelines – or code care as I like to call it – aim to assist the developer and the development team to produce good, maintainable, bugfree code.

If the Scrum process starts with a stakeholder writing a user story and ends with that story delivered as free of bugs as possible, the code care process starts with that user story getting test cases, solution suggestions, new shiny code, code reviews and finally a release and/or successful acceptance test.

By reducing the scope of the tasks at hand, all involved can focus on each specific task that needs to be addressed. And using the guidelines of the code care process there is no question how each coding item should be implemented.

Writing code and creating software systems is a handcraft, and rules of the craft should be applied. And there actually are rules out there that can be applied. It is just a matter of deciding to use them.

• 2023- ISEC Systems AB
• 2021-2023 Binar Solutions AB
• 2018-2021 Subcontractor at Svenska Handelsbanken for TEKSystems AB
• 2017 Winassist AB
• 2016-17 ISEC Systems AB
• 2011-13 Prime One AB (partner)
• 2006- Linri AB (owner)
• 1998-2006 Dataline Sweden AB (partner)
• Earlier engagements provided upon on request