I have a somewhat different financial game I use to motivate myself to work seriously on my hobbies. When I have a piece of gear I want to buy, like let's say new hiking boots. I make my self complete a challenge where say every time I run hills I put 5 dollars in savings towards the boots. That way I can't just buy the gear without putting in serious work at the activity first. Same thing for computing stuff, or photography, art or music. Want a new guitar? Need to play the one I have more to earn it first.
I really hate this kind of language, but it is really useful in an American corporate context, as I have recently realized while doing an executive MBA program. A lot of Americans tie up a lot of their emotions in work success. A lot of other Americans don't care about their co-workers, and don't want to put in the effort to figure out how to actually respect people (calling cheap places to work "discount" is a good example of this). Sometimes, the same person is in both groups.
The way to usefully make both groups work with others is to use language that is devoid of meaning and, in particular, lacking value judgments. That way, you can say "Steve, can you explain the learnings from your recent project?" and mean either, "Steve, you fucked up, what are you not going to do again?" or "Steve, your project went great, what tips can you share?" That way, Steve can feel recognized for his achievements even when Steve did something that was really stupid. Steve's colleagues have an emotional barrier, too: they won't feel bad for Steve if you are calling out his failures, and they won't feel bad for themselves if you are saying that Steve did something exceptional.
It's really fucked up how we have created this sanitized dictionary, but it's too effective in a corporate context not to use it.
The pattern above has a benefit that the dispatch still comes from Phoenix, so you are not relying on IDs or query selectors to attach functionality. You can see how we use it in Livebook here: https://github.com/livebook-dev/livebook/blob/main/assets/js.... However, if the callbacks get too complex, then you may indeed want to test them via headless browsers.
I’ve noticed in myself and anecdotally in others that a lot of stubbornness in conversation simply comes from the desire for validation. Having someone acknowledge what I’m saying is generally enough to get a conversation moving forward, where ignoring or not responding to my input can cause me to fixate until I recognize what I’m doing and break myself out of it.
But if I feel mild validation, even if it is concluded with a “no”, I’m far more likely to consider myself having reacted “humbly” and more openly during the introspection I am forced to have at 3:45am the following morning.
Maybe this was all a tangential comment, but that’s the thought that was sparked by this post.
In the old days 100% of computers were doing civilization critical work, Air traffic control, Social Security checks, nuclear reactor monitoring. Computers are expensive and automation provides the most gain in those applications. There just aren't that many civilization critical systems.
In the modern era we continue to have the same small number of civilization critical systems, we still have exactly one air traffic control system. However we have billions of, well, filler. Ringtones and social media and spam. Therefore rounded down 0% of modern computers are doing civilization critical work and safe secure systems superficially appear to be a thing of the past even if the number of systems and employees remain constant.
In 1960 the average ALU was calculating your paycheck and it was rather important to get that done on time and correctly. In 2010 the average ALU is a countdown timer in your microwave oven, its your digital thermostat, its my cars transmission processor, maybe its video game system or other human interface device (desktop, laptop, phone) but probably numerically unlikely. Things are sloppier now because they're sloppy-tolerant applications.
There's a book, Everything In Its Place, Dan Charnas, which does a good analysis of the analogies of cooking and productivity in the office.
Basically it recommends doing the "process" tasks first, the ones that the rest rely on. In this case, it would be grilling burgers. In the office, it might be something like assigning tasks or approving PRs.
Charnas recommends that planning starts by "first things first" as opposed to say, the Tim Ferriss, Brian Tracy, or Eisenhower methodology of most important things first. And often the first thing is to figure out which things come first.
And yeah, the book also recommends finishing where possible. A dish 90% done might as well be 0% done, but it occupies mental space while it's not done.
> So the leading hypothesis seems to be that perhaps the SSDs were from the same manufacturing batch and shared some defect.
Really sorry that you had to learn the hard way, but this is unfortunately common knowledge :/ Way back (2004) when I was shadowing-eventually-replacing a mentor that handled infrastructure for a major institution, he gave me a rule I took to heart from then forward: Always diversify. Diversify across manufacturer, diversify across make/model, hell, if it's super important, diversify across _technology stacks_ if you can.
It was policy within our (infrastructure) group that /any/ new server or service must be build-able from at least 2 different sources of components before going live, and for mission critical things, 3 is better. Anything "production" had to be multihomed if it connects to the internet.
Need to build a new storage server service? Get a Supermicro board _and_ a Tyan (or buy an assortment of Dell & IBM), then populate both with an assortment of drives picked randomly across 3 manufacturers, with purchases spread out across time (we used 3months) as well as resellers. Any RAID array with more than 4 drives had to include a hot spare. For even more peace of mind, add a crappy desktop PC with a ton of huge external drives and periodically sync to that.
He also taught me that it's not done until you do a few live "disaster tests" (yanking drives out of fully powered up servers, during heavy IO. Brutally ripping power cables out, quickly plugging it back in, then yanking it out again once you hear the machine doing something, then plug back in...), without giving anyone advance notice. Then, and only then, is a service "done".
I thought "Wow, $MENTOR is really into overkill!!" at the time, but he was right.
I credit his "rules for building infrastructure" for having a zero loss track record when it comes to infra I maintain, my whole life.
The author misses Rite in the Rain, which makes my favorite notebooks, they're printed with heavy, acid-free, waterproof paper. Pairs great with a Fisher pen cartridge (waterproof, pressurized ink made for writing in almost any condition).
As for dating, I like to do something a little different; it's still ISO8601 but with a slight twist. Each page top has the date in basic form (eg, 20220430) and each note on that page has a timestamp to describe that note and a title for the first line (eg: "T1234 Groceries"), followed by the note body below, a little like a git commit message. This allows me to link between notes by enclosing the date and time stamp in pointy brackets. To save some ink when linking, I use the date at the top of the page for context. If my page top is dated 20220430, and I want to link to a note from the 23rd at T0631, I write it like <23T0631>. Since the year and month are the same as the context I'm in, I don't bother writing those. I don't use page numbers at all.
Some other notebook habits I have: I like to use the first page for my contact info if anyone finds my notebook (and maybe offer a reward). The next page is for goals I'd like to work toward during the anticipated lifespan of that book. I also like to create a weekly index. When I've filled the notebook, I create an index of index pages on the very last page. If I wait to index the entire thing when the book is filled, I usually don't. Also, I use the last few pages to create monthly calendars. I fill in dates on them with letters (A, B, C...) for an event, which I reference on the back side of the page, either with a short description or a link to the timestamp I wrote down event information on. Finally, after filling a book, I write the range of timestamps that book covers in the spine so I can quickly find notes in the future.
System design rounds are my favorite by far, on both sides of the interview.
If you're someone who likes browsing a lot of the engineering blog posts that come across HN, reddit, etc, there is a treasure trove of questions to be had.
Just look up a large company tech blog and read through one of their articles. Whether it's well written (you get to learn a lot from the trenches) or not (you have to think about the gaps that aren't explained) you win.
One thing I like to do is take a post-mortem or breakdown of a service (say messaging at slack, which has quite a few blogposts about it), read until they say "since we did not have X as a constraint", then mentally rewrite the rest of the article with that constraint put in.
One can usually find tons of these implicitly, or some explicitly stated.
Depending on the technology, you can also search specific forums to see other problems that things run into at scale. Which leads me to another fun source of system design problems:
* Find people talking about pushing the bounds of configuration values in production.
There are a _ton_ of config values in many pieces of software. Go check the software forums to see why the heck someone would be setting the value so high/low/strangely. An example of this are the elasticsearch or kafka forums. Find someone storing lots of very small things in elasticsearch and hitting scaling issues, or someone trying to maximize storing some very large things, and how they work around it.
Had an offer from Citigroup a few months ago, hope this is useful for anyone approached, this is from my interview/offer experience and from talking to folks at Citi privately:
- They claimed remote was impossible, after I told them it was a red line there was suddenly an exception. They did claim this exception required a lot of approvals but take from that what you will.
- The projects they wanted me to work on were genuinely ambitious and impactful, not just something thankless.
- They claimed to want to start open sourcing large parts of their tech from 2023 onwards.
- It's definitely a different world from the rest of tech, people seemed to care about the things they worked on, but the way things were reasoned about just seemed a bit different.
- The people I met there are genuinely nice people (at least in Tech) who I'd be happy to sit down and have a coffee with anytime.
- Even the very specifically designated tech places had debt coming in from the rest of the company (primarily in process when they had to touch other teams), they did say they had C-Suite buy-in to go solve that but as I didn't join I can't comment on how strong that buy in really is.
- Politics is everywhere, people will fight you not on technical merit but because they want to claim responsibility for something even if its inferior to the product you could build - if you don't have the support to push through this I suspect you'd get stuck here.
- Corporate structure is confusing because everyone's titles are massively inflated.
- Claimed to have internal open source in the Division I interviewed for (didn't expect that).
- Offer for 2 YoE UK was VP £190k/year with no stock
I would try to gently put them on the back foot when they offer a wage.
When you receive the offer, you should comment on the differential between expected and offered wage, even if you intend to accept. For example, you might say with a gently puzzled tone, "this is lower than what I would ideally be earning, based on my experience and capabilities. Can you explain how you came to this number?"
You may be able to push back on them a little bit. You will be able to tell if there's room to negotiate, based on the response to you. Don't overdo it, as simply commenting on the differential and seeing how they respond is a way of gently squeezing them. If it seems the number is negotiable, ask if they can compromise with (for example) $33. The art is in doing this in a confident and friendly way, so that the position doesn't collapse.
Whatever number you set as the price you want, don't waver on it after it escapes your lips. Let them consider the number unless it's clear there will be no budging. If possible, do some research on other roles or other engineers you know in the business, so that you can justify your ask. It's not your standard of living that sets the price, it's your alternative job and their alternative hire.
HN title moderation is more consistent than it may appear. It all follows from the guideline: "Please use the original title, unless it is misleading or linkbait; don't editorialize." (https://news.ycombinator.com/newsguidelines.html) Submissions should stick to the original title—submitting an article doesn't confer the right to change it to suit one's opinion. But we make exceptions for misleading titles and linkbait. Given how the internet and media work, we often have to change titles for one or both of those reasons.
When we do, we look for a representative phrase from the article itself that can work as an accurate and neutral title. We only ever make up our own titles as a last resort, which is rare, maybe once a week if that. Sticking to the article's language often ends up being truer to the article than its own headline, because those are often not the author's doing. For example the current NYT article does not say "loophole"; only the headline does. The word the article uses is "provision" and it uses it four times. Presumably the headline writer switched "provision" to "loophole" for obvious reasons: it makes the title more provocative and thus more attention-getting. Normally we'd switch it back, but in this case I ran into HN's 80 char limit, so I squeezed "rule" in instead.
When users start objecting to a title in the comments, we usually acknowledge the objection and apply it to the title: https://hn.algolia.com/?sort=byDate&dateRange=all&type=comme.... HN readers have an eagle eye for inaccuracy, so their objections are usually fair. More importantly though, if we don't do it, the thread will increasingly be about how irritating people find the title. By translating their objection into a concrete edit, we ground out that energy. People feel heard, and the thread can go back to discussing the article itself, which is always more interesting.
Never underestimate the passion users feel about titles. It is a force of nature—I call it 'title fever': https://hn.algolia.com/?sort=byDate&dateRange=all&type=comme.... You cannot fight it, only yield: https://news.ycombinator.com/item?id=17496011. When I started this job, I found that perplexing: why care so much about titles? How is this the most important thing? But I've come to understand it better. Titles are the one thing everybody reads, so they're the one thing we all have in common. It sounds trivial, but they're the most public, most shared space the community has, and so carry the strongest charge. Thousands of lasers are focused on them. They're also small enough that it's possible to understand them and to feel like one can get them right—at least in comparison to anything else. The community's passion for correctness, so frustrated in most other places, ends up pouring into this.
This creates a strongly reinforcing loop on HN's front page. The feeling of HN titles being accurate and neutral—"I want it to be bookish" was what PG originally told me—gets compounded and cements into an expectation that things must be that way. If they're not, strong frustration exerts pressure to make it that way. This is what I mean by force of nature. And when readers see that they actually have influence over this place, like when people object to a title and we change it, they bond with it more closely and the loop gets stronger.
It also gets stronger because of the contrast between HN and other places on the internet, which have to play games to get clicks that we are blessed with not having to play: https://hn.algolia.com/?sort=byDate&dateRange=all&type=comme.... The brain works in contrasts, and the contrast between the neutral HN style and most other places is so sharp that it creates an "ow my eyes" effect going one way and an "ahh" feeling of relief going the other. HN being text-based affects that too: no garish images, no flashing lights, no loud videos. The more often people come here, the more such small contrasts get registered—thousands of them. We're all conditioned now to expect HN's front page to be this way. Coming here should feel like walking into a library.
It's an interesting question what all this emotion that people feel about HN titles, the HN frontpage, and HN itself is really related to. It's far too strong to only be about HN, which is merely an internet forum and basically just an entertainment site.
