davnicwil

This is exactly what makes estimates categorically unreliable. The ones that aren't accurate will surprise you and mess things up.

In that sense, it does compress to being binary. To have a whole organisation work on the premise that estimates are reliable, they all have to be, at least within some pretty tight error bound (a small number of inaccuracies can be absorbed, but at some point the premise becomes de facto negated by inaccuracies).

The reluctance to accept the reality that it cannot be made true achieves nothing positive for anybody. Rather it results in energy being lost to heat that could otherwise be used for productive work.

This isn't about respect between functions, this isn't about what ought to be professionally acceptable in the hypothetical. It's about accepting and working downstream of a situation based in objective truth.

Believe me, I wish it were true that software estimates could be made reliable. Everyone does. It would make everything involved in making and selling software easier. But, unfortunately, it's not easy. That's why so few organisations succeed at it.

I don't present easy answers to the tensions that arise from working downstream of this reality. Yes, it's easier to make deals contingent on firm delivery dates when selling. Yes, it's easier to plan marketing to concrete launch dates. Yes, it's easier to plan ahead when you have reliable timeframes for how long things take.

But, again unfortunately that is simply not the reality we live in. It is not easy. Flexibility, forward planning and working to where the puck is going to be, and accepting redundancy, lost work, or whatever if it never arrives there is part of it.

That I think is what people in different functions are best served rallying and collaborating around. One team, who build, market and sell software with the understanding that reliable estimates are not possible. There simply is no other way.

The details are what stops it from working in every form it's been tried.

You cannot escape the details. You must engage with them and solve them directly, meticulously. It's messy, it's extremely complicated and it's just plain hard.

There is no level of abstraction that saves you from this, because the last level is simply things happening in the world in the way you want them to, and it's really really complicated to engineer that to happen.

I think this is evident by looking at the extreme case. There are plenty of companies with software engineers who truly can turn instructions articulated in plain language into software. But you see lots of these not being successful for the simple reason that those providing the instructions are not sufficiently engaged with the detail, or have the detail wrong. Conversely, for the most successful companies the opposite is true.

my blog with a few posts that have been on HN front page (eg [0]), but under my old domain davnicwil.com which unfortunately was poached after I accidentally let it lapse. Doh.

[0] https://news.ycombinator.com/item?id=21934358

Also, by the way, my perspective isn't about nuclear Vs X (wind turbines etc) - I like all the ones that are net clean and useful in different circumstances as part of a mix.

I'm just addressing the narrower point about whether nuclear per se is a net benefit for society, which I believe it is, massively.

We understand very well how to safely handle nuclear waste and make it a very (very) low risk downside.

There's bluntly not strong external evidence that software quality is a driving priority at Apple in recent years, so it most probably follows that concerns about maintainability aren't either.

I mean from the off, people were claiming 10x probably mostly because it's a nice round number, but those claims quickly fell out of the mainstream as people realised it's just not that big a multiplier in practice in the real world.

I don't think we're seeing this in the market, anywhere. Something like 1 engineer doing the job of 20, what you're talking about is basically whole departments at mid sized companies compressing to one person. Think about that, that has implications for all the additional management staff on top of the 20 engineers too.

It'd either be a complete restructure and rethink of the way software orgs work, or we'd be seeing just incredible, crazy deltas in output of software companies this year of the type that couldn't be ignored, they'd be impossible to not notice.

This is just plainly not happening. Look, if it happens, it happens, 26, 27, 28 or 38. It'll be a cool and interesting new world if it does. But it's just... not happened or happening in 25.

Yeah, it's funny, I'm often arguing in the corner of being verbose in the name of plain-ness and greater simplicity.

I realise it's subjective, but this is one of the rare cases where I think the opposite is true, and using the 'magic' thing that shortcuts language primitives in a sort-of DSL is actually the better choice.

It's dumb, it's one or two lines, it says what it does, there's almost zero diversion. Sure you can do it by other means but I think the (what I will claim is) 'truly' inline style code of Mockito is actually a material value add in readability & grokability if you're just trying to debug a failing test you haven't seen in ages, which is basically the usecase I have in mind whenever writing test code.

I'm not sure if people would subject themselves to this, but perhaps the market will just serve it to us as it currently does with internet and services sometimes going down :-)

I know for me when this happens, and also when I sometimes do a bit of offline coding in various situations, it feels good to exercise that skill of just writing code from scratch (erm, well, with intellisense) and kind of re-assert that I can do it now we're in tab-autocomplete land most of the time.

But I guess opting into such a scheme would be one-to-one with the type of self determined discipline required to learn anything in the first place anyway, so I could see it happening for those with at least equal motivation to learn X as exist today.

It is an incredible accelerant in top-down 'theory driven' learning, which is objectively good, I think we can all agree. Like, it's a better world having that than not having it. But at the same time there's a tension between that and the sort of bottom-up practice-driven learning that's pretty inarguably required for mastery.

Perhaps the answer is as mundane as one must simply do both, and failing to do both will just result in... failure to learn properly. Kind of as it is today except today there's often no truly accessible / convenient top-down option at all therefore it's not a question anyone thinks about.

Instead your mocks are all just inline in the test code: ephemeral, basically declarative therefore readily readable & grokable without too much diversion, and easily changed.

A really good usecase for Java's 'Reflection' feature.

I'm talking, I pull up the camera and try to take literally 4-5 shots quickly and by the 6th there's what feels like seconds of lag between the button press and the photo being taken.

It feels like I'm using an ancient camera phone, or a more modern phone but in extreme heat when the CPU is just throttling everything. But instead, this is a 2 year old iPhone at room temperature.

In another comment I used the example of rails as a kind of canonical 'framework' that can potentially do everything for you full stack, and django is in the same category, juxtaposed against something like React that cannot.

To that, I think your last paragraph is the one I agree with most closely. It's true, but only for the view part of the app, right? I think that's where I get stuck on stretching to calling it a framework.

I guess I can see it if you're defining your view/client as a separate logical entity from the rest of the stack. Which is totally reasonable. But I guess just not how I think about it.

I think you can probably see that distinction already, but to spell it out React is described as a library precisely because it does just one thing - the view - and leaves it to you to figure out the entirety of the rest of the stack / structure of your app.

Framework, at least to me, but I also believe commonly, means something that lets you build a full application end to end using it.

You can't do that with React unless your app is just something that lives in the browser either in-memory or with some localstorage backing or something. If that's your app, then probably I'd agree React is your framework per se, but that's hardly ever the case.

By the way, back to my original point, I still do think these things are impossible to define and in lots of ways these terms don't matter - if it's a framework for you, it's a framework - but I just had to defend my position since you described it as absurd :-)

The later stuff adds other ways of doing the same thing but a library it remains.

That's as self described by the React team, and I think the consensus more broadly.

For example I mostly agree with your calls/called definition but you also get self-described libraries like React giving you defined structure and hooks that call your code.

[0] https://youtu.be/sPdvyR7bLqI?si=2kIpHtNuJ52jEdmm

For my part, I'd just always assumed the charge would be ultimately converted by my bank in any case. Seems obvious now I look back, but I honestly just didn't think about the trick.

Just as an example that gives evidence for this, sometimes you'll go to the same place multiple times and the norm is they ask but occasionally someone won't. So it's not a policy.

I presume the people who don't just don't know about it, don't want to bother me and aren't aware it will make a difference.

Interesting point on the word augment. I'd always took it to mean something more like a value-neutral addition, to which one is free to apply their own value judgements, which could be positive or negative and in any case aren't objective.

To take an example of the kind of thing I'm thinking of: you're out on a peaceful countryside walk yet are able to receive emails. The experience is augmented by this-- in my interpretation meaning you have something literally added to it. But the effect of this can be both positive or negative, to any degree, depending on the email itself and any number of other factors.

Anyway I think we're mostly just getting into semantics and I probably agree actually with your original point :-)

Technology is augmenting real world experiences all the time, and not always in positive ways.

Whenever anyone does anything with the real world as the destination, the phone comes too, and all that comes with the phone intersects with whatever it is you're doing. Again not always in positive ways.

I completely agree that the nature of the technology / platform doesn't matter or affect this.

One thing I love about coding on public transport is the sense of urgency can be fun.

Being on the verge of figuring out a bugfix or whatever when you know train is pulling into the station and you have maybe a minute to go, cracking it, quick test, bundle the laptop quickly back into your bag as you step off the train is quite a nice feeling.

It doesn't mean absolutely everyone takes part, of course, but it does mean it's a 'thing' that people may take part in with support from many of those around them if they choose.

Looking at the inverse: If you're going against the cultural wind, you're just going to have a much harder time doing whatever it is.

It just seems like this must show up in outcomes, it would be strange if it didn't.

I think what we're getting here is a way to just spin up a local shell / app and run arbitrary queries from any point in time over the network without having to sync the full prod database. I guess with LiteFS you would have to do this, or pre-plan to do this, it's not totally on-demand.

Or said another way, do things locally as though in prod without having to ssh to prod and do it there (if you even can, I guess if 'prod' is just s3 you can't really do this anyway so it's an entirely new capability).

@benbjohnson is this right? I humbly suggest adding a tl;dr of the main takeaway up top of the post to clarify. Love your work on litestream, thanks for what you do!