Random comments on random subjects in random language
I’ve got this friend, he has been working as a software engineer for nigh on 30 years now and has steadily accumulated an arguably impressive amount of knowledge about the workings of computers and programming languages and software design. He tends to be good at what he does and the amount of experience he carries is invaluable when setting up teams and systems. This is recognized and also…
My guidelines for using chat (Teams, Slack, whatever you fancy) as a collaboration tool in a software development team are as follows: Chat is asynchronous Always provide context when addressing someone. Never go “Hi!”. Ask the question immediately and with as much information as you can provide. If you don’t provide context you are demanding the immediate attention and response from your…
The advent of AI marks a fundamental change to the discipline of software engineering. It is one of those changes that rearranges the way people work and think about that work. So, in the interest of self-preservation I have been spending time with various AI models. There are two avenues that I am interested in pursuing this, how it affects my coding and how it affects a team. Delegating coding…
“Happiness” is a dumb metric within a work context. Success is measured in outcome not output and blithely sailing past a deadline while deliriously happy is not my idea of a good thing. Also, satisfaction at work, while important, is not measurable in the emotion scale I associate with happiness. Confidence, the feeling of achievement, satisfaction in a job well done and appreciation of said work…
The subject is autonomy within a software development team, or rather the consequences of interpreting a very broad and vague term such as the single word “autonomy” in very different ways depending on where you come from, how experienced you are or what suits you. My first reaction once I got the idea of writing this down was to go back through the sources, my own influences over the years and…
It has been a decade in less than 8 months. The last time I had some time to gather and collect thoughts is shrouded in mental mist. In the beginnings of April, while adjusting to a full lockdown with far reaching personal consequences, I took on a new challenge by casually accepting a new project assignment. The new team needed a “data lead”, someone described as “knows databases”. It has been…
This is part of a series of posts documenting my ongoing adventures in TeamCity, starting at Tales of Teamcity: Adventures in Kotlin Kotlin is cool. I am a fool. These two sentences are both true. The best aggro moment of the last three days was when I spent over two hours trying to figure out why the following script failed: import jetbrains.buildServer.configs.kotlin.v2019_2.* version = "2019.2"…
TeamCity is one CI system I haven’t had a lot of contact until now. As will become evident, this has now changed. So, alongside a crash course in basic Kotlin, I now have to figure out how to get my brand of build automation working in TeamCity. The gatekeeper I have one criterion for accepting a build management system: Build job specifications have to be stored in the repository Let’s explore if…
One of the hackiest formats under wide adoption is the JUnit report format. It is not really from JUnit, it’s from Ant. It is not really documented anywhere - some people try to figure it out by reading the source (after looking for it first in the JUnit sources - lots of fun following the different StackOverflow threads on this). Given that there is no official schema or spec I am not surprised…
Azure Devops has this really cool feature, where you can use specially formated stdout strings to pass different commands. They are called logging commands and by far the most useful of those is setvariable which allows us to set a variable in one task, that is then available as an environment variable in subsequent tasks: #!/bin/bash echo "##vso[task.setvariable variable=testvar;]testvalue" A…