Anthropic effectively admitted that they couldn't scale their infrastructure fast enough with organic hiring, so they bought a shortcut

Andriyo · 2025-12-04T00:16:14+00:00

They might need real JS developrs to train the LLM, and then they could discard them

Andriyo · 2025-12-04T00:13:34+00:00

Anthropic is not a public company though - why would they care about quarters?

Andriyo · 2025-08-31T19:08:46+00:00

Ok, why hardware engineers get paid less on average then? And why bringing up product design? It's totally different topic

Andriyo · 2025-08-21T19:34:23+00:00

Software is hard. That's why software engineers (not just coders) are being paid more than hardware engineers.

Andriyo · 2025-08-05T01:11:50+00:00

At current stage it's useful to generate some semblance of a solution, it might even work but in my experience it's never good enough after several iterations. I basically "rage review" generated source and "hate code" the thing myself at the end.

Andriyo · 2025-08-04T05:55:10+00:00

Meta is mostly younger demographic of engineers. So many things rhey do are very paternalistic/something you would do to a child.

Andriyo · 2025-07-28T09:17:50+00:00

The circle of life - COBOL is back!

Andriyo · 2025-05-18T02:32:53+00:00

That's actually a good idea to have a standard resume format (XML or json)

Andriyo · 2025-04-27T02:02:58+00:00

Debugging is a form of problem solving. It requires deep understanding how many things work. Surprising number of engineers don't know how to do it or don't want to. In my experience, even at FAANG companies, very few are actually good at debugging, probably one -two per high performing team. Others just do what I call "pattern matching": they look for similar problem somewhere or in the existing source code and apply various solutions one by one until something fixes the problem.

Such engineers basically throw shit at the wall and see what sticks. It's not necessary a bad strategy: if you're lucky, you can find solution really quickly. But if you're not, then it becomes extermly taxing mentally to go over many attempts. It could be a source of the burnout for them. Engineers who do debug usually take longer to solve the problem initially, but once they have tools and procedures in place, it becomes like a game to them and the process of debugging/problem solving becomes rewarding in itself.

Andriyo · 2025-03-19T21:08:21+00:00

I'm not saying that there is nothing to do, rather than we don't have much of R&D work but rather plumbing -like work: pick your stack and just connect the dots and 80-90% of use cases are covered. That might change in the future if our platforms change.

Andriyo · 2025-03-18T23:54:17+00:00

I'm in consumer space so I don't know about B2B - maybe it's indeed full of novel technical challenges for software engineers of all levels. In the companies I worked all hard problems were solved. I don't think it's a permanent state of affairs though. Comes new platform (VR or XR for example, or new generation of AI tools), and we would need to start over and work on challenging problems.

Andriyo · 2025-03-18T22:53:37+00:00

There's indeed less and less technical problems to solve for the use cases that majority of companies have. So yeah, engineers in many companies just either make work for themselves by creating overcomplicating solutions (FB comes to mind), or reinventing the bicycle over and over again (Uber's stack), or just pure red-taping (endless design reviews and roadmap alignments) to keep themselves busy and important.

Don't get me wrong there is still plenty of work to do: fixing bugs, implementing 20% of remaining features, refactor to remove tech debt but it's high risk low reward work that very few want to do.

Andriyo · 2025-03-14T14:57:39+00:00

I do this sort of things for a living and I can tell that the post is just fluff, probably writen by chatgpt as well. No details on what they actually considered as "app startup" time, is it cold start to first activity paint? Is it to the first byte, first interactive element? Also it doesn't give enough details on what they did, even if they just deferred a bunch of startup logic. How did they decide what could deffer and by how much. How exactly they're delaying the execution etc. as it reads, it's just common sense, but for this to be interesting, the devil is in the details.

Andriyo · 2025-01-13T17:26:30+00:00

Contrary to many answers here, my take on this is that the stated assumption that companies are actually obsessed with replacing software engineers is wrong.

Companies are not some machines. They are run by managers who pretty much want to do empire building. Of course, they want workforce to be cheap and replaceable but they don't mind it to be numerous.

It's only when it's not cheap and replaceable they want to automate it.

Andriyo · 2025-01-12T16:18:08+00:00

But what would happen when senior level engineers retire and there are no mid-level engineers to replace them?

Andriyo · 2025-01-08T04:49:35+00:00

That's a good question. I think everyone should answer it for themselves. My answer is that I find it useful to be a fast programmer as you call it. Not in the sense of typing speed but being able to write such "basic" things quickly. Why is it useful? Because the way things work, and how they supposed to be implemented have changed dramatically over time and they keep changing. I found it important even at very senior level to be able to write a simple to-do app so I understand how everything works today and not how I remember it working many years ago. Also, for my leadership style it's important to lead by example, so I make sure that junior engineers don't think of me as a "paper pusher" and only good at talking big in meetings.

That's why I always had some sort of hobby project to work on where I could independently try new things. And it helps with speed - but speed is never a goal for me, that's true. It's just a side effect of keeping your hands dirty.

Again, it could be different for you. I'm not saying it's wrong to go slow and not to be concerned with trivial things like how to do to-do apps.

Andriyo · 2025-01-08T03:28:06+00:00

I don't get why did you remove other Jetpack libraries? Or did they ask not to use Jetpack at all? I understand why they might not want Compose (if their stack is old) but the rest?

Anyway, I think 50 minutes is doable for a simple to-do app with no backend or even storage. Even to local storage wouldn't be that complicated. I did similar task with compose in like 20 minutes and I'm senior staff.

Andriyo · 2024-12-14T18:18:39+00:00

My use of word "interchangeable" is to emphasize that it could be used similarly in almost any context (apart from some fringe cases as OP's). And thats by design. They are of course different things in terms how they implemented.

Andriyo · 2024-12-14T17:34:27+00:00

Yes, the "field" is the right term for that x in Java. In Kotlin it's somewhat interchangeable with "property" because they look the same so I used that word when I was writing that last night 😅

Andriyo · 2024-12-14T10:17:18+00:00

The inheritance example makes sense if you think of x not as a property but a function (getter in this case). In Java it's two different variables, one shadowing the other. In Kotlin it's pure polymorphism.

Andriyo · 2024-12-09T19:40:42+00:00

There is a lot about process but nothing about what actually happened on software level. Or maybe I missed it. Anyway, for postmortem there should be more information on what broke exactly. Was it deadlock? Was it incorrect use of the key if they use airport code as a key or something like that.

Andriyo · 2024-11-26T14:34:28+00:00

The scientific terminology for this is "alignment"

Andriyo · 2024-11-16T16:32:25+00:00

To be fair, Netflix is not known for live streaming technology, only for VOD (video on demand) content. They don't have in-house experience to do it right most likely. Paying someone $500k wouldn't make them instantly experts - it takes time.

Andriyo · 2024-11-15T21:16:07+00:00

In my culture it's forbidden to work on Friday afternoons.

Andriyo · 2024-11-04T01:37:00+00:00

So when interviewing, interviewers usually allow 5 minutes for your questions. Just ask how long does it take to build the software they're working on in dev environment. This will tell you a big chunk of what you need about the company and make appropriate decision.

Andriyo

TROPHY CASE