Who invented the idea that interface names in code needed to be prefixed with "I" and how can I yell at them?

Reminding myself to take my time with Pokemon Sword. Better to enjoy it than to fret about "catching up" to others with wildly different schedules/interests.

Software development makes much more sense once you realize that you're not working on an assembly line but actually designing, managing, and rearranging the assembly line in real time.

Does your system tracking and respect countervailing factors adequately?

How would you know you were making "too much" profit? (i.e. that expenses and dangers are being overlooked or papered over.)

Does your system have a way to detect when the potential to improve in a given area has approached or passed the point of diminishing returns?

(I'm thinking of our endless efforts to make individual workers more productive.)

It's been years since I dabbled in browser extension development and I kinda miss it.

Suddenly feeling strong nostalgia for Metroid Prime today.

Would "technical debt" work better as a metaphor if developers explained to business that too much of it made the company vulnerable to the technical equivalent of a hostile takeover?

For example: "If we don't upgrade from MySQL 5.7 soon, we'll get 'owned' by someone who moves faster in the database innovation space."

Embarrassed that I don't do more to customize my command line prompt.

Makes me feel like a wizard with a store-bought wand instead of a hand-carved one.

Project idea: Coffee machine that 3D prints the mug first.

(This is a terrible idea. Please don't try it.)

The one thing I miss most from my Pebble was its pomodoro app: I could silence my phone entirely and still get notified of each pomodoro's end.

Remember to wrap those third-party services up in compatibility layers, kids! Future test code writers will thank you.

Have you explicitly trained your developers in pair programming skills, particularly the soft skills? How well can you expect them to perform at that if you haven't?

Imagine trying to make an automobile factory match the unit/day productivity rate of a shoe factory by replacing all the auto-part machines with shoe-part machines. It would turn into an absolute mess.

That's what happens when the specific rituals/processes of one team are forced onto another, very different team without a thought as to how well they would fit.

Periodic reminder that agile software development practices don't require (nor even explicitly mention) daily stand-ups.

Similarly: If your team can't opt out of daily stand-ups (in favor of more situationally appropriate approaches to updates) then you're not agile.

Show more
Toot.ThoughtWorks

This instance is running on ThoughtWorks infrastructure to allow its employees to create an account and interact with the rest of the Fediverse.

DISCLAIMER: The views or opinions expressed by the users of this instance are solely their own and do not necessarily represent the views or opinions of ThoughtWorks, Inc.