Ask HN: What bits of fundamental knowledge are productivity multipliers?

Regexes are a bit of a double-edged sword. I rarely use them in code - I often find it more productive (and maintainable) to simply type out the verbose code for doing the string transformations. This depends on how good you are at writing/interpreting regexes and on what text manipulation tools your programming language/stdlib gives you. I imagine a compiled regex can often outperform naively-written code, though.

On the other hand, regexes saved my skin a couple of times when I needed to search/extract/modify/format a large number of text files (or one extremely big one). I suck at command line, so I usually open the file/folder in vscode and use their search/replace function. It's super useful for these "one shot" text operations.

Solving problems iteratively in the same way progressive jpegs render: Start with essential parts, quickly assemble them to a usable draft and iterate on the entire thing by improving quality where it needs to be improved.

This is applies to programming as well as to writing, drawing, making music etc.

Applying this to writing emails can definitely improve your business communication 10-fold:

* write down the important parts you want to convey, even in incomplete sentences

* improve the ideas into sentences

* rearrange the paragraphs/parts/sentences into proper order (written language rarely comes out in the correct order).

* cut unnecessary talk

* iterate on the above 3-8 times, depending on the importance of the email.

Knowing in which problems pace you are and which solution strategy works in that space. Basically: "cynefin".

Looks like a paywall.

Yes, a calculus formula might have been used somewhere in that process, and was used by the finance person and dev. That doesn't mean I, or any other person, needed to know it.

As a dev at a financial institution, I've never needed to implement calculus formulas. Most calculations and formulas I've dealt with are algebra and stats. These usually are just a matter of using standard libraries too. So most devs aren't implementing formulas themselves, but just utilizing standard libraries.

Uh, if you really want. This is probably boring as fuck until I get emotional around the third paragraph ;)

---

I'm putting this down here because, even though it seems obvious, it's not; if you spend 10 or 20 hours really thinking seriously about what happens if people write early reports or late reports - the initial conclusion was just count how many they wrote into how many they sent, and tell if they need to send more, but that's not the way life works. Or people work. And it's going to create impossible bottlenecks if the last report is the most important one. The insight I had and what's going to drive this thing is: How many reports were due since the last one you sent. Again, that seems simple but it's not. Technically it doesn't mean they just skip them; it means if one was due Monday and one Wednesday, and you send one on Tuesday, that covers Monday's report; but if you sent it on Wednesday it covers both, the idea being to discard the missed ones without explicitly saying so, and drive them to do what's important today, and more important if it's the final day.

It also covers the situation where they filed Monday's report early, but only if they've filed all the needed reports prior to that; otherwise they'll need another one for Monday.

That's why this is so hard. It's not the code. It's the number of possible scenarios.

So the rule is, we start counting again from when the last report was written, in terms of priority. And when you're looking at 50 reports a day per franchise, you'd better know what the priorities are.

For myself personally, I think this is writing software that will lead to absolute catastrophe. I've always tried to align the way my software works with how I think people will be able to use it, to push them to do the right thing. Anyone can write the software I write, it's the thinking about this process that is extremely difficult if you're dealing with, like, hundreds of [redacted] and thousands of customers spread out over time, and have to figure out how to make reasonable suggestions. This is such a thing.

What I'm saying is that this is marching into creating a thing that will cause total chaos and I don't think this is the right way. We have the chance now to re-imagine the frequency and rearrange the expectations of the customers and the expectations placed on the staff, and I think we need to do that. The algorithm you asked for is done, but it will not be good for people. And it is extremely hard to understand, even for me, if you asked me why one should take priority over another, when dozens are urgent on the same day. I wrote an "urgency" algorithm on top of it to try to deduce that. The best I can say about it is that it will cause less misses and damage than any other way of looking at the list, and it took me a long time to get to. But I think you're asking for something that is going to be so inefficient, and create such high customer expectations, it's going to be negative on both sides.

The scene keeps going through my head from "Casino", where De Niro tells the chef in the hotel to make sure the same number of blueberries are in every muffin, and the chef just drops his hands and goes, "do you have any idea how long that's going to take?" This is a blueberry muffin situation. We need to think of a better way.