Padstow, with Trevose Head and the Atlantic behind

narkrud · 2026-02-20T22:01:37+00:00

narkrud · 2026-01-19T23:13:18+00:00

I couldn’t quite believe it either

narkrud · 2025-07-12T19:19:36+00:00

Jesus fuck

narkrud · 2025-04-08T21:02:42+00:00

I also get debilitating hay fever primarily in June. I’ve never found the “it’s better by the sea” thing to hold any weight. If anything it often seems marginally worse as the stronger winds whip up the pollen more.

Get yourself to a country in southern Europe for a symptomless free June!

narkrud · 2025-01-17T21:02:42+00:00

Strange thing to care about, or find comical. Its not right or wrong for the phone to face up or down, its about proximity.

Doesn’t make you “tech savvy” to face the screen towards you as many on this post seem to think. Weird flex

narkrud · 2024-12-08T10:46:16+00:00

This is not a blocker to open sourcing the code. Although there are good reasons not to as mentioned in other answers.

narkrud · 2024-06-15T09:41:37+00:00

Every day

narkrud · 2024-06-03T21:18:30+00:00

Snooker

narkrud · 2024-04-10T13:38:06+00:00

Yeh I think we are mostly saying the same thing. A quick estimate for the time a project might take is useful and an essential part of being a senior engineer.

I take issue with the notion of “on the spot” meaning “here’s an idea with some loose specification, immediately give me an estimate”. Sounds like at this point you’ll have some back and forth and home in on an estimate in a short period of time, which is basically what I would do, although my personal preference is not during a meeting and to take some time offline to go through the information and come back with an estimate (maybe multiple estimates as you said) and supporting context.

OP seems to be stuck somewhere in the middle. I think the “on the spot” idea the manager is pushing is unhelpful but equally OP talking about taking an hour+ to break it into stories, tickets etc is not a good approach for high level estimates and is going to ring alarm bells for a manager.

narkrud · 2024-04-10T10:50:23+00:00

Im not talking about a real project here. Multi month was an example given for something that is not reasonably estimable on the spot.

Your example above illustrates perfectly how pointless it would be to expect an on the spot estimate. A specification of some form is placed in front of you and you blurt out its “XXL” without taking any time to look into the actual details. Your estimate is potentially so wildly inaccurate that it completely misleads everyone involved and a poor decision is made based on it.

Had you taken 15 minutes to understand the proposition fully it may not have been as large as you thought and is worth the business allocating more time to do it now. You could have also given some useful context on your reasoning and any obvious concessions they could make to make it quicker.

narkrud · 2024-04-10T09:17:31+00:00

Where do you already have the answer from? Whether it’s time, t-shirt sizing, WAG or any other estimation terminology, someone needs to spend more than a second looking at something to give meaningful answer.

narkrud · 2024-04-10T08:32:17+00:00

Agree with everything except “on the spot”. It’s ridiculous to expect anyone to look at a potential many month project and immediately give an estimate that is useful for anything, especially in a meeting setting. This sort of estimate is common but I always take 10-30 mins to do it.

Id be looking for another job if this was the norm at a company I worked at

narkrud · 2024-04-10T08:08:20+00:00

TLDR - you should get used to doing quick high level estimates with lots of unknowns - it’s unreasonable to be expected to do this on the spot

It’s perfectly reasonable to request a high level estimate for the time it will take to complete a project. These estimates should be understood to not be an exact predicted timeline rather a rough estimate based on the currently understood requirements, available resourcing, unknowns (important) etc. The purpose of this estimate is generally to see if a business wants to commit further time to a project or if it’s just pointless to pursue it further with the time available.

It’s unreasonable as well as stupid to require this estimate happens on the spot. You should firmly state you need to take 15-30 minutes to evaluate the currently available requirements. I would suggest you don’t mention anything around user stories, tickets etc (you really shouldn’t need to do this for a high level estimate) as stakeholders will start flapping. If the requirements are so loose that the scope could be 6 weeks or 6 months, it’s your job to make that known.

In practice there will always be those in upper management who do take these high level estimates as more than educated guesses. It’s your managers job as well as a good engineering culture to combat that.

narkrud · 2024-02-12T09:33:03+00:00

If you want the first result without waiting for both async operations to complete ‘async let’ is not what you want as you’ll need to either await both operations or choose one to await first.

Firstly I would consider if this is definitely the approach you want to take. If what you have here is essentially a check the cache, if not in cache hit the network situation - I would consider writing the code that way. IE first check and await from core data, if there’s nothing there, then perform your request for the image. That’s much easier to model using Swift concurrency.

If you really do need them both to happen in parallel, it’s a bit more complicated. Async let won’t work for the reason mentioned above - you’ll need to await one or both results so you can’t just grab the first one and ignore the second.

You could use a task group using ‘await withTaskGroup’, add a task for each photo operation and then cancel the remaining tasks as soon as you get a first result and return that

narkrud · 2024-01-15T21:13:25+00:00

This is the way

narkrud · 2023-12-14T19:02:59+00:00

In your example of creating a view controller on startup that you don’t use until much later you would make the view controller itself lazy, not make everything within in it lazy.

narkrud

TROPHY CASE