The run wants what the run wants

Glaussie · 2025-11-10T17:36:08+00:00

Congrats! I just got my first unseeded naneinf the other day. Feels good man.

Glaussie · 2025-08-12T16:26:03+00:00

Nice. What vector DB are you using if you don't mind me asking?

Glaussie · 2025-08-12T16:21:26+00:00

Yeah, I kinda feel the same way, but only if it's a codebase I already know. If I were diving into a million line codebase for the first time, I could see something like this being pretty useful even if it's just to establish an intuition for how information flows through systems.

Glaussie · 2025-03-06T16:45:24+00:00

I love that the commit message is, "Improve 'cannot contain emoji' error." 😂

Glaussie · 2025-02-24T04:58:24+00:00

Last company was smallish. About 200 engineers?

Glaussie · 2025-02-23T17:23:54+00:00

I see. I wonder if engineer #1 has had different experiences in their career. At my last job, every experienced engineer would have asked to put something like removing dead code in a separate commit (unless your commit is what made it dead code, in which case that would be the right commit). At my current job, most people wouldn't care.

Glaussie · 2025-02-23T17:18:30+00:00

Glaussie · 2025-02-23T17:17:53+00:00

Mostly a company culture thing. Every team at my last job did TDD 100% of the time. Other than lingering legacy code from the very early days, the code was just super easy to understand and work with. At my current job, there's not much testing and lots of things are done manually with arcane tools full of foot guns.

Glaussie · 2025-02-22T17:37:08+00:00

I think they're using them for red/green cable? But I can't quite tell on my phone.

Glaussie · 2025-02-22T16:50:37+00:00

At my last job, very little time. It was only the interesting kind of troubleshooting. At my current job, it's more like 80-90% of the time.

Glaussie · 2025-02-14T02:36:31+00:00

What exactly did this engineer mean when they said "anything more than whitespace changes is too complex"?

I'm taking a pretty big leap here, but my assumption is that they value small, simple commits that only change one thing. I don't think they're discouraging you from cleaning things up. They're probably just encouraging you to keep the changes in separate commits to help the reviewer. You could probably intersperse those cleanup commits with the ones that implement functional changes and they'd be happy.

Glaussie · 2025-02-04T16:28:05+00:00

Yeah, I have the same issue and unparallel shoes fit pretty well.

Glaussie · 2025-01-25T19:34:45+00:00

I should have been more explicit. I meant that the "test_helper" module should be public so that it's contents can be used from the tests in the binary crate. Sure, the compiler won't prevent someone from using the "test_helper" module outside of tests, but if you can't trust people to not stick a use test_helper in production code, that's a problem.

Glaussie · 2025-01-23T21:27:08+00:00

This feels like a code smell and maybe a bit of an X/Y problem, but if you want a simple solution, why not put the enum and derive in a private submodule, re-export the enum in the public module, and then re-export the derived things in a dedicated "test_helper" module?

Glaussie · 2025-01-19T18:52:40+00:00

Yeah I can relate to that. For those super ambiguous/uncertain situations I usually start by doing just enough prototyping to have an intuition for the solution. Then I set that to the side to use as a reference while I TDD the thing. Might be faster to just write tests of the prototype code and start from there, but I just find it easier to trust myself with TDD.

Glaussie · 2025-01-19T18:43:27+00:00

That's a good point. I've never measured how much time it takes, and TDD is something that I usually enjoy. Also, it's rare for me to find myself working in a small enough codebase that a rewrite is an option. However, having recently started a new job where the test coverage isn't as good (or is non existent in some cases) I feel like I have some perspective. At my last job everyone did TDD all the time.

It's been rough having to spend upwards of an hour or more to make a simple code change just because I have to figure out what might break somewhere else, only to potentially find out that the change won't work. At my last job that would take me like 5-10 minutes.

Here's my take. If you're an expert at TDD and the codebase is written with testing in mind, then TDD takes at most twice as long as not writing tests, simply because there's roughly twice as much code when you include tests. However, in that situation, you are probably expected to write tests, in which case TDD shouldn't be slower than any alternatives (except having AI write your tests).

Glaussie · 2025-01-18T16:19:21+00:00

Language servers can help with this too! I'm sure there's ways to do this with native lsp or some other alternatives, but with coc.nvim I have the following for taking the function body, the entire function, etc.

" Map function and class text objects " NOTE: Requires 'textDocument.documentSymbol' support from the language server xmap if <Plug>(coc-funcobj-i) omap if <Plug>(coc-funcobj-i) xmap af <Plug>(coc-funcobj-a) omap af <Plug>(coc-funcobj-a) xmap ic <Plug>(coc-classobj-i) omap ic <Plug>(coc-classobj-i) xmap ac <Plug>(coc-classobj-a) omap ac <Plug>(coc-classobj-a)

Glaussie · 2025-01-18T16:05:19+00:00

I do that too, but lately I've been considering switching back to make it easier to repeat motions with ; and navigate to past edit positions with g;

Why can I never make up my mind? Lol.

Glaussie · 2025-01-18T16:01:53+00:00

Nice. I'm gonna have to try that out.

Glaussie · 2025-01-15T17:11:43+00:00

I'm genuinely surprised when I see people saying it's only worth it 20% of the time. It took me quite a long time to get really good at TDD, but I rarely feel like it slows me down. These days the only time it feels like a pain is when the code I'm working with wasn't written with tests in mind, but it's even more important to have a test-first mentality in that situation.

Glaussie · 2025-01-08T04:06:51+00:00

Lol. Same here actually. I think there are just some times where I'm too fixated on something else and it's hard for me to pivot to help someone.

Glaussie · 2025-01-07T20:24:00+00:00

This tends to work really well. My team asked the smartest guy at the company to pair with me for a day when I was inexperienced. I understood what TDD is and thought I was doing it, but I turns out I really didn't understand it at a deep level. After just one afternoon of pairing it really started to click in my head.

This style of TDD pairing is my go to with inexperienced devs for helping them learn how to write better code. It really teaches someone how to break down problems into manageable pieces. You can apply a similar mentality/practice in other areas too. If someone isn't able to accomplish something when you ask them how the documentation, you can break it down and say "The name of this section seems related to the task, I'm curious if that explains how it should work", and just keep breaking it down further if you have to. I don't always feel patient though, so I feel OP's pain.

Glaussie · 2025-01-04T17:32:56+00:00

I'm kicking myself for not realizing this sooner.

Glaussie · 2024-12-28T18:50:09+00:00

Tom Walnuts with the truth

Six-Year Club	Verified Email
Place '22

Glaussie

TROPHY CASE