My MTBP (Mean Time Between Pushes) is about 10-12 minutes when I'm not spiking. That's the stride-limit for coding for me, discussed at considerable length in my MMMSS work.

I don't keep a stopwatch by my keyboard or anything, but if a step I'm doing in the code starts to approach 30 minutes, my stomach starts to hurt.

At 45 minutes, I almost always just pull the plug.

"Nice try, kid, come back when you get another dime."

Show thread

The bulk of the work of a software developer is in understanding code. They haven't automated /that/ yet.

Few #dotnet #oss projects have the longevity of #NUnit. After *over 20 years* of stewarding the project, @charliepoole is stepping back.

Read our announcement / appreciation here:

To attempt to quantify Charlie’s contributions to NUnit is a daunting task. He was the lead of NUnit across at least 207 releases in 37 different repositories, authoring 4,898 commits across them. He participated in 2,990 issues, 1,305 PRs, and impacted 6,992,983 lines of code.

I have been writing Go since 2009, which is now 14 years. Today I typed "null" instead of "nil" and had to be corrected by the compiler.

Programming is constant relearning. I have written tens of thousands of lines of perl, but could not create a hash map today without looking it up. Our programming languages and libraries have to be simple because we will forever be looking them up.

@GeePawHill I learned that from experience about 10 years ago. The status of the codebase is a reflection of the techniques, skills and choices made by the developers working on it.

After enough time it becomes the mirror of those things.

That way to change the status of the codebase is to change the techniques, the skills and the choices made - by improving them

#coding #rewrite #architecture #design #skills #refactoring

@samir I see you're trying to stress your mastodon instance again 😉. Wish the tooling didn't drive the conversation so much. People equate PRs with code reviews because that's the only way you can do it in GitHub. But I used to be on teams that would do regular reviews of components or features as a whole and consider long term architectural changes as part of it. They could be great mobbing sessions as well.

"The stereotype of programmers as antisocial
represents a fundamental misunderstanding of what the job is.

Programmers, but the nature of the job, need to dive into someone else's domain." That takes social skills.


“What the leaders need to be doing is offering gifts to the developers. The developers are only going to listen to that if they trust you and appreciate what you want to give them. “

@emilybache on technical leadership

#Leadership #StaffPlus #SoftwareEngineering

Bechdel Test but for women at tech conferences getting to talk about their tech stuff, not being asked to talk about being women in tech at conferences.

🎸 We're *slighlty* overwhelmed to announce
will be speaking at #NewCrafts 2023. Kent's work has had a huge impact on our generation of developers and we look forward to sharing with him!

ℹ️ More information about speakers 👉🏻

Example 2: I stumbled over a very neat Config class in Flask (, which is basically a subtype of Dict with a lot of handy methods that fill the Dict from different sources like files, environment variables or objects.
This motivated and inspired me to do something similar in my own JavaScript tooling.

So after 2 weeks, deliberate code reading of unfamiliar code already had some significant impact on my code writing.


Show thread

@davenicolette @cvennevik It's really that simple. Fast feedback loops (including rock solid CI/CD etc), and healthy collaboration based in psychological safety. And yet...

London vs. Detroit TDD is not about tests, it is about the design of the system under test.

Those design details affect what kinds of tests we write, but more importantly they determine what it's like to work in the system: to read/understand/modify, as well as test.

The reason re-writing software for this year's sexy architecture doesn't work is that the re-writers will use the same techniques to make the new code that made the current code so hard to change.

They've reached the first insight, that their existing code must change. But they haven't reached the second insight, that *all* code in the modern world must change.

It was always the technique. It was never the architecture.

Until they adopt change-enabling technique, they're doomed to fail.

It’s very funny to me that the dominant Twentieth Century conception of AI was a slightly awkward nerd with an inhuman mastery of facts and logic, when what we actually got is smooth-talking bullshit artists who can’t do eighth-grade math.

Show older
Software development is a social activity

A social place intended as a chill hangout place for software testers, developers, or just about anyone involved in delivering software and who is interested in both the technical as well as the social side of things. is supported by the Association for Software Testing.

For more information about this instance,