Hi Arthur Denner . You raised a good point that I didn't highlight. Thank you for that. And thanks for the read too.

Nice! Thanks Simonas Urbelis . Thanks for checking through it too. That's a really interesting find. I would love to be able to run the same code across different machines with different specs. My hunch was that the number of cores on a machine had a big effect on parallel performance too. It's a shame you can't share your GitHub implementation. That would be lovely to see. My aim, unless someone does it before me is to create a GitHub repo and be able to take advantage of their machines to run the tests and benchmark them too. That'll make the tests more fair. True. Also, I have to decide whether I want to test just blocking or truly sequential. So as someone mentioned the node:test overhead, I may have to remove node:test completely so there are no promises or async awaits being used in the callback tests at all. Thank you again for your comment. I truly appreciate it.

Thank you, Sergei. That's a very important point. I noticed when I ran all the tests together, it increased all the times. So you make a good point that node:test may have a greater effect than I expected. Hopefully the results still work out relatively but still, it's definitely worth comparing. With the promises test I tried to avoid using await, so I'm not sure if that is causing the increase in the times you saw. But I'd love to take your example and tweak it without node:test and without the await/async in the promises test to see the results. And thank you for taking the time to read through the benchmarks. I really appreciate that too. And helping pointing out any flaws in my benchmarks. It's so helpful.

👏👏👏 True Ricardo Lopes . I should compare blocking to blocking. One thing that came to me was also resource usage. I hope you won't mind me mentioning you in the article as a helpful reviewer too?

Yep. That changes things a lot! 😂. I'll do an edit! And thank you for taking the time to read 🙏

Oooooh. Really good point, Ricardo. Let me address that and re-run those tests. Yes. I told you I was a really bad benchmarker! 😂 test('callback passing test', (t, done) should help.

Nice Brian King ! Either way sounds good to be fair. If it's like docker-in-docker 😂, as funny as it sounds it's something I do inadvertently within CI, but it would be good to see an intentional use and use-case.

Chaitannyaa Gaikwad It was my second job, and after the main team left who managed Jenkins among other things (and who were exceptionally more senior and advanced than I was), I found it incredibly complex to use as a beginner developer versus something like TravisCI or now GitHub Actions. Because of this complexity, I opted for simpler and easier solutions ever since. First off, in my first few years of development, I wasn't smart as you to take the time to learn Jenkins. But your tutorial has made me want to revisit it again. So I'm sure I'd be learning from you! If I were to use it again, I'd use it to split my CI from CD solution. So I'd continue with GitHub Actions for CI to build an artifact, like a containerized image or zip. Then I'd use Jenkins for CD, allowing non-engineering to trigger deployments and move releases through a QA->UAT->pre-prod->production pipeline using a nice GUI interface. I know this can be achieved through GitHub Actions (especially their higher-tiered versions), but with cost-savings, Jenkins now looks like a good solution.

Brian King Nice. Is it a weekly update you keep to or do you write articles as-and-when you can? Nevertheless, I look forward to containerisation stuff especially.

Organize team-building activities or events to promote collaboration and build strong relationships among team members. That's a good point. That's something with remote working that's harder to do.