Many technical leaders know how to scale what they build,

but many don't know how to scale good practices in a team.

4 lessons to teach your team at scale, from the Samman method:

1️⃣ Active over Passive

Understanding new concepts require elaboration.

Provide a space for others to elaborate either by talking or writing, and less by listening or reading.

Rather than getting others to sit in a 1-hour talk to learn new concepts, facilitate a 1-hour session where they can sit down and actively elaborate.

The Samman method calls this the learning hour.

You can still give a talk, but cap it to 10 minutes.

When elaboration is done as a group exercise, the team will benefit from listening to each other's elaboration attempts.

Listening to diverse articulation strengthens the connection to new concepts better.

2️⃣ Concrete over Concept

We build connections in our heads when we put new concepts into practice.

Provide an easy medium for others to practice so that they can start to build the connection.

Create small exercises for others to experiment on, and do this as a large part of the learning hour.

If the concept you're trying to teach is about coding, prepare a small kata where others can apply the concept.

This kata can be borrowed, or created from your codebase.

Group people to experiment and learn together during learning hours.

Not only is that more fun, but your team will be less dependent on you once they have built the habit of learning from each other.

3️⃣ Real World over Experiment

The best connection is built when the concepts are practised in real-world settings.

The small experiment in a learning hour may help some start a connection, but engineers may not be able to see how the methods can be practised in the codebase.

When you apply what you've taught in the team's codebase, chances are you'll discover that there are many concepts that the team have yet to learn.

For example, if you've been teaching about how to organise tests, questions might come up around the approach to mocking.

You can show the real examples applied in code, or more effectively practice the new concepts together in a pair programming activity.

Better yet, why don't you do it together as a team? The Samman method encourages the use of Ensemble working, which brings us to ...

4️⃣ Activity over Artefact

As a technical leader, many of the technical artefacts (including code) you produce are more valuable when they're produced together in a group activity.

A group activity allows you to scale better as you'll repeat less.

I used to fall prey to producing technical artefacts like the C4 Model or Wardley Maps, alone, later to find out that it didn't mean anything to others when I presented it.

Concepts that were new to others at the code level had the same effect: they didn't mean much to others.

The Samman method encourages coding in a group activity i.e. Ensemble programming.

Ensemble programming definition by @WoodyZuill: "All the brilliant minds working together on the same thing, at the same time, in the same space, and at the same computer".

Ensemble programming allows you to get others to see how you'd bring new concepts into the codebase.

Best of all, given that you'll be rotating the typist around, others will also get to practice the new concepts in the codebase, finally making the ideas concrete!

If you're concerned about the productivity loss from Ensemble programming:

1. Think about the time savings you get from wait time.
2. Think about the long-term productivity gain from the learning.
3. Think small, you don't have to do it all the time.

To get more in-depth experience on how to use Ensemble working to teach software engineers, check out "Learning through the Ensemble with @ClareSudbery" interview video by @mob__mentality.

https://www.youtube.com/watch?v=L5hbonDKITo

That's a wrap!

The key to scaling learning is to ensure that effective learning is happening even in your absence, and the Samman method will help you do that.

To learn more about the Samman method, you can check out the @CoachingSamman book by @emilybache or the official website.

https://sammancoaching.org/.

4 Lessons to Teach Good Practices at Scale (the Samman Method)

X: How did you get your 6yo into coding?

5 ideas (and examples) I have tried based on the flow model:

This thread contains privilege, luck, and survivorship bias, and has been controversial with some parents/carers when I shared them in person.

Take the ideas with a grain of salt.

This is my 6yo playing with Scratch very recently after @pgr0ss recommended a book on Scratch programming.

1. Provide and articulate flow experience.

Children need a good reason to return to an activity just for the sake of it, and the flow state is the answer to that.

Continuously review their activities to match their skills and challenges to help them enter the flow state.

Help them articulate the flow state, children begin to learn about emotions at 3yo.

Whenever my 6yo enters the flow state at home, I'll help her articulate that feeling as 'enjoyment', or 'focus'.

Example: One characteristic of the flow state is the transformation of time.

Me: "You sure enjoyed that a lot. You've spent 2 hours coding!"
6yo: "What? 2 hours?!"

The flow experience can be provided in the early years.

We were lucky enough to be able to afford for our child to go into a Montessori nursery since she was 2yo.

I think some Montessorian principles help enter flow, so that's something you could explore.

2. Provide connections from current interests.

Most children will experience the flow state not in coding for the first time, therefore you need to connect their interests from non-coding to coding.

What's important here is to understand the concept of "interest".

Something is interesting when it hits the balance of relevance.

When something is not relevant, it's uninteresting. When you've done it before (too relevant), it's ALSO uninteresting.

When you see a spark of interest, ignite them.

For example, the flow experience that my 6yo experienced in her early years is puzzle solving.

I connected puzzle solving to various other toys, various video games, and then later to coding-related puzzle toys or games.

The first coding-related toy she played with was when she was 2yo.

The first coding-related video game she played was when she was 3yo.

Don't get stuck in finding the "best" coding video games, or the "best" coding toys.

Try a variety and see if they spark any interest.

Familiarity with a computer helps a lot, she used to draw on a computer (she loves art & crafts, so that's one other connection).

Map their interests into the flow model. This may help you connect their interests better.

You could also connect programming ideas to their daily lives.

She struggled to understand nested if statements, here I showed her that she already understood it!

The strikethroughs were her correcting the logic based on what she has in her head.

3. Provide new challenges.

The more your children are doing the same flow activity, the more boring the activity would get. This happens because their skill will increase.

For them to get back into the flow state, you need to provide a new challenge.

It's a good thing for children to feel bored when they do a certain activity (as long as they still sit on it), so don't push for new challenges too soon.

Boredom lets them learn and get creative, and hopefully, that creativity will generate a new challenge for themselves.

The problem arises when they can't generate a new challenge for themselves.

You have to be there and provide them with new challenges they could take on.

My 6yo tried a few coding video games and some of them get boring quickly because they don't have enough challenges.

I'd find other games where there were more challenges.

Again, don't get stuck in finding the "best" toys or games. If the games start to get too easy, find other options. There are many options out there.

4. Provide support (scaffolding).

Sometimes in the exercise of finding a new challenge to get your children out of boredom, you can't actually find any challenge that fits their skills. This triggers anxiety.

You need to support them closely.

Some video games jumped from basic coding skills into advanced skills too fast that my 6yo couldn't cope.

When she tried Scratch, it was also really hard for her as there wasn't any roadmap she could follow. There are a lot of features that she needs to familiarise herself with.

To get them through the challenge, sit with them.

For example, I tend to sit with my 6yo to play Scratch or Lego Spike, with me doing the same exercise.

Years before, I'd play coding toys or video games with her and support her.

If you are anxious about coding, though, it's probably best not to sit with them. Children mirror your anxiety.

This is one of the reasons why children have math anxieties, they mirror their parents' math anxiety when they sit together.

Maybe find a tutor if you're really keen?

Praise for effort when your children get through the challenge. This will cultivate a growth mindset.

And... Encourage them to take breaks.

(I still can't believe how hard it is to get my 6yo to take a break from coding - she's like a tiny strong-willed software engineer that already builds up a bad habit).

5. Provide external rewards.

This is probably controversial for some of you.

For me, external rewards are important to encourage my 6yo to step out of low-skill, low-challenge activities.

Think of your current hobby.

How did it start?

Chances are, you had an external motivation first (friends, money, family, etc) before it becomes intrinsically motivated.

We provide rewards by using pocket money.

She surprisingly builds up a desire to buy children's magazines from an early age. They cost £5 each, and she'd only spend 1 hour on them.

It's costly, so whenever she wants to buy them, I'd ask "Do you have enough money to buy it?"

To earn the pocket money, I asked her to build daily schedules on her own (because the one I made for her she never followed), and when she sticks to her schedule, she'll get pocket money!

We used this last year and it motivated her a lot to get going.

This is the most recent way she earns pocket money.

Interestingly, she never really cares about this version, last Sunday we Scratch-ed for 2 hours and she didn't even care about tracking them.

I take that as a good sign that she's doing coding for the sake of it.

She tried other revenue streams that she really liked, but this thread is getting a bit too long, so I'm going to wrap it up!

To help children master a skill, try: experience, connect, challenge, support, and reward.

Children being children, she might eventually shift interests and might not find coding cool anymore.

Regardless, I hope you found those 5 ideas useful. Remember that these are not steps, you have to meet where the children are in the model!

Good luck!

Ana had also previously applied the idea of flow to children if you'd like to read more about it.

https://twitter.com/anafabrega11/status/1507398544537362441

You can read the unrolled version of this thread here: https://typefully.com/ceilfors/Az4EFbs

Using the flow model to get my 6-year-old into coding

Are you still sceptical about TDD?

I'd like to challenge your beliefs and assumptions by sharing the 8 common fallacies about TDD.

Firstly, how are fallacies formed in our heads?

Fallacies (incorrect beliefs) are formed in our heads because of how we infer information.

Given the amount of information that we consume, human brains have evolved to filter a lot of information out to make an inference and jump to conclusions, the fallacies.

That's why believing in fallacies should not be seen as a weakness.

My intention here is to help you climb down the ladder of inference.

Here are the 8 common fallacies about TDD and how to think differently about them:

❌ Fallacy 1: If it's not here, it's not anywhere.

"We don't use TDD in our team, no one practices TDD. Most practitioners are talking about it because they're trying to sell their courses or talks."

✅ That's a faulty generalisation. When I was working for ThoughtWorks, people around me practices TDD. It was also one of the competencies ThoughtWorks check in the interview process.

( Do you think it's useful to see my real work streamed live on a platform like YouTube/Twitch? Like this tweet so that I can consider it. )

❌ Fallacy 2: A fun workflow is fun to learn.

"Most TDD practitioners told me how fun it is to do TDD, but it's somewhat quite stressful when I tried it. TDD is not for me."

✅ Effective practices require you to push yourself outside of your comfort zone. This feeling may or may not be fun, it's subjective. Not fun could be a sign that you're practising properly!

You may find TDD fun when it's no longer outside of your comfort zone.

❌ Fallacy 3: If it's not widespread, it's not a good idea.

"We'd been talking about TDD for a long time, the fact that it's still not widespread means it's not a good idea."

✅ Not all widespread things are a good idea e.g. cigarettes.

Meditation sharpens our attention, but it's only practised by 15% of the UK population.

❌ Fallacy 4: Simple workflow is simple to adopt.

"TDD practitioners told me how TDD is a basic skill, I tried TDD for 1 week and discovered that it's slowing me down."

✅ Think about bad habits in your favourite sport that you're trying to correct, it's hard. The process of unlearning is hard in any activity.

Whilst you can see benefits faster when adopting new tools, a workflow that requires a change of habit takes patience and time.

❌ Fallacy 5: Self-confidence reflects great workflow.

"I'm confident with my current workflow. I've not seen problems with it, it works fine. I don't need to change my approach."

✅ With respect, confidence is not a reliable indicator of skill. This is a well-researched study:

The lower the ranking of the chess players, the more they are confidently overestimating their chess skills.

Collecting feedback from others or coaches is also useful.

❌ Fallacy 6: If it's not natural or intuitive, it's not a good workflow.

"I tried TDD and everything just seems backwards to me. Writing tests first is just not natural or intuitive. It's not for me."

✅ The idea of the earth being spherical was not intuitive. The idea of the earth orbiting the sun was not intuitive.

Some good ideas are not intuitive at first.

Trust your intuition less, our intuition deceives us.

❌ Fallacy 7: New era requires a new workflow.

"TDD is old and being taught by people who are 60+ years old. We now live in a new era, technology advancement renders what's been discovered outdated."

✅ Effective workflow optimises your head. Our primitive brain hasn't changed significantly, therefore what's been discovered would still be relevant for years ahead.

If you have a 'modern' well-defined workflow where you can articulate its benefit well, I'm super keen to learn.

❌ Fallacy 8: Complex problems require a complex process.

"Building software is a difficult business. There is no way a simple 3 steps loop like TDD is going to help our situation better.

Surely a great outcome requires great effort."

✅ Niklas Luhmann wrote over 70 books and 400 articles on various subjects. The amount of writing he had written is not only a matter of quantity but of quality.

When he shared his workflow, Zettelkasten, the world of writing thought it was too simplistic to be true to adopt.

The last fallacy is probably one of the reasons enterprises are looking to frameworks like SAFe to adopt Agile.

Agile is too simplistic for large enterprises.

I don't know if this thread will change your mind, but hopefully, it'll encourage you to try TDD again!

How does an effective workflow optimises our head? See my previous thread where I cover this in detail.

https://twitter.com/ceilfors/status/1578324320555716609

8 common fallacies about TDD

Do you struggle to code after a meeting? In the morning? Do you struggle to pay attention to a meeting after a deep work?

We know that context switching is costly but we rarely talk about how we can be more interruptable.

Here's a simple interruptible workflow that you can try:

When we are getting interrupted a lot, our natural reaction is to try to reduce the number of meetings.

Unfortunately, we can't entirely eliminate meetings therefore I'm not going to talk about optimising meetings, but rather optimising our workflow.

I first discovered this interruptible workflow from @kctang 12 years ago.

Every day when he's wrapping up his day, he would type something like this to his IDE (see the red curly errors), then go home on time.

He then would come in the next day instantaneously productive!

I was sceptical at first, but this is now my habit for 12 years! This quirky technique works surprisingly well for me.

I practice the technique not only before I wrap up for the day, but also before meetings.

To resume your flow state, you have to pause in the middle.

Here's how and why:

1️⃣ Pause when you're about to be interrupted.

This is easier said than done and probably sounds crazy.

All of the information I need to finish the task is already in my head, why would I stop?!

a) The code I write when I rush is normally crappy.

b) My estimate is always wrong, and it always takes longer to finish my task. Why bother working late writing crappy code?

c) This is also apparently practised by credible authors:

Roald Dahl, an author who's sold 250 million copies worldwide, learnt a trick from Ernest Hemingway:

"When you are going good, stop writing."

This keeps Dahl's writing momentum as he'd never have to deal with those scary blank pages. He knows how to resume work the next day.

There's, however, an undesirable side effect to this technique.
When you pause, your unfinished tasks will linger in your head. Your subconscious will still work on it.

We will now mitigate this in the next step.

(Note: This side effect can be desirable in some cases!)

2️⃣ Flush your working memory.

Write down everything that you have in your working memory to the 'inbox', which you'll 100% look at after the interruption is complete.

This can be your IDE (like @kctang's example above), or in any tool, or even in sticky notes.

The reason we can't switch off, or focus on meetings after deep work, is because of the Zeigarnik Effect; the tendency to occupy our working memory with unfinished tasks.

Writing activity tricks our brain into forgetting the unfinished tasks, circumventing the Zeigarnik Effect.

You have to write all the things related to the task until your head is empty.

Type as quickly as possible.

This doesn't need to be pretty, you can have typos, it doesn't have to have the right grammar, it can be anything so long as you can recall it later.

After the writing, context switching into meetings is easier. You'll feel something that GTD-ers would describe as "Mind like water" i.e. water is shapeless, put it in a bottle, and it becomes the bottle.

When I do practice this technique, I can code in between meetings easier.

Depending on your role, after your meeting is finished, you might want to flush your working memory again before you move to the third step.

For example, I'd sometimes flush all my thoughts and/or feelings into my personal meeting note. Empty your head, again.

3️⃣ Restore your working memory.

This is the easiest part of all. You look at what you have flushed in the previous step, then resume where you left off. You'll no longer have the scary blinking cursor or blank page.

What you have jotted down in step 2️⃣ is now serving as a cue to retrieve your relevant memory.

If forgetting is a process of inhibiting irrelevant memory, what we have written in step 2️⃣ helps circumvent the inhibition process at the right moment via written cues.

This is also where what you have written in step 2️⃣ is important. The more cues you have written the better, it will increase your retrieval memory strength.

Remember, it doesn't need to be precise, grammatically correct, etc. Type it quickly!

Managing an ad-hoc interruption is similar. My wife often interrupts me as I'm working from home.

When this happens, though, you are skipping step 1️⃣ without willpower, so it's a chance to practice!

Next, let others that you need to 'flush your memory' before you can respond.

There you have it.

To resume your flow state, you have to pause in the middle.

I know some engineers hate meetings with passion, so I hope you'll have a better relationship with interruptions!

Do you already practice something similar? What habits have you built to handle situations like this?

Share it with us!

Setting a mind point

Great communication skill is essential in making an optimal technical decision.

Behaviour-Driven Development (BDD) is a tool that can help teams communicate better.

Let me tell you a short fiction about how BDD helped a team succeed:

In the beginning, there was a team who were building a product that will make millions of pounds.

Let's call that team Granola, because who doesn't like good old granola?

They struggle to deliver as the product should submit data to the legacy system at the backend.

Given the legacy integration challenges, a new architect was hired to help Granola tackle those complexities.

They were sitting in their ivory tower, observing and collecting information. It's a big enterprise after all.

One day, the architect decided to soar and strike up a conversation with Granola's PM to solve the integration challenges.

Architect: So, would you like the system to be synchronous or asynchronous?
PM: What do you mean by that?
Architect: Is the form sync or async?
PM: 🧐💭

<Long discussion>

PM: Let's reconvene in a week.

Another week passed, and it was time to soar.

Architect: Give me your decision. Is it async or sync?
PM: I, uh, I'm not sure if that's a product decision, to be honest.
Architect: But I need to know if it's going to be async or sync to architect this product.
PM: 🤔💭

These types of conversations went on for weeks. Poor Granola. By now, they are blocked and unable to move ahead.

Is it going to be sync or async? It's all a mystery.

In all the frustration, the famous Cucumber Newsletter landed in the architect's inbox.

The newsletter introduced BDD. It talked about how it has saved some communication costs in Gherkin Ltd. It showed how communication can be easier when a Given/When/Then language is used.

That looks extremely simple, the architect thought.

Let's give it a go, it's time to soar again.

Architect: *Given* that the form has been filled out. *When* the button is clicked. *Then* what do you expect to happen?
PM: I expect the data to be readable in the legacy system.

Architect: And *Then* what happens to the form?
PM: I would expect it to show that it's been successful.

Architect: Do you expect it to show the submitted data in the table below immediately?
PM: Oh yes, of course.

There are sparks in their eyes now.

The PM thought, finally, this person is talking in human language.

The architect thought, finally, the PM is making a decision.

Architect: *Given* that the form has invalid data, though. *When* the button is clicked, what *Then*?
PM: It immediately shows an error.
Architect: That's expensive. How about we *Then* send an email instead? Here are all the options I can think of ...

<Productive conversation>

A month has passed. Team Granola is now collaborating really well with the architect and delivering at a steady pace.

Every time something is not clear, they would sit together and talk in the Given/When/Then language, even writing it down for a shared understanding.

Even better, the developers are now taking what's been written down as an inspiration for their tests.

And they lived happily ever after.

The moral of the story:

✅ BDD is a communication tool that's useful in a certain context.
❌ BDD is a silver bullet, adopt it, and all your problems will disappear.

I hope this gave you more insights into your original questions @twtyagi

https://twitter.com/twtyagi/status/1578425720136556548

Granola and BDD

Many of the software engineers I talked to told me that they practice TDD out of guilt.

That's not right, we need a different way to think about TDD.

I've been practising TDD for almost a decade, here's how I currently think about it:

Current literature focuses on how TDD is the best design technique out there, therefore we have to adopt it.

But, I don't use a hammer merely because it's the best tool to drive nails, it's also because I can't drive nails without a tool.

Let's try that angle instead.

Effective techniques or tools circumvent our biological limits.

Usain Bolt can't outrun a domestic cat, but on a bicycle, he could.

When it comes to creative works, such as programming, our biological limits are in our heads.

It's difficult to recognise what our limits are when it's in our heads. We're not going to visibly bleed if we're not using any tools to drive those metaphorical nails.

Therefore I think it's important for us to describe what our limits are so that we can recognise and address them.

Here are three limits that I observed throughout my career:

1️⃣ Willpower

Not all of the work that we do to keep the business running is interesting or exciting. To motivate ourselves to do the work, we use our willpower.

Unfortunately, willpower is a resource that depletes quickly. We will run out of mental energy, which is quite limited per day.

That dopamine boost coming from chasing something shiny is also hard to resist.

We need to have an alternative resource to motivate ourselves.

2️⃣ Working memory

There is a lot of information that we have to juggle in our heads to ship a change. We need to think about the user needs, UX design, architecture, engineering principles, tech debts, writing tests, those old libraries, and the list goes on.

Unfortunately, we can only hold 7±2 things in our heads at the same time. We often think about the wrong thing at the wrong time e.g. we would refactor or optimise before our code is working.

We need to have the right information in our working memory at the right time.

3️⃣ Wit

We need to apply our intelligence to our work. There are many business and technical challenges that we need to solve, therefore we would think about the best solution to tackle all those challenges.

Unfortunately, our wit often introduces a whole set of new problems. We don't spend enough time thinking about simpler alternatives. We try to be clever at the wrong time.

We also tend to jump to conclude that we know enough about what needs to be solved and start coding without thinking ahead.

We need a system that helps us control when or when not to be clever.

Those three limits are what we need to circumvent, and we need a technique to help us work better.

The answer to that is an effective workflow.

Seriously, a workflow?

Yes. Niklas Luhmann famously wrote more than 70 books and 400 articles on various subjects. The amount of writing he had written is not only a matter of quantity but of quality as well.

The secret to his abnormally impressive productivity is his workflow.

What does an effective workflow look like in our software engineering world?

I'll describe them below whilst connecting them to TDD.

1️⃣ Effective workflow forms a positive feedback loop

The answer to our limited willpower is not stronger willpower, but to think about how we can live without willpower. The answer to this in creative works is a positive feedback loop.

We motivate ourselves by making a progress, and we know we're making a progress by getting feedback. The best kind of feedback that we should look for is the feedback that we get from the work itself, which will create a feedback loop.

When you practice TDD, every time you make your red tests turn green, you are making a progress. That's a positive feedback loop.

2️⃣ Effective workflow embeds a sequence (via a mnemonic device)

We would like to fill our working memory with the right things in the right sequence. A mnemonic device helps us remember this. We can recite the sequence of the alphabet by singing the ABC song as a mnemonic.

TDD's mnemonic device is Red > Green > Refactor. Each of these steps pulls different information into our heads in the right sequence, circumventing our working memory.

The separation of Green and Refactor is also the answer to circumvent our wit. The green step encourages us to think simple. What's the simplest way for us to make this red test green? That will reframe our heads differently.

3️⃣ Finally, effective workflow enables flow state

Flow state is correlated to happiness. Who doesn't want to be happy at work?

The prerequisites of a flow state are clear goals and immediate feedback.

Each of the steps in TDD defines clear and smaller goals for your task.

Each of the completion of the step, each of the green tests you're getting, and each of the commits you're making after the refactoring step is a form of immediate feedback.

In summary, an effective workflow is required to organise our heads better and circumvent our biological limits.

TDD may not be an answer for everyone, but it's one of the workflows that I found effective so far (I do have other workflows that complement TDD).

If you have a workflow that circumvents our limits, I'll be keen to know.

And don't feel guilty if you don't practice TDD!

I would appreciate your thoughts and feedback on this rambling 🙏🏼 @RonJeffries @GeePawHill @KentBeck @hillelogram @allenholub @tottinge @unclebobmartin @davefarley77

How TDD helps me organise my head

Smaller commits help retain my flow state, therefore improving my productivity.

To have smaller commits, you have to be able to slice your task into nano-slices. I have found adopting Angular's commit format to be helpful in the slicing activity.

The part of the commit format that helps me slice my work is the definition of commit types.

You don't have to remember all of the commit types to start with. In day-to-day development, I'd only use four of them: feat, fix, test, and refactor commit types.

Before I start my work, I tend to have these commit types in my head.

What is it that I'm doing now? Is it a `feat` or `fix`? Is it a `test`? Is it a `refactor`? Then I'll start coding, attempt to consciously stop when I'm done, and then commit.

I try to timebox each of my commits. If I can't a single commit to my 25 minutes pomodoro timer, I might have not analysed the task well beforehand.

The types are short and self-evident, therefore they're not too intrusive to your team.

Once you adopt this, your commit history patterns might look like the following:

1. feat/fix > refactor > (perf)

Following @KentBeck's mantra of "make it work, make it right, make it fast".

Notice that `perf` is a separate commit type. I like performance improvement to be done as a separate effort, which encourages less premature optimisation.

2. refactor > feat/fix > refactor

Following @KentBeck's articulation of "When you want to make a change, first, make the change easy. (Warning, this may be hard.) Then make the easy change".

3. test > feat/fix > refactor

The `test` type is not meant for adding *new* tests, but I break Angular's guidelines here especially when I spent too much time writing the new tests.

To keep your commit to be a working commit, ignore that new test (`it.todo` if using jest).

Angular's commit format is not the only format that you can use https://twitter.com/cvennevik/status/1575060818768842753

You can find the original Angular's commit format here https://github.com/angular/angular/blob/22b96b96902e1a42ee8c5e807720424abad3082a/CONTRIBUTING.md

Note: Even though Angular's commit format is now standardised as conventionalcommits, the commit types that I have found helpful are not part of the standard.

https://www.conventionalcommits.org/en/v1.0.0/

Bonus: You can use commitlint + husky to ensure to instil the habit of committing this way.

Make sure you're using this package so that the commat format is enforced. https://www.npmjs.com/package/@commitlint/config-conventional