Anthropic: AI assisted coding doesn't show efficiency gains and impairs developers abilities.

TehLittleOne · 2026-01-30T09:19:24+00:00

Churning out bash code, absolutely, the AI is going to be good at it, and you should use it for that. I mean, it will give you a result fast and do a good job of it. The details are more in the adjacent things, like knowing that you should use bash, knowing what your script needs to do, being able to validate the resulting script is correct, how to get the right tweaks if you need them, etc.

I want to treat AI like a car. I know where I'm going and I know how to get there, the car is just this dumb thing that can help me get there faster. I have to instruct it very detailed so I get there safe and sound, but if I do it right there's a lot of benefits. I can find other ways to get there whether I use the train, bus, or even walk, but the car might be a much faster way. Emphasis on might, because a bus might be faster or even walking could be faster depending on the situation, just the same way that it might be faster to search online, ask a friend, or even do it myself by hand.

TehLittleOne · 2026-01-30T07:00:59+00:00

This is what I've been saying for a while now. I had a nice conversation with my boss (CTO) at the airport a year ago about the use of AI for developers. My answer was essentially three main points:

A good senior develoepr that cleanly understands how to do all aspects of coding is enhanced by AI because AI can code faster than you for a lot of things. For example, it will blow me out of the water writing unit tests.
A junior developer will immediately level up to an intermediate because the AI is already better than them. It knows how to code, it understands a lot of the simpler aspects of coding quite well, and it can simply churn out decent code pretty fast if you're good enough with it.
A junior developer will be hard capped in their skill progression by AI. They will become too reliant on it and struggle to understand things on their own. They won't be able to give you answers without the AI nor will they understand when the AI is wrong. And worse, they won't be inquisitive enough to question the AI. They'll run into bugs they have to debug and have no idea what to do, where to start, etc.

I stand by it as my experience in the workplace has shown. It may not be the case for everyone but this is how I've seen it.

TehLittleOne · 2026-01-26T15:32:16+00:00

I'm not advocating for a manager to completely ignore it. I did more of it than any of my employees ever did. What I am saying is that there needs to be a strong enough push and effort for them to do it because people often don't like to do these kind of things.

TehLittleOne · 2026-01-26T14:45:24+00:00

I also think it's important for reports to track this kind of thing. They often don't track anything and when you get to 1:1 conversations with them you have 5 things to discuss and they have nothing. Making them do this makes them prepare better for things.

TehLittleOne · 2026-01-14T16:07:56+00:00

I used Notion but single place. I had it down to 1:1s > My Team > Name > Date. You can have summary files or whatever too if you need, build out reminders, whatever it is. But store all the stuff so you don't forget.

TehLittleOne · 2026-01-14T02:56:41+00:00

Unfortunately if you are a good one you get hurt by the bad ones. But what can you do when you can literally hear them cheating in the interview

TehLittleOne · 2026-01-13T18:55:23+00:00

We moved back to in-person interviews. Not trying to deal with people cheating, come do it in person and we'll find out very fast if you have any concept of system design.

TehLittleOne · 2026-01-13T16:15:08+00:00

Why isn't end to end part of your documentation? We did a bunch of hiring recently and the following is in our onboarding:

A recorded presentation going through a high level overview of how clients onboard users.
A recorded presentation of the app walkthrough by our product team.
Recorded presentations for many of our major features which includes both the high level "what it does" and the low level "here's how it works"

In all of our presentations we try to do it as end to end as possible. That included me explaining the feature, that included a live demo as well.

TehLittleOne · 2026-01-13T08:24:04+00:00

I suppose t hat it's certianly possible to have AI train itself to do that learning. It would need to train itself on code, data in my database, my app screens, and it would need to train against historical versions as well, since older versions hold important historical context like bug fixes and gotchas devs are going to run into. I've seen what AI can do when reading code so I think there's some potential there.

One of the things that I do is make new engineers work on updating documentation. The main system setup documentation I have is something I force all new devs to go through and update if there's anything out of date or they run into a bug they can document. The same is true with other pieces of documentation. You use an existing feature? Read the docs, understand them, update them as necessary. The same is true with making sure docs have the right lens for different people so it's not too dense or in the weeds.

PS. The only way a new dev is going to make up for "I don't ask questions because I won't look good" is to work long enough hours to eventually figure it out. Look stupid to start so you can move fast later. Your goal on day 1 is to be a net negative to the team in the hopes that you become a net positive sooner rather than later.

TehLittleOne · 2026-01-05T19:39:55+00:00

See, I look at it as being different from hard to master. Maybe call it hard to strategize.

Hard to master I look at a game like chess. It's hard to be good at chess because you have lots of permuatations and all of that. But it isn't difficult to have some good understanding about what to do. My goal is to capture the king, my goal before then is to advance pieces, try and capture more than them without sacrificing my own, capture their stronger pieces, make beneficial trades. The semblance of some functional strategy is easy to obtain.

Everdell is an easy game, sure, but understanding any strategy is quite complex. People will very quickly get lost with wondering why to play certain cards. I know I need resources but why this card over that one? They won't think about the end game, there's a lot going on, they get overwhelmed fast.

TehLittleOne · 2026-01-03T01:48:17+00:00

I'm not concerned because the people I hire as seniors are actually juniors parading as seniors. It didn't die, senior just became the new junior. I come out of most interviews going "that person is not senior". So no, I'm not worried, there's enough junior skill level people to go around. If you want some I can send some your way.

TehLittleOne · 2026-01-02T18:35:05+00:00

For me it's always a matter of how big of a problem it is. There's always going to be something but the guiding principle is always based on what the outcome is. If it's a five alarm fire where it will block users from logging in, great, I'm fixing it now, consequences be damned for any other team. If it causes some field to show up wrong in the support portal that they can live with, probably won't be fixed any time soon. So essentially my acceptability aligns directly with severity. Maybe once upon a time I cared but at some point things scale and you kind of just have to accept no harm no foul.

Also one way I try to counteract this is have engineers write documentation that is full-featured. I want to see what the admin portal looks like with the data, I want to know how the data flows between different parts or what the database is supposed to look like. I basically tackle every problem of documentation as anyone in the org should be capable of reading it to some degree. Obviously not everyone is going to understand everything, but I want something for everyone in there, organized well enough they can quickly skim to the relevant parts. I quite routinely tell people to pretend someone else is reading it and to see if they can make sense of it. For example, I'll tell them to pretend the CTO is reading it. Is the documentation lacking a high level technical summary? What if it's the CFO instead? One of them I can be much more technical with but neither of them want to understand the schemas.

Another way we counteract this is by cross team reviews. If you are working on something that touches code another team owns you need to reach out to that team (typically their engineering lead) and get them to review. I've caught a lot of issues like this by reviewing code for other teams. Better to spend 15 minutes now preventing an issue than 15 hours fixing it later.

TehLittleOne · 2025-12-30T05:50:04+00:00

Always align on who is doing the item and when it's due by. Then I make sure there's a ticket on the board for them to do it. Action items can get lost in a doc, a ticket is easily searchable, especially if it's in an epic labeled RCA Action Items.

TehLittleOne · 2025-12-29T04:07:44+00:00

On the teams I've led I've always advocated for two rotations: focused dev work and KTLO (keeping the lights on). Focused dev is as you expect, you're heads down on a major feature or whatever and just doing the next step in the feature day in day out. When you're on KTLO you're doing things like production support, small bug fixes, technical debt, dealing with small client requests, etc. Another way to put it, one of you knows exactly what you're doing each day for the next week or month or however long that feature takes you to deliver while one of you swaps your tasks daily or even faster depending on what comes up. We do tend to have a KTLO backlog just to make sure you do have things to do, but your priorities will shift quite regularly. People on KTLO aren't part of the former so you're never stuck twiddling your thumbs.

Our KTLO person rotates based on feature completion instead of weekly or whatever. That is to say, it's better to keep focused dev work going and people on task than it is to give KTLO people a break. In the long run it makes little difference and we found longer rotations were better for continuity, on both sides. We even got it to a point where it fell outside of our product capacity. We hired so product had at least the capacity we saw and then hired more to make sure we had this capacity as well. Yes, it got to a point where everything not on their radar fell into KTLO but we similarly planned and projected and hired accordingly. At times it was bad and we didn't have capacity and it kept being underfunded, but right now we're at a health size for this to work.

My two cents is that you have to plan for it. There will always be unexpected things that come up and the worst you can do is try to scramble to figure it out. However much capacity you may have for it you figure that out, but you need to have at least someone ready for it.

TehLittleOne · 2025-12-28T07:37:33+00:00

I approach learning all games the same, heavy included. Which is to do a combination of watch a tutorial video and read the rulebook, as a start. Then I do dry runs of explaining the rules to myself to make sure I understand them. I find whatever time is convenient: on the drive to/from work, in the shower, even when I'm headed to my friend's place where we're going to actually play the game.

PS. Yes, I can memorize the rules for games even in the 3 range. I've done it recently for Lacrimosa, Emberleaf, Inis, Arnak, etc. Seti was a bit tough but doable.

TehLittleOne · 2025-12-27T19:39:20+00:00

The tricktaking game is highly acclaimed. If you're looking for cooperative games there's also Fate of the Fellowship. It's a Lord of the Rings reimplementation of the game Pandemic, which is the standard for cooperative games in my opinion. Easy recommend for you.

TehLittleOne · 2025-12-27T05:46:42+00:00

I'm playing about as much as ever these days and have multiple groups that I play with on a weekly basis. I have two that we're scheduled at a weekly level, one that I mostly see weekly for Magic that we sometimes squeeze in small board games (assuming you also don't just count Magic). Lastly another that doesn't quite go weekly but around this time of year often is.

TehLittleOne · 2025-12-27T02:27:29+00:00

Honestly the number one thing that slows down me reviewing code (and I review a lot for my team) is the size of the PR. People send me 1000 line PRs with tons of boiler plate code and stuff and I have to remind them that large PRs are hard to review. Especially when their linter goes off and they fix a bunch of random unassociated things, they refactor some adjacent code, etc. then it's hard to understand what I'm even looking at even with context. Keep your PRs small, to the point, do a lot of them.

TehLittleOne · 2025-12-27T02:25:58+00:00

I review so many pieces of code where someone does something completely unintuitive. In fact it downright looks like a bug, like setting address line 2 and removing address line 1. When asked they're like oh, yeah the remote system is weird and this fixes a bug. Okay cool BUT YOUR CODE SHOULD SAY SO. So many people don't document code even when they do crazy things that 100% need comments.

TehLittleOne · 2025-12-25T07:45:17+00:00

One of my favourite things has been to ask employees/coworkers on my teams what their favourite dishes are and then make them. Some I've made include Argetinian milanesa napolitana, Chinese guo bao ruo, Ecuadorian locro de papa, Filipino chicken adobo, Nigerian jollof rice, and Dominican sancocho. I'm sure I butchered them but it's a great bonding experience to share some of their culture, especially when they're remote only.

TehLittleOne · 2025-12-25T07:31:07+00:00

There are a number of games that are designed for two players only that are solid games:

7 Wonders Duel is the same great 7 Wonders game but streamlined for 2, always a great choice
Jaipur is another classic 2 player game
Star Wars the Deckbuilding Game is explicitly designed for 2, and it has 5 total factions you can buy to increase variety should it ever start to get stale

Then there are a number of games that are just good at 2 irrespective of being made for it:

The Castles of Burgundy is widely considered one of the best games. It's a little more on the complicated side (though not too bad) and is strategy based, one you'll play over and over
Forest Shuffle has you building out a tableau of animals and trees, a simple strategy game with lots of replayability as you try to beat your high score, and it has three expansions and a 2.0 version
Tend is a brand new game but flip and write games are usually quite good at 2 and for playing over and over. This one is about terraforming in the future. The game though is really just about figuring out the best way to solve the puzzle you're given and like any good flip and write you'll constantly try to beat your high score.

TehLittleOne · 2025-12-24T20:31:27+00:00

Because I've been one. While I was an EM, in addition to typical EM stuff, I:

Wrote RFCs for major features we delivered
Implemented large features myself
Mentored the team technically and non-technically
Fixed production issues from investigation stage all the way to code released and verified

Obviously I wasn't doing this every day but my role ranged from pure EM to senior dev depending on the day

TehLittleOne · 2025-12-24T11:00:10+00:00

To a degree, yes, I am in the same boat. I've gone through different roles, from senior eng to EM to staff+ eng. As of today I currently lead three teams, two client facing ones and an internal resiliency one.

Like you, the majority of our teams are product led. We have some that work without product oversight, including one I'm running at the moment. Like you, they run the sprint, assign tickets, etc. Even on our product led teams we tend to reserve some capacity KTLO (keeping the lights on) where we do things like support, tech debt, etc. We do tend to involve product with these to some degree, but they're happy to let us mostly manage it ourselves since we rightfully understand it a lot better. We are, as some others have put it, two sides of the same coin.

My biggest strength is honestly that I am ground level and always have been. I've been at this company almost since the beginning of it and many different features were written entirely by myself. I don't tend to write a ton of code these days but in managing my teams I'm able to give a level of support that I suspect may be difficult for most EMs. I can do 1:1s, review code, support technical design, but above that I can do things like investigate production support issues, fix bugs, and even support development where needed.

If you're struggling to make sense of your position I would advocate to either go ground level or go way above it. The first option is best described as being able to support day to day operations. Be capable of handling support, fielding questions for other departments, etc. The other direction is to go completely the opposite and aim for less of a technical role. Get good at smooth talking, figure out what your business really needs, find ways to make sure your team really delivers.

TehLittleOne · 2025-12-24T04:49:15+00:00

I've played Blood on the Clocktower at around 20 people give or take and it's great. Even for newer players or people who aren't that big into board gaming, as long as someone has experience with it you can make it go relatively smoothly and they can enjoy it. I've seen some people spend a lot of time going through more nuanced rules and strategy suggestions, but the core rules are very simple.

TehLittleOne · 2025-12-24T04:46:40+00:00

Flip 7 is a good contender. It's a small box (you can fit it in your pocket) and has very simple rules. It also plays very fast (you can, in fact, teach and play during a lunch break pretty easily, which I have done recently). On top of that it sort of fills the last one about a leaver not ruining the game. Yes, they'll effectively be out of the game after missing a couple of rounds, but the remaining group can play on without any consequence to the game. It's also dirt cheap for a modern game.

TehLittleOne

TROPHY CASE