shalmanese

I find it so fascinating the deep yearning some people have for contextless ontologies.

Someone decided to call the Mac Mini a workstation... for what purpose? Did categorizing it as a workstation illuminate or confuse the larger point they were trying to make? If the former, then it's a workstation in that context and if the latter, it's not, again in that context.

Fundamental to my worldview is that we put things into boxes solely to aid in communication and the box is not important except insofar as it serves that functional purpose. But for others, the boxes themselves are deeply important and a huge amount of effort is spent cramming continuous functions into discrete containers for the sheer, seeing like a stateesque satisfaction of seeing the world organized. I'll never understand it.

How much does it cost you to buy a GPU with 128GB of RAM on it?

Reading fiction isn’t about the books, it’s about yourself. The books are a stimulus to introspect about your relation to the text.

As long as you keep changing, the quantity of books to read is infinite. I like the analogy of the article that books are like a stream and just dip in and pick the one of the moment and let the rest float by. It’s only people who don’t change enough who consume too much from the same point in the stream and feel the effects of water sickness.

To the people pooh poohing this, do y’all really work with such terrible coworkers that you can’t imagine an effective version of this?

You need trust in your team to make this work but you also need trust in your team to make any high velocity system work. Personally, I find the ideas here extremely compelling and optimizing for distraction minimization sounds like a really interesting framework to view engineering from.

> If a technology comes up in a meeting or 1:1 that you don’t know, add it to a list of things to research later. Then, dedicate time in your week to go through that list and learn about the technologies on your list well enough to have your own opinions about them. This practice allows you to have further discussions with whoever mentioned the technology.

> If you get interested in what you learn about the new technology, you may want to keep trying to understand it better; you may read more or embark on a personal project using it to gain more practical knowledge. As I said, it isn’t that you must stop coding. It is that, eventually, it shouldn’t be your day job anymore.

One thing that gets elided in a lot of "servant leadership" style chatter is, as a manager, you have permission to be straight up selfish. New leaders often struggle falling back into their old "inefficient" patterns of learning things but you have a team of resources at your disposal now.

You can just straight up ask a member of your team to prepare a bunch of background on the new technology and book a solid hour for them to personally tutor you through it. Sad to say but your time is more valuable than theirs and it does them no good for you to struggle at the other parts of your job because you're too modest to use your vested power. Often, teammates are actually happy to take the burden off your plate, if you poll ICs about gripes about their manager, one that comes up a lot is they wish they could get a few solid hours of the manager's time so they can educate them properly on a technology concept.

If you look at leaders as they move up the chain, one mark of who gets to the next level is who has learnt to be "selfish" enough to really leverage the resources under them. People are often under the misapprehension that these leaders are just sociopaths or heartless but if you actually ask them, it's not comfortable for them either and it's something they've had to learn but it's necessary mathematically to get any work done as your span of control increases.

I bet the collection of potions you've managed to accumulate after you've beaten the final boss must be really impressive!

It seems even more flexible than a lease, you can pause and return the car at any time and get a new one when you unpause.

The Apple provided tools are the ones used at first party Apple stores to perform authorized repairs. At some point, some bean counter tabulated the cost of building X000 machines and shipping them across the globe for a marginal increase in repair quality and deemed it a worthy tradeoff.

If you want to repair phones to the equivalent quality of Apple stores, Apple makes it possible via their "overengineered" machines. There's nothing in Apple's ToS that forces you to make repairs this way, you're welcome to buy the Apple genuine part and use your own heat mats and press and whatever and knowingly make that tradeoff.

To add to a bit of comment serendipity, @btrettel posted recently that one of his contributions from his PhD work was the characterization of "turbulent Rayleigh" liquid jets that describe men peeing but had remained largely ignored by academia because it didn't usually happen to industrial machines, only humans.

https://news.ycombinator.com/item?id=41547882

One distressing trend I've noticed becoming ubiquitous on HN is that any writing that is confronting to a consensus worldview becomes flooded with highly upvoted comments that are, in essence, excuses for why it's not necessary in this instance to re-examine your priors.

He's making low value content/the culture of the company is horrible/he's a fraud/it's more luck than skill. The actual critiques are personalized to the content and, to one extent or another, valid, but the social purpose of the critiques is universal which is that I felt uncomfortable that reading this might mean I have to re-evaluate my worldview and I'm going to dive into the comment section and upvote all the people telling me actually, I don't have to do that.

I actually spent over an hour writing 750+ words of my takeaways reading this document and shared it privately with a few founder friends of mine and I briefly considered also posting to share with the community but I took a look at the comments and took a look at what I wrote and decided I didn't have the energy to face the endless onslaught of nitpicks and misunderstandings that are driven, at the end of the day, not by a genuine intellectual desire to reach an understanding, but by the need to prove emotionally that others are not taking this seriously so I don't have to either.

All I can do is be vague and say I think this was an enormously valuable piece of writing that is worth engaging seriously for what it is as it might change your worldview in several important ways.

But also my larger meta-point is that there's a now near ubiquitous "sour grapes" attitude that's pervaded HN that makes it an extremely unpleasant place to hold a conversation and people reading should be aware of this systematic bias when reading comments here.

This, fr, is a better explication of "founder mode" than anything pg & co have put out about it so far.

If it wasn't the iPhone, it would have been something else. The logic that drove the decision and not the end result was the undoing of Intel and the logic would have remained the same as long as the culture remained the same.

Well, they're different in that they're vendors and also vendees. The theory behind employee ownership is that it makes them better vendees on top of maybe making them better vendors.

I mean, that's more life imitating art imitating life. The show was explicitly inspired by a Murdoch biography: https://nymag.com/intelligencer/article/succession-based-on-...

As in you took the survey but declined the iPod or you didn't take the survey because they offered an iPod?

Curious for people who think this is unethical how they think about swag at conference booths?

The range of practices I’ve seen go from just come up to the booth to get some trinket to put in your email address to get something a bit more valuable to listen to our 5m spiel and you can pull something out of a claw machine.

Is there a line there that you personally wouldn’t cross? A line that’s prohibited by your company policy? A line that you believe makes a company unethical and should be prohibited? Curious where everyone falls on this.

They're also useful in retro for the simple fact that something was written down. If your story point estimate was way off for a particular task, you can pull up the original conversation, identify what assumptions were violated or what new info was surfaced that wasn't present at the original estimation and whether there's learnings/process changes to be made.

Of course, retro is usually the first thing to go in a deluded attempt to increase velocity and story points hang on as this vestigial tail, contributing to more cargo cult software engineering.

edit: One scenario that might play out:

The team all agreed that tasks A, B & C were worth 3, 5 & 1 points respectively but Steve and Mei thought task D was worth 5 points but Carol thought it should be 13 because it involved integration of an external API where her experience was that other API integrations in the past had exposed hidden complexity.

Task D ultimately was not completed because during the process of integration, it was discovered that the API did support a key feature that was needed and instead, an in house alternative needed to be built.

It was decided that going forward, the team would instead assign a 1 point task to building a toy app for any new API integrations that would then feed into the process of deciding the story points for features requiring that integration.

Right when FiveThirtyEight launched, they did a brilliant piece of content strategy in that one of their very first pieces was a quest to find the best burrito in America [1]. Anna Maria Barry-Jester self reportedly "traveled more than 20,000 miles around the United States and eaten 84 burritos in two rounds (to say nothing of the dozens of extracurricular burritos I polished off)."

I was glued to the series as it plodded on week by week and it still sticks in my mind today as simultaneously the best and worst job in the world I could imagine. Part of what made it so enthralling to read was this grand act of human perversity that a single woman would endure such a gruelling quest for such a trivial question and she made you feel that perversity along every step of the journey.

[1] https://fivethirtyeight.com/features/americas-best-burrito/

I'd be wary of almost any startup that hired without any form of interviewing whatsoever. The big difference is that you walk into the interview as a default-yes rather than a default-no, ie: they're on the lookout for any red flags that would cause them to have serious reservations but if no flags pop up, you're assumed in.

At big companies, there's more of a formal process but the key is get the attention of the hiring manager and make sure that hiring manager has enough juice to quietly backchannel to whatever process to treat this as a default-yes conversation. A good sign of how effective your manager is at a Bigcorp is how well they know how to work their internal system to get the right people onto their team.

But there's art that exists in freeports whose only value is that it's moved from locker A to locker B as a part of a financial transaction. Definitely, not all art is a security but it's an interesting question, both philosophically and legally whether there can be some class of art that functions so close to a security that security provisions should apply.

Don't you mean Clbuttic Scunthorpe?

"It said real adversaries may have instead used prolonged password-praying attacks rather than phishing at this stage"

Did the author mistype Password-Spraying or is there a seperate type of attack known as Password-Praying? Googling doesn't reveal any other hits on this term.

Isn't that exactly the point of the policy? Consumer habits don't have to change but their sugar consumption goes down because of economically rational incentives and they have to make an affirmative change in habits to go back to their previous levels of sugar consumption.

Why not get a swamp cooler?

To me, the two ideas are slightly orthogonal. Conceptual skills are cross-domain applicable and is a good measure of your ability to gain new technical skills whereas "technical" in the context I'm using it refers purely to your ability to pierce abstractions in the domain you're working in.

eg: I would be confident stepping in as a technical manager in a software team but if I were to work in eg, aerospace, I'd still have strong conceptual skills but I'd be distinctly non-technical. There's a pretty shallow set of abstraction layers beyond which, I just don't have the education. If I were to go back to school for aerospace engineering, I'm sure my strong conceptual foundation would mean I could master the material 4x faster than anyone else but it would still be a lot of grinding work doing the math and using the software and building prototypes and testing so I could learn. And like, at this stage in my life, the ROI simply cannot pencil out, which is why it's so important to build the foundation when you're young.

I'd say almost every strong non-technical manager is strong on the basis of their strong conceptual skills but that still makes them a non-technical manager and there is a distinct difference.

To me, "technical" in this context simply means how many layers of abstraction are you capable of piercing together with me?

I'm 20 years removed from any deep technical work at this point but I'm quite thankful that my CS degree's philosophy was that by the end of the program, you should be able to sketch out conceptually what's happening on a computer from electrons on a wire to how users react to your UI (basically, Nand2Tetris before Nand2Tetris). I've forgotten the fine details but that conceptual stack still exists in my head and it's an asset I'll always have.

There absolutely are many amazing managers of tech teams that are deeply non-technical and rely on their mastery of the abstraction layers they can grok to drive effective team performance. But there's also many times where the details do matter and the ability to dive deep into the guts of minutiae is an enormously valuable tool in your toolbelt. Management is a diverse set of skills and every manager rolls a different set of attributes on your character sheet and nobody is a 10 across the board. The art of management is to figure out what differentiated management style works with your character stats and build a team/environments to buff your strengths and make up for your weaknesses.

But the kind of technical knowledge you get from a solid CS education is too time inefficient to learn on the job and so there's real value to in absorbing it as much as you can in an collegiate setting.

Like what the article stated. “I should ship this week but I really feel we need a mobile app to ship.”

You build the mobile app and you still don’t ship because the mobile app was not the problem, it just hid the problem. Until you understand and confront the true problem (emotional discomfort at the consequences of shipping), there will always be another reason not to ship.

No, almost certainly the other people didn't start the project because they saw his video and were so inspired by the idea they rushed off to build it. Almost certainly, it was a case of parallel evolution where they faced a similar problem and there are only so many parameters in the design space so they figured out a similar solution.

People who focus on ideas think their ideas are so inspirational and unique that they must be protected. In reality, anyone who has tried to go out actively and convince anyone else to build their "brilliant" idea quickly realizes the level of indifference and lack of engagement anyone else has to your baby.

This is the wrong framing of it, shipping is an internal mental battle, not an external one.

We are not perfectly rational automatons that always work towards our rational best interests. Shipping is hard so we create mental battles inside ourselves to avoid it and use post-hoc justifications to feel morally ok with that decision.

The choice of when to ship isn't nearly as important as the answer to why you aren't shipping on the choice you said you would ship. Yes, shipping at different points of maturity represent different sets of tradeoffs in a complex multi-dimensional matrix and it's an intellectually fascinating challenge but often, the choice is far less important than the debate that sucks it in and engineers end up bikeshedding the decision. Whenever you find yourself bikeshedding, it's important to realize you don't solve it by looking at the decision but by looking at why people feel the need to bikeshed in the first place.

You talk about how "Your job is to create great software. What's great software? The kind you'd be willing to put on your resume without feeling bad.", what is the "job to be done" by that belief for you? Is this a true, genuine held belief by you or is that here as a cover to some deeper belief that is uncomfortable to surface?

The answer is something ultimately only you can answer and no internet comment can force that deep degree of introspection, only those close to you who have a requisite degree of insight and therapeutic practice can reliably help with that. But the larger point I want to make is that the shape of the conversation around shipping is all around exploring where we feel different mental resistance around shipping at any point in time and uncovering where that resistance truly comes from vs the reasons we make up to dress it up.

Games and software operate from a different set of first principles, games are more akin to movies in that we consume them for the experience and that final level of polish often does make or break it.