chrismdp

It is nothing new - and that makes it predictable and scary.

The final puzzle piece

...to what? That's what I'm worried about!

100%. You can't and shouldn't wrap every interaction. We need a new approach.

I think the building blocks of the most impressive experiences will come from choosing the exact right point to involve an LLM, the orchestration of the component pieces, and the user experience.

That's certainly what I found in games. The games which felt magic to play were never the ones with the best hand rolled engine.

The tools aren't there yet to ignore prompts, and you'll always need to drop down to raw prompting sometimes. I'm looking forward to a future where wrangling prompts is only needed for 1% of my system.

It's always true that you need to drop down a level of abstraction in order to extract the ultimate performance. (eg I wrote a decent-sized game + engine entirely in C about 10 years ago and played with SIMD vectors to optimise the render loop)

However, I think the vast majority of use cases will not require this level of control, and we will abandon prompts once the tools improve.

Langchain and DSPY are also not there for me either - I think the whole idea of prompting + evals needs a rethink.

(full disclaimer: I'm working on such a tool right now!)

For UK people there's Lollipop: https://lollipopai.com (full disclaimer: I'm a co-founder :)

It's integrated with Sainsbury's with one-click basket transfer, an option to remove items you already have, and a recipe uploader for your favourites. Early days so feedback really welcome.

Happy to answer any questions people have!

Lollipop | On-site/Hybrid, London, UK | Fullstack Devs, Product Designers | https://lollipopai.com

Lollipop is making the mundane magical. We are cooking up the fastest and most enjoyable online grocery shopping and cooking experience in the world, helping busy families and those overwhelmed by the pressures of daily life.

We building a product that doesn't just look after everyone but our planet too. Helping to reduce the £10 billion of food waste thrown away every year is a huge priority for us.

Our diverse founding team of 17 have built businesses such as Monzo, Amazon, Curve and our backers have scaled companies like Ocado, Innocent, Babylon and Deliveroo. We know what it takes to build products enjoyed by millions of people across the world.

You'll work in a small tight-knit semi-autonomous cross-functional product squad, iterating useful, usable, and delightful experiences on web and mobile.

Our tech: * Hotwire (Stimulus/Turbo), Rails, PostgreSQL, Flutter for mobile

* Senior Fullstack Dev: https://apply.workable.com/lollipopai/j/C665DE0B03/

* Senior Product Designer: https://apply.workable.com/lollipopai/j/A0F5518C53/

I should have put this quote at the top of the article! :)

So, so true. I wish I'd learnt that earlier.

This one is particularly embarrassing for me :) -- anyone got similar tales of woe?

Anyone else got it and read it yet?

Postscript: The idea was to put to bed some of the endless Scrum vs Kanban debate. Processes have to be adapted for use: hardly anyone says this, because people get paid to say the opposite.

Nice list.

It's painful, isn't it. I think about it again from time to time, and it reminds me to take my time as you do...

It's been renamed to whereby.com and they've iterated their offering quite a bit.

No more ad-hoc channels - I now use talky.io for this.

How many teams are _actually_ running real retrospectives I wonder?

Gower Street | REMOTE (UK-based) | Full-time | Developers/Data Scientists

Gower Street Analytics is a startup in the movie business, using Clojure to do data science.

We mostly code in Clojure, ClojureScript and Python. We use Postgres and CSVs in S3 for persistence, and host services with Docker, Terraform and AWS.

We’re growing the team carefully and interested in meeting developers and data scientists at all levels of experience. We’re committed to being an equal opportunities employer and are actively looking to increase diversity.

See more and apply at: https://gower.st/blog/2018/working-at-gower-st/

Yeah, thanks for linking to this: the reason I didn't use it was mostly because it was longer than 18 lines :) Nice not to have to track and maintain a version of other people's code when you don't have to.

I'll fix it when my game requires update files of >5GB :)

Exactly my thinking. Nice to have one thing less to install on a new Jenkins node, for example.

Yeah, I know :/

People have crawled github for these in the past and turned up some pretty "interesting" results...

I don't dislike RAII: it's a useful construct. I use it occasionally for automatic cleanup of files, memory etc.

It's been up and down all day - very irritating :(

I'm the developer, and happy to answer questions!

One of them was "How to read a book" by Mortimer Adler. I kid you not.

It taught me just how much I was reading for my own entertainment, not for real information.

http://pininthemap.com

You've got clients, so you're a contractor, right? Which means you have savings... hopefully?

I'd be straight with them, and tell them you need some time off for personal reasons. Be specific as to how long you want. Help them find a stand-in in the meantime if appropriate. If you deal well with them rather than just going AWOL you stand a good chance of keeping good relationship with them.

I'm really sorry you're going through a hard time. I'm sure you'll pull through it. Hang in there!

Yeah, Relish is similar but not quite the same: it's a separate website rather than an integrated one.

Be very careful of over reuse of step definitions, and of Transforms. You'll end up with code that's very difficult to understand as your step codebase grows.

I now tend towards minimal step re-use, lots of one or two-line steps calling into nice clean plain ruby classes which actually do the work of my steps.

I've blogged a lot about how to use cucumber well here: http://chrismdp.com/tag/cucumber

This entirely depends on how you write your step code. If you treat it like production code and aggressively refactor it, so you have minimal reuse of steps, lots of one or two-line steps, calling clean well factored plain Ruby code that actually does the work, you'll be a lot better off.

This does take time to create, but in my experience having acceptance tests written in a form which is readable to anyone is very useful. I've even gone so far as to create a gem to display the features as the 'help' section of a website:

https://github.com/chrismdp/rack-usermanual

I've used Cucumber for years, and I've never had a customer write a feature. Customers reading features after I've written them and checking them works much better in my experience.