xgb84j

You either die a software engineer or you live long enough to see yourself become the project manager.

Claude Code has the issue that sub agents inherit the thinking level. This means that to use a smarter or dumber sub agent you need a different model. That's not a particularly good reason, but that's my one use case for Sonnet.

It might be that you're just working on projects where LLMs don't provide much benefit.

The second thing is that using LLMs in a useful way is a skill in itself.

I do not believe you read my comment in good conscience.

>>Claude was consistently doing database operations in a for loop, where it could use batch operations.

>>The code in the end is better than a lot of the code I've seen humans write.

>It's a little amusing to see those two sentences written back to back with no hint of irony to be frank.

There is no irony because I have seen humans do the same thing. The difference is that the human was paid 50x more.

I do not understand your arguments around outsource shops. I get clients. They want something. I deliver. There is not a lot of complexity to this. I am not a world start programmer that has 50 clients to choose from.

>>Set up excellent testing.

>Is this the part that you hand code or constantly review yourself? I guess not, since you would have explicitly mentioned something that important. I would caution you not to be surprised when no one believes you have excellent testing when you've unleashed multiple LLMs on it and are not reviewing code anymore.

I set up excellent testing the same way a CTO would set up excellent testing: I give clear guidelines on the architecture I want to see on the project. I then review key parts and samples of it and give feedback. When it looks good I mark it as done and move on. Any bugs or defects always result in additional test coverage.

I'm happy to have a constructive discussion about this, but I do not appreciate your sarcastic, tongue-in-cheek, condescending tone. It makes people not wanting to communicate with you.

In my country we have very protective labor laws, but what you describe is one of the few reasons that allow for instant termination: You refuse a direct order. If your boss says that he does not care about long term consequences and he want things done a certain way, you do it that way. Everything else is unprofessional. Your opinion on what you think he wants is legally irrelevant.

All the projects I work on have an explorative character. It's very difficult to design a product, build it and sell it. You need actual customer feedback. LLM code gives you a much faster feedback loop.

If you have a clearly defined problem with customers lined up, you should absolutely use a different approach. In the startup world you often don't and you already know that you will throw away or rework 90% of the code before the first line is even written. The best thing to do then is to have clear boundaries and good tests, which allow ripping out parts of the codebase and reworking them.

I am hand-holding the AI on the e2e setup. It mostly consists of Playwright + Cucumber + a test API to set up more complex scenarios. I also have unit tests for logic that lends itself to that. I also use mocked LLM responses for LLM projects.

If you enjoy writing tests, AI is really good at finding appropriate fixes for bugs that are easily reproducable. Just make sure to always have another AI review the fix. Otherwise you get a lot very, very dirty quickfixes. (At least in my experience.)

I am currently writing a lot of code that I am not reviewing anymore. These are all the things that make it work for me:

- Work on small projects (< 500k lines of code).

- Work for business people who want fast results. Agentic coding gets you to something presentable much faster at the cost of code quality. I have never seen a customer or business person care about that.

- Have clearly defined API boundaries. Examples: If the back end is solid you can just vibe code the first version of a front end according to some mockup. Define a data pipeline with steps and clear contracts of what data gets passed around and what each step does. If the LLM messes up one step, rip it out and rewrite it.

- Have clearly set up workflows for tasks. Start with a "ask me everything" phase, then comes a plan phase, a review phase, an implementation phase, another review phase and then the integration phase. Multiple agents going over the same problem catch a surprising amount of dumb stuff that would otherwise slip through.

- Set up excellent testing. Build your whole architecture around being easy to test.

- Have skills for common problems. For one of my projects I had to set up a skill on how to query the ORM, because Claude was consistently doing database operations in a for loop, where it could use batch operations.

The code in the end is better than a lot of the code I've seen humans write.

I don't think this works for everybody and every project. If you have a culture that values code quality and readability, if you work on large existing projects, if you have to nail the architecture of some non-trivial piece of software etc. you are going to have a bad time.

On the other hand you can probably build the MVP of your AI-supported CRUD app 10-20x faster.

I think a lot of the discussions around development tools and techniques just stem from two facts:

1. Developers work on widely different projects with different management and constraints.

2. Tools, libraries, frameworks and code style have to match your mental model, otherwise you going to dislike them.

Could you share what projects you are working on? (tech stack and size)

I am mostly working on small to medium sized Next.js and Kotlin projects and Claude works really well, while Codex often misunderstood my instructions, while I was testing it.

Mediocre is fine for many tasks. What makes a good software engineer is that he spots the few places in every software where mediocre is not good enough.

If you mean the Buddhist meditation: I joined a local group a few years ago. I wasn't super serious about the practice until I saw how directly it can improve my life. Even now it's hard to find this much time every day.

This is a book that helped me getting started: https://www.amazon.com/Roaring-Silence-Discovering-Mind-Dzog...

Hey, I just wanted to let you know that I have the _exact_ same issue as you since 2 years. It was much worse than what you described 2 years ago. Now it's just very annoying.

The diagnosis I got from my therapist is PTSD from my chikdhood due to the strong connection between stress and body.

The only thing I found that alleviates my symptoms short term is lots of Buddhist meditation (1-2 hours per day).

I wish you all the best and thank you so much for sharing.

When learning new stuff I consider 2 things: - How much fun is the actual learning? - Can I actually apply what I am learning?

So I would learn things that are either fun for you to learn or things that you can directly apply.

For AI this means you probably should learn about it if you are really interested and enjoy going through build-your-own-NN tutorials or if you have good chances of switching to a role where you can use your new skills.

Edit: Basically investing anything (also time) is risky. So invest in things that directly pay off or bring you joy regardless of the outcome.

Could you elaborate on what will happen in July?

Thank you for this in-depth reply! Your answer makes a lot of sense. Also thank you for writing the article!

In the article they talk about how printing an error from the anyhow crate in debug format creates a full backtrace, which leads to an OOM error. This happens even with 4 GB of memory.

Why does creating a backtrace need such a large amount of memory? Is there a memory leak involved as well?

What you describe is how development of basic packages that are part or on the level of the standard library should be done. The languages we are currently using will still be used decades from now. Slow good decisions now save much more time later on.

How do you think Meta profits off React and PyTorch? Just marketing to get good candidates?

No serious Java code uses booleans to indicate failure or success. It's on the same level as not using a language's standard variable naming scheme. It's not wrong, but something experienced Java developers working on good code will immediately notice.

In good Java code you would return either void to indicate side effects or the newly saved user. Exception handling should be done outside the function, because depending on the context you might retry etc.

The main idea is to check if people who say they are very experienced understand conventions and have experience with common Java libraries.

Great idea, that's exactly what I like to do as well.

Because many people were interested in some actual code, here is an example that we used for Java:

---

public class UserDao {

    private Provider<Session> sessionProvider;

    public UserDao() {
        this.sessionProvider = new DbSessionProvider();
    }

    public boolean saveUser(User user, ApiConfig config) {
        try {
            Session session = sessionProvider.get();
            session.save(user);
            System.out.println("User saved!");
            return true;
        } catch (DbException e) {
            EmailUtil.sendEmail(config.getTechnicalSupportEmail(), e);
            return false;
        }
    }

}

---

"Solution": We always ask the candidate "What would you change about this code?" or something similar. We expect the candidate to come up with some selection of: - Database sessions should come an injected provider. - Configuration should probably be injected as well and not passed as a method parameter. - Booleans are not canonical Java as return value. - Don't write to stdout but to a logger. - Exception handling should probably happen outside the DAO. - Don't use static methods for sending Emails without good reason. Non-static methods are easier to test.

Finding these things is as important as being able to talk about them and give background on advantages / disadvantages of doing things different ways. With good candidates one can talk easily half an hour just about this example and adjacent topics (e.g. error handling).

---

Edit: Formatting

Edit 2: added "Solution"

One challenge I encountered in the past was syncing data between a SaaS software I built and customers' ERP systems. Building these integrations was an absolute pain because there often is no publicly available documentation. This means you need to pay an SAP consultant 300 dollars per hour to tell you all the things normal apis have in their public documentation. Is this something you plan to address? Or are you just making already usable apis even easier to use?

Btw great product! Just really curious about a personal pain point of mine!

  Location: Vienna, Austria
  Remote: yes
  Willing to relocate: no
  Technologies: Angular, Java, PyTorch, Tensorflow, Python, PostgreSQL, SQL, Presto, Hive, AWS, Typescript, Hibernate and many more
  Résumé/CV: https://www.dropbox.com/scl/fi/4rni8wxfjzwa7qv4usdw6/CV_Duer_20240401.pdf?rlkey=049japrdopw5y33wulkb9b86h&dl=0
  Email: mail.duer[at]gmail.com

I am currently looking for a data-centric role such as data or machine learning engineer.

I spent the last 5 years as the founding member and CTO of a startup, which still thrives under the leadership of my two co-founders. There I architected, designed and developed a procurement software for custom made packaging that convinced customers with industry revolutionizing features and excellent UX using Angular, Java and PostgreSQL. I also applied state-of-the-art optimization and machine learning algorithms to industry specific tasks. One example is a packaging size optimization service that I created, which saves Germany's leading e-commerce websites (e.g. Flaconi) 10 - 15% of packaging and shipping costs every day.

Before that I worked as a data engineer at a global mobile advertisement company. I worked on extremely high traffic systems with hundreds of servers, where the limiting factor was the number of requests, which required us to switch to an asynchronous architecture by migrating our application to Vert.x, which reduced the number of required computing resources by over 60%. I also delivered on a data pipeline redesign, where we reduced data storage requirements by 80% through efficient sampling, which saved tens of thousand of dollars every month.

If you are interested in working together feel free to reach out.

There is difference between expropriation and fair taxation. The problem as far as I can tell are tax loopholes that you can only abuse above some wealth threshold.

That's a good point. I personally always like Angular and React, because even with most simple projects there is this one feature that is so ridiculously complicated that making it slightly easier to develop and maintain is important to me. I'll gladly write thousands of lines of boilerplate just so I make it easier for me to succeed in developing this one endboss feature. If you do not have at least this one insane feature, Angular and React are definitely overkill.

The point where frameworks like Angular and React pay off and what I think of as complex projects are those where there is a some nontrivial feature. This coukd be a project with 1 developer working on it for 6 months.

For example a static page with a booking process with various entry points on the website, which slightly change the booking logic. Also you can book as a new user, as a logged in user, for somebody else etc. Also the logic is changing at regular intervals, because the business owner is trying different things out.

Using Angular with reactive forms makes this easier to develop, maintain and hand off to other Angular devs.

While it makes writing the static parts of the website more complicated, it makes developing the booking process easier. And overly complicated business processes are what is mentally challenging for me. This is where I want all the help I can get. Writing static pages is something I can do in any framework even when I am tired. Making this part easier or reducing boilerplate is nice but doesn't make me much happier. Being able to build ridiculously complicated forms without my head exploding does :) Of course if you work on projects with relatively straight forward requirements there is 0 advantage in using Angular or React for you. It always depends on the type of work you do.

Because in practice there is little value in making easier things easier. While 95% on the web are small projects, 95% of work is done on large projects.

Many developers also dislike using many different frameworks, because that would require more learning. If you have to choose one technology it's better to use one where you can do everything. Not one where you can do 95% really fast, but 5% not at all.

I personally always use "complex" frameworks like Angular or React because sooner or later feature requests come in, where those frameworks pay off. On average it saves time for me to always use those frameworks. That might be different for you depending on the work you do.

I think these eastern concepts (e.g. meditation concepts such as chakras, "organs" in traditional chinese medicine) are not meant as objective truths, but rather as useful mental models. Different mental models used in the same culture often contradict one another, which only makes sense if you don't see them as ultimate truth.

Small business already have all the relevant characteristics of selling B2B. They have much more in common with a large multinational company than with a consumer, with regard to the sales techniques we use.

The main difference I see is, that with B2C you need to find a useful product and the rest is marketing. This is my simplistic view as somebody who doesn't do B2C. There is lots of nuance, but I believe you need a similar skillset for most B2C ideas.

B2B has a larger logical component to product design and sales pitch and a much more individualised emotional component.

The logical component is about what to sell to solve a specific problem. If you have different products that each increase a company's revenue by a million dollars, some of those won't sell for 0 dollars and for some you can charge more than a million. Why? Because the company doesn't make any decisions. The people within that company will buy what helps them and a sales representative will pay a million of the companies money to make a million more in revenue, because his numbers go up.

For the restaurants that means they might not pay anything for automation in regards to online delivery, because they don't even recognize how much time they waste. If they don't see a problem or only a temporary problem you won't sell your solution.

The emotional component is also very individual when selling B2B, because people have hidden agendas. They want a tool because their numbers go up and then they get a promotion. They want to start a project to make their boss pat them on the back. The want a tool that saves them time, so they can go home earlier and see their kids.

You see it's all about finding the right angle to solve a problem in B2B. It needs to solve some problem for the business and it must solve a big problem for the person you are selling to that they are emotionally invested in.

With restaurant owners it might mean that saving the owner two hours a week is worth nothing to them because they still need the same number of employees and it's not their two hours but their employee's.

Here what has worked for us:

Talk to potential customers and use very open ended questions. Be upfront that you are doing market research about delivery app usage in restaurants. Start with something like "How is using delivery apps going for you?" The opener the question the better. Most people love to complain. So your hope is that they rant about their biggest problem. If they don't ask about other areas until they start ranting.

After you found a problem, ask follow up questions about how the problem is impacting them personally. (People don't care about their company, they care about their salary, promotions, if their boss likes them etc.) This will help you later in selling your product, when you call back the person 3 months from now with a prototype.

When you have a concrete product or prototype that you show off, the best indicator is that people ask if they can buy the product right now. If they don't or you have to ask them if they are interested it's probably not solving an important problem for them.

PS: This works for B2B. B2C is probably different.

I cannot speak for OP's sister, but I personally feel gut problems in my back. There is no medical explanation for that, that I am aware of. But when I eat certain foods, I have intense back pain the next day.

The only reason I think it is related to gut problems is because the back pain is perfectly correlated with certain foods (e.g. large amounts of gluten, smoked meat) and has 0 correlation with normal reasons for back pain.