A surprising amount of my exobrain lives in email. It basically functions as my external memory for a lot of things.
Between that and calendar it's distressing how much of mind lives in Google.
Hypothesis 1.3 is probably the first version of Hypothesis recognisable as its modern incarnation. Previously it had a really weird API based on using values to describe types. So e.g. the value [float]
described a list of floats.
This was cute but turned out to be a terrible idea. Describing things with simple function calls turns out to be far superior to doing cute but highly inflexible things like this.
The problem is that in general it’s really hard to write books for the “expert” because every expert is different. If you’re writing a book for use as a reference manual that’s fine because you can just make it a bunch of self-contained sections, but if you want to write something intended to be read from cover to cover I think the best you can really do is write something targeted at beginners in increasingly specific niches.
I'm finding the move back to physical books from Kindle quite interesting. It seems to work better with habits of deep concentration for me - the Kindle has little too much of the "I'm bored. Let me just change tabs and see what else is here" effect of electronic devices because it's basically a library in a tiny box.
I'm still using the Kindle for fiction, but I seem to have mostly switched to physical for non-fiction (and not just because of gifting)
I currently have a number of problems of the following form:
I have a boolean value random variable Q I want to simulate draws from. I cannot precisely calculate q = P(Q), but I can produce a sequence u_1 <= ... <= u_n <= ... <= q <= ... <= v_n <= ... v_1 with v_n - u_n -> 0.
And this is enough to simulate Q:
Draw a random number r between 0 and 1. Run the sequence until we find some n such that r <= u_n or r >= v_n. If r <= u_n return true, else return false.
This works because it ends up equivalent to returning true if r <= q or true otherwise, which is precisely how to simulate Q.
The interaction with Conway's law is interesting. I mostly had in mind people who were in different job categories (sales, customer support, QA, etc) but maybe that's worth considering too!
Freezing lemon wedges works really rather well. We've started doing it because we have a problem where our citrus usage is very erratic, so we buy lots and then it goes bad.
We've only tried using them in gin and tonics and similar so far, but they work very well for that. Combined lemon and ice cubes!
How is vampire Ada Lovelace not already a thing?
Explicitly controlled laziness offers a lot that you can't do in e.g. Haskell with a more principled implementation of laziness.
Here's are a couple examples:
There are a bunch more I've run into like this. Some of them are things that a sufficiently smart compiler would do for you anyway, but even then it would only do them in circumstances where the algebraic properties of your operations are visible to it, and most of the time that's not going to be the case.
Proposed rules for self-calibration:
The big difference is that a big team is capable of achieving many things that a small team is not. Either through sheer amount of work they are capable of doing, or through the fact that they represent more skills than small team can have.
e.g. code coverage. People have a bit of a hate for it, but I think that's because they perceive it as a score that they're trying to make go up and thus perceive increased code coverage as meaning your tests are better. This is often not the case.
Code coverage instead treated as a constraint (either "You must have 100%" or "You must never decrease code coverage") produces very good results, because at that point it becomes where testing starts rather than the goal, and is much more useful in that space.
Streams by this user that have been favorited by others.
One of the most annoying things about open source is you have absolutely no idea who is using your stuff for what unless it breaks.
A surprising amount of my exobrain lives in email. It basically functions as my external memory for a lot of things.
Between that and calendar it's distressing how much of mind lives in Google.
Hypothesis 1.3 is probably the first version of Hypothesis recognisable as its modern incarnation. Previously it had a really weird API based on using values to describe types. So e.g. the value [float]
described a list of floats.
This was cute but turned out to be a terrible idea. Describing things with simple function calls turns out to be far superior to doing cute but highly inflexible things like this.
The problem is that in general it’s really hard to write books for the “expert” because every expert is different. If you’re writing a book for use as a reference manual that’s fine because you can just make it a bunch of self-contained sections, but if you want to write something intended to be read from cover to cover I think the best you can really do is write something targeted at beginners in increasingly specific niches.
I'm finding the move back to physical books from Kindle quite interesting. It seems to work better with habits of deep concentration for me - the Kindle has little too much of the "I'm bored. Let me just change tabs and see what else is here" effect of electronic devices because it's basically a library in a tiny box.
I'm still using the Kindle for fiction, but I seem to have mostly switched to physical for non-fiction (and not just because of gifting)
I currently have a number of problems of the following form:
I have a boolean value random variable Q I want to simulate draws from. I cannot precisely calculate q = P(Q), but I can produce a sequence u_1 <= ... <= u_n <= ... <= q <= ... <= v_n <= ... v_1 with v_n - u_n -> 0.
And this is enough to simulate Q:
Draw a random number r between 0 and 1. Run the sequence until we find some n such that r <= u_n or r >= v_n. If r <= u_n return true, else return false.
This works because it ends up equivalent to returning true if r <= q or true otherwise, which is precisely how to simulate Q.
Interesting exobrain thing I'm currently doing: A weird experiment for beeminding caffeine.
Historically complex experiments like this don't really work for me and I'm not entirely sure why. This one plays to a fairly established "streak" effect though so I've some degree of hope.
I'm in the process of shutting down the part of my exobrain that forces me to post here regularly. I will probably keep posting here irregularly, but it's currently of unclear benefit for me given my current normal-blogging rate.
The interaction with Conway's law is interesting. I mostly had in mind people who were in different job categories (sales, customer support, QA, etc) but maybe that's worth considering too!
Believers in Conway's Law would say that spending time at other groups' water coolers may not have tangible immediate payoff; but it may well enlarge the feasible design space.
On a somewhat related point:
Excerpts from How Not to Network a Nation: The Uneasy History of the Soviet Internet
Figure 1: The OGAS Project was developed by scientists in 1960s Kiev that also formed a group that pretended to be an independent country called “Cybertonia”: on the left of this passport is a map of its capital city, Cybergrad. On the right is their mascot and supreme leader: a saxophone-playing robot.
Chapter 5 chronicles the slow undoing of the OGAS between 1970 and 1989. Neither formally approved nor fully rejected, the OGAS Project found itself ... stalemated in a morass of bureaucratic barriers, mutinous ministries, and institutional infighting among a state that imagined itself as centralized but under civilian administration proved to be anything but. ... This chapter frames how hidden social networks unraveled computer networks.
(emphasis added)
Tagtime is amusing. Sometimes it forces me to read for two hours to score the 0.4 stochastic hours I need to complete my goal. Sometimes (like right now) I get 1.2 stochastic hours on three different goals (business, email and todoist) for writing a ten minute email.
One of the things that seems to keep coming up in the work context is that cross-team communication is vital. I wonder how broadly applicable that is? Is maybe one of the biggest things you can do in broken systems in general trying to talk to people outside your corner of the system?
I'm very much thinking about my new making work better project/community in this light: Being in a broken work environment is the very definition of systemic problems, and what you do about it is personal responsibility.
I've been going from tracking the amount of time I spend reading to actually noting down what it's spend on and am doing weekly blog posts about it.
It's both very personally satisfying and also seems to produce quite an interesting list I think.
Freezing lemon wedges works really rather well. We've started doing it because we have a problem where our citrus usage is very erratic, so we buy lots and then it goes bad.
We've only tried using them in gin and tonics and similar so far, but they work very well for that. Combined lemon and ice cubes!
I tried remaking the ice cream with much less sugar (1/3 the quantity) and twice as much alcohol. By using more egg and cooking the custard for longer the consistency was pretty good, but I think a middle ground is needed for the sugar as it was much less tasty.
How is vampire Ada Lovelace not already a thing?
I'm kinda tempted to write "Whiteboard Interview with a Vampire" based on this tweet.
When a place brags like "Our team has over 300 years combined experience!" I hope the team is one intern + one extremely competent vampire
— Kathleen Jacques (@kathmachine) May 3, 2016
(it was going to be "Job interview with a vampire" but obviously that's been used before)
Apparently I'm a famous fanfic author. By which I mean, Stargate Physics 101 is probably the most widely read thing I've ever written.
Therefore in order to make useful changes as an individual you need to:
In particular, high effort low impact things done as an individual will make you feel better (right up until you burn out) but they won't do squat.
The origin story of Hypothesis was really that I just wanted to learn Python and needed to come up with a project to hack on in it. For some reason property based testing had been on my mind recently (I'd previously used ScalaCheck a fair bit), I looked around and the available Python options seemed... lackluster (I've since found paycheck which actually predates Hypothesis and is pretty good), so it seemed like an interesting choice of project.
It really shows in early Hypothesis that my progression had gone Scala -> Ruby -> Python.
I have a bottle of Amarula Gold I brought back from Namibia, but I haven't really been able to figure out what to do with it. It's tasty, but a bit overpowering on its own and I haven't come up with a cocktail for it.
But I'm currently living in a house with an ice cream maker, due to reasons, so I thought I'd try my hand at making ice cream with it. This turns out to work really well!
Recipe I used:
Steps:
Note that these were not the correct steps. The correct steps would be to transfer it to a jug, put it into the fridge until it had cooled, and then transfer it. It worked OK though, it just took a while.
The result is really nice, but it's too sweet. I'd definitely make it again, but I'd cut the amount of sugar down to 1 cup. This is both because the Amarula itself is sweet and also because I think that's just too much sugar.
ETA: We've now eaten this for dessert, and I'm basically an ice cream making god.
That being said, I still think it needs a bit less sugar. It could also stand to have more Amarula, but I think it would lose consistency if there were too much more and the consistency of this was basically perfect.
One of the most annoying things about open source is you have absolutely no idea who is using your stuff for what unless it breaks.
Explicitly controlled laziness offers a lot that you can't do in e.g. Haskell with a more principled implementation of laziness.
Here's are a couple examples:
There are a bunch more I've run into like this. Some of them are things that a sufficiently smart compiler would do for you anyway, but even then it would only do them in circumstances where the algebraic properties of your operations are visible to it, and most of the time that's not going to be the case.
Thoughts by this user that have been liked by others.
The big difference is that a big team is capable of achieving many things that a small team is not. Either through sheer amount of work they are capable of doing, or through the fact that they represent more skills than small team can have.