pftg

The problem of handoffs makes this work far from cheap.

And tests are not dumb work. TDD uses them to establish clarity, helping people understand what they will deliver rather than running chaotic experiments.

Highly paid people should be able to figure out how to optimize and make code easy to change, rather than ignoring technical debt and making others pay for it.

QA is just postponing fixing the real problem - hard to change the code.

I cannot believe the excuse for why shift-left QA is “not working” is that Amazon hires developers who can’t learn basic testing skills that QA engineers picked up in three months. If developers can’t write valid code for tests, that’s on the organization, not on the practice.

The author forgot to mention the costs of handoffs, which paid off all those tiny learning investments.

Shift-left has over 30 years of proof as one of the most effective ways to build reliable software.

P.S. This isn’t an ACM article; it’s a strongly opinionated post based on personal experience.

P.P.S. I'm not against QA, but make them as bug/quality hunters, instead of toil.

You can easily build your own clear, simple DSL with Minitest, Pytest, or JUnit - no overthinking needed. Engineers can whip up more readable and reliable tests quickly. Since only engineers are writing tests, there's no need for unnecessary complications.

React just doesn't meet our needs, and switching from server-side rendering to it wouldn't really benefit us.

CodePilot delivers the most effective performance for its cost.

After trying other options like Continue + deepseek-v2, I found that the expense of hosting a bigger local version of LLM is too high to match CodePilot's performance.

Played with Continue + Yi-Coder too - requires a lot of time to clarify requests to generate valid code.

I made the decision to stick with CodePilot.

Some time back, I was tasked with sharing my thoughts on sustaining an out-staffed venture with outsourced cartage services and onboarding 200 to 400 developers within 3 years. What started as a blog post has now evolved into a novel-like narrative, adding a new layer of depth and intrigue to the topic.

It was enjoyable and challenging to intertwine tech tips and life experiences into a novel-esque format. I successfully expressed complex and technical concepts, making the writing exciting and witty.

Please give me at least 100 words of your opinion. Did you find the article interesting and clear enough?

Your feedback is invaluable to me. I want you to know that your critical assessment is welcome.

Great story, nicely written. The goal is to show off ;) But really nice to read.

Definitely, this is a bad example and precedent to build toxic and non-cooperative environments. And instead of solving the issue it make it worth.

Clickbait sharing the issue but related with unit tests but mocks ;(

Yep! RubyMine is like Ubuntu, and VSCode is Arch Linux!

> find out that not having types causes lots of problems

Yeah, it's hard to find a decent team, so we work with less experienced guys who need a lot of safeguards like static types ;)

Ruby solves this problem: you do not need big teams, so you are more comfortable finding better developers. Ruby allows to reduce team 5x.

No, it's an additional tool only for big legacy projects! TDD is much simpler and safer.