digitallogic

Some big findings:

JSON retries generated 7x to 14x more output tokens than the args path.

But!

On PowerShell, the cost gap between args and JSON was 9x. On Bash, it collapsed to 1.5x.

The conclusion of the post is "cli args are better than JSON", but the argument for why only holds up on Windows. This post says more about Powershell than anything else.

I have the same experience, but there's another dimension I want to throw out: breadth versus depth.

I've wildly increased my breadth of learning. If I'm ever curious about anything, even a passing thought, I can scratch that itch in a way I never could before.

But am I going deep? Acquiring new skills? Eh... I usually go far enough to unblock myself and/or settle a curiosity. I don't think that's good or bad, but it does present a certain set of tradeoffs that are different than going deep.

Document for other developers: you put in the work for someone else to get what they want.

Documenting for Claude: you put in the work to get what you want.

Seems pretty straightforward.

This kind of thinking is why a lot of market place startups fail.

You have two parties engaging with each other in a subpar way, and your solution is to make things better for one party (hiring side) and significantly worse for the other (candidates). Trying to convince candidates that this is good for them, won't make it so. Eg:

Every stamp that you hand out, pass or fail, leaves a candidate richer than they showed up. This attracts strong candidates to you, because even your rejections are worth something to them.

Candidates don't want stamps. They want stable work.

Very much on the same page as far as the holy grail! Would love if I had all that data (and it was actionable).

As for the Stryd... take this all with a grain of salt because I only have a consumer level understanding but: You can establish your FTP, but then the issue is setting zones from there. My understanding is that the big thing with establishing them is having an accurate estimation of LT1 and LT2 lactate thresholds. Most zone calculators are approximating that, but those calculators are based on a large body of data comparing lactate levels to cycling power in a controlled environment (a lab). That large body of data doesn’t exist for running power, and I recall reading that the little bit that does indicates that formulas for cycling power’s impact on L1/L2 thresholds don’t line up with running power. It’s also been maybe 4 or 5 years since I was engaged with this so the science may have improved!

Watch wise, when I used it, I have a Garmin Fenix, and it had options to show watts/zones/etc. You can even plug in zone based workouts just like you can with cycling power. I did find it a bit of a pain to monitor on a watch vs a bike computer, but not too big of a deal.

This is pretty cool! Your note about cycling power meters changing the way you perceive effort matches my experience as well. One other bit from my experience: I'm a runner and a cyclist, and I've always lusted after having cycling style data and prescribed workouts for my running. When Stryd launched I was all in, but... all it gave me was power numbers. It didn't have the tribal knowledge that came with my cycling power meter. Eg - lots of online content about zones, free and paid workouts / plans to target different goals (eg sprinting vs long endurance). It almost seems like any discussion of serious training on a bike comes back to watts.

But with the Stryd, all I got was power numbers, and the option to signup for a monthly paid subscription with some training plans that were pretty bare bones. It seems like running power meters just haven't been adopted widely enough for that critical mass of information to emerge. My realization from this is the data is useless without the tribal knowledge of how to use it. So my Stryd sits in a drawer somewhere, and I'm back to running by heart rate.

1-2% on millions of dollars is significant but it's not nearly as impactful as finding Product-Market-Fit in your actual business.

You've got really significant, broader lesson here for startups at this stage.

I had an advanced algorithms professor who was brilliant but not always put together. Eg - he didn't always dress himself correctly. Think, two different shoes or a button shirt mis-buttoned so there was an extra hole at the top.

He came in one day and wrote this problem on the board, and asked if anyone could solve it in O(n log n). No one did, he seemed really disappointed. The TA came in afterwards, and someone asked why we were going over this specific problem. Would it be on the final? The TA said "You professor gave you this problem because he went to a conference recently, and this was announced to great fanfare as a new unsolved problem. For the last two weeks, he's been asking anyone who will listen if they can solve this problem."

Teams typically implement their earliest version of an access control system with a home-grown solution or an open source library. Many implement role-based access control, often with roles, attributes, and authorization logic hard coded and/or tightly coupled with their business logic.

Here's the thing, teams do this for a reason. Each one of these checks takes all of 2 minutes to add. And the next one takes 2 mins to add, and so forth. Until it's a total mess. But, as someone who been through this cycle multiple times, that's exactly what I would do again in the future. Because, on day zero, if my options are "the 2 minute solution" or "spend hours/days/weeks? evaluating a vendor for a problem I won't have for years"... well, the choice seems pretty clear there.

As a product grows in usage and complexity, this is no longer enough. But the thing is... while it's not enough... I can add to it. Far more easily than I can to refactor everything to support a vendor provided system. And I know it'll be a big ball of mud, but at just about every decision point along the way I'm better off not switching. And every time I add something to my system, it's that much harder to adopt yours.

It feels like there's a circular dependency here. The easiest time to adopt your product (day zero) is also when I'm least likely to get value out of it. Solve that for me, and I'm very interested in your product.

Kind of amazed that my 15 year old account still works.

Paying Google Music user here. It's not a panacea.

> * I assume you aren't shelling out :)...

>

We in fact are.

Words can not express the joy I feel in reading this. Thanks so much for the responses!

Customer clusters are created/managed by programmatically running Terraform

I have soooo many questions about best practices doing this. I run a service that needs to dynamically provision AWS resources, and lacking a clear path to do this programmatically, I shell out to Terraform.

* I assume you aren't shelling out :). Do you have any additional helper libraries on top of the Terraform code base to make it more of a a programmatically consumable API, as apposed to an end user application?

* Are you still pointing at a directory with resources defined in HCL, or are the resources defined programmatically?

* What are you using for state storage?

* What is the execution environment for the programmatic Terraform process? Since Terraform uses external processes for plugins, I've hit some issues with resource constraints around the max number of process sysctl's in containerized environment where I have multiple Terraform processes running in the same container.

edit: formatting

Maybe this could be fixed in a json extension which allows words to be read as strings of themselves but if you extend json you lose any interoperability.

I worked on a product that did this for its storage file syntax, and the issue around interoperability was a huge drag. Both on us, and also on our customers. By nature of the product the customers often wanted to generate the files themselves, but generally didn't because they lacked tools to do so.

Interesting! I especially enjoyed the insight into the evolution of the company. Though with this insight I have slightly different conclusions than the author:

1. A bias to ship and a bias to ship new things are not one and the same. A lot of the problems, such as a failure to iterate on existing products/feature, sound very much a product of the later, not the former. If anything, the issue "Insufficient Iteration" is probably not correctable without a bias to shipping.

2. A bias to ship and a bias to ship things that impact your customers are not one and the same. There is a note about an early shift to micro-services. I can't speak to this organization, but, generally speaking, spending time on internal engineering work to the detriment obvious missing features is a common issue with early stage companies.

3. A bias to ship and a bias to ship to the right customers. Specifically in regard to the high value, high demand customers.

4. A bias to ship and... idk what to call this? "The product specs were well thought through, sometimes crafted for months." TBH, the problem with this one feels like a lack of a bias to ship.

As described, I think the real culprit was a lack of or poor prioritization. FWIW, I suspect the author and I may actually be in violent agreement as I did find my self nodding with most of his lessons learned. Though I'd be careful about letting too much hindsight bleed in (eg - do situations that'd be improved by more decision documentation justify the effort of documenting all product decisions, especially in the early phase when the product is rapidly evolving)?

I try to minimize it as much as possible, even when it hurts productivity. Long term maintainability is more important to me.

I don't think this needs to be an either/or choice in these situations. You can have both if you make the make the conscious decision to not fight your tools. Yes, sometimes you have to be more verbose in one language than another, but the productivity hit in that case always pales in comparison to the hours, days, and in some cases I've seen, weeks, lost by someone fighting their language/tools.

My favorite example of this was a developer given a 2 week feature implementation that ballooned to two months. They had minimal experience C++, and they didn't like its looping syntax. Rather than accept that frustration and write the code in a syntax they disliked, they instead spent weeks writing a "re-usable library that abstracts away looping semantics".

Also, not all AWS follow the same deletion semantics. Example: S3 buckets. The report as being deleted somewhat quickly, but their name may not be available again for hour or so.

In this case the delete will appear to succeed, but the recreation, if done with the same name, may fail.

Whoa boy, is it ever, but maybe not for the reason you're thinking. ie it isn't caused by people typing `apt-get install python`.

There are many packages that have Python as a dependency these days. For example, on my Ubuntu system:

~$ apt-cache rdepends python|wc -l

4649

I think the best illustration of how this can happen is installing postgres libraries needed to build the psycopg2 PG client. If you know to install `libpq-dev` then you're great. But if you do something that on the surface feels totally reasonable, like installing the `postgresql-client` package... guess what? You just installed another Python interpreter.

edit: formatting

Today’s startups have a biologist talking about wet labs on one side and an AI specialist waxing on about GPT-3 on the other, or a cryptography expert negotiating their point of view with a securities attorney. There is constant and serious translation required between these domains, translation that (I would argue mostly) prevents the fusion these fields need in order for new startups to be built.

Is that all that different from a software engineer with little customer facing experience teaming up with a non-technical cofounder who does?

Keep in mind that an organization that doesn't appreciate their top performs (hence them leaving) is also more likely to not take advantage of their limited time left when they give notice.

And a grace period that isn't taken advantage of is functionally equivalent to your employee being hit by a bus.

You don't need to worry about a meteor taking out us-east-1 because us-east-1 will take itself out several times over before a meteor ever shows up.

Promotions, raises, influence, etc., are no issue for remote workers in the former kind of company but certainly can be in the latter.

FWIW, remote first companies are not automatically immune to these dynamics. A few examples of how they can still emerge:

* A group of folks that all live in the same city informally decided to start working from the same co-working space. A clique emerges.

* The CTO frequently travels to SF to talk to customers, regularly has lunch with a local employee who later gets promoted over better performing peers.

* Same but while the CEO goes to talk to investors.

* Same but the whole leadership team meets in the same airline hub city twice a quarter because it's easiest for everyone to get to. Employees in said airline hub city have better outcomes.

* You live on one coast, and your supervisor lives on another. People in the same timezone as your supervisor get more virtual face time.

There are definitely more opportunities for this dynamic when some people are remote and some are in a shared office. But I'd be wary of any organization that tells you this can't happen to them just because they're remote-first.

These dynamics can emerge in many ways, and if an organization doesn't realize/acknowledge this, there's a decent that they could fall prey to it, or may already be in progress.

edit: formatting

Pretty cool! One piece of feedback: > An illegal site's servers were siezed in a recent operation. Please submit all users number of posts' details. Please make sure there are no duplicates.

There's no declaration of what attribute should be used for considering distinct users. After guessing it gave a hint to the effect of "there are duplicate Given Name values". This is rather counter intuitive since many people share a given name.

Check out the Gradient Retreat Center: https://gradientretreat.com/

When you start an interview an EC2 instance is provisioned. This will include all the (mis)configured software needed for the challenge you select, and you'll get access to that instance via the browser based terminal.

One of the interesting parts about building the outage related challenges is ensuring not just that they break, but that they break in a consistent and reliable manner. Also, that they don't interfere with your candidate's ability to work on the host.

Yup! After each interview a recording of the terminal session is available for you to watch. You can also download a copy of the contents of the user's home directory.

That's definitely true for some folks, but it's not universal. I split my time between contracting and my bootstrapped business. The business is profitable and operational costs are very low. The only financial risk is the opportunity cost of not being employed full time.

Through contracting I make about 30% less than I did as a salaried employee, but I am immensely happier than when I was employed full time. Even if I wasn't bootstrapping a business, that tradeoff feels worthwhile to me.

Hi Everyone,

I’m the creator of Opterview. It’s a CoderPad like experience for interviewing DevOps Engineers with challenges for screening your candidates. You get a shared terminal in the browser connected to a dedicated host configured for the challenge you choose. Some example challenges include:

* Debugging a web application that’s experiencing an outage

* Diagnosing issues on a misconfigured Docker host

* Writing configuration management code to deploy a web server

* Using Terraform to provision resources in a dedicated AWS account

Opterview has been in a private beta since this spring, and last week I finally opened it up to everyone. I’m a solo founder, and Opterview is at this point fully bootstrapped. If you have any questions I’m happy to answer them!

Correct! Wife works in the field (source for my anecdote), and she confirmed I was confusing PrEP with antiviral treatment.

It's lower. You're safer having unprotected sex with someone who is confirmed to have HIV but is taking PrEP, than you are when having unprotected sex with someone whose status is unknown.