hackeryogi

I'm curious, how is the data for active building construction and active street repairs sourced?

The A/B test infrastructure is. It’s easy to wire up experiments because there is always a template/recipe to do so. Multiple subsystems can be strung together (eg: Experiment arm XX in subsystem A triggers Experiment arm YY in subsystem B). Analysis is simplified too since all the core metrics are already in place and ready for analysis.

Personally, I don’t run multiple sessions / agents (apart from the one claude code spawns on it’s own). But it seems you need an agent workspace manager - perhaps something like gastown? https://github.com/gastownhall/gastown

True. This was written with the context of Google which was, to a large extent and up until very recently, a good example of the resilience and magic a slime mold can be.

It is not true today, and as you mentioned "fundamentally incompatible with a next-quarter profit driven.."

To add to this, MCPs usually focus on capabilities. This is especially useful in multi-hop situations.

As an illustration, lets say I ask the agent to “Read the issue Bob posted today from Linear (issue tracker), pull relevant logs from DataDog (log tool) and suggest a fix”

In the MCP world, my agent doesn’t have to spend tokens / time understanding APIs or the protocol (as the parent comment suggests). Instead, it relies on the tool provider for the best way to “read the issue” or “pull logs”.

Same thing, in the API world, would usually involve multiple API hits (and possibly using the wrong APIs or params for them), interpreting the results and hitting few more APIs again.

Thanks for the link. Very succinct. Coincidentally, just a week back, I ordered the book it mentions.

I completely agree with everything you mentioned (And thanks for giving in numbers too!).

Since you’ve clearly thought this through, if I can push you to the hypothetical - at what point would you want to run multiple tests in parallel? Will it be largely a function of your dev team (more productive everyone) or active users (more frequent feature build outs / cross cutting rollouts) ?

Thanks again for the note. Very helpful.

Very well summed up.

In addition, same set of questions can also be asked to people who've recently left the organisation.

I'd use the following criteria to filter ex employees:

- Reliable 1st/2nd level connections

- Folks who have shown stability in the past (generally stick to jobs for > 2 years)

Obviously, they'd come with biases. But, talking 2-3 people should also help reliably gather broad culture patterns. Should avoid listening to evidently disgruntled folks.

Well written article

> DON'T BE AFRAID TO DISMANTLE THE WRONG ABSTRACTION

Couldn't agree more with the statement, though I don't completely agree with the author's suggestion to copy paste. Duplicating code _is debt_. It may help us go faster now, but it'll almost inevitably come back to bite. It is manageable if 1/2 people do it 1/2 times - definitely not manageable if 5/6 people do it 5/6 times.

I believe the general hesitation of not touching a piece of code (or, getting by with that optional param) is due to the fear of fucking things up. Having your code test covered gives an amazing amount of confidence to rip apart old abstractions to yield newer ones that serve the purpose of the _current code_. To me, this route is more preferable to duplicating code.

Even with the best of intentions, Hacking an abstraction with that one optional parameter is inevitable. Tests help in our ability to repay that debt faster - on time & in full.

Basically they make all abstractions a lot cheaper - easier to write and easier to throw away. Thereby solving the problem of having a 'wrong abstraction' too early.

While I completely agree with your _sentiments_ I think there is a conflation between choosing _the right tool_ for the job vs using 'too many things'.

I shun the unnecessary - completely with you on that. But I'd prefer gaining relative mastery over _1 decent tool_ in each of the areas that you pointed out so that I have enough tools in my toolkit which prevent me from using the wrong tool for the wrong job. For example, I'd hate to use shell scripts to do something that ansible does really well.

A modern solution, fortunately or unfortunately, is built up of multiple smaller tool sets as you pointed out - and, if used correctly, each enhance productivity tremendously. Writing a frontend app (something that I've only recently started doing since I'm on my own) is immensely more productive if working with something like react rather than with a relatively old framework based on the jvm.

What I'm trying to say is - tech we use is ultimately a tool - we should optimise for productivity. In that case, Boring Technology helps being more productive since we know a lot more about it which makes it easier for us to bend it to our will as well as debug/diagnose the unknowns.

But it also doesn't mean we continue to use `grep` when silversearcher/ripgrep is out there in the world :)

That's the lens that I look with when I come across new tools/technologies (regardless of how long they've been around) - do they have the potential to be net-productivity enhancers over a long-ish period of time && by how much (0.5x? 5x?).

Thank you for starting such an interesting thread. Going through all the comments a few days after the question was asked is very rewarding ! So many books marked as 'to read' :)

My contribution: If you're not familiar with Quantum Physics, do check out 'Through Two doors at once'. There were numerous instances while reading the book that I had to just put it down and think deeply - mostly philosophical thoughts around what we are and how magical nature is. The subject matter is very very approachable - even to someone like me who hasn't read a physics book in like a decade.

https://www.goodreads.com/book/show/38527619-through-two-doo...

You, sir, seem to have a xkcd catalogued in your head much better than I do.

Thank you sensei ! Well met indeed :)

Thank you for this - and the references to how you came across the concept. I was personally only recently introduced to anki [1] & [2]

However, I tried it out but I couldn't end up using it to 'remember books' or broader concepts that the books convey indirectly. I've started summarising books and using a manual form of spaced repetition to remember them better.

Do you have any advice on organising such knowledge better?

[1] https://ncase.me/remember/ [2] https://superorganizers.substack.com/p/how-to-build-a-learni...

Does xkcd even need attribution? I was sure most readers would recognise the art (if not the comic) :)

Point taken and corrected (noob blogger mistakes!)

Thanks!

Thanks for the feedback. It does have a short write up on things to do. I have a lot more opinions on that, but was trying to balance out the overall length of the post. Will try having one out just on the dev environment :)

Hopefully - that's what we're working on :)

This is quite the representative case between Infra teams (or PaaS or SRE - based on where you're located) and application teams.

Being part of the platform team, I've been in the exact same situation before at an ex employer. We assumed that _infra problems_ were _everyone's problems_ and how can anyone who cares about their application _not_ adopt to the latest-and-greatest-platform (or tool) we released. A lot of time was spent on figuring out the 'best approach' to getting everyone onboard quickly - we tried the carrot and the stick. We failed miserably at both.

The trouble is, as someone else mentioned here - we didn't really go and _talk to the customer_. Internal customers are customers too - and 'product' thinking should be equally applied to all internal platforms. The general rule applies - talk to the customer and understand what they're going through. They have their own sets of problems and priorities.

(a) Is the latest way actually _saving them a lot of time_

(b) Can we take another 2 weeks and make it even easier for them to come on board?

(c) If they're really busy and/or lack the expertise, can we carve out some time to give enough training sessions?

Yet, this never happens and we invariably end up blaming the application teams for _not doing this seemingly simple_ change. It may seem downright stupid from the platform engineer's PoV, but we are partly to blame.

This also leads me to think that the cloud wars will be won by the <cloud-provider> that does this job better - of understanding the customer needs on a day to day basis and building platforms for them.

All my dotfiles are in a git repo.

Whenever I'm doing a fresh install, I simply download all my most-used packages and rsync the dot files.

I'm planning on investing some time and setting up Ansible so I only have to install python and it does the rest for me.

HTH

With all my heart, I agree with you; but I wished I shared some of your enthusiasm.

I've been brought up with the saying, 'The sole purpose of education is to help a person think sensibly in difficult times'.

However, I've not come across any _major_ shift in education systems worldwide. Yes, there are heartening stories about a few charter school systems [1] and a few countries making strides (like Finland). But these are one off success stories.

I do hope that technology companies make a step towards solving this. But our startup culture, unfortunately, also is laced with trying to 'show growth' all the time and that leads us to think short term too. Perhaps something like the LTSE may help private players take long term bets (fingers crossed).

Also, even the history of education is ripe with missteps [2], mind you :) not unlike the decision by YouTube here (as someone said, The road to hell is paved with good intentions)

Don't get me wrong, I want to be as optimistic as you are :)

[1] https://www.wikiwand.com/en/KIPP (I think I came across this while reading Outliers by Gladwell)

[2] http://www.csun.edu/~vcmth00m/AHistory.html

(i) it's a very interesting point that you put forth. Yes, robots will compensate for the _working population_ ; However, I think the OP wants to direct the attention towards the economic impact of a changing demographic. Robots won't earn and [ borrow and ] spend. Consumption, Consumerism and the access to Capital is the reason world GDP has multiplied manifold in the last century and why it continues to grow. A shift in demographic has a massive impact on that.

This, right here is the problem with our industry. Someone has a brain wave and asks a [set of] hardworking engineer(s) to 'make it happen yesterday'. Engineers toil away and bring out something useful by making all possible hacks since yesterday has already passed. Early engineers get frustrated and leave only to be replaced with some more hardworking engineers who now have to clean up the mess, keep the lights on _and_ implement the next brain wave that the idea man came up with. The problem is, a lot of 'thinkers' are becoming entrepreneurs - most of them have no idea about the complexities or intricacies of software or those who wrote code so long ago that they largely worked on monoliths and have absolutely no idea how complex systems work together 'in the cloud'. We need more 'builders' (engineers) as entrepreneurs. It'll invariably lead to people working on more sensible, real world problems that need real solutions - since, hopefully, builders would know what it takes to build out something and won't waste resources on frivolous and ill thought out ideas.