Since minqlx seems to stand for “Mino’s Quake Live eXtension” and I go by the player name of ShiN0 in QL, I thought an obvious name for my Rust implementation of minqlx would be shinqlx for ShiN0’s Quake Live eXtension.
But before we dive into the first steps I took, maybe a few introductory words and maybe some references in case you want to go a similar route.
Continue reading Getting started with Rust and shinqlx
I recall discussions in the early software craft days on the mailing lists. One thread, in particular, comes to mind today, that was about whether a good crafter should learn a new programming language every year to learn new coding styles and paradigms, and maybe bring those back to their usual work environment.
Last year, Craig Larman recommended learning the programming language Rust to help, especially with embedded programming. Linus Torvalds also allowed Rust as a third language in the Linux kernel development around the same time. It took me a while to actually try it when I found the perfect for me pet project to dive into.
Over the next couple of blog entries, I want to dive into some of my learnings and approaches. Today, let me give you an introduction to the project I picked for my personal Rust learning curve, where I am, and maybe give you an update now and then about the things I still have open to learn.
Continue reading So…, I got a bit rusty lately
The other day, someone on the Crafters’ slack posted a video where someone argued about software craft vs. engineering and asked for opinions from the community. Let’s elaborate on my reaction to watching that video.
Continue reading Software – Craft or Engineering?
Stick around long enough in the consulting business, and you might notice something I will coin the Arxta-Moment in this blog entry. I’m pretty sure, I’m not the first one to notice this, yet, I’m unaware of someone giving it a name. Let’s explore some history, and look for some advice from Jerry.
Continue reading My Arxta-Moment
Over the years, I have seen many companies struggling with paying off technical debt and legacy code. Heck, I produced legacy code within a 45-minute session at a code retreat on my own, so consider me guilty as charged as well. Over the years, I have seen a pretty tiny fraction of companies actually managing their technical debt. So, here are a few stories that I oftentimes share from these companies and how they tackled technical debt and legacy code – with no claim for this to be a complete list of things that might work. Please add any additional advice you want to share in the comments.
Continue reading How to handle technical debt?
A few years back, I ran a public course in Düsseldorf, Germany. While looking through my options for one of the evenings, I noticed a public Coding Dojo run by the Softwarkskammer group there and decided to have some coding fun in the evening. During the dojo, I had an experience with one of the attendees that I keep on sharing every now and then.
I think I wrote up on this a while ago. Since I keep on referring to that experience, I thought maybe a reflection on what I think happened a few years later, might be helpful.
Continue reading “I’m an architect.’
Every once in a while I read something like this:
Yeah, [TDD|BDD|ATDD] is great. But how do you convince [your manager|your employer|your colleagues] to get the time to do it?
In the past week I decided that I need something to point folks to when this questions comes up again. So, here it is.
Continue reading How to sell TDD to <x>?
This morning, when I took a look at twitter, I noticed a direct message from Michael Bolton on my latest blog entry on learning:
In your blog post on learning, you’ve left out community, and bafflingly to me, practice.
Wholeheartedly I thanked him for the idea for today’s blog entry.
Continue reading More learning as a professional
Testers and programmers are much more alike than some people think they are. Many of us work in organizations, some of them large. There are several dynamics in these larger systems that have an impact on our habits, shape our culture, and influence our private lives.
There is something to say about professionalism, and the practices of our craft. Where and when should we learn about such stuff? Let me tell you my personal story. Though I will refer to software testing, pretty much the same also holds for programming, and most programmers I have seen in the organizations out there.
Continue reading Learning as a professional
Today marks the fifth anniversary of the Software Craftsmanship manifesto. Doug Bradbury asked me the following question:
Do you think that the bar of professionalism has been raised in the 5 years since the Software Craftsmanship Manifesto was published? Why or why not?
My short answer is “yes” – and “no”. Being around since the early days back in November 2008 when I joined the Software Craftsmanship mailing list, and having been involved in the different thoughts on the Ethics of Software Craftsmanship, my longer answer hides in this blog entry.
Continue reading Five years of fighting crappy code