pftg

Location: Berlin, Germany Remote: Yes. Europe for a leadership seat; worldwide for Rails work, hire or contract Willing to relocate: No Technologies: Ruby on Rails, PostgreSQL, pgvector, Python, LLM/RAG, AI coding agents, CI/CD, DORA metrics Résumé: https://linkedin.com/in/paul-keen · https://github.com/pftg Email: [email protected]

Looking for a Head of Engineering or CTO seat at a small product team, or a Rails tech lead role.

Since mid-2025: a two-developer LLM/RAG product from zero to production, built with autonomous coding agents.

Earlier: scaled an engineering team from 3 to 25 in three months with change failure rate under 1%. Delivered dozens product on the market and fixed delivery processes for struggling companies.

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.

This reminds me of a brilliant Soviet satirical cartoon that illustrated the same principle with hats instead of shoes: https://youtu.be/gSpjDi2BrQk?si=CtJwQTHkm0HfNrxx

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

Yeah, I believe Sinatra https://sinatrarb.com/ or Padrino https://padrinorb.com/ inspired Hono. So you are back to Ruby ;)

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.

> Using VS Code as a Ruby on Rails editor shouldn't be so hard!

However, I personally prefer RubyMine since it comes with everything out of the box.

I only use VS Code as a text editor replacement.

First version was cleaner, and new code is, obviously, not clean at all, because it requires much more energy to learn then first one. Interesting that author misguide DRY code with Clean code

Nice list. Some good and some of them are contr-productive like promoting of use of preloading and calc in memory.

There is an irony here. Because in 2010 Bitcoin said the same that transactions should be cheap and fast, and now you see that they have failed to deliver that ;(

missed process part. devops is not just automatization

great reply

I found great advice on Twitter https://twitter.com/pauld_fgc/status/1574107791651905536 by Paul P.

API & Platform Results:

Rails: @Railway wins. Render wakeup boot extremely slow (~1m). Flyio cannot run Rails for free.

Crystal: @Render wins. 5-10s wakeup boot time. Railway & Fly keep growing memory infinitely.

Node: @flydotio + Railway both win. Very slow boot on Render.

nope, still other alternatives requires some invest in integration and onboarding

This is just our staff model, which Ukraine companies have provided for the last 25 years. We have a lot of them. I have not found any difference or deal breaker in your story.

TopTal changed that way to have better-motivated people, who want to work anywhere, so your idea is to step back.

The most closest tools is Cucumber

hey, nice flow!

have you shared with team that standups are not effective and could be improved or replaced?