HN user

blakehaswell

154 karma
Posts10
Comments40
View on HN

One thing that might not be obvious about checklists is how they're used.

I used to think checklists were used by reading the item, then doing the thing. I literally thought of them as a recipe that you would follow. Complete a step, check the box, repeat... This is typically referred to as a "read, do" checklist. In aviation this style of checklist is typically reserved for non-normal operations—procedures that you wouldn't use often enough to commit to memory.

The other style of checklist is "do, confirm". In this style you complete a procedure by memory, and read through a checklist to ensure you didn't miss anything (no box ticking, you just read the items and confirm to yourself that they're complete). In aviation this is the style used for normal operations, and for the initial action-items in an emergency (which although not commonly used, must be committed to memory because they are time-critical).

Because you're expecting that the procedure is completed by memory, a "do, confirm" checklist can be extremely brief. You do not need to write in detail what each step involves, you just need a word or two to name the step. Additionally, they're an extremely low operational burden; it takes a couple of seconds to read through a "do, confirm" checklist but the upside of catching common errors is significant.

I feel for everyone working there who is suffering whiplash from being pulled from one direction to the other.

What can you possibly learn about a new feature in a few hours apart from the gut reaction of a mob? If that's enough to change your mind, what evidence was there in the first place that the feature was a good idea? Probably none.

Citation needed. Whether the server is serving HTML or JSON it still needs to serialise the data, so I don't think serialising JSON is going to be significantly faster than serialising HTML. Plus then the client needs to deserialise that JSON before it can render HTML, so all of that work related to (de)serialising JSON is work which doesn't even need to happen if the server is rendering HTML. Not to mention the work on the client to parse and evaluate the JS which needs to happen before it can even start rendering HTML.

As for data across the wire, GZIP is a thing so again I would want to see real world performance numbers to back your claims.

I really enjoyed this, I think looking the organisational structure through time is a good take that I haven't really seen addressed so clearly before.

I would have liked to see an exploration of the "through time" lens on some of the more micro code-organisation structures he talked about at the end like class hierarchies. It's definitely a common problem in legacy code—there's some idea you want to express but the existing structures make that very difficult and so you end up twisting your idea to fit, further ossifying the existing structures.

I've also seen cases where the organisation structure was changed to affect some change, but the existing code structure makes that so difficult that the software doesn't actually change to reflect the new structure at all, and instead the new organisation is just slowed down by coordination costs at the organisational level as well as different coordination costs at a technical level.

did Facebook, Apple, Amazon, Netflix, Google, etc all make a terrible engineering mistake?

Is that so impossible? There are many other considerations that go into technology choices at these companies. There are trade-offs involved, and for companies with huge teams of developers the considerations need to be very different than for small–medium sized groups of developers.

I would argue that a smaller group of developers can focus much more on user experience and engineering efficiency, whereas a large company has a organisational scaling issues and a significant bureaucracy to support. At a large company, engineering considerations come second to very many things. It would actually be surprising if the trade-offs and choices those companies made were correct for other very different companies.

What exactly do you mean by multiple entry points? Do you have multiple processes which run independently but are co-located in the same repository or are you talking about something else?

great speed in iterating new features […] makes our customers happy

For me this is a leap. I can't think of many examples of software which I use where new features have actually made me happy. Normally it's just change which forces me to learn something new while I'm in the middle of trying to accomplish something actually productive.

I think our industry over-estimates the value of "new features". But in my experience 90% of new features provide neutral or negative value. If—instead of a new feature—the software I used released a performance improvement, then that would actually help make me more productive.

Exactly what I did. After reaching top still somewhat technical position at the company I got so fed up and burned out that I quit. Went on my own and been this way ever since for some 20+ years.

I'd love to hear more about your journey. What did going out on your own look like? What type of work do you do? How long did it find you to figure out the kind of work that satisfied you and paid the bills?

At the end of the day our software is going to run on real machines, sending data across real networks. I feel like we'll always be leaving performance on the table if we don't understand the characteristics of the hardware we're developing on.

I can build a cubby house in the backyard (low performance system) without understanding the the physical characteristics on the materials I'm using, but if I want to build a sky-scraper (high performance system) I need to understand the actual physical materials and how to use them effectively.

C++ provides programmer control over memory layout, which is something managed languages don't provide. So although C++ is an older language and it isn't designed for modern machines, it does allow you the control to make performant programs for modern machines.

HN was down 5 years ago

Me too. I was trying to browse HN on my phone earlier and my first instinct was that my WiFi was having a moment. It's a testament to how reliable HN is.

I was thinking "modern C++" is potentially a good fit for avoiding most of these complaints (i.e. if you solely use smart pointers). Given their other post about technology choices[0] I'd guess it's a safe assumption.

That said, I don't think any language is without trade-offs. As the author says:

Hint: if you can't find something stunningly wrong with your "chosen one" language, you probably haven't been using it long enough...

[0] http://rachelbythebay.com/w/2020/09/24/feedback/

If you actually don't need it (i. e., your hot methods are never overridden), then the JIT will trivially compile those "virtual" method calls as non-virtual ones.

But isn't that the thrust of this article? Of course the JIT can optimise a monomorphic call-site. The question is, in reality, what percentage of the time will it be optimised for your users?

Code Budgets 6 years ago

I agree. I don’t think lines of code is necessarily the right thing to budget, especially if you limit it to “lines of code written by our team”.

But there is something interesting in this idea. Our software is growing immeasurably complex. We’re piling on more and more layers of abstraction. Ostensibly the goal is to make our lives easier. But in reality we’ve got companies throwing hundreds or thousands of developers at the problem of building a wiki or a social network, and they end up building these Rube Goldberg machines where 99% of the effort is spent on things other than the actual problem users want the software to solve.

Moore’s law has been totally offset by Wirth’s law[0], and as an industry I don’t see us doing anything about it. Even if lines of code is the wrong constraint, we could do with learning how to do more with less.

[0] https://en.wikipedia.org/wiki/Wirth%27s_law

My concern with this is that it gives the "rain skeptics" a platform to spread their views, and presents "rain skeptics" as a legitimate alternative to the "rain scientists". The problem with this is that once people are given a platform and presented as legitimate, then they can convince people not based on the logic of their arguments but on things which have nothing to do with the matter under debate (e.g. "I like the way he speaks, not like that snooty scientist").

I think people I know have been convinced in this manner. I don't think people necessarily reflect on why they were convinced. They just know that they agree with the "rain skeptics".

I'm not convinced that giving "rain skeptics" a platform would be the right thing to do if they only make up a small percentage of the population. If they make up half the population, I have no idea.

EDIT: My experience above is probably not helped by weak moderation in debates. Moderators with a backbone would probably help in cases where "rain skeptics" are given a platform. Sadly that seems to be rare.

If Not SPAs, What? 6 years ago

I'm not sure that's such a huge problem. HTTP routing provides a wonderful architectural seam so that we can use different solutions for different domains like `/profile` and `/document-editor`. We can create rich client-side experiences without creating a monolithic SPA. And as long as we make sure we have those architectural seams we have the flexibility to decide.

New JSX Transform 6 years ago

to write off GraphQL or React as "cancerous" on account of someone having made a less than optimal decision in how to use them seems premature.

Apologies, cancerous isn't how I'd describe it, but the sentiment of the quote did resonate. "Tightly coupled" is more representative of my concern.

Thanks for the counter-example!

New JSX Transform 6 years ago

From a purist perspective, this has a "cancerous" feel (as opposed to being "encapsulated")

I have the same feeling about much of the React ecosystem (edit: though I'd say "tightly coupled" rather than "cancerous"). The other day some folks were discussing the idea of building a new UI backed by a new GraphQL schema. We started talking about the possibility of delivering the UI independently of the GraphQL schema by using an existing REST API, and the idea was shot down as the GraphQL client we're using on the frontend is highly coupled to the UI components. Changing the data source later would have been a highly intrusive change.

I totally understand the benefits that a GraphQL client provides, but it feels like a serious architectural smell that changing the data layer is such a wide-ranging change in a web app. Wrapping a data-source in an API and being able to change the implementation without the rest of the application being impacted is really compelling, and I'm not convinced it's something worth trading-off.

The Shapes of Code 6 years ago

How much longer will this rumor persist that "good code" doesn't need commenting?

Indeed. I recently came across an article[0] which does a good job of debunking this idea, and describing different types of comments and when they can be valuable. Have a read if you're skeptical about comments.

[0] http://antirez.com/news/124

I’ve been playing with microcontrollers for the last few weeks, where debugging typically involves reading data sheets more often than Googling, and I could definitely see myself integrating this type of workflow into my day job.

  it's a lot of risk
What’s a lot of risk? Saving a significant portion of your income? Sounds less risky than “work until I’m 70 and then hope I have a good pension.”
  I think at the level of complexity of current day products, the "think for
  the first 75% of the time" is flat out impossible.
Maybe, but from my experience we don’t do enough up-front thinking. Indeed, if our products are more complex these days then shouldn’t we be doing more thinking? If our products are more complex then diving straight into code is one of the worst decisions we could make. No wonder we end up with tangled balls of yarn.
  In the electronic and bureaucratic control systems, changing state is the
  point of the program. The thinking revolves around state, when it should be
  updated, and what it should be updated to. Stuffing this all behind a monad
  results in unnatural-feeling programs.
Changing state is the point of almost any long-running user-facing application. And you are correct, thinking about when state should be updated and what it should be updated to is very important. So important in-fact, that allowing state updates to occur anywere in the program, with no rhyme nor reason, dramatically reduces an engineer’s ability to understand that program.

It may feel natural, or familiar, or easy to change state wherever it is convenient to do so. But that doesn’t make it a good engineering decision. As I mentioned in another comment it introduces complexity around logical reasoning, future change, code re-use, and testing.

It is much simpler if you define your application’s state in one place, and in terms of the actions that can be performed to update the state. This is simple, and easy to reason about. Then the functions to update the state can be pure. Again, this is simple, and easy to reason about.