I haven't tried it, but someone at work suggested using voice input for this because it's so much easier to add details and constraints. I can certainly believe it, but I hate voice interfaces, especially if I'm in an open space setting.
You don't even have to be as organised as in the example, LLMs are pretty good at making something out of ramblings.
I agree it's best if working in isolation, but if you need to synchronise then estimations make sense.
If you need 3 months to implement something, and another team 1 week, and both need to be ready at the same time; then if you actually know those estimations the second team can wait until then and do something immediately useful in between.
Yes, then you must have a rough estimate for that. Or in the other extreme example - in the case of an outage, estimates must be much more precise (i.e. "we should have a workaround in ~30 minutes").
But neither case requires too much thought or discussion. My point was more that estimation ends up overwhelming time and energy, when you can just do the thing instead. I've worked on teams where we've spent more time arguing about how complex a task than it would've been for someone to crank out a solution.
I also don't mean engineers shouldn't collaborate, just that it should be more ad-hoc and not manager/tpm/scrum-master driven.
> you break it up into a small investigation story for this sprint, then decide for the next sprint whether it's worth doing
That's just too slow for business in my experience though. Rightly or wrongly, they want it now, not in a couple of sprints.
So what we do is we put both the investigation and the implementation in the same sprint, use the top of the range for the implementation, and re-evaluate things mid-sprint once the investigation is done.
Of course this messes up predictability and agile people don't like it, but they don't have better ideas either on how to handle it.
Not sure if we're not enough agile or too agile for scrum.
That's definitely one way of doing it! And totally valid.
I think it often depends a lot on who the stakeholders are and what their priorities are. If the particular feature is urgent then of course what you describe is common. But when the priority is to maximize the number of features you're delivering, I've found that the client often prefers to do the bounded investigation and then work on another feature that is better understood within the same sprint, then revisit the investigation results at the next meeting.
But yes -- nothing prevents you from making mid-sprint reevaluations.
Not at all, it has one of the lowest rate in Europe along with the UK. It's very hard to get the building permit required to install one.
Portable AC has had a boom those past few years though (because it doesn't require a permit).
Anecdotally, my gym had a "challenge" some times back where the goal was to achieve the max total volume in one set without pause.
I tried various combos of weight* reps, and in the end the optimum was somewhere in the middle because no matter how light the weight there was a limit for me at about ~150 reps.
In my case, the curve would be: total volume increases quickly initially at you go from max weight/1 rep to something like 20/30 reps, then something of a plateau as things equalise, then it goes down again as you reach the max reps threshold.
Right, although I would argue the most interesting part of the type here is the container, not the containee.
With good naming it should be pretty obvious it's a Foo, and then either you know the type by heart, or will need to look up the definition anyway.
With standard containers, you can have the assumption that everyone knows the type, at least high level. So knowing whether it's a list, a vector, a stack, a map or a multimap, ... is pretty useful and avoid a lookup.
I think the argument is that if you take the airline industry as whole (so not just airlines, but aircraft manufacturers, travel agencies, airports, all the concessions there, ...) it's still very profitable.
And if you add the value to the customers, then it's through the roof.
Maybe the reverse is more clear: if air travel didn't exist, it would have a huge economic impact; a clear proof of the value creation. Airlines just happen to capture essentially 0% of it.
That's a false dichotomy. If airlines didn't exist, we would have found some other way to move things. Maybe trains, which would have been the better future by far.
What timeline are you in that we skipped trains and went to airplanes instead? We went to planes because trains were slow, and have a problem going across large bodies of water.
The reasonably best examples of commuter trains are far superior to those of commuter airplanes as long as we are not talking about travel over or around significant bodies of water or long distances.
Trains carry much more weight, are more fuel efficient, are safer, generally experience fewer delays and cancelations, and door-to-door are faster for shorter trips (<450 miles).
Safety: since 1964, the Shinkansen has carried over 10 billion passengers without a single passenger fatality from a crash or derailment.
Speed: for trips < 450 miles, trains win because of security, ATC, taxiing, etc.
The majority of travel is not over water. It may be that trains' other advantages are preferable even for longer trips where a train would be slower.
It might not be as reliable in other places to do it every day, even just in summer. Still, there's clearly a trend globally towards more dynamic prices.
A bit off topic, but there seems to be quite a few SQLite experts here.
We're having troubles with memory usage when using SQLite in-memory DBs with "a lot" of inserts and deletes. Like maybe inserting up to a 100k rows in 5 minutes, deleting them all after 5 minutes, and doing this for days on end. We see memory usage slowly creeping up over hours/days when doing that.
Any settings that would help with that? It's particularly bad on macOS, we've had instances where we reached 1GB of memory usage according to Activity Monitor after a week or so.
sounds like normal behavior of adjusting buffers to better fit the usecase, not sure if it applies to sqlite or if sqlite even implements dynamic buffers.
Grit, or willpower, or whatever you want to name it isn't a unique, constant value. There are plenty of athletes who could spent hours training every day but are overcome by addictions. People who grind at work but cannot fill paperwork to save their life. That will diligently do something for months then stops after an unexpected interruption.
There's probably generally a bit of correlation. But just because someone can be very focused and go to extreme lengths in one aspect of their life doesn't mean they can consistently do it in every aspect of their life.
You don't even have to be as organised as in the example, LLMs are pretty good at making something out of ramblings.
reply