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.
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.
It’s been five years since – sadly – Gerald M. “Jerry” Weinberg passed away. Ever since then, I struggled with some public mourning about him, until recently I had just the right idea. I already covered Jerry’s physical books in the past year. There are some gems left in some of the books he later published on Leanpub. This week, I will dive into Agile Impressions. (You can get most of the content of the physical books I reviewed on Leanpub as well – some might have a slightly different name.)
Imagine a world of work in which we no longer fight about agile or not agile, Scrum or not Scrum, Kanban or not Kanban.
Imagine a team that continuously adds value while providing the needed information for the business to have the company thrive.
Imagine what would be possible in such a world, and what would stop working.
I think at the heart of agile software development once stood this imagination, resulting in all the different things we see in the agile cosmos today.
Unfortunately, this imagination sort of has been replaced by all the discussions we have around this vs. that. To maybe bring back these initial driving thoughts, I send you off to the weekend with your own imagination, hoping that you will bring back that agile essence next week.
A couple of years back, while I was involved in a group that eventually created the ScALeD principles, we were of course discussing the benefits of the different scaling approaches out there. One of the participants – I think it was Andreas Schliep – mentioned to me that the release train concept in the scaling approach that Mike Beedle always referred to as S_Fe was pretty clever. Since I spent some amount of time on trains in the past twelve years, I tend to disagree. Let’s see how I perceive the release train metaphor based on my experiences in the German train infrastructure.
I recall when I read the #noestimates book, there was a concept that felt strange to me – and it still does. Without spoiling too much, at one point the concept of running, tested feature (RTF) is introduced. Let’s explore my thoughts together.
Sometimes while reading along song lyrics, I get some silly inspiration. One of these days, recently I listened to Let there by Rock by AC/DC and got the following idea for an Agile version of the lyrics.
This week I had a conversation with several coaches at a client on something I consider pretty basic Agile knowledge, actually. To collect my thoughts together, I think it would be good practice to write all of them down for the time being. The topic at hand deals with test automation and enabling release-at-will through a zero-bug policy and how to get there. I think it’s going to be a brief blog entry, but fear my thoughts might run away there. So, stay with me.
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.