Sep 29, 2020 11 tweets 2 min read Read on X
One of the standard issues with going to swarming or mob programming is always "How will we spot the bad programmers then? How will we catch the people who are loafing? How will we spot underskilled people if they don't do individual work?"
I went as far as to add it to my slide deck when I am teaching whole-team structures. It is going to come up anyway, and people are usually glad it's already in the topics list.
Of course, the first thing I say is "I don't know. I've not seen it yet. Swarms seem to keep everyone involved and interested pretty much all the time." This is true. It's hard for people to believe.
This suggests that either it doesn't happen, or they're REALLY good at hiding in groups. ;-)
The other thing I ask is how they managed to hire bad programmers who don't want to work.
Were they this bad when they were hired?
How long have you had them on staff without catching them so far?
And, of course, how are you sure that there ARE any bad programmers? Considering your rigorous hiring guidelines and the accelerated schedules you've had, why do you think that you must have loafers, slackers, and losers in your teams? Maybe everyone is pretty good?
I often am told that it's human nature, that anyone given the chance to get paid for doing nothing will happily do so. But this isn't what I've observed: developers WANT to develop. They WANT to solve problems. They WANT to ship code.
Self-motivation is common.
but...
... the other things I've seen is that people can be tired and demotivated if they've been pushed hard to do work that is beneath their ability ("don't design, don't test, don't learn, just hack") for a long time.

They don't loaf though; they rest.
They might back off a bit.
After having a moment to recover, though, I tend to find them eager to get into meaty, complex, interesting work and often are surprisingly driven.
You probably don't have any bad people working for you.
They may be frustrated or exhausted and they may need a break. That's okay, work is hard sometimes.
I wouldn't insist on calling them "bad" or "spent."
Here, again, I suspect we might want to suspend judgment and exercise curiosity.

What if you don't have any bad people?
What would you do instead of rooting them out and firing them?

• • •

Missing some Tweet in this thread? You can try to force a refresh
 

Keep Current with "Agile Otter" Tim Ottinger

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!

PDF

Twitter may remove this content at anytime! Save it as PDF for later use!

Try unrolling a thread yourself!

how to unroll video
  1. Follow @ThreadReaderApp to mention us!

  2. From a Twitter thread mention us with a keyword "unroll"
@threadreaderapp unroll

Practice here first or read more on our help page!

More from @tottinge

Apr 16
What does software development look like from the outside?

I request N things. A few of them come out months later.
Hence: these programmers need to work faster.

1/ Image
however, each of the N things really only took about 4 days to complete on average. Working 2x as fast (a dubious prospect) would carve off only 2 days from delivery time.

2/
What you don't see is that the work was delayed, prioritized, queued up behind dozens or hundreds of other bits of work, rejected and reworked, queued up some more, approved, and then batched up with a bunch of other work while it waited for a few more things to finish.

3/
Read 12 tweets
May 9, 2023
Test first - red.
Oh, I don't like the way that message reads.
Ah, better.
Code - not green?
Quick, most obvious solution.
Still not green.
Oh, why didn't that work?
Was it the test or the new code?
AH! It's the new code. Okay...
Green.
Refactor: I don't like how I structured that test.
Still Green.
The code has some funny names in it. Rename.
Still Green.
Oh, crud, there's a library function for that.
Revise.
Still Green.
Okay.
Read 6 tweets
May 1, 2023
A: Why do you use a ticket tracker?
B: We have thousands of backlog entries.

A: wait... what? Why? How does that help?
B: If we don't store them, we may forget.
A: if you have a list of thousands, you'll remember them all?
B: No, but if we review it we can see that we stored them and might pull them into the sprint.

A: How often do you do that?
B: We don't, there's always too much new work.
A: Okay, so you store them in case you ever run out of new work to do and need to pull something old and forgotten into the sprint.
B: Well, yes, and so we can tell people it's in the backlog.
Read 8 tweets
May 1, 2023
Sometimes you cannot plan. This is either because of the prevailing circumstances (chaos, complexity, extreme complication, dependency) or because you just don't know how.
In those cases, you set an intention and take advantage of opportunities.
At the end of the road, looking back, an excellent opportunist or an exquisite planner will not only have the same results, but their paths are indistinguishable.
Everyone thinks people reach their goals through exquisite planning and flawless execution, but (truth be told) it was largely intention & exploited opportunity.
Read 6 tweets
Jan 21, 2023
“How long does a 2-point story usually take?”
“We peg story points to half-days so 2 points is one day.”
“Yes, how long does a 2-point story usually take?”
“One day.”
“Historically, or ideally?”
“One day.”
“Most of the features you released are over 40 days old.”
“But, um….”
“So 40 days is more than one day, right?”
“Yeah, but the coding part only takes one day.”
“Are you sure. Did you check the actuals on that?”
“No, but they are estimated for one day, so it’s got to be pretty close.”
“But is it?”
“Now that you mention it, no.”
“So how do you know?”
“Well, we always fail our sprints by coming in short. We need the developers to work faster.”
“Work faster so that the estimates become true?”
Read 7 tweets
Jan 20, 2023
If I had to work in an editor that didn't have refactoring support, I probably wouldn't refactor much either.

I'd rather leave a bad name in place than have to manually go to EVERY PLACE in the code where it's referenced and fix it by hand.
It's oddly less bad to move a method from one class to another. I know techniques to get away with that easily.

The recipes in Refactoring (Fowler) work just fine, but they're more steps than just pressing a hotkey.
I'm also spoiled.

I don't want to have to go to a terminal and run the test suite after every line of change. I want the IDE to do that for me.

I never want to have to ask if I'm currently 'red' or 'green' on the tests - that should be constant and automatic.
Read 6 tweets

Did Thread Reader help you today?

Support us! We are indie developers!


This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3/month or $30/year) and get exclusive features!

Become Premium

Don't want to be a Premium member but still want to support us?

Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal

Or Donate anonymously using crypto!

Ethereum

0xfe58350B80634f60Fa6Dc149a72b4DFbc17D341E copy

Bitcoin

3ATGMxNzCUFzxpMCHL5sWSt4DVtS8UqXpi copy

Thank you for your support!

Follow Us!

:(