HN user

elseweather

54 karma
Posts0
Comments27
View on HN
No posts found.

Yes, it seems intuitively obvious, which is why mathematicians spent a long time trying to prove that the conjecture was true. It turns out The conjecture is false in a non-obvious way. The result described in the blog post is a specific counterexample: the conjecture fails, just barely, for a specific graph with several thousand nodes and edges. It's not the kind of counterexample you would intuit in your head or even on a whiteboard.

1. Trial by fire; learning on the job

2. CS stuff is widely available for self-study if you've got good discipline. "The Algorithm Design Manual" by Skiena is my favorite textbook on algorithm fundamentals. CLRS is a bigger book with more mathy crunch, if you're into that.

There's a lot more to computer science and software engineering than just algorithms, but it's what you'll get grilled on the most in junior level interviews. By the same token, the skills you need as you get more senior in this industry aren't really taught in school.

Ah, man, I get being anxious in interviews but it never occurred to me that newbies would be stressed out by their (lack of) Leetcode score. It's totally unnecessary of course - the people who've racked 1500 problems are probably as unemployed as you are :p

I mean, you can also just let the data go. "nothing, chaos" is pretty simple. I don't believe being able to search my chatlogs from 2005 would make my life simpler, or better.

Some people are natural archivists and love that second-brain stuff though, and this is a pretty sweet example :). One area I strongly relate to Karlicoss is how bad it is getting data out of my bank; as a regular non-institutional customer I don't get API access, so I have to download a PDF manually every month and run it through some script to parse out the line items.

This is a fascinating article that winds through a whole raft of problems that feel super relevant in the software world today: end-to-end encryption, distributed messaging, what we would today call "containerization" (in 1984!), many other things besides. I often dislike this kind of abstract general nonsense but I think there's a really interesting through-line here I hadn't noticed before.

One thing that struck home with me was this line:

Some of these source files were corrupted by byte exchanges, and their owners were forced to the ultimate end-to-end error check: manual comparison with and correction from old listings.

At work I sometimes joke that us SWEs are the last line of retry-and-checksum defense, but it's not a joke! This paper argues correctly that engineering extreme reliability into lower level common components is uneconomical, but on the other hand pushing reliability all the way up the stack doesn't work either. If you surface the jank all the way up to your customers you just have a buggy, crappy product and your business will fail. One level down, if you rely on talented engineers to fight operational fires all the time you have to pay a lot of expensive engineers to not make progress delivering features.