Tech Politics, Math, and Career

It looks like Baakt is finally cleared to launch physical Bitcoin futures. This has been long awaited. I was expecting the price of cryptocurrency in general to go up due to this news but it didn’t seem to move much. I guess that’s crypto for you.

I’m wondering if the somewhat low quality production of Project Veritas is turning me off to this whole situation. It’s making the whole thing seem unnecessarily conspiratorial. I also don’t like that Zachary is calling himself Snowden, rather than letting the public draw their own conclusions. The low quality of the videos is making the whole thing seem like a PR stunt or staged or something, which is a shame because we shouldn’t judge a book by it’s cover, particularly when it comes to whisteblowing. Poor production quality aside, the docs don’t lie.

An odd theme in this newsletter that I wasn’t expecting was the politicization of tech. I’m hoping this doesn’t continue to be a theme, but also I’m not convinced it won’t be given society’s current fixation on the topic (thanks Netflix). The fact that this happened is interesting nonetheless (and, no, I don’t know anything about it).

I generally tend to agree with the Taleb tweet linked above. The media often tends to exaggerate market moves to get ad revenue. If you’re swayed by the exaggerations you’re going to be in a bad place as an investor. Confidimus in statistics.

The last recession we had was a statistical outlier, but being that it was the most recent, we’re more prone to remember all recessions as the previous one (availability bias). The next one will not be as bad. Also, the last was exacerbated by the unknown-unknown of the subprime mortgages. This time everyone can see the recession coming, which to me means it’s already been priced in. You should find comfort in the fact that Berkshire Hathaway just purchased more Amazon stock.

I’m currently reading How to Solve It as I always felt I was a bit of an unimaginative mathematician. One thing I came to realize in my reading is that part of the reason I was so unimaginative is I approached mathematics from a computer science perspective. By this I mean my intuition about problems is not bad, but I always had trouble constructing proofs from my intuition, or attaching rigor to my intuitions (in the book Polya calls it “check every step”). This is because in programming, you need an intuition and an implementation. If the implementation works that’s usually the end of the story (although it can be argued that this shouldn’t be the case). It’s very infrequent in software engineering that you’re expected to prove anything. Because of this I never developed skill in proof. Some might say this is not a problem, but speaking from experience, it is. Here is why: skill in formal proof can often drive intuition, even as much as the opposite is true. Understanding where you’re going, and the options related to how to get there (you can take a bus, you can fly, you could walk, etc), can often lead you in directions you wouldn’t expect to go in.

I would often get to a point of understanding a math problem, even convince myself of the mechanics of the problem and find a solution, but when it came time to prove it, nothing. I was bad at convincing not only myself, but any reader. This is because you get little to no practice doing this in a computer science curriculum.

As an aside, I think checking that your logic is sound after developing an intuition is also important as an intermediate step in computer science that is often dropped (as it was for me). The steps to a computer science solution should be intuition -> convince yourself that the intuition is correct -> “check each step of the argument” -> code -> “check each step of the implementation”.

Given this is my first post in this newsletter, I’m going to make a second observation from the book. Polya’s introduction of the “unknown”, “constraint”, and “data” of a problem that can be applied almost universally is a useful tool, particularly when applied to the part of the book outlining different approaches to varying these “parts” to a problem.

The importance of patience in a work context is something I’ve had to learn with experience (it’s almost impossible for someone to give you this feedback as it could easily be misunderstood by the person receiving the feedback, so managers tend to avoid giving it). When given a task, particularly a complex task, I was prone to diving right in to the problem to arrive at a solution quickly. There is something about visual effort in that a junior engineer wants to appease their superiors by delivering something even if it isn’t the exact correct thing. Usually this is fine. As long as you’re close enough to correct, it can be course corrected by more senior employees. But, sometimes you may be way off, causing a long delay between being assigned the task and the ultimate solution due to your impatience. I’ve learned to be more effective by being patient when given a new task. Don’t be afraid to “peruse”. You should know what you plan to do in very good detail before carrying it out. The act of carrying it out should be just that, carrying it out, nothing more. You should not be finding new things out in the act of enacting your plan. If you do not have this clear path forward, you should not be proceeding and should instead either investigate the thing blocking you further, ask questions, or often, wait for something to happen. Experienced management will understand this and will respect you for showing restraint and patience much more than they will laud your ability to dive in. Effective, prudent, deep dive is the goal.