I know what you mean. Quite often when I’ve worked in a project where there is a pull request template, a lot of the time people don’t bother to fill it out. However, in an ideal world, people would be proud of the work that they’ve delivered, and take the time to describe the changes when raising a pull request.

I’m not an architect, but I do dislike how much of development work has AWS wrangling, dealing with the architectural hoops that are mentioned in the article

Things are getting easier. Many of the JavaScript runtimes support TypeScript out of the box now.

Back in the day, I used CakePHP to build websites, and it had a tool that could “bake” all the boilerplate code.

You could use a snippet engine or templates with your editor, but unless you get a lot of reuse out of them, it’s probably easier and quicker to use an LLM for the boilerplate.

I also make use of ‘⚠’ to mark significant/blocking comments and bullet points. Other labels, like or similar to conventional comment prefixes, like “thought:” or “note:”, can indicate other priorities and significance of comments.

Thank you for introducing me to conventional comments! I hadn’t heard of them before, and I can see how they’d be really useful, particularly in a neurodiverse team.

How does one measure code quality? I’m a big advocate of linting, and have used rules including cyclomatic complexity, but is that, or tools such as SonarQube, an effective measure of quality? You can code that passes those checks, but what if it doesn’t address the acceptance criteria - is it still quality code then?

The author does make some good points about colours as visual cues, instead of just making things look colourful. I have to admit prior to reading this post, I always picked my themes on aesthetics, but it has made me think about colour as utility.

Exactly but generative AI has exacerbated the problem

What is new is the scale of the problem being created as lightning-speed code generators spew reams of unread code into millions of projects

My understanding is that an example of a hypothesis, is that users want a feature. The experiment is putting that feature in front of users, or performing user research, which which then allows you to validate if a hypothesis is true or not.

I am intrigued. Could you elaborate on this with some examples?

After a bit of experimentation, I’ve managed to find a cleaner solution to enforcing the ticket number in the subject:

module.exports = {
  extends: ['@commitlint/config-conventional'],
  rules: {
    // Enforce scope to match JIRA ticket format like PER-123
    'jira-ticket-rule': [2, 'always'],
    'subject-case': [0],
  },
  plugins: [
    {
      rules: {
        'jira-ticket-rule': ({ subject }) => {
          return [
             subject && subject.match(/[A-Z]+-\d+/),
            'Your subject should contain a JIRA ticket eg PER-123',
          ];
        },
      },
    },
  ],
};

To clarify, when you say freelancer, do you mean on a part-time basis? Or do you mean having a contract and working on a full-time basis for that client? Also, where are you based? I’m happy to give advice as a UK based contractor, who does a tiny bit of freelance work