-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathindex.html
74 lines (74 loc) · 5.02 KB
/
index.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
<!DOCTYPE html>
<html>
<body>
<ol>
<li>
<h1>Break Things</h1>
<p>'Move fast' isn't a meaningful value; 'Move fast and[/even if you] break things' is a meaningful value. A company's real values
are defined mostly by what they <em>aren't</em>; by what things you will trade off to get the things you value. If you say you
should 'Be a host', what <em>aren't</em> you being? A bouncer? A detective? If you will 'Make something people want', what does
that mean you're <em>not</em> doing? ...Okay, actually that one works pretty well; it means you're not making something <em>you
</em> want. But you see the idea.</p>
<p>I am a big fan of <a href="https://www.keyvalues.com/">KeyValues.com</a>, but I would like it even better if it told companies to specify not just what they
care about, but what they consider backburner-at-best. Let me see the company that specifically says it thinks 'EQ > IQ' is not for
them, or specifically <em>isn't</em> 'Data-Driven', or hates 'Pair Programming'. I'm not sure I actually want to work at any of
those companies, but five positive values and two-three negative ones would tell me a lot more about a company's culture fit than
ten ranked positives.</p>
</li>
<li>
<h1>Try Planning Meetings On Fridays</h1>
<p>Inspired by the Crowdstrike debacle, I was considering things that might structurally discourage Friday afternoon pushes. And it
occurred to me that if you structured the 'beginning of the week' on Friday, 'get this done by the end of the week' would tend to
mean Thursday. And there are some other good points in favor:</p>
<ul>
<li>Retrospective and planning is done with the last four days in more recent memory</li>
<li>Most plans and projects will be in the early stages over the weekend, and so less context will get lost and need to be
remembered</li>
</ul>
<p>Of course, there are also some considerations against:</p>
<ul>
<li>'Do this immediately' would have a tendency to mean Friday pushes. This is probably easy to remember and discourage, but it
won't go away entirely.</li>
<li>Probably at least minor productivity loss on Friday afternoon since you'll forget a lot of your state before Monday.</li>
</ul>
<p>I think that on balance this would be net positive, and definitely has high enough expected value to be worth trying.</p>
</li>
<li>
<h1>Disk Encryption Password Changes</h1>
<p>If you want to change the disk encryption password for your Linux machine, there is a simple set of steps.</p>
<ol>
<li> First, run <pre>sudo lsblk -o name,fstype</pre>. Look for the entry whose fstype is <pre>crypto_LUKS</pre>; common values
are <pre>sda3</pre>, <pre>nvme0n1p3</pre>.</li>
<li> <pre>$luks=/dev/NAME</pre>, where NAME is the result from the previous step. </li>
<li> <pre>sudo cryptsetup luksDump $luks</pre>; look at the listed "Keyslots" entries. If you have not changed the disk
encryption before,
there will be an entry for "<pre>0:</pre>" and no others, but if it has been changed before, or there are multiple
passphrases, there may be entries for 1,2, etc., which may go as far as 7.</li>
<li> Assuming there was only the single entry for 0, execute <pre>sudo cryptsetup luksAddKey $luks -S 1</pre> to create the new
passphrase. Change the number in <pre>-S 1</pre> if necessary.
You will need to enter an existing passphrase, then you will be able to add your new passphrase.</li>
<li>(Technically optional, but skip at your peril) Restart your machine and decrypt the disk with your new passphrase, to be
sure you have it correct.</li>
<li> <pre>sudo cryptsetup luksRemoveKey <$luks> -S 0</pre> to delete the old passphrase. Since you restarted, <code>$luks</code>
won't be set, and you'll need to substitute this in manually.</li>
</ol>
</li>
<li>
<h1>Rails</h1>
<p>A wise man once said of Las Vegas:
<blockquote>"It is glorious that we can create something like this. It is shameful that we <em>did</em>."</blockquote>
This is approximately how I feel about Rails.</p>
</li>
<li>
<h1>Dynamic Programming</h1>
<p>I am convinced that dynamic programming is a fad that has stuck around for no real reason. If you're writing an algorithm that
has repeated subproblems, you can straightforwardly write a recursive algorithm that works intuitively. You can then add
memoization, which in the right circumstances gives substantial benefits to speed at the cost of space.</p>
<p>Or, you can rewrite the entire algorithm to optimize the subproblem records, i.e. dynamic programming, at the cost of
comprehensibility for readers and considerable time and effort for the author. Frequently this only improves performance by a
constant factor, and rarely does it do better than O(n<sup>3</sup>) to O(n<sup>2</sup>) or O(n log n) to O(n log log n).
Choosing DP is almost always a mistake.</p>
</li>
</ol>
</body>
</html>