necovek

26 ms·

691.
by necovek 10mo ago
I wonder if this has actually been used for backing up in real use cases (think how LVM or ZFS do snapshotting)? I.e. an advanced compressor could abuse the zip file format to share base data for files which only incrementally change (get a
692.
by necovek 10mo ago
Not as much geek cred for using an off the shelf solution? ;)
693.
by necovek 10mo ago
Since firmware is supposed to be accessible to users worldwide, making it easier to get it is good. But how is an open, read-only S3 bucket worse than a read-only HTTPS site hosting exactly the same data? The only thing I can see is that it
694.
by necovek 10mo ago
Can you elaborate? Is this pairing on small tasks that get done in (less than) a day? Or do you also have longer-running implementations (a few days, a week, or maybe even more?) where you rotate the people who are on it (so one task might
695.
by necovek 11mo ago
It sounds pretty simple to automate that away too: make it part of the merge hook to include the source branch name into the message. We are engineers, everything is a problem waiting to be automated :)
696.
by necovek 11mo ago
Invite engineers to solve it in a way that makes it cheap for them. Most shops I've been at prefix their branch names with ticket numbers ("bug-X-" or "TCKT-Y-"), and then it's trivial to reference it back. So
697.
by necovek 11mo ago
But if nobody writes them, they don't have the habit of reading them either. However, also make sure your PR descriptions are not "substantial" in the "there is a lot of it" sense, but only "substantial" i
698.
by necovek 11mo ago
But there are really two types of things you need to describe in a change request: - What and why needs changing - What the code does after the change One should really try hard to keep the first one answered in a change request descripti
699.
by necovek 11mo ago
What is the overall practice in the team? Does everybody write good descriptions and nobody reads them, or only a few of them write good descriptions and nobody reads them? Because if it's the latter, there's your problem: even th
700.
by necovek 11mo ago
By investing in quality on your job, your job will be easier and take less time. In software, you won't be called in to resolve that incident over the Thanksgiving weekend, and you won't be asked to debug why your system broke aft
701.
by necovek 11mo ago
It can be your problem if the company goes under and you lose your job: you might not be able to pay your mortgage or bills. If you believe your manager is asking for unreasonable things in what you are an expert in despite you raising thes
702.
by necovek 11mo ago
Obviously, unleash LLM code reviewer with the strictest possible prompt on the change :) Then innocently say "LLM believes this is bad architecture and should be recreated from scratch."
703.
by necovek 11mo ago
2 decades ago, so well before any LLMs, our CEO did that with a couple of huge code changes: he hacked together a few things, and threw it over the wall to us (10K lines). I was happy I did not get assigned to deal with that mess, but gett
704.
by necovek 11mo ago
Pairing people together on a single task makes that task get done faster, with higher quality. However, when paired together, the people still pick up some of the same biases and hold the same assumptions and context, so it is really worse
705.
by necovek 11mo ago
With time and experience, reading code becomes much easier. And well-written code is usually easy to read and understand too! The purpose of a code review is, apart from ensuring correctness, to ensure that the code that gets merged is easy
706.
by necovek 11mo ago
Right, we already had both: pre-review build & test runs, and pre-merge CI (this actually ran on a temp, merged branch).
707.
by necovek 11mo ago
Doing code review as described (actually diving deep, testing etc) for 10 engineers producing code is likely not going to be feasible unless they are really slow. In general, back in 2000s, a team I was on employed a simple rule to ensure r
708.
by necovek 11mo ago
Wow, that's a very arbitrary practice: do you remember roughly when was that? I was in a team in 2006 where we did the regular, 2-approve-code-reviews-per-change-proposal (along with fully integrated CI/CD, some of it through si
709.
by necovek 11mo ago
I believe they meant you could create an executable that is accessible outside the container (maybe even as setuid root one), and depending on the path settings, it might be possible to get the user to run it on the host. Imagine naming thi
710.
by necovek 11mo ago
There are better definitions. Monolith would be a full product (as we are talking Twilio, their main offering) in a single, tightly coupled codebase which does data passing mostly by directly calling appropriate code paths. Service-orient
711.
by necovek 11mo ago
Even better, agreed!
712.
by necovek 11mo ago
You'd still need one real measurement at least: this might get proportions right if background can be clearly separated, but the absolute size of an object can be worlds apart.
713.
by necovek 11mo ago
I'd suggest a different verb like "detach" or "unlink".
714.
by necovek 11mo ago
Oh, just funny mental gymnastics if we are aiming for survival in 10 seconds with a valid, exit code 0 tar command. :) As tar is a POSIX (ISO standard for "portable operating system interfaces") utility, I am also highlighting wha
715.
by necovek 11mo ago
Care to elaborate?
716.
by necovek 11mo ago
That's not how things play out in practice. Say you do backwards incompatible changes "infrequently", say every 4 months, or 3 times per year. In 5 years, that's 15 versions with backwards incompatible changes. Everybod
717.
by necovek 11mo ago
What you are talking about is simply keeping the API (whether a library or a service) backwards-compatible. There are plenty strategies to achieve that, and it can be done with almost any interface layer (HTTP, protobuf, JSON, SQL, ...).
718.
by necovek 11mo ago
They don't have a monolith: they have a service that has a restricted domain of responsibility matched to the team that runs it. There is nothing magic about their queue service, and it seems correctly tuned to the complexity that they
719.
by necovek 11mo ago
What everyone else is saying is that the core value proposition of microservices is that they are independently deployable (which I believe is what you are aiming for as well), which means that there is no tight coupling between them. If on
720.
by necovek 11mo ago
But really, a shared "money library" is exactly the same thing as a shared "money service" if everyone is using the same, latest version (which is easier to enforce with a networked "service"). The difference i

More ›