It's funny, i am a litterpicker (not as a profession, just as a hobby) and spend a lot of time working with an open-source app/website in which you can register litter (and do a lot more). I am also a professional tester and i work/talk a lot with one of the developers of that app and i am very impressed by what he does and especially his view on testing. While a lot of devs talk about developing and stuff like that, he is developing but also talking about testing a lot. He understands the value of 'the green-button' and during one of the talks last week, he mentioned this video from UncleBob and i love it. Thanks for sharing and keep up the work everbody!
Introduction: Software developers rule the world: ua-cam.com/video/BSaAMQVq01E/v-deo.html Expected professionalism. Principles: Do a good job (‘We don’t ship shit’): ua-cam.com/video/BSaAMQVq01E/v-deo.html Be always ready: ua-cam.com/video/BSaAMQVq01E/v-deo.html Stable productivity: ua-cam.com/video/BSaAMQVq01E/v-deo.html Inexpensive adaptability (‘Keep the SOFTware soft’): ua-cam.com/video/BSaAMQVq01E/v-deo.html Continuous improvement (check-in your code just a bit better that you found it): ua-cam.com/video/BSaAMQVq01E/v-deo.html Fearless competence (if you fear your code, it controls you and you cannot make it better): ua-cam.com/video/BSaAMQVq01E/v-deo.html The magic button, TDD (if you can clean your code -> code gets better -> easy to change -> increase productivity): ua-cam.com/video/BSaAMQVq01E/v-deo.html Extreme quality: ua-cam.com/video/BSaAMQVq01E/v-deo.html ‘We will not dump on QA’: ua-cam.com/video/BSaAMQVq01E/v-deo.html QA should find nothing: ua-cam.com/video/BSaAMQVq01E/v-deo.html Test automation: ua-cam.com/video/BSaAMQVq01E/v-deo.html Nothing fragile and we will cover for each other: ua-cam.com/video/BSaAMQVq01E/v-deo.html Honest estimates (accuracy and precision): ua-cam.com/video/BSaAMQVq01E/v-deo.html The privilege and responsibility to say ‘no’: ua-cam.com/video/BSaAMQVq01E/v-deo.html Continuous aggressive learning: ua-cam.com/video/BSaAMQVq01E/v-deo.html Mentoring (half of the programmers in the world have less than 5 years of experience): ua-cam.com/video/BSaAMQVq01E/v-deo.html
This is why Junior programmers need to be managed. They are naturally over ambitious and don't have the horrifying memories of managing legacy systems. The problem with programming is that we don't take it as seriously as other engineering fields when it comes to trying new methods. We jump on new methods, even if they are unproven. That is our downfall.
If I code up some CRUD app in php of course I'm not gonna take it as seriously as if I would be programming some robot arms used in heart surgery. This is a property of "profession", the nature of the software project might allow for lousiness, you can always hit ctrl+z. I don't believe that devs who work on projects closely related to human life have the same attitude as frontend developers for instance. The company should endorse policies to make sure everything is safe and sound. If they hired some irresponsible dev, the management should be also questioned about their competency.
If we don't jump on new methods, they will never be proven. Software Engineering is a few decades old (and most of the time we went in a very very bad path), we are still figuring out how to do this thing.
I would counter to say that willingness (even though it is due on part to ignorance) to try new things is our greatest strength. The rock stars among us able to translate their previous experience to be tech.
Did not intend to watch this talk, but immensely enjoyed it - it was attached to an article we had to read for school and I clicked the video to hear the quoted part and got rapidly sucked in and ended up watching the whole thing. I have no idea who this guy is (but I assume he's quite important lol) but I'm a fan now and learned a lot of things and gave me a lot to consider in my learning process! I'm glad I decided to click.
"always check it in a little better" - so many times I've been tempted to do just that, but that bit of code I want to improve does not directly effect my ticket. Touching it increases test effort a lot. An change which is not strictly necessary to deliver that specific piece of work would never get through code review.
This is big picture thinking that will get you in to trouble. The solution is to break your work day in to tiny tasks by a PO to be questioned constantly by a SCRUM master so that you only see a tiny task instead the whole picture so you can be a happy little line workers with no responsibility for the overall performance and reliability. Your burn down chart will be good and you will not be considered a bad apple by the 20 year that just got their 2 day SCRUM Alliance certification.
In some development processes you may not check it in better. You yourself have an example where fixing the spelling of a human interface item broke a customer's automation. Similarly it might lead to incorrect operation of medical equipment, weapons systems, nuclear missile failsafes, etc due to mismatching the documentation and training, being too visually similar to anothe r item, being pronounced differently during crunch-time side conversations, different mistypings, etc. Changes can make cache hits change and reduce performance by an order of magnitude, missing a deadline once in 10^6 events instead of once in 10^20 events.
Waterfall test phases are unbiased double-entry validations of the testing that developers already ran. It's renders a process that is an approximation of the derivative of the process you want (with its random walk term) into an approximation of the process you want where the size of the walk is bounded by the frequency of your QA test phases.
If you had the green button the computer could clean the code instead. If we need programmers we don't need the green button, if we have the green button we don't need the programmers.
HOLY SHIT THIS GUY FOUND THE ANSWER Just need the Green Button Silver Bullet WAVE THAT MAGIC WAND AND FIX THESE PROBLEMS NOW!!!!!!!!! GIMME MY GREEN BUTTON SOLUTION AND LET’S SHIP THIS BALL OF SHIT
The warm-up talk is - as usual - interesting, but in this case perhaps not correct. IMO the laser dot pattern we see is not caused by interference, but rather by refraction and reflection of the original laser beam. If I'm right with my doubt you should also be cautious to not believe every fairy tale, judge for yourself :-)
Well, it only takes a moment to verify: en.wikipedia.org/wiki/Diffraction_grating, and perhaps go back and watch the rest of the talk to understand what it was really about.
Why use the VW programmers as the model "ethics violators"? How about the guys who wrote the code that enables high-school under-performers to sit in airconditioned trailers at Creech, and launch missiles at wedding parties based on grainy camera footage? What about the guys who wrote the code for all the CCTV surveillance that records our movements for no obvious good reason? What about the guys who wrote the code that vacuums up all our phone and e-mail interactions, and keyword-searches them? Frankly, if I was going to make a case for ethics in software development it would be this: *don't work for government* . Fortunately, that's already a reality: government can't recruit or retain really good coders - which is why government systems are so insecure.
A good question. Is the forger of a katana responsible for the samurai's predations on the peasantry? Some say yes, some say no. It's basically yet another series of trolley problems.
None right now, that is something he wants to happen - not something that exists already, unfortunately. Hopefully we will see it come to fruition someday soon, but I'm not sure who or what will be the ones to take it on.
Super late, but the ACM does provide a Code of Ethics that members are "expected" to adhere to. But it's not like there's a legal precedent for software malpractice so there's no real penalty or anything for not following it, nor is there an expectation for any employer that I've ever seen that employees be ACM members which would entail following the code of ethics.
"The law will tell us what language we can code in" (paraphrased) - even if this happens, it doesn't solve anything. You can write shit code in any language. So what else.. hm.. Law enforcing 100% code coverage in unit tests? Still can't see how that would prevent failures. The only thing I can see making sense is to oblige products to be tested before they are released for the general public e.g like in the drug industry. But then, will the game industry be under the same law? Who is gonna decide that "hey, this software can potentially end people's life, we better test it for 5 years"? Would any type of software need to be officially checked by the gov/some organization? What about open source? Loads of questions like these arise.
I"d predict that the laws like that will apply to certain industries. Say "All air traffic control must be written in a partucular language" and "all vehicle speed and direction management cold must be written in a specified language" or say software for medical devices ( see Therac-25) or missile guidance software( GAO/IMTEC-92-26). As far as testing nearly all imported electronics are tested to conform to certain standards ( UL, CE, CSA, et cetera). It seems like most of it will all fall into place after the catastrophe happens.
As far as I heard in automotive safety there is a discipline and there's law, and project analysts can set rules in language and constructs and test coverage. But you try finding legal advice on what you as a programmer must or may do! But the implication that the law does not control us in some.fields is very dangerous. People might leave this place thinking they don't need to think about that in their work when they do need to.
1:07:40 I'm a fan of Alan Turings work myself, but he wasn't the first programmer. Here is something Uncle Bob seems to have missed, that happend in 1941: en.wikipedia.org/wiki/Z3_(computer). Of course there were also programms for it. Also he seems to have missed Ada Lovelace en.wikipedia.org/wiki/Ada_Lovelace#First_computer_program who already wrote programms back in 1842-43, altough ... and this is kind of hillarious in context of this speech here: Her programm was never tested :-D (Which is excuseable, given that the system she wrote it for was never built and only existed within a scientific paper she got for translation)
Expecting professionalism...not from the speaker. Nah. First 6 minutes is him playing with a laser and going on about something he finds interesting and which the audience are held hostage to have to sit through. Then at 6:14 the words I dread to hear at any talk..."before I begin" agggggrrrrr Is this f'in thing ever going to get started??? Holy crap...2 hours long??? It amazes me software even exits. I would think programmers would still be working on the first code trying to get it done...while still having time to play with lasers. Programming is not and never has been a profession. I doubt that will change in my lifetime. I've been a programmer for almost 40 years.
Jesus Christ, quit whining like a baby. You're not in the audience. You can skip the video to the actual start. I can only imagine the tantrums you throw when you hit a snag when writing code. And yes programming is not the profession. Software engineering is.
It's funny, i am a litterpicker (not as a profession, just as a hobby) and spend a lot of time working with an open-source app/website in which you can register litter (and do a lot more). I am also a professional tester and i work/talk a lot with one of the developers of that app and i am very impressed by what he does and especially his view on testing. While a lot of devs talk about developing and stuff like that, he is developing but also talking about testing a lot. He understands the value of 'the green-button' and during one of the talks last week, he mentioned this video from UncleBob and i love it.
Thanks for sharing and keep up the work everbody!
First time I’ve heard TDD explained this way … it’s beginning to make more sense
Most devs just cargo cult it
Even bobs missed a few details like you are supposed to experiment with toy solutions before starting the TDD process
Introduction:
Software developers rule the world: ua-cam.com/video/BSaAMQVq01E/v-deo.html
Expected professionalism. Principles:
Do a good job (‘We don’t ship shit’): ua-cam.com/video/BSaAMQVq01E/v-deo.html
Be always ready: ua-cam.com/video/BSaAMQVq01E/v-deo.html
Stable productivity: ua-cam.com/video/BSaAMQVq01E/v-deo.html
Inexpensive adaptability (‘Keep the SOFTware soft’): ua-cam.com/video/BSaAMQVq01E/v-deo.html
Continuous improvement (check-in your code just a bit better that you found it): ua-cam.com/video/BSaAMQVq01E/v-deo.html
Fearless competence (if you fear your code, it controls you and you cannot make it better): ua-cam.com/video/BSaAMQVq01E/v-deo.html
The magic button, TDD (if you can clean your code -> code gets better -> easy to change -> increase productivity): ua-cam.com/video/BSaAMQVq01E/v-deo.html
Extreme quality: ua-cam.com/video/BSaAMQVq01E/v-deo.html
‘We will not dump on QA’: ua-cam.com/video/BSaAMQVq01E/v-deo.html
QA should find nothing: ua-cam.com/video/BSaAMQVq01E/v-deo.html
Test automation: ua-cam.com/video/BSaAMQVq01E/v-deo.html
Nothing fragile and we will cover for each other: ua-cam.com/video/BSaAMQVq01E/v-deo.html
Honest estimates (accuracy and precision): ua-cam.com/video/BSaAMQVq01E/v-deo.html
The privilege and responsibility to say ‘no’: ua-cam.com/video/BSaAMQVq01E/v-deo.html
Continuous aggressive learning: ua-cam.com/video/BSaAMQVq01E/v-deo.html
Mentoring (half of the programmers in the world have less than 5 years of experience): ua-cam.com/video/BSaAMQVq01E/v-deo.html
Hard job for a cameraman.
Big fan of Uncle Bob
I'm a welder and all of these tips apply to my trade
In what way?
@@ChrisAthanas continuous aggressive learning
This is why Junior programmers need to be managed. They are naturally over ambitious and don't have the horrifying memories of managing legacy systems. The problem with programming is that we don't take it as seriously as other engineering fields when it comes to trying new methods.
We jump on new methods, even if they are unproven. That is our downfall.
As a recent grad and sole dev, I agree with this. I am constantly over ambitious .. which is crushing
If I code up some CRUD app in php of course I'm not gonna take it as seriously as if I would be programming some robot arms used in heart surgery. This is a property of "profession", the nature of the software project might allow for lousiness, you can always hit ctrl+z. I don't believe that devs who work on projects closely related to human life have the same attitude as frontend developers for instance. The company should endorse policies to make sure everything is safe and sound. If they hired some irresponsible dev, the management should be also questioned about their competency.
If we don't jump on new methods, they will never be proven. Software Engineering is a few decades old (and most of the time we went in a very very bad path), we are still figuring out how to do this thing.
I would counter to say that willingness (even though it is due on part to ignorance) to try new things is our greatest strength. The rock stars among us able to translate their previous experience to be tech.
History of Software is full of arrogant loudmouths, oversimplifying know-it-alls and cyclic fads
Did not intend to watch this talk, but immensely enjoyed it - it was attached to an article we had to read for school and I clicked the video to hear the quoted part and got rapidly sucked in and ended up watching the whole thing.
I have no idea who this guy is (but I assume he's quite important lol) but I'm a fan now and learned a lot of things and gave me a lot to consider in my learning process!
I'm glad I decided to click.
The Q&A section of this lecture is really excellent: ua-cam.com/video/BSaAMQVq01E/v-deo.htmlh14m23s
"It works" means "the first smoke test worked"
i've just read the caption and knew this talk will be fucking good
The expectation of what a QA does in this talk is enlightening to say the least!
The economics and arbitrage of bugs is a very real phenomenon
20:40 "Because it was our fingers on the keyboard."
ChatGPT: "He he he heeeeeee!"
1:47:30 Future reference: Question related to Bob's thoughts on DHH and Rails and how good software developer should look at frameworks.
Fievel Mousekewitz thanks!!!✌🏽️
Thanks for the highlight..
The real talk starts at 11:15.
thank you uncle bob
"always check it in a little better" - so many times I've been tempted to do just that, but that bit of code I want to improve does not directly effect my ticket. Touching it increases test effort a lot. An change which is not strictly necessary to deliver that specific piece of work would never get through code review.
I think he predicted the 737 MAX.
Google the photo of the electronics room of the 737 Max electronics bay
It explains alot
This is big picture thinking that will get you in to trouble. The solution is to break your work day in to tiny tasks by a PO to be questioned constantly by a SCRUM master so that you only see a tiny task instead the whole picture so you can be a happy little line workers with no responsibility for the overall performance and reliability. Your burn down chart will be good and you will not be considered a bad apple by the 20 year that just got their 2 day SCRUM Alliance certification.
In some development processes you may not check it in better. You yourself have an example where fixing the spelling of a human interface item broke a customer's automation. Similarly it might lead to incorrect operation of medical equipment, weapons systems, nuclear missile failsafes, etc due to mismatching the documentation and training, being too visually similar to anothe r item, being pronounced differently during crunch-time side conversations, different mistypings, etc. Changes can make cache hits change and reduce performance by an order of magnitude, missing a deadline once in 10^6 events instead of once in 10^20 events.
Waterfall test phases are unbiased double-entry validations of the testing that developers already ran. It's renders a process that is an approximation of the derivative of the process you want (with its random walk term) into an approximation of the process you want where the size of the walk is bounded by the frequency of your QA test phases.
Can you simplify what you’re saying?
@@ChrisAthanas only ad nausiem
@@tricky778 seems like the normal overcomplicated manager dictated dev process
1:23:48 bob likely has not used a modern UI testing framework bc it’s not pixel based and Can reach into the structure of the screens
51:05 - non stop lol
Can anyone recommend new book for logic gates and basic cpu design for 12yo, something like UncleBob was mentioning around 9:30.
Very iteresting
I just want to know where I can get that laser pointer!
WarGames, 1983
~ 10:00 Karnaugh table! I just smile because I used it to build PLC programs 😜
thanks a lot!
Matrix- Neo (main role programmer)
nice conference.
1:02:32 aggressive learning.
If you had the green button the computer could clean the code instead. If we need programmers we don't need the green button, if we have the green button we don't need the programmers.
Wow, i respect your right to speak but man , practice thinking
HOLY SHIT THIS GUY FOUND THE ANSWER
Just need the Green Button Silver Bullet
WAVE THAT MAGIC WAND AND FIX THESE PROBLEMS NOW!!!!!!!!!
GIMME MY GREEN BUTTON SOLUTION AND LET’S SHIP THIS BALL OF SHIT
28:45 killed me when watching on x2 speed
Cool
The warm-up talk is - as usual - interesting, but in this case perhaps not correct. IMO the laser dot pattern we see is not caused by interference, but rather by refraction and reflection of the original laser beam. If I'm right with my doubt you should also be cautious to not believe every fairy tale, judge for yourself :-)
Well, it only takes a moment to verify: en.wikipedia.org/wiki/Diffraction_grating, and perhaps go back and watch the rest of the talk to understand what it was really about.
Uncle Bob is the best. If anyone knows where I can get a complete distillation of all his talks please let me know!
He wrote a book, didn't he?
He did, everyone should read clean code
I think he sells all of them on his website. The address is something with “cleancode” in it.
His book Clean Coder covers a lot of this. Clean Architecture, too. Anything he writes is critical reading.
48:20 Uncle Bob being arrested?
Polarized Filters & scotch tape.
Why use the VW programmers as the model "ethics violators"?
How about the guys who wrote the code that enables high-school under-performers to sit in airconditioned trailers at Creech, and launch missiles at wedding parties based on grainy camera footage?
What about the guys who wrote the code for all the CCTV surveillance that records our movements for no obvious good reason?
What about the guys who wrote the code that vacuums up all our phone and e-mail interactions, and keyword-searches them?
Frankly, if I was going to make a case for ethics in software development it would be this: *don't work for government* . Fortunately, that's already a reality: government can't recruit or retain really good coders - which is why government systems are so insecure.
A good question. Is the forger of a katana responsible for the samurai's predations on the peasantry? Some say yes, some say no. It's basically yet another series of trolley problems.
the point is, things that are going to make the government come sniffing around asking us what the hell is going on.
Why we have QA ua-cam.com/video/BSaAMQVq01E/v-deo.htmlm56s
Does anybody know which professional organization does he endorse?
+Jake Beasley You mean 8light? Its logo is in his shirt
I mean what professional organization certifies software engineers in the way he is describing?
None right now, that is something he wants to happen - not something that exists already, unfortunately. Hopefully we will see it come to fruition someday soon, but I'm not sure who or what will be the ones to take it on.
Super late, but the ACM does provide a Code of Ethics that members are "expected" to adhere to. But it's not like there's a legal precedent for software malpractice so there's no real penalty or anything for not following it, nor is there an expectation for any employer that I've ever seen that employees be ACM members which would entail following the code of ethics.
So does the IEEE Computer Society and other societies. There are some comparisons and discussion on the web on these.
"The law will tell us what language we can code in" (paraphrased) - even if this happens, it doesn't solve anything. You can write shit code in any language. So what else.. hm.. Law enforcing 100% code coverage in unit tests? Still can't see how that would prevent failures. The only thing I can see making sense is to oblige products to be tested before they are released for the general public e.g like in the drug industry. But then, will the game industry be under the same law? Who is gonna decide that "hey, this software can potentially end people's life, we better test it for 5 years"? Would any type of software need to be officially checked by the gov/some organization? What about open source? Loads of questions like these arise.
I"d predict that the laws like that will apply to certain industries.
Say "All air traffic control must be written in a partucular language"
and "all vehicle speed and direction management cold must be written in a specified language" or say software for medical devices ( see Therac-25) or missile guidance software( GAO/IMTEC-92-26).
As far as testing nearly all imported electronics are tested to conform to certain standards ( UL, CE, CSA, et cetera).
It seems like most of it will all fall into place after the catastrophe happens.
The point is not that the regulations will be good, or effective, but that they will come - and that is always bad.
Just add it to the list of things the government "regulates" and fails at.
As far as I heard in automotive safety there is a discipline and there's law, and project analysts can set rules in language and constructs and test coverage. But you try finding legal advice on what you as a programmer must or may do!
But the implication that the law does not control us in some.fields is very dangerous. People might leave this place thinking they don't need to think about that in their work when they do need to.
Leaving this comment so when someone likes it I get to watch again
I disagree, it is a lot of fun to write unit tests after the fact.
41:42
1:07:40 I'm a fan of Alan Turings work myself, but he wasn't the first programmer.
Here is something Uncle Bob seems to have missed, that happend in 1941: en.wikipedia.org/wiki/Z3_(computer). Of course there were also programms for it. Also he seems to have missed Ada Lovelace en.wikipedia.org/wiki/Ada_Lovelace#First_computer_program who already wrote programms back in 1842-43, altough ... and this is kind of hillarious in context of this speech here: Her programm was never tested :-D (Which is excuseable, given that the system she wrote it for was never built and only existed within a scientific paper she got for translation)
Java on the decline ? Hmm 🤔
isn't it?
Boring
Expecting professionalism...not from the speaker. Nah. First 6 minutes is him playing with a laser and going on about something he finds interesting and which the audience are held hostage to have to sit through. Then at 6:14 the words I dread to hear at any talk..."before I begin" agggggrrrrr Is this f'in thing ever going to get started??? Holy crap...2 hours long???
It amazes me software even exits. I would think programmers would still be working on the first code trying to get it done...while still having time to play with lasers. Programming is not and never has been a profession. I doubt that will change in my lifetime. I've been a programmer for almost 40 years.
@Peter Mortensen You can use just links in youtube comments. en.wikipedia.org/wiki/Hyperlink
Jesus Christ, quit whining like a baby. You're not in the audience. You can skip the video to the actual start. I can only imagine the tantrums you throw when you hit a snag when writing code.
And yes programming is not the profession. Software engineering is.
Dude calm down