pm

Working on a freelance job 3 years ago, I got sucked down a rabbit-hole for months trying to get Azure Durable Functions to work. Too many bugs, no visibility into its workings and the worker would always grind to a halt. That job did not go well.

Avoid ADF (let alone Azure) until you've got some innovation tokens to spend, or go with another provider.

A couple of months ago I tried to generate a Swift SDK using Cloudflare's OpenAPI spec with Apple's Swift OpenAPI generator, to no avail. Apple's generator is quite strict from what I can tell, so I'm curious about the differences between Stainless' and Apple's work.

(I haven't tried it since then, so it may work now).

i was hanging around the Gong around then; I'm in Rads and was attempting to make a game with some friends from there at the time.

Those were some fun times.

The 0.1x is the 10x developer. Slow is smooth and smooth is fast.

Xcode and Android Studio have plenty of warts. What is it about Android Studio's experience that you find lacking in Xcode?

Svelte and SvelteKit have earnt a place in my heart. They've allowed me to enjoy learning reactive- and component-based development. In comparison, React has always felt like a chore, and I avoid it as much as possible, despite it being the most popular framework.

(Side note: I rate Vue as well, though I prefer SvelteKit over it these days)

Rich Harris and the Svelte family have always been pragmatically minded, and there's value in expounding one's development philosophy, but I've gained no insights with this list. Perhaps it's the language used, rather than the tenets themselves.

Consumers find it easy to justify a hardware purchase: it's tangible, and save for requiring an electrical outlet (which is ubiquitous in our society), runs anywhere. Software is, in some regards, intangible, and is constrained to certain platforms. It makes it easier to dismiss, even though it's no less work to make great software.

The characterisation is off (stumbling vs. nimble), but the metaphor is apt. Adapt or die.

Thanks for that, I'll add that to my vocabulary.

The CEO and co-founder, Karri Saarinen, is a designer, and was desigining it in the early days. I don't know about now, but the attention to detail is still there.

I honestly made it up on the spot, so don't take it as proper nomenclature. However, to describe it another way: the unconscious mind synthesises its emotional choice, which the conscious mind presents as rational fact. If you want to know how the mind arrived at that conclusion, you've got to go on a fact-finding mission, i.e., asking why.

However, asking that question without triggering a negative response is an art form within itself. Rarely can you be so direct, which is why it's often much easier to watch how a person interacts with a product rather than asking them why they did what they did.

Absolutely.

95% of the suggestions product creators receive are solutions. A product creator's job is to work out what problem their customer is trying to solve. It goes to the same motivation as root cause analysis when analysing an outage: the actual problem is nestled deep under layers of semantic shielding.

Whether your product is trying to solve that problem is another question, but at least you can understand how others perceive and try to use your product, which goes a long way to getting a product to be more broadly adopted.

I'm sure he did more than just one game, but the revenue wasn't enough and he had a family to feed. We connected on GarageGames back in the day, which saw some reasonable success. I think it's easier these days to make a living as an indie game developer, but it's still very much a hit-driven business.

I had the pleasure of working with Jay doing the character illustrations on his indie space shooter, a couple of years before I started coding professionally. This was the article that always stayed with me, especially at times when progress was difficult (which became especially poignant 18 months ago with my ADHD diagnosis).

These days he works for a VR company, but his main creative activity has been writing sci-fi/fantasy/horror novels for some years now, and he has his own series.

PS. I was going to say this article was from way further back than 2014, but on reading the post it appears it was his own repost.

Sydney was always expensive, but there was a reason for it; now everyone has caught up thanks to the economic climate, and it's just because they think they can get away with it.

I've lived in Adelaide my entire life, and it's impossible to find reasonably priced accommodation currently, and I'm saying that as a working class software engineer. You might not feel the pain, but there's an entire corpus of people besides you who do.

Which excellent ideas does it have that other languages can't replicate?

I've seen Shpong referenced in couple of articles that made it to the HN front page. There were some interesting ideas there; keen to see how it goes.

Glad to see this here! I've been looking forward to being able to participate on something concrete.

There are plenty of reasons why something you think should take a day might take a week. We often (fallaciously) assess a problem as "easy" without considering the context in which it has to be incorporated, i.e. the codebase. The duration is moreoften a function of the complexity of the codebase, rather than the complexity of the isolated problem.

As someone who's not familiar enough with LLMs to deduce why this is amazing or scary, would you kindly explain as to why this is so?

The time dimension is often forgotten when applying these maxims. When we see code, we often fail to consider the the journey it's taken to arrive at that point in time, and where it might be headed in future.

In the example you set, it's the right time to apply an abstraction, so it's no longer premature. Perhaps the maxim should be labelled as "premature abstraction", rather than "premature optimisation".

As you rightly point out, creators don't operate in total isolation: you're constantly taking in the world around you, even in solitude. However, as you've surmised at the end of your comment, there's a difference between sparking an idea and following through on its creation (though they often work in concert).

Absolutely: ideas reinforce if you're around them long enough. I don't think it was Facebook's intention for echo chambers to occur, but it was too profitable for them to stop it once it had.

You can always charge an hourly rate for that duration of work whenever it comes up.

I'll rephrase: they're not paying you to mindlessly churn out lines of code. The end product matters. But the bulk of that time is spent thinking, whether you realise it or not, and frankly that's a much more useful perspective for the OP to take, as they're trying to reconcile their comfort with charging for time in meetings and lunch, because they think they're not being "productive".

Do yourself a favour, and bill by the day, rather than by the hour. Engineering is creative work, and you're paid to think - code is just the end product. Thinking happens consciously and unconsciously, at all times of the day. Billing by the day will allow you to focus on the work rather than the administrivia.

Whatever you do, do not drop your rate: you'll just be undervalued by your clients.

So far I've been using Earthly for structuring builds, and it's been brilliant for the most part. Dagger was interesting but a no-go without Python, so curious to see how it stacks up.

I would love to see this implemented purely for curiosity's sake, even if it's architecture-specific.

Personally, cosmo is one of those projects that inspires me to crack out C again, even though I was never understood the CPU's inner workings very well, and your work in general speaks to the pure joy that programming can be as an act of creation.

Thanks for all your contributions to the community, and thanks for being you!

ClickUp is a confusing mess. It tries to be the centre of your universe without doing anything particularly well. It copies features verbatim from other software and then slams it in as a new "view". The coding doesn't seem to be up to scratch either, e.g., updating a value won't always update it everywhere it's displayed. It's very hit-and-miss.

I had a look at Asana again for non-software project management after dismissing it 8 years ago when trying to use it, and was pleasantly surprised: it's much more opinionated than it used to be, a lot slicker, and it integrates with everything I use.

I also use Linear for software development, and won't ever look back.

Indeed, it's on my list of things to read, and it's why I'm not considering these signals to be definitive.