The only point from the article I agree with strongly would be putting the keyboard away for a bit and picking up a pencil & some paper and trying out some rough sketches (though I think you can do this just as well at your regular desk)
I think the reasoning is that interfaces are implemented by a dynamic lookup. Part of Go's philosophy is that things that could be expensive (function calls) should be visually distinct from cheap things.
Struct field access is cheap, hopping through a dynamic dispatch table is less cheap.
I can't remember where I picked it up from, but nowadays I try to be mindful of when things are "accidentally" repeated and when they are "necessarily" repeated. Abstractions that encapsulate the latter tend to be a good idea regardless of how many times you've repeated a piece of code in practice.
Exactly, but distinguishing the two that requires an excellent understanding of the problem space, and can’t at all be figured out in the solution space (i.e., by only looking at the code). But less experienced people only look at the code. In theory, a thousand repetitions would be fine if each one encodes an independent bit of information in the problem space.
This all strikes me as very similar to promise pipelining and distributed capabilities from an OCap system like E.
Any code sending an outbound request in reaction to a write is causally related and could be represented as a pipelined promise. The receiving system can then proceed in its work until it needs to "await" the incoming promise and can see whether it was broken due to a failure to persist some earlier write. This could also be handled at the network layer if the receiving system was external.
I'm pretty sure I remember Kenton announcing that Cloudflare Workers now supports something like (or exactly) object capabilities and promise pipelining and his knowledge/interest in such systems is already reflected in Cap'n Proto RPC.
At present output gates operate on the scope of a single worker, blocking the output from being sent. It's easy to imagine, though, that we extend things so if you are sending a message to another worker (including a Durable Object), the message is sent immediately, but the destination worker becomes subject to the same output gate. Haven't done it yet but would definitely like to!
This sounds a lot like letting the monkeys bang away on typewriters while you sit back waiting for Shakespeare...
TFA seems to present reasonable advice. Yet lots of comments here don't seem to agree that "give experts necessary context and trust to build good products" is a decent strategy.
> This sounds a lot like letting the monkeys bang away on typewriters while you sit back waiting for Shakespeare...
Well, humans are primates and I suppose we could draw a parallel between keyboards and typewriters. Although if a dev is trying to write Shakespeare they will get gentle feedback that this is an inappropriate use of their time.
> Yet lots of comments here don't seem to agree that "give experts necessary context and trust to build good products" is a decent strategy.
I expect all the opinions agree that the plan is to give experts necessary context and trust to build good products. There aren't actually that many options here. You have to talk to devs, and then you have to let them dev. The question is how much context can/should be front-loaded and how to deliver feedback.
And those are relatively simple to answer; much as possible and frequently. Beyond that we're relying on monkey-typewriter dynamics.
Tagged templates are really cool. They are a reasonably simple extension of template strings, which allow constructing strings very easily by allowing arbitrary code to be put inside a ${} block inside of template strings (ones that begin and end with backticks ` instead of single or double quotes).
So if you think about it template strings are like a tagged template who's function just calls .toString() and concatenates each argument it is given. There are some really nice safe sql libraries that use this for constructing queries. They are useful basically anywhere you might want string interpolation and a bit of type safety, or special handling of different types.
Lit Element is also a very clever usage of tagged templates.
I just wish they had something like pythons triple quotes or here docs or c++ r strings. A single backtick makes it hard to use backticks inside the string
I especially like recent perls' support for <<~ as a << that strips indentation so you can keep your HERE doc contents indented along with the rest of the code.
(and everybody with a HERE doc implementation that doesn't have that yet should absolutely implement it, people who can't stand perl deserve access to that feature too ;)
> I don't know why the job postings make the backlog the focus of what they're looking for. I can only imagine that hiring managers and recruiters have a very poor understanding of product management, reducing it to the mere management of open issues in the backlog.
It's not just hiring managers and recruiters. A large number of senior leaders in organizations have a very poor understanding of product management as far as I can tell.
Feature factories are much easier to implement/understand and fit more neatly into traditional structures.
Maybe you're right. If so, I've only ever worked for companies with leadership that sucked at communicating.
I don't think it's that simple though. My personal belief is that leadership rarely has a good reason for obtuse decisions and following the leader seems more likely. Even if the first company has a good reason that makes sense for them, I'm not convinced the same (or any) reasoning applies to all the followers.
I also believe that the majority of the leadership at companies I've worked for are poor downwards communicators :)
