this is a gross undeappreciation of a truly remarkable effort by my dear friend and associate. also, at least one of the languages presented is due to him. you can call him @ktye. he's too modest.
it is not a Kunstkamera or some computer cryptozoology extravaganza. many things are shown here, from different eras, but some are not - they are evolving. and progress takes sacrifice.
cheers
k.
ps. we usually spell atw as atw :) he also goes by a. don't chicken out, send him an email. he's a very friendly guy. just like me.
See, e.g., Bashō's crow haiku, arguably one of the genre-defining poems [0]. Plus, English is on average terser than Japanese; I've read somewhere that, in English, 3-5-3 syllables pack roughly the same amount of content as the Japanese 5-7-5.
Fun fact: the article uses U+03C0 GREEK SMALL LETTER PI (π), but Unicode also has several pi codepoints meant to be used specifically for math. E.g., U+1D6D1 MATHEMATICAL BOLD SMALL PI (let’s see whether HN strips it: [edit: it does, see [0]]).
Yep. Existence of "the best engineers" would imply existence of The One True Metric by which you can judge the person in all context; but that's at best an oversimplification.
The actual metrics (not necessarily easily quantifiable) are the desired traits you put in your job description; they don't correlate perfectly.
There is some truth to this, but I would argue (with a considerable amount of data on both assessments and hiring behaviors) that it is less true than people might like to hope it is.
I very intentionally did not write anything about finding engineers who are just good at the things you care about and not at other stuff, because every bit of data I have says there is a considerable component of general engineering skill underlying most eng roles. No, it isn't totally one dimensional, but (in a principal-component-analysis sense) it is fairly low-dimensional.
There really are just better and worse engineers in the sense that eng A is better than eng B for virtually every job. But that's precisely why recognizing the competitiveness of hiring is important - the more you insist on narrowing your pool, especially in ways others also narrow theirs, the less likely you are to find the rare unknown great engineer.
Totally agree with this. I'm in consulting, where there's a significant client communication component to most of our eng roles, so it's a slightly higher-dimensional space than engineering for product orgs. Still, there is a pretty powerful "g factor," where someone who excels in one dimension will probably be pretty good at all the other dimensions.
Still, when we're staffing, there's a world of difference between the great engineer who is happy being mostly left alone and writing complex but well-specced SQL queries for 12 weeks and the great engineer who can balance software architecture, customer meetings, and programming for the same project.
I keep a handwritten diary and a handwritten blog. Not that my penmanship is particularly exquisite – in fact it’s pretty mediocre – but handwriting by its nature is a very focusing activity for me. It’s one of the life hacks for my ADHD.
If you can run it, then you can REPL it, no matter how deeply nested. Scope-capture (https://github.com/vvvvalvalval/scope-capture) has been probably the most important tool in my box. Hope jank supports it eventually.
Thanks for jank! It’s great to be reading about it, listening to you talking about it at conferences, and I can’t wait to try it out!
OK, I have a fun one. I was a rookie back then, it was 2007, and the cloud was only beginning to take off. My company had a physical server room.
Automated CI was not quite as big back then as it is now; we had some in-house CI-ish facilities, one of which was buildbot: a small Python script that continuously built all of our projects one after another, reporting successes/failures in a simple UI.
One day I was puzzled to discover that buildbot hung trying to build a tiny Java applet. Just a handful of .java files. But it had been stuck for more than four hours at that point.
I ssh’d into buildbot and looked at what exactly the hung process was doing. It was not javac. It was jarsigner.
Then it dawned on me. jarsigner needed some crypto-safe randomness, it was trying to get it by default from /dev/random, not from /dev/urandom, and the machine ran out of entropy!
I ticketed a change, but as an interim measure, I went to the server room, switched the console to buildbot’s server, and moved the mouse vigorously for some seconds. It proceeded.
Hit something similar a fair time ago, and installed havenged¹ to stop it repeating. Less necessary now as the kernel has its own similar (jitter based) internal entropy source, and /dev/random has been made non-blocking anyway by adding a little extra compute to “stir the pot” (like /dev/urandom did anyway, but less cryptographically safely so).
Arrays in TP were laid out in row-major order, and each character was represented by two bytes, one denoting the character itself and the other the attributes (foreground/background color and blinking). So, even better, array[1..25, 1..80] of packed record ch: char; attr: byte end absolute $B800:0000.
Replace $B800 with $B000 for monochrome text display (mode 7), e.g., on the Hercules.
