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

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.

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.

So, do you do A/B testing or feature flagging in any way? If yes, can you also mention

* Daily Active Users / Monthly Active users? Trying to understand at what “scale” does A/B testing make sense for organisations

* What’s the infrastructure and plumbing look like? Inhouse setup (add a flag to a user profile or if conditions in code?) or do you pay for a SaaS that helps?

* What’s the overhead like? Do you feel it’s worth it?

If you are not using A/B testing, why not? Is it the initial investment or the followup maintenance that is the headache?

Comments URL: https://news.ycombinator.com/item?id=49498145

Points: 4

# Comments: 3

Comments URL: https://news.ycombinator.com/item?id=46836572

Points: 4

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=24897593

Points: 1

# Comments: 0

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.

> 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.

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?).

Comments URL: https://news.ycombinator.com/item?id=23378430

Points: 2

# Comments: 0

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...

Thank you sensei ! Well met indeed :)

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...

Point taken and corrected (noob blogger mistakes!)

Thanks!

Comments URL: https://news.ycombinator.com/item?id=22977637

Points: 595

# Comments: 300

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 that does this job better - of understanding the customer needs on a day to day basis and building platforms for them.

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

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