HN Reader

"You can build a way of working that actually fits your team and company, without leaving everyone exhausted."

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.

> Thanks Linear for supporting today’s article!

Wtf, it's like I'm reading a Youtube video, except it doesn't have the production costs of an actual Youtube video.

> 2. Every code change must be reviewed

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).

What he describes as bad about feature flags is exactly the reason I want them. In most cases, the timetable to put something online does not need to correlate with deployments or releases. So as a developer, I happily outsource that decision to the product manager, give them the ability to rollback a feature if it's not working and of course I'm giving them the capability to designate a testing group if the feature needs critical evaluation. Yes, managing feature flags is a pain, but they are essential for separating concerns between management and development.

>The CTO of a startup I worked at hated dependencies. We worked with some 3D calculations (software for drones), and he was writing tens of mathematical functions himself.

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.

Every time I hear about tings like left-pad and is_even, I have to wonder... Are JS developers ok? There seem to be a lot of packages for extremely trivial things that nonetheless gets huge amounts of downloads

My understanding is code reviews are needed as part of SOC-2 compliance. More to supplement automated testing than explicitly mandated. In other words, it makes auditors happy to check off the requirement about verifying changes going to prod.

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;

Unless you’ve written Vite/rollup plugins, which many folks haven’t, you’re going to appreciate a comment that at least points to some docs.

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.

For a second, I read dogmas as some kind of X-mas for dogs, and I had a hard time parsing the title. To my defense, I haven't had any coffee yet today.

Anyhow, happy holidays to all of you!

> With LLMs, it’s easier to both get into this mess and get out of it: it’s much easier to install an unneeded dependency by mistake, but it’s also quicker to implement ‘known’ solutions from scratch.

So, rolling your own say ‘cryptography’ is now good advice even if your solution is a worse, because we have LLMs?

At my previous company, we shortened sprints, to make them fit in one single week. The satisfaction at the end of the week to have finished your planned work is unbeatable. And then we shortly stopped to call them sprints.

I’ve noticed the same pattern. Most “rules” break down once systems get long-running or stateful. Separating decision-making from execution solved more issues for us than any single framework change.

There's a danger in taking guidelines as dogmas. There's also a danger in dismissing guidelines as dogmas.

That linear ad was icky.

This just reads like a bucketlist of product recommendations.

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.