Sure, most definitely. Although I hope I wasn't giving off the illusion of neglecting my core topics, I certainly wasn't planning on that. I was just thinking that perhaps some of the topics present a sort of diminishing 'rate of return', since going too in-depth past a certain point may not be too useful/enlightening(?). But this may just be purely ignorant thinking on my part, since I have not fully grasped the important parts of each commonly taught CS topic yet.
This part is enough to mark the test as exploratory and not usable for a guide on the real world:
> The experiment was conducted on “live” projects that the teams were developing at that moment.
There are plenty of experiments on those conditions. If they had consistent results, we could trust those, but they are all over the place, what means that confounding factors are more relevant than the thing being studied.
Did the non-TDD team do regular testing, or no testing at all? It doesn't say, and it seems rather important to judge the results..
I think the debate is not whether testing in general reduces defects (which is rather obvious), but if adhering to a stringent Test-Driven Development (TDD) process is better than regular testing (typically adding the tests after writing the code, instead of before).
The usual wisdom is that the later a problem is detected, the more it costs. 15-33% extra time for removing ~half defects very early is a great trade-off!
Imagine assembling a car engine without any QC process, perhaps just visual inspection of the parts. The end users (whoever will drive the car) will be the actual testers.
You jest, but I have been in a conversation where I proposed a user experience improvement and heard "but if we change the code, it will no longer be tested. Right now, users have reported bugs and we have fixed all of them."
Because users always report bugs...
If you've ever been frustrated by the package manager Conda and the UX of its command-line interface ...I'm sorry. I tried.
It's a trade off. Sure, the ultimate testing is done by customers, but how fast one can push new fixes without tests? 1 reported bug could break many things.
> but how fast one can push new fixes without tests?
Well, if you refuse to write tests and you are scared to make new changes without them... then you can't push new fixes at all. Which is apparently fine for some organizations.
Welcome to the land of ambiguity and subjectivity - enjoy our stay!
The problem is, that there's no way to generally quantify "too much" or "not enough" when it comes to tests and documentation.
Even "harmful" isn't a well defined term on its own and needs to be properly defined on a case-by-case basis.
The statement is a platitude without any substance behind it and you can replace "testing and documentation" with just about anything and come to the same result:
Vitamines and calorie intake are both essential but too much of either becomes harmful.
My 2 cents regarding testing. Written tests have 2 goals, 1: help to build your code (you verify your code as you write it). 2: Regression testing (new changes have less chances to break your code).
We as devs need to hand over/deploy a verified code. Without tests this means manual testing, without manual testing means not verified code. Manual testing means slow development process.
It's 2020, I think we have more time writing tests than before with all those cool IDEs, tools, frameworks. No tests means laziness and/or cockiness. Imho of course.
That's what you do tests or no tests. Write some code, go to the browser, check it works (assuming it's a web app). I don't think even the most undisciplined of developers just writes code and assume that it works.
>Manual testing means slow development process.
I don't think its necessarily slower, in fact initially it is faster, which is why so many places don't have much in the way of tests. Much of this depends on the size and scope of your project.
I have worked on systems with lots of tests and systems with next to no tests. The tested systems were not "better", they still contained bugs and poor abstractions. The regression tests were useful, but the team required to maintain them was even bigger than the development team.
One thing that doesn't get discussed is that tests provide a way to run bits of code independent of the rest of the (probably over complicated) system. The last two places I have worked, getting a dev environment set up to run the application took a couple of days work at least.
> Write some code, go to the browser, check it works (assuming it's a web app).
That's a test. It's called manual testing, and in reasonable organizations there'd be a list of what test actions (as a checklist, often) should be done in this fashion.
The problems I see with "open your browser" for quick testing: 1. it's short gain, the team will be slower (will they know how to test it?) 2. how much code needs to be written so that you can even use the browser to test it?
Personally I will believe it when I see it, at least for Pro line. Apple has the resources to pull it off (although they will be remembered by their keyboard issues for some time), the question is what is Apple's ultimate goal?
I don't know, I guess it depends. I tried recently to switch to gruvbox dark, solarized dark and so other popular themes. It is difficult for me to use them in the day. Gave up after couple of days, switched back to intellij light + redshift app.
Late nights i just reduce the overall screen brightness.
Boring tech is subjective, it depends on the team. A tool for the job needs to be in right hands to be right. Some may be fine with 1 hour after hours deployment, some may want a fully automated CD pipeline.
Nope, boring technology implies mature and tried enough ecosystem where the users community found out and know almost every failure scenario. Your team skills are not relevant in this definition, if a tech is "new" and "exciting".
Tools/best practices come and go, can be learned quickly with so much information out there.
That said, be curious and try different things and you will know what you like. Passion amplifies learning by a magnitude.
All of the above is imho, that I would've told younger myself.