3 lines of code shouldn't take all day

Actually, currently am about to be asked when the feature will be done, whereas i've decided to actually write tests for it (reusable library code across multiple projects). As far as the reality is concerned, the people who say that writing tests "uses up" time are right: being slow now will be more visible than no one understanding why development takes a whole lot of time down the line, which is when many might just shrug their shoulders and go "legacy code". What's the benefit of making others able to develop code faster, if that makes you be slower - both facts probably being visible to management, though oftentimes without the underlying reasons behind those being relevant to them?

I'd argue that that's why even governmental projects in my country (that are often contracted out to random companies) oftentimes have poor test coverage and just generally not a lot of thought is put into the quality and sustainability of those codebases - they got paid, they could iterate reasonably quickly while the contract was ongoing, why should they worry about anything? The people who take over the project then can also deliver features more slowly, not only because of the poor domain understanding, lack of ADRs, lack of documentation, but also lack of tests - and still often get paid on a time material basis. Thus, no one actually wants to improve things, apart from me wanting to tear my hair out whenever i'm expected to work on garbage like that and fix their problems.

Thus, you see some people in the industry adopt an egoistical approach to it all - join a company, focus on the speed of their own iteration without thinking about the project in the long term, spend a few years doing this and then leave for another company where they'd do the same thing. It might be a cultural thing, but working on other people's projects instead of starting my own feels like losing at this point - no READMEs, no automated CI, no Ansible, no Dockerfiles, no IDE run profiles, no common linting rules, no code static analysis, no local DBs with migrations, no local setup scripts etc. Why should i be expected to toil away without results that are visible to the business because someone else was allowed to neglect the codebase?

At this point, i use unit tests and code coverage rules defensively: to prevent someone from jumping into the project and ruining how things should work with breaking changes, which will be caught by the tests, or by introducing untested and undocumented code, which the coverage rules will catch and make CI fail. Of course, depending on the culture, you might find that other devs talk amongst themselves and before long your tests have @Ignore added to them or have been removed entirely, which is the point where it might just be easier to look for a less dysfunctional environment, despite living in a country that others outsource to and therefore quality isn't a priority.

In short: i agree with your point, but i think that there are social problems at play. You need to actually care about the code that you're developing to prevent these issues in the long term. And even then, if you care, that doesn't mean that other team members will.

With short iterative changes I have unit tests and fine grained git history, to untangle it.