I like iroh’s simplicity from the user-facing marketing angle: it provides you a primitive, dial by public key instead of IP, and everything else is built on top of that or serves it in some way. Networking is not my area, so when I read about most networking/p2p projects, I’m suitably impressed but don’t walk away with a good understanding of what they really do or how I would use them. But iroh is simple enough that I can understand what problems it solves and how I could use it.
I’m not sure if this is how they got there, but the style of engineering I’ve been gravitating towards for years is starting from the intended user interface and working backwards. It consistently results in the strongest APIs, the cleanest abstractions, and the most intuitive tools I’ve found of any other ‘paradigm’.
I agree, but it’s also really easy to derive this guidance from a question: is your product the code or the tool? Too often it’s easy to get lost in the weeds on the code and forget about the actual product. And a corollary is adding too many features or making things more generic than they need to be in the product. The tighter the constraints are, the better the code will be in general.
But in the end it’s just guidance, not a rule. There will be trade-offs to make for when early generalization is a good thing too.
That backwards thinking applies to both? When you’re building some product you’re necessarily making decisions and performing work on behalf of your users, so it still makes sense to think about what they’re going to be doing and interacting with and how from the outset.
To a degree, they’re the same thing. If you’re making an API or library, your product is the code and your users are other developers. They’re not really substantially different, it’s all about knowing your audience.
No idea about the cleanest internals, but that’s the biggest difference between “enterprise” software and custom one for me. The first is most often “here’s how we model the data, now let’s put some CRUD lipstick on it”. The second is what people are actually comfortable using in daily flows. (I’m creating small dedicated apps that are essentially usability overlays on enterprisey medical software)
I like iroh’s simplicity from the user-facing marketing angle: it provides you a primitive, dial by public key instead of IP, and everything else is built on top of that or serves it in some way. Networking is not my area, so when I read about most networking/p2p projects, I’m suitably impressed but don’t walk away with a good understanding of what they really do or how I would use them. But iroh is simple enough that I can understand what problems it solves and how I could use it.
score 1 · canonical
I’m not sure if this is how they got there, but the style of engineering I’ve been gravitating towards for years is starting from the intended user interface and working backwards. It consistently results in the strongest APIs, the cleanest abstractions, and the most intuitive tools I’ve found of any other ‘paradigm’.
score 1 · canonical
I agree, but it’s also really easy to derive this guidance from a question: is your product the code or the tool? Too often it’s easy to get lost in the weeds on the code and forget about the actual product. And a corollary is adding too many features or making things more generic than they need to be in the product. The tighter the constraints are, the better the code will be in general.
But in the end it’s just guidance, not a rule. There will be trade-offs to make for when early generalization is a good thing too.
score 1 · canonical
That backwards thinking applies to both? When you’re building some product you’re necessarily making decisions and performing work on behalf of your users, so it still makes sense to think about what they’re going to be doing and interacting with and how from the outset.
To a degree, they’re the same thing. If you’re making an API or library, your product is the code and your users are other developers. They’re not really substantially different, it’s all about knowing your audience.
score 1 · canonical
No idea about the cleanest internals, but that’s the biggest difference between “enterprise” software and custom one for me. The first is most often “here’s how we model the data, now let’s put some CRUD lipstick on it”. The second is what people are actually comfortable using in daily flows. (I’m creating small dedicated apps that are essentially usability overlays on enterprisey medical software)
score 1 · canonical