Location: Las Palmas, Spain
  Remote: Yes
  Willing to relocate: No
  Technologies: Go, Python, Kubernetes, AWS, Apache Spark, Airflow, LangGraph, RAG, gRPC, PostgreSQL, Docker
  Résumé/CV: https://cv.fiodorov.es/
  Email: hn@fiodorov.es

Background: Cambridge MMath, UCL MPhil in Probability (published paper).

Looking for senior, autonomous roles at small companies or start-ups where I can drive technical decisions from architecture to production.

Source is at https://github.com/afiodorov/hn-search

When a project has little to no traffic, the on-demand pricing of serverless is unbeatable. A static site on S3 or a backend on Lambda with DynamoDB will cost nothing under the AWS free tier. A dedicated server, even a cheap one, is an immediate and fixed $8-10/month liability.

The cost to run a monolith on a VPS only becomes competitive once you have enough users to burn through the very generous free tiers, which for many side projects is a long way off. The primary driver here is minimizing cost and operational overhead from day one.

  Location: Las Palmas, Spain
  Remote: Yes
  Willing to relocate: No
  Technologies: Go, Python, SQL, Kubernetes, Docker, AWS (S3, EMR, RDS, Aurora, Athena), Apache Spark, Apache Airflow, TypeScript, React, gRPC, REST APIs, PostgreSQL, Google BigQuery, LangChain, LangGraph, RAG, faster-whisper
  Résumé/CV: https://cv.fiodorov.es
  Email: hn@fiodorov.es

https://hn.fiodorov.es

I treat it more like a homework exercise for a Coursera course but I like the result.

This is exactly right. Our role is shifting from writing implementation details to defining and verifying behavior.

I recently needed to add recursive uploads to a complex S3-to-SFTP Python operator that had a dozen path manipulation flags. My process was:

* Extract the existing behavior into a clear spec (i.e., get the unit tests passing).

* Expand that spec to cover the new recursive functionality.

* Hand the problem and the tests to a coding agent.

I quickly realized I didn't need to understand the old code at all. My entire focus was on whether the new code was faithful to the spec. This is the future: our value will be in demonstrating correctness through verification, while the code itself becomes an implementation detail handled by an agent.

  sign of serious organizational disfunction.

The reality is, most engineers spend far less than half their time writing new code. This is where the 80/20 principle comes into play. It's common for 80% of a company's revenue to come from 20% of its features. That core, revenue-generating code is often mature and requires more maintenance than new code. Its stability allows the company to afford what you call "dysfunction": having a large portion of engineers work on speculative features and "big bets" that might never see the light of day.

So, while it looks like a bug from a pure "coding hours" perspective, for many businesses, it's a strategic feature!

Anecdotally, when I bought my car recently, they forgot to even offer me the extended warranty they'd planned to push. I find it funny to think it was so minor, even they forgot to care.

An antelope's greatest desire is to be in the herd, because while it may contain a lion, the world outside contains a thousand wolves.

We've built a herd—society—that is incredibly effective at holding those wolves at bay: famine, plague, and chaos. We willingly participate because it provides "shields" our ancestors could only dream of. The problem isn't the herd itself; it's the lion that we allow to stalk within it.

What I am suggesting isn't to abandon this safety and comfort brought by modern capitalism. It's to improve the herd—to enjoy its protections while finding ways to tame, cage, or evade the lion of exploitation. What we're discussing here aren't futile attempts to escape, but vital tactics for building a better, safer herd for everyone.

If you know which car you want to buy it doesn't matter what the salesman has to say.

This isn't theoretical, it's happening right now. The boom in digital detoxes, the dumbphone revival among young people, the shift from public feeds to private DMs, and the "Do Not Disturb" generation are all symptoms of the same thing. People are feeling the manipulation and are choosing to opt out, one notification at a time.

The real issue isn't the technology itself, but our complete inability to predict its competence. Our intuition for what should be hard or easy simply shatters. It can display superhuman breadth of knowledge, yet fail with a confident absurdity that, in a person, we'd label as malicious or delusional.

The discourse is stuck because we're trying to map a familiar psychology onto a system that has none. We haven't just built a new tool; we've built a new kind of intellectual blindness for ourselves.