i guess i have learned that spending 80% of the time getting your architecture, data models and structures good and 20% on the code is good, whereas spending 20% of the time on architecture, data structures and 80% on the code sucks ass and makes you r...

Prema Marsik

@jonny i should carve this to stone … and bang my collaborators on their heads with it

jonny (good kind)

@prema more blunt objects should teach you things as they beat you up

Plaid

A novice programmer was once assigned to code a simple financial package.

The novice worked furiously for many days, but when his Master reviewed his program, he discovered it contained a screen editor, a set of generalized graphics routines, and an artificial intelligence interface, but not the slightest hint of anything financial.

Plaid

@jonny

When the Master asked about this, the novice became indignant. "Don't be so impatient," he said, "I'll put in the financial stuff eventually."

The Tao Of Programming, koan 5.3

Plaid

@jonny

Thus spake the Master Programmer:

"When a program is being tested, it is too late to make design changes."

The Tao Of Programming, Chapter 3

jonny (good kind)

@plaidtron3000 oh man i have been trying to introduce my labmates who have never written a test in their life to a sort of modified TDD flow, and some questions like "what do i write tests for" and "when do i write the tests" seem like they have clear answers but actually have no answer

Jon

@jonny personally, i tend to spend 80% of my time getting stuff right up front, 80% of my time on the code, and then 80% reworking it. agreed though that it's better than the alternative: 20% getting stuff wrong up front, 200% on the code, and 2000% reworking it.

Jeremy Kahn

@jdp23 @jonny

O(n) cost overruns always preferable to O(polynomial)

jonny (good kind)

@trochee
@jdp23
I was thinking that it was time that was polynomial, that time is not gauge invariant and the same amount of time measured in the future is 2000% as much as measured now. So when I say something will take a week, when I finish it in 6 months I will not have been telling a lie.

Jeremy Kahn

@jonny @jdp23

"It's not my estimation skills, it's the whole timeline that's drunk!"

Jon

i once worked with a developer who would have the same estimate for every task. fix a small bug? "hmm, probably a week or two". Change the API of the core module and ripple the changes throughout the product? "hmm, probably a week or two".

Usually after a while i got pretty good at correcting for dev's tendencies to under- or over-estimate ... but this was challenging.

@trochee @jonny

Jeremy Kahn

@jdp23 @jonny

Points for consistency, though

Jeremy Kahn

@jdp23 @jonny

I mean, if I knew that estimation effort was uncorrelated with actual results, I would put in as little effort as possible and just start working

This guy figured out how to make *you* do the estimate

jonny (good kind)

@trochee
@jdp23
That's genius. Like the "best way to get the right information is to say the wrong information confidently" but for labor. Be sort of frustratingly opaque about something until someone else does it for you out of spite. The most obnoxious delegation method

Plaid

@jonny Design by contract, design your tests during your architecture design phase. Write in Spark Ada and question all your life choices forever.

jonny (good kind)

@plaidtron3000
One of my colleagues just wrote their first test ever in python so I think I am gonna hold off on introducing spark Ada into the workflow lmao