Engineering dogmas it's time to retire
newsletter.manager.dev
newsletter.manager.dev
Separating them does also create some incidental complexity (permutations of configurations, feature flag management) but in my experience that complexity is easier to analyse and deal with. (Dealing with feature flag complexity involves retiring them promptly, differentiating between feature flags and kill switches, etc.)
Of course, TFA knows this. They've moved the goalposts by making an extreme claim ("every" change behind a flag) and then argued against it.
Many folks that get into software development underestimate how much human interaction and social skill is required to "work together" (me included). Software development is a team effort. Amazingly, just by saying the words "Scrum" or "Sprint", you can get people fuming.
I think it’s crucial to get the idea behind agile software development on every level in a company. It‘s simple, actually: Communicate and get stuff done. Produce something the customer can use, quick. That‘s it. How you get there is your journey to figure out.
With all the conservative movements that are going on in the world right now, I really hope we don’t go back to micromanaging as a counter movement to agile. That would be exhausting.
Planning is hard. Not doing it is not a great plan. Conflating development cycles and planning cycles, which is what a lot of teams end up doing with sprints, either sets the pace too aggressively or not aggressive enough. If it's too aggressive you end up shipping stuff that isn't ready. If it's not aggressive enough, you end up sitting on ready to ship code for too long.
In a company with multiple teams, planning gets harder. Especially if they span multiple timezones. Company sprints are a thing in some companies. But it's not necessarily very effective or scalable.
Calendar driven planning cycles where you ship whatever is in a shippable state is much more scalable and predictable. A lot of large OSS projects practice this (most of them) and it works in large companies too. It allows teams to self organize around known deadlines and work towards them.
That doesn't mean there is no planning but it is acknowledged that plans sometimes don't work out and that that's generally not a reason to stop a release train. If some planned thing isn't ready, park it on a branch and try to get it in the next time. Many OSS projects are very strict on this actually and ship regular as clockwork at a scale and quality level that puts most enterprise teams to shame. A lot of large companies that are typically involved with such OSS work as well do this internally as well. They are too large to orchestrate company wide sprints. So they rally around the calendar instead.
It doesn't actually exclude some teams in such contexts using e.g. Scrum or other agile methodologies. It just doesn't require it. And if you know your agile history, a lot of the Agile manifesto signees were very much into teams electing to use an Agile methodology rather than that being imposed, like is the practice in a lot of companies. It's just that a lot of OSS teams don't seem to bother with that.
You may well be correct about the general case: I've not witnessed cat-herding, the closest was managment constantly chasing new shinies and one time forgetting to tell the devs about the latest change.
That said, I suspect a bad technical decision may have people and communication causes and not fixing the problem once it is apparent is definitely rooted in these.
Technical debt and leadership vacuum are both interesting and intertwined hard problems.
Conservatives are more likely to prefer decentralised decision-making, I would say. At least nominally.
At a couple of places I worked at this was a hard compliance requirement: there had to be at least one review by a human to guard against an engineer slipping in malicious code (knowingly or otherwise).
I worked on an underwriting system where we had to be able to explain the reason for a decision. This meant that you needed to have on file both the state of the flag and the effective logic at the moment in time that a line of credit was offered to a customer.
They're useful, but not necessarily simple.
Most startups can ignore all that at least until they get to a scale where "run out of money, go bust" is not the biggest risk to their business :)
There are different stages of company lifecycle, different industries, different regulatory environments etc.
The processes put in place always have a cost - if picked appropriately it is worth paying, otherwise it is a waste that can hurt or even kills a project. This balance is the “art” of the job that I personally am only starting to probe around at my level and so it is still quite interesting. :)
It's possible this is more relevant in B2B contexts than B2C
Wtf, it's like I'm reading a Youtube video, except it doesn't have the production costs of an actual Youtube video.
I use it like once a quarter and trying to remember how to mark a task finished makes my eyes water.
The remarks about code comments are little too extreme in my opinion. Some code can be difficult to understand at face value. Like I’m writing a Vite plugin and it has code like this:
const moduleId = "virtual:mypkg";
const resolvedModuleId = "\0" + moduleId;
If anything, succinct code comments that explain obscure conventions or describe relevant critical requirements are worth their weight in gold because they are valuable tokens for a coding assistant.
From the article:
> I definitely think you should use feature flags - just not abuse them.
What a terrible idea. Implementing mathematical functions is extremely hard to do well. And by well I mean "function properly at all". This isn't about speed, this is about the fact that if you haven't done actual research into what you are implementing, then your implementation is going to full of errors, many of them totally non obvious. Rolling your DIY numerics, without spending a lot of time on it is just asking for problems.
Plus then making them work optimally on N different microarchitectures.
I actually wonder what language/system they were using that lacked this in the stdlib or at least in very widely available libraries.
Also, I'd bet money that most people couldn't write most things bug free on the first try without looking stuff up unless it's trivial
If this was such a common use case that it warranted being in some sort of stdlib, then make a standard lib and make sure it can’t be deleted.
We’re stuck with it now. We should be engineering front end with the assumption that it will break or get compromised.
Anyhow, happy holidays to all of you!
So, rolling your own say ‘cryptography’ is now good advice even if your solution is a worse, because we have LLMs?
I found the following to be most amusing, as the author explains the idea of “Iterations” without mentioning them by name:
> We work in 6-week cycles. Once a cycle is over, we take one or two weeks off of scheduled projects so everyone can roam independently, fix stuff up, pick up some pet projects we’ve wanted to do, and generally wind down prior to starting the next six week cycle.
> Note: These are not sprints. I despise the word sprints. Sprints and work don’t go together. This isn’t about running all out as fast as you can, it’s about working calmly, at a nice pace, and making smart calls along the way. No brute force here, no catching our collective breath at the end.