Interesting about the *emotional* aspect of TDD. Write a test. Pass the test. Iterate. Set a challenge. Pass the challenge. Small, well-defined incremental challenges with success/failure feedback. All day you're setting challenges and defeating them. And you have a *written record* of all those challenges you've defeated. It's a recipe for giving you dopamine hits all day long. Just watching Andrew Huberman. The trick to accomplishment is getting a steady flow of those dopamine hits. Setting incremental goals, completing them, and *celebrating* the completion of them.
O damn yeah, I was in one of those companies that I had to be afraid of the code someone else was writing because it would screw up my code! Things changed with daily briefings of half an hour.
You call for a tester when you need to know your last merge did not mess the UI. You call for a QA engineer when you're ready to deliver to the customer and you need to know what you want to deliver is what the customer paid for _and_ what the customer needs _and_ to protect the company from being dragged into a tribunal etc. ... most of the time they appear to do the same thing, but the small difference in focus is ignored in these agile times.
I agree that this needs to be checked, but I'd say that this is a job of developer and that he's the one that should be talking directly to product owners and customers. No management, no business analysts, no QAs. Irresponsible developers have a need to throw over the wall documents, code and functionality and this is something that developers that love what they do and are doing development because they want to help their customers don't do.
I agree, but the reality is most QA departments are too hung up on tests to actually do quality checks. Bob is talking about them not having their jobs in a year after you start doing proper TDD, but that might not be true - I can see the department changing, not going away. Instead of being 1000 indians, instead if's 4-5 guys who are qualified in things like UX and interface design - who can actually have valid opinions on the quality of the software itself, rather than being that department that you hand stuff to and then never talk to again. Combine that with exploratory testing, and you can have a dept that is really small, really efficient, and contributes a lot to the actual software design, which would make them seem a lot more respectable and valuable to the business as a whole.
On the subject of manual testing, I thoroughly agree with you. I used to work for a company that was mainly responsible for replacing old, expensive manual test suites with automated test suites using tools like Selenium and Tosca. Looking back, even with these new-fangled automated tests, there was an eternal maintenance burden, as trying to test the system thoroughly was always going to be a bad idea. Since we sold them on the idea of "your test suite is unmanageable and takes forever to run, let's speed that up", I now feel, looking back, like that was fundamentally immoral. We weren't actually solving the problem, we were just making it more manageable. Tests that would take 5 minutes now took 30 seconds, but there would still be a large number of them and they would grow exponentially. Worse, new features would require old tests to be remade, so the workload would actually compound on itself. If you work for a company that currently does manual testing, and your boss calls you into a meeting about "automating the manual tests", please do everything you can to make sure your highest test coverage is in unit tests, not UAT or anything like that, since I guarantee you it's going to cause a lot of unforseen problems and not be as much of a silver bullet at everyone at the organisation thinks.
Guys & Gals. This guy is off putting due to his smarmy, glib attitude. But he’s right. And he’s better than most of those who have opined at writing software. The real reason is not that he’s gifted intellectually, though that helps. It’s that he is supremely confident in his ability to write software. And the vast, vast majority of the people I’ve worked next to are confident enough to get by, but not like this dude. How else would one gain this level of software hubris? TDD, kiddies!
Despite agile software has gotten worse. Perhaps waterfall wasn't that bad. It's not people's fault it's just code in general and code env are too fragile. But he has good points. If you can't change js then maybe change the environment and your approach. Pretty much. Do a good job. Be organized.qa is very important like that he said let was write tests just be automatically run.
Interesting about the *emotional* aspect of TDD.
Write a test. Pass the test. Iterate.
Set a challenge. Pass the challenge.
Small, well-defined incremental challenges with success/failure feedback. All day you're setting challenges and defeating them. And you have a *written record* of all those challenges you've defeated.
It's a recipe for giving you dopamine hits all day long.
Just watching Andrew Huberman. The trick to accomplishment is getting a steady flow of those dopamine hits. Setting incremental goals, completing them, and *celebrating* the completion of them.
I started programming in about 1962 in 1620 machine language and with an interpreter that ran a subset of Fortran.
O damn yeah, I was in one of those companies that I had to be afraid of the code someone else was writing because it would screw up my code!
Things changed with daily briefings of half an hour.
Actually accountants have qa - it's called audit.
QA don't do testing, they do check the quality ; software can have no bug and still be crap
Hey, this is interesting. How do they check quality then? I didn't meet such QA team yet in my career.
You call for a tester when you need to know your last merge did not mess the UI.
You call for a QA engineer when you're ready to deliver to the customer and you need to know what you want to deliver is what the customer paid for _and_ what the customer needs _and_ to protect the company from being dragged into a tribunal etc.
... most of the time they appear to do the same thing, but the small difference in focus is ignored in these agile times.
I agree that this needs to be checked, but I'd say that this is a job of developer and that he's the one that should be talking directly to product owners and customers. No management, no business analysts, no QAs. Irresponsible developers have a need to throw over the wall documents, code and functionality and this is something that developers that love what they do and are doing development because they want to help their customers don't do.
I agree, but the reality is most QA departments are too hung up on tests to actually do quality checks. Bob is talking about them not having their jobs in a year after you start doing proper TDD, but that might not be true - I can see the department changing, not going away. Instead of being 1000 indians, instead if's 4-5 guys who are qualified in things like UX and interface design - who can actually have valid opinions on the quality of the software itself, rather than being that department that you hand stuff to and then never talk to again. Combine that with exploratory testing, and you can have a dept that is really small, really efficient, and contributes a lot to the actual software design, which would make them seem a lot more respectable and valuable to the business as a whole.
very well spoken, thank you
On the subject of manual testing, I thoroughly agree with you. I used to work for a company that was mainly responsible for replacing old, expensive manual test suites with automated test suites using tools like Selenium and Tosca. Looking back, even with these new-fangled automated tests, there was an eternal maintenance burden, as trying to test the system thoroughly was always going to be a bad idea. Since we sold them on the idea of "your test suite is unmanageable and takes forever to run, let's speed that up", I now feel, looking back, like that was fundamentally immoral. We weren't actually solving the problem, we were just making it more manageable. Tests that would take 5 minutes now took 30 seconds, but there would still be a large number of them and they would grow exponentially. Worse, new features would require old tests to be remade, so the workload would actually compound on itself.
If you work for a company that currently does manual testing, and your boss calls you into a meeting about "automating the manual tests", please do everything you can to make sure your highest test coverage is in unit tests, not UAT or anything like that, since I guarantee you it's going to cause a lot of unforseen problems and not be as much of a silver bullet at everyone at the organisation thinks.
So what I learned: most of us programmers owe their job to messy colleagues. So a big shout out to our messy colleagues at this point
Guys & Gals. This guy is off putting due to his smarmy, glib attitude. But he’s right. And he’s better than most of those who have opined at writing software. The real reason is not that he’s gifted intellectually, though that helps. It’s that he is supremely confident in his ability to write software. And the vast, vast majority of the people I’ve worked next to are confident enough to get by, but not like this dude. How else would one gain this level of software hubris? TDD, kiddies!
Very nice talk!
Very useful talk
great talk..
Great!
Link to the next talk please?
good video
electronics/computer hardware engineering is more or less the same age as programming, am i missing something here?
I do find that most of those who think they are doing agile development are actually doing Agile or Scrum.
Despite agile software has gotten worse. Perhaps waterfall wasn't that bad. It's not people's fault it's just code in general and code env are too fragile. But he has good points. If you can't change js then maybe change the environment and your approach. Pretty much. Do a good job. Be organized.qa is very important like that he said let was write tests just be automatically run.
18:16 so true :')
No one really did Waterfall, just like today no one is really doing agile.
hahahahahahahha Thats what I sometimes think while removing a crap piece of code.
The most annoying portion of the TDD debate is both sides believe they are 100% correct.