Stories about Software


The Beggar CEO and Sucker Culture

The other day, I was doing something on LinkedIn, when I noticed a post title that somehow made its way into my feed: “Why Don’t My Employees Work Harder?”  I clicked through out of curiosity and found that this was a corporate Dear Abby sort of thing.  A CEO identifying herself as “Victoria” submitted the following as a question to Liz Ryan, who serves as Abby.

Dear Liz,

I know that leadership is all about trust and I do trust my employees, but I wish they would show a little more effort. They come in on time and they get their work done and that’s it.

I leave my office around 6:15 p.m. most nights and I don’t think that’s an especially long workday. But the parking lot is nearly empty every night when I leave. Why am I always one of the last half-dozen people out the door?

When I started this company six years ago there was a lot more team spirit. Now I have to come up with incentives to get people to put in extra effort.

I haven’t threatened anyone or threatened to cut the bottom ten percent of the team or any of that but I did tell my managers that I want them to incorporate not only output but also effort into their performance review rankings.

I want to reward the people who work the hardest here and make it clear that anyone who wants a ‘dial-it-in’ type job is not a good fit. I don’t think a growing, $10M company should be a place where people work from nine to five and then go home. What do you advise?




I tweeted my gut reaction to this off the cuff, and it got a lot of traction for a random tweet on a holiday morning.

I then read through Liz’s response, which was patient, well-reasoned, and it brought up something called “weenie management,” so that alone is sort of oddly awesome. It also pretty resoundingly dressed Victoria down, which, I think was warranted.  And yet, in spite of expressing my disgust on twitter and seeing a somewhat satisfactory response to Victoria, I still felt sort of bleak and depressed about the whole thing.  I stewed on it further and realized what my response would have been, had I been Liz. Read More


Happy Thanksgiving, 2015!

For me and for readers in the US, today is Thanksgiving.  So instead of working and writing a DaedTech post, I’m going to be watching football, eating, and relaxing with family.  I suppose I could publish one of my drafts that was written for another blog, but a significant chunk of my audience is going to be spending the weekend with family and not reading technical blogs.  So, I’ll just hold off on a post until next Monday.

For those not in the US, have a good weekend.  For those in the US, have a happy Thanksgiving, and a good long weekend.  Try not to eat too much or kill anyone while shopping on Friday morning.  (Better yet, stay home on Friday morning).  For everyone’s enjoyment, here is a picture of a turkey that my wife drew.



Agile for Introverts: Re-Imagined Programmer Collaboration

As I mentioned in a recent post, I’ve been listening to Susan Cain’s, “Quiet: The Power of Introverts in a World that Can’t Stop Talking.” I also mentioned that I’d be saying more on the topic, and here comes some more.  Today it’s going to be the idea of Agile for introverts.

In recent weeks, I’ve spent some time running a bootcamp of sorts that covered, among other things, XP and Scrum principles. Personally, I find that I light up when talking about clean coding practices and that I’m a bit more tepid when it comes to explaining process particulars. Reflecting one evening, it struck me that a lot of the practices involved in Scrum ceremonies and some of the XP practices aim to draw people “out of their shells.” In other words, a lot of agile is the Extrovert Ideal brought to programming.

This made me wonder what some Scrum ceremonies and/or XP practices might look like if they were introvert-friendly. That is, how could one accomplish the goals of these activities in ways that didn’t assume “let’s all get together and collaborate always!” was the right way to think.

What is introvert-friendly?

Before I can offer thoughts on how to make something introvert-friendly, I want to define what I mean by that. I feel it’s important to do so because the definition most people would assign by default is “things that don’t require interaction with others,” and that’s not right.

I’m going to go out in a limb here a bit and assume that I’m a good representative of the introvert population as described by Cain. I don’t feel that this is too much of a reach, since I got a 20 out of 20 on the informal “are you an introvert” quiz. So, I’ll explain my own psyche and trust that you find it reasonably representative of how you feel if you are also an introvert.

I don’t seek to minimize social interaction, per se, but I do shy away from unpredictable situations with a large amount of stimulus.  I also have an intense preference for a sort of social order that is predicated upon minimized conflict and a world in which information and opinions aren’t generally shared unless solicited.  You can actually read back through my blog posts and see a lot of this described before I’d ever heard of Susan Cain’s book.

There are probably more, but these certainly capture some of the themes at play here.  And from this basis, I propose the following concepts as introvert-friendly.

  • Differences of opinion are resolved by folks having time to process different viewpoints and build a case rather than by extemporaneous argument/debate.
  • Meetings and gatherings are limited in size.
  • In professional situations, it’s better to remain silent unless you have something high value to say, especially in larger groups.
  • Interpersonal interaction is primarily for camaraderie and logistical resolution (e.g. knowledge transfer or merging code), rather than important work.
  • The most productive work happens in a state of flow when you can tune the world out and concentrate.
  • It’s worth letting a group make a sub-optimal choice to preserve social harmony.
  • It’s good to be able to opt out of groups that frequently make sub-optimal choices.

Notice that none of this is, “I want to be home, alone, always, with no interaction.”  That’s not introversion — that’s being a recluse.  Rather, this is “I prefer orderly interactions, a cap on external stimulus, and time and space to form my ideas.”

Read More


Your Coworker’s Bad Code: Having The Hard Conversation

Editorial Note: This post was originally written for the SmartBear blog.  You can check out the original here, on their site.  If you’ve never had the chance, take a look at their blog in general.  A lot of good authors over there.

Last time, I talked about how to prepare for a tough conversation with a coworker about having bad code.  This included understanding what not to say and creating a game plan of specific shortcomings to address and concrete outcomes you want from the conversation.  This time, I’m going to talk about how to actually engage with your teammate, who I’m calling “Bob.”


Having built your case ahead of time, it’s time to go have a chat with Bob. You’re calm, you’re rational, you have a legitimate argument, and you’re all set for a constructive dialog…but the lead in for the conversation threatens to be awkward. What I’d suggest doing to put the conversation in more natural terms is to ask for his help. “Hey Bob, I’m chasing a defect through the code and it led me to this method of yours. It’s a little hard to follow at first glance, so I was hoping maybe we could trace through it together?” Now you’re not coming over to preach to Bob about the evils of his code but rather to ask him to help you solve a problem.

Once you’re looking together at a screen and starting to dig in, one of the most effective ways I’ve found to surface code problems is through the Socratic Method. Instead of telling Bob that the method is too long, ask a series of questions. “Wow, good thing you’re here—this is a pretty long method with a lot going on. How long do you think it would take the average team member to understand it?” “Huh, wow, three or four hours seems like a pretty long time to spend trying to understand a method, don’t you think?” “What if it were smaller?”


Making proclamations of fact or strongly stating opinions tends to put people in a defensive posture. Asking questions, even leading ones, doesn’t get people’s hackles up as much. They tend to join you in problem-solving mode rather than argue against you in debate mode. Still, asking questions this way may not lead to the desired outcome, which is why you’ve done your homework. Switch gears from the questions to statements of your experience and how you feel. These are inarguable. Read More


Chess TDD 54: Castling Acceptance Tests

The last few episodes featured heads down implementation around this new CastlingStatusChecker class.  It was nice to spend some time writing relatively simple unit tests to restore some sanity and get away from an overly-coupled Board class.  But, it was time to come up for some air and get back to proving some business/domain value.  Toward that end, I found myself writing castling acceptance tests.  But, before I could start with that, I cleaned up the constants that had grown a little awkward after my re-imagined implementations of the status checker.  All sorted out now, though.

What I accomplish in this clip:

  • Refactored constants in the castling status checker and the test class I was using to drive its implementation.
  • Starting on the castling acceptance tests, which worked for black and white pieces.

Here are some lessons to take away:

  • There’s no exact science to climbing up and down the granularity levels.  The heuristic I offer in this episode is, essentially, “prefer unit tests because there’s less setup and faster feedback, but come up for air periodically and use acceptance tests to verify that you’re adding business value.”
  • Make your code read plainly, like prose, in production.  When it comes to writing unit tests, go even an extra step, and act as if you were writing a Word document about your code (maybe not literally, but you get the idea).  The unit tests are where you explain how the system works.
  • It’s perfectly reasonable to write a series of acceptance tests that you expect to go green.  These acceptance tests are how you document and prove functionality to non-technical stakeholders if they have an appetite for reading and collaborating on them.  So, by all means, take the time to demo the app’s behavior by writing as many of these as you need to showcase what it’s doing.