@tottinge@techhub.social
@tottinge@techhub.social avatar

tottinge

@tottinge@techhub.social

Software, guitar, amateur cogsci reader, landscape photography, IndustrialLogic, ModernAgile, ... whatever.

This profile is from a federated server and may be incomplete. Browse more on the original instance.

tottinge, to random
@tottinge@techhub.social avatar

The work of programming does produce lines of code, and those lines of code are produced by typing into the computer. However, 11/12ths of the work programmers do is not typing but thinking. https://www.industriallogic.com/blog/managing-programmers/

tottinge, to random
@tottinge@techhub.social avatar

"...their presence in the organization has no significant impact on business results."
The SAFe backlash...
https://hrishikeshkarekar.medium.com/is-the-party-over-for-scrum-masters-and-agile-coaches-fad29844804e

tottinge, to random
@tottinge@techhub.social avatar

Most people, if asked about agile today, would tell you that it is about tickets and ticket tracking.

Somehow, it all turned into solo ticket processing, and everyone is obsessing on how to make better tickets, where "better" means solo individuals can process them quickly without "wasting time" on conversations with other people.

Can any ideology ever survive being institutionalized?

tottinge, to random
@tottinge@techhub.social avatar

Forget about dividing the world up into philosophically correct hierarchies. Divide the problem into pragmatically correct ones. --MichaelHill https://wiki.c2.com/?XpMailingListQuotes

tottinge, to random
@tottinge@techhub.social avatar

I find running an XP project is easier than convincing your managers to try it for the first time! --JamesDobson

tottinge, to random
@tottinge@techhub.social avatar

People tend to believe that there is some constant, K, such that: story points * K = actual hours. This is naive. It seems completely reasonable and yet is almost perfectly wrong. https://www.industriallogic.com/blog/story-points-why-is-this-so-hard/

tottinge, to random
@tottinge@techhub.social avatar

There is nothing wrong with doing work in parallel.
There is no reason that I can't build a doghouse in the back yard while you build a new gazebo in the front yard.
That is, unless we have to share the same hammer, tape measure, or saw.
Once we introduce any dependency, that parallel work isn't really parallel.

tottinge, to random
@tottinge@techhub.social avatar

If you have a product idea and a small pile of money, this is the best time of the 21st century (so far) to start that development business.

Do you realize how many top-notch developers are seeking salaried employment right now?

They'll bring their best programming colleagues along, so recruitment shouldn't be hard.

You don't even have to provide office space, because they want to work remotely!

tottinge, to random
@tottinge@techhub.social avatar

The reasons it works are the reasons people have avoided it.

http://www.extremeprogramming.org/

tottinge, to random
@tottinge@techhub.social avatar

Why do people find their tests an obstacle to refactoring?
One common reason is that their tests (and sometimes production functions) are too structure-aware.
https://buff.ly/3iYsWHQ

tottinge, to random
@tottinge@techhub.social avatar

Estimation doesn't really affect software delivery. A four day job is a four-day job, whether the estimate was 2 days or 9 days.

What it might influence is whether the work is done carefully and well, or in a shallow hurry (where the estimate is treated as a deadline, and the scope is fixed).

Shallow hurry delays delivery. Estimates don't cause shallow hurry; artificial deadlines and sprint-packing do.

tottinge, to random
@tottinge@techhub.social avatar

TechBeacon asked nine experts in software testing for their advice on how to speed up the testing process, focusing on how to speed up a continuous integration (CI) pipeline bogged down by tests. Here's what they had to say. https://techbeacon.com/app-dev-testing/fast-fixes-slow-tests-how-unclog-your-ci-pipeline

tottinge, to random
@tottinge@techhub.social avatar

Sometimes people claim to be refactoring, but they’re really just rewriting code or making a bunch of changes without tests; you can tell because the programs don’t work for hours, days, or even weeks. If you see “refactoring” happening without tests or commits, get some training for your team. https://www.industriallogic.com/blog/how-to-understand-refactoring/

tottinge, to random
@tottinge@techhub.social avatar

Liz says "If you’re not having conversations, you’re not doing any kind of BDD."
https://lizkeogh.com/2013/07/01/behavior-driven-development-shallow-and-deep/

tottinge, to random
@tottinge@techhub.social avatar

"Collaboration is when we get together to divide the work among us."

Well, okay, but is that all the collaboration you have? No co-creating? No working together? You're not taking advantage of all that's available to you via collaboration. Maybe that waste is okay, but maybe you can have a richer and more productive experience.

tottinge, to random
@tottinge@techhub.social avatar

"A complete rewrite of an existing application or system should be your last choice. It seems appealing, especially if the existing system is bug–ridden and the code is a mess, but take the time to rethink the rewrite and proceed with caution" https://www.industriallogic.com/blog/rewrites-hazardous/

tottinge, to random
@tottinge@techhub.social avatar

failure demand is a symptom of the system. Unless you change the system, you will not find success in addressing and reducing this waste https://medium.com/10x-curiosity/failure-demand-vs-value-demand-bbcbb5811c80

tottinge, to random
@tottinge@techhub.social avatar

"we somehow imagine that the person we are right now is the person we'll be for the rest of time."
https://www.ted.com/talks/dan_gilbert_the_psychology_of_your_future_self?language=eo

tottinge, to random
@tottinge@techhub.social avatar

I remember in the 80s a boss asked my team how long it would take to do a thing. We talked it over and said 'about three weeks.'

Boss "Okay, let's do it. And then, in the meantime, we can do these other things..."

Team: "No, no, we can't. We are not making a catalog order and waiting for delivery. YOU are waiting, but that doesn't mean WE are waiting."

That moment has stuck with me all this time.

tottinge, to random
@tottinge@techhub.social avatar

There is a certain distance at which people on the other side become abstract people rather than real people, and we start making up stories about what they feel and think and how they got there.

This happens in about 2 org chart levels, or a few degrees of affluence, or a few miles of location, one political system, one supplier contract, or one country border.

It's hard to care deeply about caricatures of abstract "probably" people.

tottinge, to random
@tottinge@techhub.social avatar

A collection of individuals does not make a team, and it fragments purpose. When team member specialization becomes the focus, collective team ownership evaporates. Team members begin to only care about finishing the tasks specific to their lane. https://medium.com/simply-agile/8-signals-of-low-product-team-purpose-no-engagement-surveys-needed-0f9a73686afd

tottinge, to random
@tottinge@techhub.social avatar

Filling the rightmost “done” column is better than emptying the left “todo” column. https://www.industriallogic.com/blog/over-starting-and-under-finishing/

tottinge, to random
@tottinge@techhub.social avatar

TDD Is Fundamentally Wrong is Fundamentally Wrong https://agileotter.blogspot.com/

tottinge, to random
@tottinge@techhub.social avatar

People often ask how they can learn Python quickly. https://agileotter.blogspot.com/2024/01/python-listicle.html

tottinge,
@tottinge@techhub.social avatar

@itsjoshbruce @ramsey Knowing the stack is valuable. If you don't know your framework, nor the language, nor the library, then your ability to make design choices is highly limited. One will be stuck with the best one does know, and that's not much in that case.
That person may still produce an acceptable result (eventually), where someone with knowledge and expertise would hardly have blinked at the challenge.
So which design alternatives are better to be ignorant about? Hard call.
There should be learning topic signals that arise while doing the work, and we don't have to ignore those.

tottinge,
@tottinge@techhub.social avatar

@itsjoshbruce @ramsey #1: no pillory. we don't make fun of people for not knowing. We share.
#2: curiosity over judgment
#3: the employer's $$ isn't for us to learn everything and anything, but for closing the gap between what we can do now, and what we would be better to do instead.
#4: Every skill needs to be in the team, not in every individual. It's nigh impossible to have everyone know everything (and not sustainable as "everything" changes), but if we each bring unique skill/knowledge and pool those instead of siloing them, we can do many things.
#5: Stop grading on a curve - the goal isn't to be better than your teammates, but to be a better team together.

  • All
  • Subscribed
  • Moderated
  • Favorites
  • •
  • JUstTest
  • cubers
  • DreamBathrooms
  • InstantRegret
  • tacticalgear
  • magazineikmin
  • Youngstown
  • thenastyranch
  • mdbf
  • slotface
  • rosin
  • modclub
  • kavyap
  • ethstaker
  • provamag3
  • osvaldo12
  • khanakhh
  • cisconetworking
  • Durango
  • everett
  • ngwrru68w68
  • Leos
  • normalnudes
  • GTA5RPClips
  • tester
  • megavids
  • anitta
  • lostlight
  • All magazines
    •