Hacker News new | ask | show | jobs
by tpoacher 1618 days ago
I have a similar "math" equation; who knows, I might write a blogpost about it one day.

It relates Boyle's law to productivity. It goes something like this:

Boyle's law, or the ideal gas equation is: PV = nRT

Pressure, Volume, and Temperature. n is the number of 'moles' of the substance in question R is a constant which is specific to the gas in question (whose pressure, volume and temperature one might fluctuate)

I find that this equation also describes nicely 'academic' work (or software work, or this kind of work)

and for the sake of using the same letters, even though other letters might have been better, hahah

we'll define

P = Professionalism (i.e. Quality of output, or personal standards of quality)

V = Volume (or amount) of work that can / is expected to be done

n = Number of projects one is undertaking at the same time

R = A 'constant' unique to the individual

T = time available / allocated for the work

First, let's define R exactly. It is a constant, unique to the individual (under constant circumstances), describing the quality that can be expected, for a single unit of work (on a single project), for a unit of time allocated.

While R is a 'constant', this does not mean that it cannot change - indeed it can change due to circumstances ... but that means that your R has changed. E.g. burnout, psychology etc. Or motivation on the other end.

But for the purposes of studying your work output as a closed system, it is a constant.

And this is a very important part of this realisation.

So

the main parts of the system, are P, V, and T.

In boyle's law, this says that, given constant pressure, an accompanying increase in temperature must be accompanied by an increase in volume. Or given constant volume, increase in temperature must be accompanied by an increase in pressure, etc.

When it comes to work:

An increase in volume of work, must necessarily lead to: - either an increase in time allocated for the work - or a reduction in expected quality.

This, btw, was the insight that kickstarted this analogy, because there's a famous dilbert comic effectively saying the same thing (let me try and find it quickly...)

https://assets.amuniversal.com/fa5edf906d5101301d7a001dd8b71...

So. Let's examine keeping the other variables constant.

Expected professionalism / quality of output needs to improve. This necessarily means that - Volume of work needs to be reduced, given for the same deadline. - Time allocated needs to go up for the same amount of work

Let's examine time. The deadline has been pushed forward: - Volume necessarily must go down, or - Quality must go down.

The other directions also lead to nice insights.

You just got an extension. If you choose to use up this allocated time, you can choose to: - Try to improve quality of already existing material (i.e. procrastination, lol) - Try to improve amount of work at the same quality

Your volume has gone down (an unexpected project is now off the table). Do you: - Choose to finish things up on time - Improve the quality, but stick to the same deadline (i.e. Parkinson's Law / Procrastination) :p

Your boss has told you that you can afford to not be so nitpicky. Do you - Do more work at a lower quality. - Finish things up faster.

etc etc

Now. Let's attack n

When talking about Boyle's law, there are two versions (kinda). PV = cT vs PV = nRT the difference being, in the latter case, we assume we're dealing with n moles of the same gas, whereas the former is general enough to assume generic volume, which may be of a mixture of gases

Therefore

If one is talking about n 'projects', which can be interpreted to all carry more or less the same volume of required work

e.g. "how many experiments do I need to conduct for my PhD"

then PV=nRT is appropriate.

otherwise you should be a bit more generic and treat 'volume' as a more generic "amount of work" situation

however, the n offers another insight into this work model.

meaning

"One way to improve quality / reduce workload / save time, is to stop bloody accepting every project you're offered"

(guilty as charged )

which could totally also mean personal projects, such as learning monads for absolutely fuck all reason

or

conversely

the case of increasing n - "by all means take up more projects, as long as you feel you can handle the increase in volume, or the increase in time you will have to spend, or the reduction in quality on all your other projects"

or something like that

now, here's where it all comes together.

I would like to believe, that in any reasonable employment, one is hired for their (perceived) R

at least as perceived at the time of interview :p

which, can be considered a "constant" in closed system terms.

however

the system is not really 'closed'.

E.g. burnout will invariably reduce your R. This means that for the same expectation of quality, and allocated time, you will be able to produce less volume of work (or alternatively, for the same deliverables, you'll only be able to do less work)

UNFORTUNATELY, for someone like me, this is an emotionally negative path

which risks reducing your R even further in a vicious cycle of psychological negativity

therefore, what we tend to consider first, is increasing T as a counterbalance

i.e. "I'll work more hours than I should"

problem is, this is not sustainable, and often serves to reduce your R even further, compounding the problem

Furthermore, if you have made the mistake of creating false expectations in your bosses about a high R

but this high R comes (possibly unbeknownst to them) from an artificially inflated T, rather than from a genuinely organically high R constant

then this will lead to more V, or possibly a higher expectation of P ... even when time T is suddenly unavoidably low

etc etc ... I'm sure you can think of similar scenarios / cautionary tales

In any case, what PV=nRT has done for me is the following:

If my bosses ask me to increase V, with no increase in T, I am now unashamedly willing to reduce my P

rather than steal T from personal time and suffer consequences that at the end of the day make things worse by 'opening' the system and affecting my R

and in fact, people seem to expect this

I have battled with my psychological aversion of low P for a while, but this thought helps me do it without suffering the negative thoughts so much.

"It will not reflect badly on me if my quality drops. I should simply point out it's a natural cause of the reduction of the other variables in a closed system"

And my employer should NOT expect me to change my R

In other words, they should not expect me to:

"Do better work (without giving me the right ammunition to do so)" "Increase my workload (without giving me the time and resources required for it" "Finish this quickly" (without helping me mitigate my workload, or expecting the same effort and quality)

And also, it has made me a bit more pragmatic about saying no to projects, even though they could benefit me (genuinely or not).

Or at least, it has taken away much of the guilt for not doing those projects even though they're on my list etc.

That is all.

1 comments

btw! I forgot the best part!

How does technical debt fit into the whole PV=nRT framework.

The story goes like this. "We have n tasks. Unit tests are an extra task. We don't have time for n+1 tasks"

In reality, technical debt is not an additive, it's a modifier. It applies a modifier a to the current task, and a modifier b to all related tasks after it.

So it's more like having E[n] = 1 * a + (n-1) * b, where a > 1, and 0 < b < 1

E.g. if writing a unit test makes your task double, but your remaining tasks now take half the time, then you didn't really make n into n+1 with unit tests, you made n become 2 + (n-2)/2

So, for the above (admittedly unrealistic) modifiers, if you have 8 projects to do, and you're thinking should I do unit tests

In your mind you may be thinking, fukit, I can't afford to do 16 tasks instead of 8 (i.e. 8 tasks plus 8 unit tests)

But because geometric processes are so hard to reason with, it's hard to see the benefit, but the benefit is massive!

octave:16> f = @(n) 2 * n;

octave:17> g = @(n) 4 - 2 .^ (2-n);

octave:18> [ f(1:8); g(1:8) ]

ans = 2.0000 4.0000 6.0000 8.0000 10.0000 12.0000 14.0000 16.0000

    2.0000    3.0000    3.5000    3.7500    3.8750    3.9375    3.9688    3.9844
Not only is it not 16, but actually it will save you so much time, that you'll spend even less than the original 8 time units!

(assuming related tasks and compounding effect paid from technical debt)