hitchstory

9 ms·

31.
by hitchstory 2y ago
>as though framing problems "in a way coding agents can solve" is itself a well-understood or bounded problem. It's not, but if you can A) make it cheap to try out different types of framings - not all of them have to work
32.
by hitchstory 2y ago
The pyramid makes sense for certain types of application - very logic heavy with light integration touch points with everything cleanly dependency injected. rqlite fits this pattern. If you're building a logic lite application which
33.
by hitchstory 2y ago
That sounds like a reasonable average, yeah. Some tiny changes take 45 seconds, some harder changes take 40 minutes. I find that working in working code increments that are as small as possible to be ideal.
34.
by hitchstory 2y ago
People leaving is a great reason to write literate tests and other kinds of docs - the kind people actually look for and want to read. If somebody asks a question that can only be asked by looking in a commit message that usually repres
35.
by hitchstory 2y ago
I do squash them where appropriate. I do use git stash where appropriate. These arent nonobvious novelties, save perhaps to junior engineers.
36.
by hitchstory 2y ago
I mostly just message the person who wrote it if I have questions when I look at a commit and have questions. I suppose if I painstakingly write 1000 beautiful commit messages I could save myself from having that one conversation when som
37.
by hitchstory 2y ago
> can be good self-promotion. You may not realize When I said nebulous and hard to pin down this is kinda what I meant. Do you routinely monitor commit messages on adjacent teams' repos? I dont. I dont know anybody who does. When
38.
by hitchstory 2y ago
I'd estimate I probably commit ~30-50 times a day. I dig into and read a commit message once every 3 months. A 90 seconds a commit that's an hour a day spent writing beautiful commits. That one hour a day could be substituted with
39.
by hitchstory 2y ago
>Already it’s pulling teeth just to get literate commit messages… I usually push back on this because those commit messages almost never actually get read. It's an investment whose dividends are nebulous and hard to pin down. It&#x2
40.
by hitchstory 2y ago
A drop in remote worker will still require their work to be checked and their access to the systems they need to do their work secured in case they are a bad actor.
41.
by hitchstory 2y ago
My issue with the formal methods community is that it always tended to hand wave away the cost/benefit trade offs. It's not that they didnt see those trade offs (they constantly reiterated that they weren't suitable for every
42.
by hitchstory 2y ago
>if it was really that helpful, more people would be applying it and the benefits would speak for themselves. They've been around a long, long time, though, and never caught on - it's hard not to conclude that there's prob
43.
by hitchstory 2y ago
That depends on what the drawings are of.
44.
by hitchstory 2y ago
>Engineers dabbling in documentation and feeling lost as they approach the field, on the other hand, are drawn to docs frameworks because frameworks are all they’re used to working with Im drawn to frameworks because without them I canno
45.
by hitchstory 2y ago
I dont either, but this can be mitigated by adding guard rails (strictly validating input), double checking actions with the user and using it for tasks where a mistake isnt world ending. Even then mistakes can slip through, but it could st
46.
by hitchstory 2y ago
Snapshot tests are even more sensitive to flakiness than E2E tests but flakiness is still a bug that can (and probably should) be fixed like any other. As an example - the different browser you have running locally and in CI? That's a
47.
by hitchstory 2y ago
>the algo-heavy code is a small fraction of the total code they write Wasnt the case in the trading firm I worked at. Do you work at Jane Street? Have you worked elsewhere?
48.
by hitchstory 2y ago
>in my opinion, because users don't care about "custom widgets," "queues," or "databases." Users care quite a lot when these things break. >They care about business functionality, which is quite easi
49.
by hitchstory 2y ago
>Why is PBT useful at Jane Street, at least more than in other places? Because trading firms write a lot more algorithmic code than most businesses. Trading strategy code is intensely algorithmic and calculation heavy by its very nature
50.
by hitchstory 2y ago
Trading companies are unusual in writing a lot of algo-heavy code. Did you assume every company was like this? I can assure you they arent.
51.
by hitchstory 2y ago
>Hah! Try to separate your domain logic from your interfaces Im not an amateur. The only time I dont do this is when there literally is no domain logic yet (e.g. a CRUD app). >In my experience, these gaps are what's typically e
52.
by hitchstory 2y ago
If the arbitrary input is, say, a text box which takes a name and puts it into a database, it probably won't uncover any bugs. It has some use if you build something like a complex pricing engine, numerical code or a parser for a mini
53.
by hitchstory 2y ago
Property testing is a lot like formal methods - really cool, but almost entirely useless in ~95% of commercial contexts. They're both extremely useful when, say, building a parser, but when the kind of code you write involves displayin
54.
by hitchstory 2y ago
I use it for: * Reminders * Checklists * Idea collation * Fleshing out and prioritizing personal tasks * Reference notes - e.g. passport number, tax numbers, frequent flier numbers, anything else I might want to input into a form one day.
55.
by hitchstory 2y ago
It often protects me from things I miss. E.g. when I'm TDD'in a feature and I'm implementing the 5th-6th test I often find myself inadvertently breaking one of the earlier tests. I do think there is such a thing as overtestin
56.
by hitchstory 2y ago
There isnt much consensus on the right kind of test to write with TDD, but when you get it right or wrong it makes or breaks TDD. Recently Ive been writing mostly "end-to-end unit tests" - stateless, faking all external services (
57.
by hitchstory 2y ago
>Unit tests tend to have a lot of boilerplate sometimes, often not copy-pastable When people use LLMs to write code and they find if helpful, invariably it is because they are spewing boilerplate. If you dont systematically eliminate b
58.
by hitchstory 2y ago
Using LLMs to generate tests is bizarre. If anything, humans should write the tests and the LLMs should make it pass. Tests lose value the further away from the spec they drift. Writing a test after the code causes drift. Writing with an LL
59.
by hitchstory 2y ago
>If you’ve ever heard someone claim that Test-Driven Development leads to zero-defects code I havent. It's a lot more reliable, still not 100% reliable. >If you can define the inputs, predict the outputs, and cover edge cases,
60.
by hitchstory 2y ago
How do you do that? Im curious because I wrote a framework for this (same name as my username) but when I talk about the idea I receive a sea of blank faces.

More ›