HN user

avg_dev

1,405 karma
Posts8
Comments441
View on HN
Delete tests 11 months ago

idk, i never thought

“it is blasphemy to delete a test”,

was ever a thing. i still don't.

if a test is flaky, but it covers something useful, it should be made not flaky somehow. if tests are slow, but they are useful, then they should be optimized so they run faster. if tests cover some bit of functionality that the software no longer needs to provide, the functionality should be deleted from the code and the tests. if updating a small bit of code causes many tests to need to be adjusted, and that's a pain, and it happens frequently, then the tests should be refactored or adjusted.

Confidence is the point of writing tests.

yes, agreed. but tests are code, too. just maintain the tests with the code in a sensible way. if there is something worth deleting, delete it; there is no gospel that says you can't. but tests provide value just like the author describes in the "fix after revert after fix after revert" counterexample. just remember they're code like anything else is all and treat them accordingly.

Nullable but not null 12 months ago

Thanks for the info. One minor point:

But `timeofday()` is not volatile, so `DEFAULT timeofday()` is going to lock the table for a long time.

Perhaps the “not” was a typo?

Nullable but not null 12 months ago

I believe PostgreSQL does this since v11, which was released in 2018: (current is v17)

Many other useful performance improvements, including the ability to avoid a table rewrite for ALTER TABLE ... ADD COLUMN with a non-null column default

https://www.postgresql.org/docs/release/11.0/

I think there is some restriction there, like the default can't be "volatile" - I can't remember the precise definition here but I think current_timestamp would be volatile, but any static value would not.

I really enjoyed this article. I liked what the person had to say about “care” especially, and the sort of crappy scarf that his mother-in-law still loved.

I’m both an amateur musician and a professional coder.

Definitely IMO code is a real physical thing that produces tangible results. (I personally think that code operationally is a physical thing, down to basics like logic gates and stuff. We abstract far away from that with high level languages but even making a pixel change colors is inherently, to me, altering physical reality)

But the experience of writing code and making music with your body is such a different one. You will feel and think about the code in a more imaginary and thoughtful way (you could write all your code in a notebook or a text editor and you would just be writing or typing on a keyboard) whereas the music (I play a wind instrument) is a tactile experience in the sense that it will physically be something you hear and you can actually feel the vibrations in your body; I might be wrong but I think that is what hearing is. And there is a real bio-feedback thing going on because you use your body to physically make it happen and you get immediate or very near immediate feedback (auditory, etc. You may even hear or see feedback from other musicians or even listeners). It’s just a viscerally different experience.

There’s nothing fake about seeing metrics on a dashboard or tests going from red to green or money or bits of data flowing around, at all. But it is experientially much different from the feeling of playing an instrument.

That’s my take anyway.

tbh i don't feel like the people who scheduled a 10 min meeting did anything wrong. the room is marked as free during that time; they know they will be done in 10 mins; it's a shared resource... what's the point of a schedule for a shared resource if people don't respect it?

Leaving Google 1 year ago

just a quick response, i have asked a few Go questions that he (ILT) has answered on public forums. i don't work at google and never have. but he was clear and thoughtful with me. most of all, he was helpful.

I didn't agree with everything, but I did with a lot; in particular this:

As Julie says when someone repeats that Amazon was started in a garage: Ain't no garages in the trailer park.

Not sure who Julie is, but I think she's spot on.

how is the webauthn story for FF? I recall that some hardware tokens could sometimes play weird with FF on Mac, I am not sure if Windows had the same thing. that was one practical advantage Chrome had.

Where I live, most software developers are not legally allowed to call themselves software engineers (engineering is licensed by regulatory body). Still, many do call themselves that and so do their employers. But in my view, "I don't really care until we can start coding" is not actually engineering at all.

Yes, artifacts (PRs, tickets, commit messages) should have good context (documentation) associated with them, and yes, simplicity is very important, and yes, some tech debt is always going to be incurred, but most importantly, not understanding a "legacy" system that is already running in production, and then modifying it significantly, is not going to lead to good results. I think it's as simple as that.

Don't know what language or database you use, but check this out: https://github.com/peterldowns/pgtestdb

If you happen to use Postgres, the approach is ultimately portable: it uses Pg database templates (also, regarding perf, the author recommends using a ramdisk and turning off fsync on your test DBs; you'll see this in the project readme). But you’ll have to write the code yourself.

Maybe a code gen layer that generates rust types from a db schema. I don’t know rust but have seen those in other languages. I could see a DB enum type corresponding to a language specific enum type and then the language rules applying.

I do think this is a level of indirection myself; if the generated code was perfect and always in sync, that would be one thing, but by definition it is not the case.

one of the things i like about working at very small companies is that i don't have to immediately have a solution to everything. i can file an issue and/or mention a bug or issue that i see or foresee when we talk. i can then let it marinate until it either becomes necessary to act on it or i think of a solution and have time to work on it, whichever comes first.

i often think of software as a series of problems. i don't have to worry about solutions initially. when we have polished off solutions to all of the truly immediately important problems - within some reasonable/useful level of engineering tolerances - the software can be thought of as done, for a time. just my opinion.

That sounds like a very difficult situation. Would you be willing to elaborate on what kinds of bugs lay in the pre-existing functions? Was some sort of operation that was supposed to be idempotent (“if you call it with these unique parameters over and over, it will be the same as if you only called it once”) not so? I am trying to imagine what went wrong here. A tough situation, must have been quite painful. How serious were the consequences? If you don’t feel comfortable answering that is okay.