mbrevoort

A bit of a hot take: In agentic engineering, individual throughput is no longer the bottleneck — coordination is. In coupled domains, smaller aligned teams will outperform larger ones working the same problem space.

Individual throughput is no longer the bottleneck — coordination is. Smaller aligned teams will outperform larger ones.

Same, I took several of his classes in the late 90’s at UD. I remember him fondly. RIP

Firebug how sweet the sound That saved a wretch like me! I once was lost, but now am found, Was blind, but now I see.

Using 400A consistently would be insane. Building the capacity to support 400A but using much, much less on average is... prudent, especially when building a house that is remote.

Just because you prudently plan for 400A of peak capacity doesn't mean you would actually come anywhere near using it at any given time. Part of building a house in the woods is planning for contingencies.

This is interesting... I really like that someone is building a note taking app specifically for developers. The way I take notes to assist in the process of writing software is quite different than taking notes for posterity sake. When just taking notes, what's produced are, well, notes. When using a scratchpad while developing for keeping track of little details, ideas, results, links to blog posts or docs, any kinds of breadcrumb, or anything along the way is sort of like scaffolding that is important _only while building_.

It’s definitely happening and from multiple vectors including productivity, privacy and decentralization. Now that Chromium powers every major browser (except Firefox), it’s helped stabilize a standard base for others to disrupt upon like:

* [The Browser Company](https://thebrowser.company/)

* [Sidekick](https://www.meetsidekick.com/)

* [Bonsai](https://bonsaibrowser.com/)

New rendering engines in WASM and decentralized communication protocols are potentials for anchoring new alternatives.

Would love to hear more about that. What was your biggest takeaway from Ultralearning?

This post is more oriented to those building developer tools, APIs and platforms. You have to understand developers from a needs/value perspective in relation to the product you are building, and sometimes “developers” need to be described as multiple personas; the developer at your customer who is extending your product is different than the ISV/3rd party building for your marketplace. There are usually tensions in the dynamics of the product between developers and other user personas in terms of their needs, tolerance to complexity, motivation and desired outcomes.

In addition the point is also to be careful with generalizations like “What most people mean when they talk about the tension between DX and UX…” I generally agree with Malte but not in every circumstance. If you are a developer that primarily is the consumer of dev tools others produce, it’s common that you’ll only see things from that perspective, but the dynamics are more complex.

I’ve been in tech lead roles for many years now and I agree with almost everything in this post. 80% of Insights often come early after transition because you can more clearly see the contrast. The other 20% usually comes much later with deep reflection and when you’ve been distanced from the work.

If your service is non-trivial, composed of multiple services or a variety of workloads (long and short lived processes), Google Container Engine (aka Kubernetes) hands down. It is the most versatile, solid, cost effective option IMO.

If you just have a simple app with modest scale needs, the simplicity of Heroku is tough to beat.

I like JBot...

Other options: bot4j J4bot Botsdk (pronounced botstick) Bot devkit Chatbot kit Botlib

Inspired so much that you stole the name? That's embarrassing.

I'd much rather them forget reverse compatibility and fix the core problem once and for all. I personally like gb and the ability for each project to be its own GOPATH.

Interesting, we've tried very hard to make Beep Boop a 1st class experience on mobile. The login is through Slack which has worked well in all of our testing on mobile. I'd love to see what you're seeing. Email hello@beepboophq.com if you could. Thanks for checking it out!

Sorry you had a bad experience :(

We completely rely on Slack's authentication. Once you sign-up you should receive an invite to the BeepBoopHQ Slack team and you need to log in with the Slack account. After you're able to login you can add additional slack user/team combinations under settings and then log in through that team via the Slack auth flow.

Sorry about the confusion! There are some constraints we're working around with the way Slack supports authentication and "adding" integrations. They have been great partners, and we're working with them to improve this.

So like Brad mentioned, signup and then you should see the Slack invite to the BeepBoopHQ team and then you can log in with your BeepBoopHQ team user. After than you can associate other user/teams under settings and then log in from accounts in those teams as well. If you get stuck, please reach out in Slack or to hello@beepboophq.com. Thanks for the feedback!

Thanks, it's been really fun to create too :)

The most useful bot that we use internally is a deployment automation bot that orchestrates deployments and scaling in Amazon ECS. We are working to generalize and open source that bot.

In general, I think that bots on Slack will be boom or bust, but it's clear that Slack as a platform and Slack integrations are one of the key things that make the product special and successful. We'd like to give developers the best shot at making bots successful and useful in Slack.

Here is a super simple weather bot example that you can try if you want to see what the Beep Boop user experience is from the consumer side:

http://bit.ly/wittyweather

And here's the source: https://github.com/mbrevoort/witty-weather-bot/blob/master/s...

Wow . We're fixing that right away. Thanks!