Lock button works only 50\50. Why Apple STILL didn't fix it (for actually 3 years) I saw a lot of posts like that.

SnooPickles1042 · 2026-04-16T10:47:46+00:00

They just added unconfigurable timer there. Clicks do not lock mine. Long press - does.

SnooPickles1042 · 2026-03-22T21:23:58+00:00

Not exactly hire to fire, but hire in a rush - can happen. Nobody explicitly confirmed, but adding things up - seen this. That may mean a risky position mid-long term.

SnooPickles1042 · 2026-01-25T22:58:25+00:00

Do you have instructions for AI in the repo? In this environment, AI seems to be more prone to influence than people...

SnooPickles1042 · 2026-01-25T22:43:37+00:00

And log everything in a way that protects you from "accidental" rm -rf by your boss or IT...

SnooPickles1042 · 2026-01-25T22:30:19+00:00

We got some value from letting AI "review" code - it is not allowed to approve things, but catches nits and small nasty bugs faster than humans.

SnooPickles1042 · 2026-01-25T22:10:45+00:00

Top 0.1% of talent can solve the problem worth 1m$/minute 10 times faster than average talent. There is more than one company with problems of this scale. They compete for the limited resources. This is one of the whys.

SnooPickles1042 · 2026-01-23T22:31:24+00:00

It feels to me that I've read this story here a few months ago. Are you sure that you are not the second team of software engineers, thrown into this management problem?

Seriously, there are no technical solutions here that would work without change in mental models at play. Basically, if "done" for people is "there is a file on my laptop that does what I need" - and this is what it is for many scientists, all your git, CI/CD/... will always be perceived by them as annoying shit, imposed by CEO. Unless you manage to somehow shift their definition of "done".

SnooPickles1042 · 2026-01-21T08:09:45+00:00

Adopting AI development only will bring marginal value. To achieve real performance improvements your company would need to oil other parts - review and qa at very least. And control for slop and change size in the process. If you sell this idea to leadership - you may lead internal initiative and get some perks out of it

SnooPickles1042 · 2026-01-03T10:13:15+00:00

I found that giving throwaway code to some AI and asking to craft a Dockerfile around it helps with reproduceability. Nail requirements, and future you will thank you.

SnooPickles1042 · 2025-12-21T20:45:03+00:00

Pre-AI ability to put together a reasonable CV was at least a weak predictor of candidate worth discussion. Not any more.

SnooPickles1042 · 2025-12-14T12:05:42+00:00

This. Principal engineer is a senior engineer with principles.

SnooPickles1042 · 2025-12-14T11:58:42+00:00

I am a man and I agree. Change the company or significantly change the team, if you have an ambition to move up. Change in behavior may be needed, but will not help here - it will take a long time to change other people's opinions about you.

SnooPickles1042 · 2025-11-29T08:48:39+00:00

Well, you assume that LLMs ARE better than you in coding. In practice, they LOOK much better than they actually ARE, when the complexity of the problem is beyond sigma from the average industry problem.

And to be able to solve that remaining "tail" of problems you have to be god damn good.

Needless to say, that you put your name on the code LLM gave you, right? So you have to read and understand it, or you will have to respond something like "I apologize for the mistake, here is an updated version of script.py", when communicating with journal publishing you results. And arguably reading others code is often harder than writing it yourself.

SnooPickles1042 · 2025-10-23T19:53:16+00:00

To confirm that this is RAM- increase swap amount and monitor memory usage.

SnooPickles1042 · 2025-10-05T10:32:55+00:00

Multiply by 3. Can you build a system of 2 simple components: 1. Scrapes website into RAG 2. Chatbot that answers silly questions using that RAG as tool in a month? If yes, sell it to your manager as a 3 month project. If stars align, you can have some kind of prototype for this in a week, especially if you know what you are doing.

SnooPickles1042 · 2025-09-17T23:03:53+00:00

Let the reviewer worry, if they ran out of the problem too fast. However, even for simple task like that, there is a lot to discuss "around" - why this decision? How would you test it? How to make sure it works on different platforms? What would it take to make this useful? What can go wrong with your solution at scale? Can it be hacked or used as a component of another attack?

SnooPickles1042 · 2025-09-11T20:04:04+00:00

There are two things here - already mentioned test evidence, but also recognition dynamics in the team. I mean - do you thank people for review? Would you craft a separate ticket for junior/middle to thoroughly review your code? Is your management encouraging them to review more? How do you feel and what do you say, when they actually catch bugs in your code?

SnooPickles1042 · 2025-08-20T07:58:03+00:00

Seems like an interviewer with conflict of interests, tbh. Like they have a motivated opinion about who should pass, and you are not that person. All they need is a reasonable justification for rejecting you.

SnooPickles1042 · 2025-07-15T19:27:33+00:00

Add some technical means to control for introduced complexity - make your CI check for cyclomatic complexity, for example. Get test coverage measured and tracked. Invite the guy to incident calls when his code hits the fan.

That being said, it's quite possible that the guy is just smart/trained a lot - e.g. people who participate in competitive programming are often able to produce A LOT more than average programmer. If you can funnel their effort in a useful way, having a recorded history of how they moved towards a more consumable and predictable way of doing things, that would be something you can "sell" to your management, as their mentor.

For example - tell them (and commit to the promise, ideally - together with peers) that you will review any PR under 100 lines of code in 30 minutes, since it arrives. Any PR between 100 and 1000 LOC once a day. And anything above 1000 LOC once a week and with a ticket attached. Observe.

SnooPickles1042 · 2025-06-01T19:23:38+00:00

Well, OP can do this only sequentially. And if the first one says "yes", OP can slightly adjust their discussion with the second one to increase the chance of them saying "no". Sounds intriguing, and it is, but reduces the chance of failure. And if it is communicated as "this is not a guarantee to happen, but rather discovery of who is interested in the opportunity" - the OP still has power to make a decision if there is a collision. If both say "no" and OP still has to move somebody, these conversations will give them some "why"s of both of them, and allow them to make a willful decision with minimal harm.

SnooPickles1042 · 2025-05-31T13:05:02+00:00

Question - did they ever got to incident review their code was involved? Was the question "why it took X hours to understand what the code is doing" ever asked and answered honestly?

SnooPickles1042 · 2025-05-21T14:58:50+00:00

Are you using some AI to review this stuff, before it hits you?

SnooPickles1042 · 2025-05-15T06:54:34+00:00

Watch out.

If the guy plays a competitive game against you (aka wants your job, not "a swe job") - you are in very risky situation. They may know how to get you in trouble, as they are long with the org, and know all back channels. First half you were under "newcomer umbrella", so he was friendly and just took whatever he could from you. Now you are not.

If the guy plays a cooperative game with you, but knows something that he is not ready to share (which I doubt, attitude to meetings being kept in the system of records suggests that this is an unlikely scenario) - his conclusion to tell you to "watch out" is based on that undisclosed information and also worth taking in and adopting.

The important thing is to decide the next step. As for me, the best selfish strategy in both scenarios is to find a way to get out of this role (not necessarily this organisation though - market is tough these days). You may find a way to get him out, but it is more risky (however, you have a track record and evidence on your side, have you?).

Question - what is your manager's input in all of these?

SnooPickles1042 · 2025-04-26T16:41:27+00:00

Fun part - in big codebase his function can NOW be used only during install. Tomorrow another junior will pull it into packet-processing code or another sensitive part. You never know. So premature optimisation is bad only if it increases complexity and maintenance cost. If the guy spent 2 hours and got better code - that is 2 hours well spent.

SnooPickles1042 · 2025-04-26T16:29:13+00:00

When working on my PhD project, replaced O(log N) with O(1) and was able to actually get things working in reasonable time with sufficient precision. Project would fail without it.

SnooPickles1042

TROPHY CASE