richie5um

Thank you for sharing. As a T1 diabetic too, I was reading this nodding my head all the way through.

“Most diabetics have CGMs these days” - not where I come from :-(

Agree. They came out of the gates with a really well put together chat app, that made a massive impact. Then, basically, didn’t advance it beyond that. It is still great for chat, but Teams is sooo much more useful for the virtual office, and discord waaay better for social. Slack is in an ever decreasing middle zone.

I love the book ‘Back of the Napkin’. He talks about identifying what you are trying to present, and marrying that to the diagram you draw. I’ve used those approaches many times in tech/product descriptions.

I wrote an NPM package to convert JSON objects to/from a dotted format. It doesn't (currently) sort the flattened output, but that would be easy to add.

https://www.npmjs.com/package/flattenjs

Couldn’t agree more. It must have one of the worst usage-to-enjoyment ratios of any site.

100% agree. I realised many years ago that to try to restrict/fix requirements was futile - or, you can try, but to what end. It’s like swimming upstream.

The hard part is that being adaptive to change increases the complexity exponentially with size (of project, of people, etc...).

Therefore the only way out of this formula is to reduce ‘size’, and iterate with (/alongside) the customer (even if that is an internal _customer_).

It is basic math(s).

I think the high-level summary of the article is ‘fire-and-forget development’ - ie producing features, but not measuring impact/benefit/usage.

I’m not convinced ‘feature factory’ in itself is problematic (definition not provided). There is no problem (IMO) in optimising to ship features - as long as the overall approach is to measure impact/benefit/usage and then learn and iterate.

Agree. I much prefer the term ‘product engineer’ to all previous titles. It shouldn’t be a cargo-cult switch where everyone starts calling themselves one, but it is by far the best title as a guiding principle to what we are meant to be doing.

Also, I think we are going to see further evolution in the software industry where the current middle-mgmt layers get wiped out. You are either contributing directly to the product - and you can easily measure that - or, you need to get out of the way.

DevOps is a drive to reduce the number of vertical organisational ‘layers’, ProductEngineering would be a drive to reduce the number of horizontal organisational layers.

IMHO.

Yup.

Business benefit supersedes customer benefit. Always.

This story is similar to mine. I really don't want to have lots of subscriptions, but I use 1Password sooo much, it is a clear winner for my money.

Fair response - my assertions were a bit extreme :-).

You can use process to force change, but, personally, I think a strong manager/leader would aim to resolve these issues irrespective of the process. Also, and I think this is why so many complain about agile, is that it is used to change these types of behaviour and is then seen as ‘the bad _guy_’.

My personal view is that the process should be aligned with your business, not as a tool to fix people challenges.

The 15 min daily catchup is invaluable irrespective of your overall process.

Easier said than done though :).

Happy to talk further and learn from your experiences. Thanks.

That’s a list of poor engineer attributes, which need to be addressed via conversations. Not impose a process in the hope that’ll fix them.

Really liked this article.

I liken software methodologies to cooking recipes.

On one end of the scale you have a highly skilled and experienced chef, who can craft a great (requested) dish with a variety of ingredients and equipment. Knowing how to adapt and what to add and when. This works well, but requires a heavy cost (experience) and is, from the outside, difficult to follow and control.

On the other end of the scale you have fast food. A strict process and fixed ingredients that ‘just works’. Those involved in cooking have very little knowledge of why, and are almost certainly not able to adapt. This works well for scenarios where you exactly know and control both the input and output.

A skilled chef can ‘codify’ their recipes, but this results in a specific description of what to do, and not why. Thus marginalising the adaptability.

In my experience, most software engineers are trying to attain the skilled chef role. While most _managers_ want the fast-food style predictability. With the ‘process’ being the battleground.

The best process is where you - a complete multi-disciplinary team - make as quick iterations as possible, learning as you go. But, always knowing where you are trying to get to (and why!) and constantly adjusting accordingly.

Good luck out there.

I've used Hugo for a few sites now. There is a bit of a hump at the start - finding a theme you like and customising it to your needs. But after that it is fantastic.

Unfortunately I can't get this in the UK. I asked, but they only give out to kids or people who poorly manage their T1. :(

Me too.

Completely. As a T1 I could complain that it is draining, but, hey, it's just the way things are.

¯\_(ツ)_/¯

As a Type1, I wish they'd give them different names - diabetes is too often seen as a 'fat person disease'.

Maybe I shouldn't care, but it is upsetting to have to explain to people all the time. Even more so when they close their ears to the response.

In the U.K. it is very difficult to get a CGM - unless you are young or manage your Type1 very badly.

Even with doing finger prick blood tests 5 times a day, for years, I feel mostly clueless. And rely heavily on how I feel. Given how much time this condition (?) costs healthcare, this seems a poor way to manage it.

I'm desperate to learn more about my body's glucose trends. A watch that could do that would be awesome.

Yep, me too. [Type1]

I agree. I doubt it is as black and white as people have interpreted. I suspect it was more along the lines of "we want to take a different approach to _automation_, are you with us or not?"

Completely. Disappointed is fine, but surprised. Given this seems explicitly designed to avoid the need for AppStore reviews, this was inevitable.

I don't want anyone pushing code updates to the apps that have been reviewed. Whilst that isn't foolproof, compromising the deployment mechanism with this approach is very scary.

I love the speed of Sublime, and still use it sometimes. But, the vast majority of time is in VSCode.

I do - I use it for subscription and one-off licensing. I live in the UK.

I completely agree. What is, for most programming languages / code, a huge waste of time and huge amount of annoyance becomes something you no longer have to deal with.

Having choices can be nice, but it introduces a huge amount of cognitive load. And, really, if we all just use the same format, we'll all (eventually) get used to it.

We really do have better things to deal with than formatting style.

I use Hugo for static blog generation and GitHub pages for hosting. Works well, and, apart from the domain registration, is free.

I moved from the UK, with my wife and two young kids, to the Bay Area in 2012. I'm an experienced dev; mostly hands-on architecture/development, but also leading teams.

Spending time there and experiencing the people and general fast approach to development has definitely help me and my career. It is, mostly, different to the more conservative approach typical used elsewhere. So experiencing the two and being able to use both, when appropriate, is helpful.

After two years we moved back to the UK.

Living and working there was amazing. But, overall it felt like it came at a too huge a cost (financially, work commitment, and commuting).

PS: I do miss being there though. :)

This seems like the oddity of it. The keyboard is poor, but the touchbar is useless if you don't use the keyboard.

The lack of (useful/mainstream) ports seems surely due to the desire to go thinner - looking at the old MacBook Pro, it was as thin as it could go for those port dimensions.

Sigh.

Don't worry about that. It really is that good. [Long-time Mac and Vim user.]