abhayb

I used to live under the guy that ran Lost Weekend on Valencia street. Held out till like 2014/2015. At the time I wasn't really sad about it but now I wish it was still around

Thanks for that! I'll have to get a pint next time I'm there (for some prog-metal in like two weeks). Concert beer tastes better in glass glasses too heh

Sorta sounds like Enneagram types is what you're looking for?

Finally a place for new desktop wallpapers after http://exoteric.roach.org/bg/

Also I would describe your server situation as "brave" and "a mood" (I mean that in the very best possible sense)

And finally, a question: what other interesting stories does the creator have to tell?

First, I understand what you are saying and understand the constraints keeping you at a job you have issues with. I've certainly seen organizations go too far on consensus even when each person individually (especially the ones at the top) would like more decisiveness. This is a hard and draining place. And all moves out require even more energy that you may not have and should not (in a just world) have to expend.

Someone recommended "Moral Mazes" and I heartily second it. Though mostly because it was so profoundly cynical that it pushed me to defend the systems I was so annoyed by.

If you want to learn the language of design by committee, "Nonviolent Communication" by Marshall Rosenberg is the book that the rest of the committee is playing from. It has genuinely useful pieces. But I also find it fundamentally dishonest in that it frames all other forms of communication as "violent" in a rank misuse of the word. Additionally, the techniques it recommends require that you put in all the effort of framing a situation as no-blame or shared-blame when it very much is not. You do not need to agree with your opponents' tactics manual to find value in its study.

"Radical Candor" by Kim Scott is an attempt to bring directness in to otherwise passive aggressive situations. It's a valiant attempt but it's unclear to me how viable its recommendations are.

However it's not clear to me that any amount of high or low level reading is going to help with your feelings of dissatisfaction here. It sounds like you're looking for a "win" instead of an "out". And despite the deeply cynical feelings it can generate, you cannot succeed at office politics through cynicism. Or irony. Or cynical, ironic, distance. The successful are either completely earnest, or sociopathic enough to fake complete earnestness. And from the outside those are indistinguishable.

Secret third option: spun out of the Business School!

Data has always been plural! Datum is the singular. But actually treating it as plural is mostly a question of where the person speaking/writing is based. Americans treat it as singular, Brits plural. See also, corporations

Hello, yes, recent member of the HN note-taking crowd here. Throwaway meeting notes are exactly my use case. It helps that I do most of my thinking on paper anyway so I have a pen and pad handy at all times. For me it's all about focus. Writing is an activity that I enjoy doing independent of what I'm actually writing. Can't zone out if I'm taking notes which leaves me in a position to drop all of the many great insights I always have in every single meeting.

Hey komali2, why'd you have to go and describe me this sharply on a Saturday morning? Is it that I accidentally crowded you out at the Four Barrel pour-over bar and now you want your revenge?

I've heard it said about running: it doesn't get easier, you just get better. I'm beginning to think that that is true of life in general. My greatest source of dis-ease (rather than literal disease) is the feeling that I'm not living up to my potential. Been with me since at least third standard/grade.

While I've never been to Stockholm (heard Noma's a good local joint), I'm at the place where I'm more afraid of getting too comfortable than I am of never being at ease. I'm trying (and usually failing) to think of things one bandaid at a time rather that the whole million at once. Setting my goals real low: to suck less rather than to be good/great. Help's a lot that there's one or two things that I legitimately feel I'm damn good at.

I'm curious, especially on the topic of stringing-together-unix-tools-on-a-whim, have you found any little tricks that apply to that area specifically rather than to the general concept of productivity?

This is what I hear out of Bangalore too. Maybe even further? Like you can command Valley level comp (or at least base+bonus) if you can clear the right hurdles. Though maybe in Poland too, the issue is that there are far more people one rung down. Cut distance from from 110m to 100m and suddenly there's a lot more competition

Some amount of post-install runtime loading is basically necessary on Android if you're using shared native libs. Can't remember off the top of my head what needs to happen but basically every app runs into strange crashes until they start packaging their .so as a resource and then loading it in Application.onCreate. Chrome does this so it's at least de facto allowed.

Google has to allow dynamic loading at app start because of this. Or fix whatever subtle interaction between Android and an OEM's "improvements" is causing this. Not a huge step from here to getting your library from the internet instead of bundled with the app.

Not trying to justify any one app's behavior, just bringing up a fundamental reality baked into what you're saying: Apple doesn't have to deal with the gaps in its security model becoming load bearing features.

Yes! I've seen these called guardrail metrics. Having a single metric be the one to optimize works pretty well if that optimization is what you want. But optimizing a teams work is messy and generates organizational instabilities. Tuning the guardrails feels like the best way to make sure that you get enough instability for interesting things to happen but not enough that other teams start deciding to take over whole functions just to get work done.

All infra teams eventually become platforms. All product teams eventually become experiences. When viewed negatively this is called scope creep. I don't know what it's called when viewed positively but I expect the word "holistic" to be used unironically.

Org charts that ship a platform are default stable because everybody it a team or group is doing approximately the same things. Growth is less uncomfortable, advancement feels more objective, and individual developers are relatively interchangeable.

But what if a company needs to change? Now the stable org chart resists that change. By rejecting requests from client teams that are responsible for a new set of objectives. This recurses. One layer of platform can simultaneously be moving too slowly for the layer above and too quickly for the one below. Shear forces tear it apart and the organization finds itself with n (3 < n < 6) fewer platform engineers.

The super power I see is not so much written communication as intentional communication. I try to get myself to communicate intentionally by having command-enter send my Slack messages. But sometimes you need to Do the Thing. And you can't afford to Intend to Do the Thing first. In those situations the speed of spoken-face-to-face makes the organizational debt worth it.

Hmm... I think the idea with synchronous communication is very much the same as it is with with synchronous method calls. Synchronous communication lets you break your thoughts down into smaller chunks and thus make them easier to understand. Synchronous methods do very much the same (at least how I write them).

I like what you say about needing to "learn how your co-workers communicate[d]". Maybe that's the abstraction layer that makes async everything possible. Still a leaky abstraction and I'd prefer not to have it. But it might actually have worked for me over the last couple of months.

I sort of see what you're saying. When a person with Great Authority says that Something Needs Doing, I need to think through what I'm going to say about what I'm going to do. But the single best response is to spend those fifteen minutes seeing if there's an obvious solution. If there is, you can be quite terse and just say: "done". Do that five times and even Tim Cook has your attention.

Just got a three pack of Iroshizuku in! The tsuki-yo, kon-peki, and take-sumi. Only tried the first so far but it's lovely. Maybe I need to get the set with asa-gao soon?

> it has a clear preference for pricy paper

Well so do I :)

Computer Systems: A Programmer's Perspective. Flies a little under the radar. I'm definitely biased here (TA'ed the class that originated it). But by the end of it I left with a decent understanding of x86-64 assembly to the point that I could hand compile C functions. And also a rough and ready understanding of how shells, malloc, and web servers work.

Pretty much. I'm all about data classes so the code reads just fine. Definitely less boilerplate than something like JsonObject. But using Gson means non-nullable fields can still be null if the incoming JSON doesn't have them. So you get these "impossible" NPEs. Also, this is more a complaint about the JVM type system but Gson can encode things that it can't decode into which really messes with my mental model.

Hard same on the Kotin/Jackson sadness. Gson also has a bunch of issues. Really want to cut my code over to Moshi but haven't worked up the energy for it. Maybe we all just want to wait till Kotlin serialization is production ready?

CMU's Compilers course (15-411)[1] does a lot of what you want. Students write code generation code in the very first assignment. A particular delight of this approach is that the first assignment is for compiling straight line code while one of the later ones is for optimization. If you implement SSA form for the optimization assignment, all of the test cases from the first assignment compile down to effectively one precomputed result. Very clear marker for how far you've progressed!

[1] https://www.cs.cmu.edu/~janh/courses/411/16/

Ah I wasn't even thinking about motivation! Yeah it makes sense that I'd have to start with motivation when I'm breaking down a perf problem. I'm reminded of the talk So you want to be a wizard [1]. It definitely understands what you're talking about.

[1] https://jvns.ca/blog/so-you-want-to-be-a-wizard/

Ah dark knowledge through blood sacrifice. Was hoping they'd found an easier way :( Thanks for the pointer, been a bit since I read some OG John Gruber

I love the detail in the post! A lot of this seems to boil down to the author being able to drop to a lower level of abstraction when necessary. I'm curious to know how they got that facility. Did they dig deep when they found something was slow? Or did they do a bunch of research before hand? Maybe the higher level tooling didn't exist when they started working on the platform so they had to pick things up out of necessity?

It's been 10 years since I was a well behaved and anhedonic teenager. Not only did I fit what the newspaper describes but I actually read the The Economist cover to obituary (the obit is the best part). Now that I'm past that it seems the "wild years" don't so much disappear as move back half a decade.

I'm going to take inspiration from @lexi-lambda and respond in mini-composition form. Note that great writers write essays. I, write compositions.

It's just like Haskell for the crucial difference between two functions to be denoted by prime. For half of the essay I thought that this was a deep philosophical treatise about the degenerate case equality of lazy and strict languages. But, in reality, fold and fold-prime (can you inline code in HN?) are totally different functions.

And like with all pairs of things in Haskell once you learn the fundamental difference between them, the fact of that difference becomes obvious. So obvious that you don't know how anyone could possibly confuse the two. And so you call the method everyone should use foldl-prime even though a casual programmer doesn't even know that "single-quotes" are an acceptable value name. When you could have just called it foldl and moved the old one to the deprecated module.

You're absolutely right about not overthinking. Any architecture doc is better than none. Even if the thinking it describes is incoherent or if it describes coherent thinking sloppily. And even during editing, there's only one thing I want my principal engineer to keep in mind. Inside the technical vision, tell me a little about implementation details. Either pulled in from below or, if the principal is risen from my ranks, written from experience.

Pinker made it easy for me to slip into my own thoughts about writing, how I currently write, and how I would like to write in the future. Just for that I thought it was worth it. However Pinker has Opinions about writing rather than just suggestions. Be prepared to disagree with what he says and how he says it. I suspect he would be glad for you to do both.

This is exactly what I want to see on HN. Exactly because I will never use Plan 9. It makes me happy to know that someone, somewhere, is using it. Providing an existence proof that even something this unwieldy and obscure is for one glorious moment useful in 2019.

Both are true because this is a government official. A key skill for a government official is to communicate in a way that gives no information to people who disagree with them. This is a sensible adaptation to their conditions. You disagree with this government official. And for that reason you gain no information from them.