HNHacker News
TopNewBestAskShowJobs

johnm

783 karma · joined February 21, 2007

http://foundapp.com/ http://twitter.com/johndmitchell http://markmail.org/ http://krugle.org/ http://jguru.com/ http://www.linkedin.com/in/johndmitchell
submissionscomments
johnm··on The Lost Art of Logarithms
Indeed, I use pen/pencil and (dot) paper. Different brain space.
johnm··on LeetCode but You Can Force People to Code in Light Mode
A bunch of wimps for not going back to actual VT220 green phosphor terminals. Lol.
johnm··on LeetCode but You Can Force People to Code in Light Mode
Indeed this is the way.

I also have variants of light and dark for different lighting conditions at night and day (particularly glare).

johnm··on Automating processes with software is hard
No, those are the same that have been around forever. They just have a new tool to "justify" their crappy behavior.
johnm··on GeoWorks: The Other Windows (2019)
PC/GEOS v1.0 ran on an original IBM PC with 640K. The minimum for v1.2 was 1MB of RAM.

In terms of responsiveness, it was an interesting compare and contrast from the Sun workstations vs. the PCs running GEOS. Less mouse jitter is one memory (especially in comparison to those old Ultrix machines).

johnm··on GeoWorks: The Other Windows (2019)
Yeah, PC/GEOS was built from the ground up to give that fully scalable "WYSIWYG" "Display Postscript" experience but the PC displays at the time weren't very good.

I remember learning about self-modifying assembly in the low level drawing code from JimDF.

johnm··on GeoWorks: The Other Windows (2019)
Ah, I didn't realize that. PC/GEOS did in '89 or '90.
johnm··on GeoWorks: The Other Windows (2019)
Lol. Migration of PC/GEOS to protected-mode 32-bit x86 was not some magical rubicon that wasn't foreseen.

Geoworks was doing well until its sales deals got utterly hosed by the Microsoft monopoly power play. That started a cascade of direct and indirect problems from both a technology and business perspective.

johnm··on GeoWorks: The Other Windows (2019)
Yeah, it took way too long to prioritize and deliver a non-assembly development chain and opening that up to the public at large.

We cross-developed from Sun workstations to x86 PCs and quality of x86 native tooling wasn't nearly as good. But eventually building on x86 was actually quite a bit faster.

johnm··on Zed, the new code editor from Atom developers, has entered open beta
IME, Zed's real & perceived performance is way better than Sublime.
johnm··on Zed, the new code editor from Atom developers, has entered open beta
Yeah, they don't seem to have any serious Emacs person in their team. So, like so many people who try and build editors in the last few decades, they seem to miss some fundamental things (while focusing on other worthy things like the core rope+crdt enabling fast local & collaborative editing).

They talk about things like having a plug-in type system in the future based on e.g. WASM but, as you're pointing out, their fundamental perspective is built around the simplistic notion of a control panel with fixed functionality that's primarily accessed via a bizarre set of keymaps. On this front, might as well stick with JetBrains.

johnm··on Zed, the new code editor from Atom developers, has entered open beta
A lot of us have been following along with Zed hoping that the clarity and action on the open sourcing front would be done or at least in the process of happening before the public beta but from what was shared in the podcast, it doesn't sound like any progress has been actually made on this front.

Especially, since Zed does have a very clear distinction/dividing line of "completely functional local editor" == permissive open source vs. "all of the real-time & async collaboration features" == proprietary that is easy to explain.

Frankly, I would happily pay for great, fully supported, high-quality real-time collaboration for my teams.

Anyway, as you can see, not having any useful progress on this front instantly shuts down lots of people and there's many of us who won't even consider doing more than checking it out until this is done.

johnm··on Show HN: Svelvet – A component library for building interactive flow diagrams
Indeed, they are draggable.
johnm··on Show HN: Svelvet – A component library for building interactive flow diagrams
Nice!

Would be great if it could generate static images of a diagram in e.g. SVG.

johnm··on The endgames of bad faith communication
You'll be called much much worse than that. IME, you'll be lumped into the "other side" as defined by each of the bad faith participants. And if you point out their bad faith intent and rhetorical games, the level of ad hominem attacks increases exponentially.
johnm··on Ask HN: What are some good keyboards?
I use Corne(-ish Zen) that is a split-ergo on top of my MBP keyboard. It's low profile (uses choc switches).

I have an additional touch pad that I use with the same keyboard on my desk.

johnm··on Ask HN: What are some good keyboards?
I've worn out multiple of them over many many years of using the Kinesis Advantage (and then Advantage 2) (before I went down the splergo rabbit hole).

One thing to note is that people with large hands and/or long finger lengths can find the fixed size hand wells too cramped.

Another thing to note is that they are loud.

johnm··on Ask HN: What are some good keyboards?
Boba U4's are fantastic MX style switches. They've beaten out all of the others that I've tried on my hot-swappable Corne.
johnm··on Ask HN: What are some good keyboards?
Note that for people who are used to and prefer the short travel of laptop keyboards, they should check out mechanical keyboards with choc switches rather than the much longer travel MX switches.
johnm··on Ask HN: What are some good keyboards?
Good entry point for people coming from the "traditional" keyboard world -- particularly those who don't expect to invest a lot of time in things like learning radically different layouts, heavy use & customization of layers, etc.
johnm··on Ask HN: What are some good keyboards?
For people already heading towards (or already down :-) ) the split ergo road, the IC is open for round 3 of the Corne-ish Zen keyboard (3x6+3 or 3x5+3, wireless, zmk firmware, chocs): https://docs.google.com/forms/d/e/1FAIpQLSdCpc0rmRWP4NqA0ee0...
johnm··on Ask HN: What is a better approach to interviewing?
That doesn't answer my question about why you claim it doesn't scale.
johnm··on Ask HN: What is a better approach to interviewing?
When building your own culture, of course. However, that also misses the fact that there's also the larger context of e.g., silicon valley "norms". So much cargo culting of behavioral patterns from unicorns, the spread of the various "mafias" from them as they go to other companies, etc. Add in the various management level sillinesses and it's a harder problem to solve for most people than your comment implies.
johnm··on Ask HN: What is a better approach to interviewing?
It's not just the US but yes the lack of trust is a major component. Everyone seems to have a horror story of how someone made it through and sucked and caused problems. It's bizarre how traumatic that is allowed to become because people don't get rid of those bad apples quickly. And it's funny how people over-index on this in the engineering realm when it's a much larger problem in management.

But there's also a bunch of other dynamics going on. 'Geek machismo' is a very non-trivial one. Other's are akin to hazing. One friend of mine described one value of very high bar hiring is that people in the bubble can (go back to) assume that the colleague is smart, etc. rather than assuming people are stupid/incompetent until proven otherwise--and that can be a good thing from the culture/sociology standpoint.

johnm··on Ask HN: What is a better approach to interviewing?
Can't speak for the GP but IME, absolutely. It's much easier to dig in deeper with (much) clearer signal about somebody when they are talking/working with their own code/project. Less distractions/confounding factors/proxies, more direct inquiry and you can go as deep and broad as you want to map the edges/gaps of not only what they know but what they care about/prioritize and why. The proof is in the code.
johnm··on Ask HN: What is a better approach to interviewing?
Lots of why did you, why didn't you, what about this, how did you deal with that (and back to why). :-)

I signal a lot of things like testing by asking them. It gives room for the candidate to ask those sorts of questions back about how we do things.

johnm··on Ask HN: What is a better approach to interviewing?
Do you have some legal/security issues?

I ask people to send me code they've written via email or links to projects and go through that.

johnm··on Ask HN: What is a better approach to interviewing?
Indeed. And true humility.

"Less certainty, more inquiry." --Erik Seidel

johnm··on Ask HN: What is a better approach to interviewing?
I had a great conversation with one of my cofounders about this. First off, if you're only asking questions to a point where they are gameable then your questions aren't very good. The example I was trying to explain to him was that I look for 'aggressive curiosity' and wasn't sure I wanted to put that into the job description. He laughed and asked how far could someone game that as we keep asking follow up questions on any aspect of the discussion?
johnm··on Ask HN: What is a better approach to interviewing?
What makes you believe that? Do you believe that the e.g., algo approaches create a strictly rank orderable list of candidates which actually correlates to their on-the-job impact? Also, why do you think such a thing matters more at scale than when a team/company is small?
Page 1 of 10Next →