Thanks a lot!

Thanks for your response! It's excellent food for thoughts for me on how to argue in favor or unit test. You are right, "API e2e" can be a perfect tool in numerous instances. My work in 95% on the frontend, and I tend to forget about more backend focused approaches. A few years ago, I was heavily investigating testing JS tools for testing API—as a frontend dev you are doing QA for the backend anyway, so a bit of automatization can help here. I think a big difference between our projects is that in my case I have in mind: that at some point I can be outnumbered by junior devs, and I want them to: do a bit of their own supervision themselves, communicate back the change propositions extremely clearly, so I can review MR efficiently, I want the project to stay stable, healthy and on a good trajectory even a few years after I will leave it. For me, those are the reasons to spend extra time writing tests now. That being said, I'm not sure about the cost of doing TDD. My off hat evaluation is that over the span of a few hours, writing tests slows me at max 25%; buy over a few days benefits compound, and I'm more efficient with unit tests than without them. One E2E covers a lot, but it makes the error messages less helpful—it tells you some part a long chain of operations is off, and you have to investigate which one it is. I'm slowly getting to the conclusion that unit test value for solo developers is in unblocking TDD; and the design impact I've talked about in : https://how-to.dev/how-to-keep-your-units-testable-in-javascript

Thank you for your comment! The cherry-picking instead of doing rebase is a great technic—I use it myself as well. I learned it as a workaround for complicated rebases, and somehow it feels more advanced to me. So far, I didn't have a chance to try teaching it to someone who doesn't know rebase—it would be interesting for me to see which one is easier to grasp. My guess is that rebases can get ugly in the situations you mention, while cherry-pick requires more understand of Git. why rewrite history anyways? My main objective with it is to keep rebasing as main is updated. Very rarely are perfectly curated commit histories worth the time for a developer Yeah, there are always trade-offs. My starting point: I expect all my colleagues to be fluent with Git enough, that curating commit history is just a moment for them; letting history be messy saves their time, while sometimes costing my time (to figure out what's happening etc.) I got us to iterate on such a small change-sets that there is rarely a need to put more than 2 or 3 meaningful commits to the branch. There are strong arguments for very different policies when it comes to force pushes. I think often it's mostly a matter of esthetic preference of the team—or of the most senior person on the team.

Hey! Yes, this sounds like a problem that could be very annoying. I think, I managed to avoid this kind of situation with: CI that will definitively fail if anything is as wrong as broken YML files, Rebasing feature branches all the time There is no way to run the same projects that failed unless I touch some files (with empty spaces or enter or whatever change). This is ugly for me. Triggering jobs manually should do the trick. It's annoying, as you have to trigger them in the right order, but you can get everything build finally One idea came up, what if I always build all projects on main but when deploy the docker images that hasn’t changed won’t be deployed Yes, I would always run everything on the main branch. It's already merged, if it takes very long it doesn't matter, and it verifies all the code—even the parts that are hardly every touched.

Gracias! Siendo honesto, el artículo me tradujeron por mi – lo escribí en inglés, y para versione española y polaca tenia un traductor. Como has encontrado el artículo? El blog en traducción siempre fue medio muerto, pero últimamente veo trafico en justo este artículo. No sabía si son lectores de verdad o algunos bots o que.

Thanks a lot!

Thank you! The most up to date info is here: https://how-to.dev/free-mentoring

Thank you so much for sharing all this information!

If you go to a dentist or car mechanic, do you want one that is: the fastest, the cheapest, the best ? The key is to orient your career towards the positions that are essential for companies. When you maintain a system that essential for a company's business, the most important thing is to keep production running—the speed of new development is secondary. I'll need to explore at some point on the blog things as: product company vs agencies, and why developers are better off in product companies; cost centers vs profit centers, maintanence vs green field project.

And if you like modules, in Angular & AngularJS you have angular modules that can be done in JS modules; so you can have modules in your modules!