I’m a very skilled and experienced Delphi programmer, well versed in the art of clean coding, professional programming and quite good at spotting potential future risks in any solution, particularly Delphi ones. What I’d bring to the table is all of my experience of building robust Windows applications, improving legacy code and spreading my knowledge and passion for working with Delphi code to the team.

I draw my inspiration from writing beautiful, effective code and excavating the depths of the Delphi frameworks and talking about and reading code. After all, we spend more time reading code (trying to understand it and fixing its bugs) than writing it. I’m a firm believer (and quite passionate about) that sub-par code should not even enter the codebase. If the suggested solution isn’t up to the highest standards, it should be sent back and fixed no matter when in the process that discovery is made.

After all, we software development professionals carry the ultimate responsibility that the code running in the billions of electronic devices around us meet the absolute highest standards and quality. It’s important. In some cases, even lives depend on it.

In my experience, agile working methods are a success factor in any development project, but I take a pragmatic perspective on agility in software design and development. In my view, agility has become a buzz word and commodity. As I see it, agility is for the development team first.

A role that would suit me is as tech lead of a Delphi team determined to deliver outstanding, future proof Delphi code, be it legacy or brand new.

I’m open to new opportunities.

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.

• 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

On a more personal note, I live in Norrtälje an hour north of Stockholm, Sweden, with my wife Linda and three Chinese Crested dogs. Orbiting us are my kids, Tim and Lovisa and Linda’s kids Linus and Marcus, all of them (or nearly anyway) out of the nest.

A couple of years ago (2015) we bought a house, more or less a summer house, to renovate and make permanent, so when asked what my hobbies are and what I do to unwind, I usually answer, improve our house.

That’s not absolutely true. Rather, that work on the house is done intermittently, in waves. I am a genuine nerd though. To unwind from a busy day coding at work, I… code.

I have a long list of personal hobby projects that never seems to be finished. It seems the important thing (when it comes to hobby projects) is not to finish, but to learn, invent and push the boundaries a little bit further.