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...

[jdp23@neuromatch.social]

@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.

[trochee@dair-community.social]

@jdp23 @jonny

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

[jonny@neuromatch.social]

@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.

[trochee@dair-community.social]

@jonny @jdp23

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

[jdp23@neuromatch.social]

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

[trochee@dair-community.social]

@jdp23 @jonny

Points for consistency, though

[trochee@dair-community.social]

@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@neuromatch.social]

@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

[plaidtron3000@jorts.horse]

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

[jonny@neuromatch.social]

@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