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
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.
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?
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!