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
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.
Conservatives are more likely to prefer decentralised decision-making, I would say. At least nominally.
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.
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.
So, rolling your own say ‘cryptography’ is now good advice even if your solution is a worse, because we have LLMs?
Anyhow, happy holidays to all of you!
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.
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.
gbuk2013•1h ago
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).
Etheryte•1h ago
gregoriol•1h ago
mnahkies•1h ago
It's possible this is more relevant in B2B contexts than B2C
dcminter•58m ago
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.
gbuk2013•47m ago
dcminter•39m ago
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 :)
gbuk2013•3m ago
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. :)
dsego•49m ago
brazukadev•44m ago