I’m a rank beginner with F#, and I was looking for a fun way to get started. The usual tutorials seemed a little stale. Then it occurred to me that logic gates could be modeled as functions pretty easily. Why not practice F# by writing some functions that mimic the behavior of logic gates?
Continue reading Simulating an ALU in F#
My friends know me to be skeptical of “studies” about software development techniques. The main reason for my skepticism is that such studies are rarely undertaken by people who have any understanding of what they are studying. They combine data points from different sets of observations as a way to try and accumulate sufficient information to make charts and trend lines, but often the data points aren’t consistent enough for the aggregated data to be meaningful. I wonder whether many studies of programming techniques are based on enough observations to be meaningful, and whether the researchers’ analysis of the results is based on any direct knowledge of the subject at hand.
Sometimes I use the phrase, “novice Scrum team,” to describe a team that’s new to Scrum, still settling into the routine of sprints, and still getting a handle on the underlying values of Scrum. Often, these teams are in the process of adopting unfamiliar technical practices like test-driven development and unfamiliar processes like continuous integration, and learning to collaborate across roles that had been sequestered in functional silos before the cross-functional Scrum team was established. They’re learning a lot of new things at the same time.
Quite a few people appear puzzled or bemused by the phrase. It occurs to me they may think of Scrum as a fixed set of rules to follow, rather than as a starting point for ongoing improvement. You either follow the rules or you don’t. There’s no concept of “novice Scrum team” because there’s no concept of ongoing improvement: When you follow the rules of Scrum, you’re doing Scrum. You either do Scrum or you don’t. That’s all there is.
As long as we write tests, what’s the big deal about writing them “first” rather than “last?” Let’s explore that question.
The video looks a lot better on YouTube than it does here. Try https://youtu.be/Bf89rd0o5-0.
https://youtu.be/W1-IjCbzKAs
When we’re conscientious about writing examples before production code, and we drive all our production code from executable examples, we can enjoy several benefits:
Ward Cunningham, a fish of some note in our small pond, wanted to deliver software incrementally to a client in the financial sector. The client didn’t see the value in doing that as opposed to delivering in a “big bang” fashion. To help relate the idea to the client’s frame of reference, Ward came up with the “technical debt” metaphor. It’s explained pretty well in an Agile Alliance article.
Continue reading Technical Debt: The Man, the Metaphor, the Message
One of the key ways to keep work moving forward is to avoid working on too many things at the same time. Ideally, a person should finish what they’re working on before starting anything else. Similarly, a team should complete the work item or ticket or story (or whatever they call it) they’re working on before picking up the next one. At a larger scale, a software delivery organization should limit the number of projects in flight concurrently, and strive to “stop starting and start finishing,” as David Anderson put it. That’s what portfolio management is for (among other things).
The relative effectiveness of collaborative work over individual work for many (not all) activities has become well-enough established by now that hardly anyone questions it. No one establishes an “agile” work space in such a way as to maximize disconnected, individual work and to minimize direct communication. That would be absurd.
And yet, people are determined to defend their comfort zones. A popular way to avoid working collaboratively is to say, “I’m an introvert.” Often, this is stated flatly, with a tone of finality, as if the word “introvert” completely explains why it is impossible for the individual to collaborate with others. Obviously, an introvert has to work alone all the time. They are hard-wired that way. It’s innate. It’s an immutable trait. There are no variations or nuances. End of argument. Now I’m going to turn my back on you and put my headphones back on. Go away.
There are a couple of problems with the way people typically throw the word “introvert” around.
For context: This post is about recruiting and job-seeking in the area of software development, testing, infrastructure engineering, and related disciplines. It isn’t general.
There’s a lot of discussion just now online and offline about endemic problems in the software industry around discrimination, pay discrepancies, hiring practices, humane workplaces, and questionable interviewing methods. Most of that discussion is highly emotionally charged, to such a degree that it’s “unsafe” to disagree with just about any comment online, or even to agree with a comment using words the “owners” (is “dominators” a word?) of the discussion haven’t approved.
That situation does not seem healthy or constructive to me. So, I thought I would take a few minutes to try and cut through some of the emotion to understand what’s wrong with recruiting and hiring in our field, and whether there are some concrete steps people can take, on both sides of the interviewing table, to improve things.
Continue reading Recruiting and interviewing in confusing times
Why are your socks on the floor again?
I don’t know.
Don’t say “I don’t know!”
How many times have I told you to turn off the light when you leave a room?
I don’t know.
Don’t say “I don’t know!”
As someone who travels frequently for work, I found the advice in this article pretty annoying: 10 Tools for Getting Work Done on Long Plane Rides.
Summary: What the hell are you doing trying to work on a fricking airplane?
Life and work can be somewhat unpredictable, so there may be occasions when you have to do some work on your way to a client site, presentation, or business meeting. But the general rule for normal people is that you’re not “on the clock” 24×7.
Learn to manage your time. Get prepared for your event before you leave. On the flight, try to relax. When you arrive, you need to be rested and have a clear head. You won’t do your best work if your tired and stressed.