I was sick in bed and watching UA-cam. Fell asleep, and woke up half through this. This man is such an extraordinary storyteller, and made for some awesome dreams.
Coming from Bob's generation and relating to 90% of the times, people, technology he so beautifully--funnily-expertly narrated, I MUST admit this is 1 of the top 5 best I ever watched and was humbled by his sense of awe and reality, with an extraordinary ability to look into the future!!
Good video, tells story of the evolution of programming profession. I can vouch for his story as i retired at age 72 in 2015 after 52 years in and around programming.
He mentioned the Toyota "unintended acceleration" situation and the court case, but I do not think he properly conveyed the stark danger of what happened there. First off, Toyota followed agregiously negligent practices. Among other things, the auto industry has 94 "required" coding practices and 30 "recommended" practices when it comes to development of firmware code. In Toyotas code, they nailed 4 of those practices. They only even CLAIMED to be doing 9. Their developers did not even have a bug tracker. He mentions that Toyota had to pay out a lot of money. That is either not true or at least we don't know if it is. What happened is that in a CIVIL lawuit, Toyota was made to pay $1.5 million to each of 2 families of people killed, so $3 million total. Then, after the jury had pronounced them responsible for the deaths, but before the jury could award a punitive damage amount, Toyota settled confidentially with the 2 families that brought the suit. We don't know how much that was for. The purpose of punitive damages is to provide an economic wound so large that the company would have to be suicidal to continue their behavior. It is the ONLY effective way to modify the behavior of a corporation. We know from actual cases that car companies in particular like to simply calculate how much they are likely to have to pay out in lawsuits and compare it to how much it would cost to change their behavior, and do with whichever is cheapest. It's usually the lawsuits unless there are large punitive damages changing that calculation. However the really scary part is the OTHER court case against Toyota over 'unintended acceleration.' The CRIMINAL case. They were charged with criminal negligence for their business practices which led to their own engineers being unable to produce safe code. And despite how over-the-top terrible their practices were... they were acquitted. Because there are no legally-binding standards when it comes to software. There are no 'licensed software engineers' like there are licensed structural engineers. If they built a bridge with the cheapest talent they could find, deprived them of the tools and time needed to make the bridge safe, and did not give those engineers the ability to make the decisions on when the bridge was ready (instead allowing MBAs to make that decision for business reasons), the executives and managers of the company would go to prison. Not 'the company gets fined', but individuals would get locked in a cage for doing things that are dangerous to people. But if software is involved? All bets are off. You can be as slapdash as you want and build things that kill people and just pay a few settlements to the few people who can afford to fight a lawsuit against you for years. Much cheaper than hiring expensive experienced experts and much more comfortable being able to treat them like generic replaceable cogs whose judgement any middle manager can override on a whim if it suits the business goals of the company.
Spot on! The IEEE has been trying to provide the sort of professional body status that Bob referred to for a very long time. Software "engineers" must be the only engineers that don't follow a defined mentoring scheme designed to instil best practices.
The real problem with referencing these cases is that it almost certainly was ‘t a defect in the car’s software. There was a possible problem with the floor mat getting in the way and/or the deaths are almost certainly the result of human error. None of the court cases established the existence of a defect. Toyota has always denied the existence of a defect. And operator error is a real thing., 11 dead in Santa Monica when a 90 year old man doesn’t have his foot on the brake when he starts the car. It moves toward a crowd at a farmer’s market. He panics and slams the brakes only in his panic he actually slams the accelerator. Panic plus disorientation can lead to people holding down the accelerator while they think they’re holding down the brakes. If you’ve ever gotten your fingers misaligned on your keyboard and spent way too long trying to fix it but still writing gibberish then you know first hand how sure you can be that you’re hitting the right keys only to discover that you’re wrong.
This was one of the most sober talks i have seen in a while! I wish that I could show this video to several people, but probably they would not have the patience and the discipline to watch til the end and assimilate the message. Maybe we are faded to become regulated like doctors, engineers, architects and be there for our choices. It's true, no one understands us. Project managers, 9/10 do not understand us. It's our job to assume risks and commit to something greater. Its our job to say no (quite often sometimes). It's our job to stop thinking this profession is just a playground of self experiment and showcases. Too many show cases. Such a nice talk, thanks for the reflection!
I am an instant fan. Thank you uncle Bob Martin! My father became an IBM 1401 computer programmer in the 60's and I became a computer programmer in 82. After 30+ years of experience I felt alone thinking I was the only IT professional that saw the whole software industry as a chaotic clusterfuck of languages, code and frameworks from hell. Everyone else seems to adore the nonsense and inefficiency of software development - I call it "bug farms". Thank you for telling it so clearly in such detail and with fun.
So am I. Agree. It's fear and tears to talk to some new-fashioned devs and to see their _masterpieces_. I can bet there are a couple of percent of them who knows what the stack is.
Mauro Dutra I’m currently learning programming and was asking myself the same question. “Why do they have so many programming languages?” It’s honestly really dumb.
I keep thinking on the same lines but I was always afraid that perhaps it's just my laziness or dumbness that's skewing my perception of the modern clusterfuck of programming. I feel so relieved that an experienced professional feels the same.
@@foobarmaximus3506 although i'm in my early 20's i feel very irritated when seeing people are leaving the foundations and focusing on learning frameworks and neglecting the lower layers. The problem as i see it's that a large amount of new programmers jump right on frameworks and never touch the needed skills, propper design and software engineering until its too late. I find it hard to convince new comers to folow at least the bare minimum process needed to write software. There is almost always a guy that rant on me saying that's bullshit By the way assembly is my first language.
I'm a somewhat retired programmer. I retired for three main reasons. 1) health issues. I'm epileptic. so about once-twice a year I waste a few hours at a hospital after losing conscious. for some reason, I got always fired less than a week after that happening. 2) I didn't want to "finish" my code until I was sure it worked properly. for some reason, my bosses didn't care about that. they do care about telling the client "we did it before the deadline" 3) somehow the people that decide whom to hire got the idea that having worked for over three years in a language (and, goes without saying, four-five companies) it meant you were outdated because there's a newer version of said language. well, there's a fourth reason. I need a stable job to get a stable income and somehow put food on a plate in front of me. but that's beyond the point. now, you all may be thinking "why is this guy telling us about his life here?" well... the answer is simple. I wanted to introduce myself before I gave what I believe is the important stuff. I was hired by a company I'm not going to name as part of a group that had to do a simple task for an insurance company (that I'm not going to name). update the software from an old program that was made more than fifteen years ago to the new technologies. now, one of the first things I mentioned, at the interview when they explained what was the job, was that I had zero experience on the source programming language, only on the language that was used on the new version. their answer was "don't worry. you won't need it and, even if you need it, your companions will be able to help you" I though "what a great company. it's a lot better than the others I have worked before. maybe this will be my place" and I couldn't be more mistaken. what was the problem I found? there was two of them in fact. and I'm not sure which was worse: 1. every few days we found rounding errors over the original code. money quantities were rounded wrongly. and the client wanted us to keep them on. it got shocked me the first half dozen times. until I noticed all of them were in favor of the insurance company (and this is why I don't want to name it) so they didn't want to lose the extra income. it's unethical and made me puke but ok. I could understand it. 2. one day, during a meeting of the group, we got scolded because we were barely keeping the deadlines. we explained that we had to test the code to ensure it would work "properly" (note the quotes due to previous point) and their answer, a couple meters away from the insurance company main responsible for the project, was that it didn't matter if there was a few bugs on the code as long as the deadline was meeting. now... while I can understand that deadlines are one of the most important things on any serious project what pissed me off about this was this simple fact: is it really so important to finish a project in less than half a year when the source is a sofware that has been working, with intentional errors, for more than fifteen years? note: out of the eleven team members only one was female. and over half the team lacked any kind of relevant experience programming. sure, everybody knew the language we were using but, as pointed in this video, that and programming are two completely different things. thank you all for reading me until the end.
It was a really interesting read. I am epileptic as well but I only have night time fits so I didn't have job issues, also having sick days helped a lot. This kind of practice is still alive, even in the UK. Accounting program that major firms use, have major calculation errors that was known for the last 5 years, yet "somehow" there is never time to fix it.😔
@@NewbOoyNS mine are mostly night time fits with a handful exceptions (never at work until a while ago but not it's not an issue anymore. in fact they prefer that I'm epileptic) but at the hospital they always prefer to keep me a few hours because sometimes I do repeat after 2-3 hours and the second (or even third) is always a lot stronger. to the point that one time I got the second shortly after the ambulance arrived at my home and they called for another ambulance because they didn't feel prepared to deal with it (and, frankly speaking, they weren't and, without the second ambulance I would be dead) and it's true. there's never time to fix things. only time to make a larger mess by adding useless functionality. sometimes to the point that it's better to redo it from zero instead of trying to fix anything but, of course, those that pay will never see it that way (until the system says "fuck off. I refuse to work" and we see a blue screen with white letters)
I watched every minute of it and didn't get bored at all. I must say it is a scary future that Bob Martin showed for us there, and i can't say that we won't get there.
Woah that was really cool. I did not expect that ending of regulating ourselves but it does sound like it would make us more responsible and therefore more productive and purposeful in our programming.
Just adding a transcribed quote for something I'm writing - one of the highlights for me: Quote: from 57:45 - "If we have made any advances in software, since 1945, it is almost entirely in what not to do. Structured Programming was in what not to do - don't use unrestrained goto. Functional Programming - don't use assignment. Object Oriented Programming - don't use pointers to functions. What we have learned over the last 70-some years is more about what not to do, than what to do. There have been no radical advances in software technology. The craft of writing software remains roughly the same as it was in 1945 - a little more modern, but not essentially any different." - to 58.43
This! As a novice programmer who has started a year ago. I went into my first year of college with such a huge motivation and respect to the field, until all of it eventually waned. I tried to learn programming as best as I could, until I begun seeing flaws everywhere I looked. Somehow it all went from being very logical in the beginning to very illogical later on. Every project we were told on what not to do, but nothing about what to do. Basically the professor, teachers and even the language itself were restricting us from our own thought process on how we would solve the particular problem. Since then I have been changing from language to language, and never really found the one I liked the most. Most of them had things that I liked and didn't like. I wish people that are veterans in this field would someday make a leap and improve the whole programming and technology overall. I remember the day when I learned to write "Hello world" in Java, and then later did the same in Python in my spare time. I was a little bit shocked of why I had to make so many unnecessary steps to write it out in Java in comparison to Python. I mean why can't we have something simple but complex and especially different from current software technology...
Jamie Stevenson I agree, when I was a kid I use to play my mother in checkers. She would always beat me. After a few years of losing. I asked "why can't I beat you?" She replied "I takes a great loser to be a great winner." My Point is that we are finding all the want don't to do's. Then we will get to that point when software evolves.then everything changes.
don't use pointers to functions?? wtf ??? lol You can't do inheritance and polymorphism without them. You can use shit like delegates in C# without the concept. Event programming in general is all pointers to functions. Do you know what a virtual function table is?? apparently not
Always good to hear these talks from someone who actually lived it. The Fortran - hole puncher - rubber band /basket - computer operator handoff - 24 hr. delay process really shows how far things have progressed.
When a new market emerges, is profitable, then investors come, profit decreases, competition is higher. When a new craftsmanship appears, and there are more students than masters the product quality lowers I guess. Me and most of my fellow programmers were thrown into production from day 1,the only mentors we had were search engines and now stack overflow, there is no wonder that waterfall and OOP were successful, enforces some rules and bring some order in chaos. And another thing that lowers the standards is that when it wasn't an elitist profession any longer it became a job, just a job to pay for bills, don't want to improve the code, just want to get the task done. This and hardware evolution, programmers lead by product managers and more factors ofc.
I was just thinking about that. I guess when you are paying Indian programmers $9 per hour, QA is not on the top priority list. I liked the slide from H2G2 showing the planet of middle managers.
This comment is a confirmation bias at its best. and what a casual bigoted response by Roland Lawerence. If anything software engineering has become more robust and reliable thanks to the openness of the community we have now, compared to dark days of the speaker. And as a result the number of engineering disasters has drastically decreased.
you must not have heard too much about programming then, this talk was mediocre at best, anyone can get up and talk about history and then add in some fluff about what should happen in the future
@@johnames6430 You don't understand succinctness and intelligent inference. He has illuminated the very heart of what programming is, how it proceeds and what the outcomes can be. What you want is a pedantic, 24 part series directed at incel nerds. Bugger off...
As a software developers with 25 years of commercial experience I find complexity has also risen exponentially for no sunstantial gain. For instance, one recent fad is javascript on the server, via nodejs....Heck, we were doing Javascript in (Classic) ASP back in 92. To paraphrase "Due to the exponential growth of developers every year, at least half of existing developers will have less than 5 years experience, and due to a lack of experience are continually destined to clumsily re-invent programming languages, libraries and platforms." This at least partially explains the endless fad language/platform churn of things like Rust, Go, Dart, Angular etc. Another reason for an endless array of languages/platforms/libraries is because the "inmates are running the asylum". The programmers get to pick the tech in most cases, and the latest craze is always perceived as being better, sometimes by programmers but usually by management, regardless of its practical utility. The more complex the language or tech the more kudos programmers believe they are owed. Many developers seek to become a high priest of a particular tech. When programmers meet, the more geeky ones especially, will try to ascertain your knowledge of a particular tech to work out your status relative to theirs. It also comes down to greed. Probably the largest reason for the rising complexity is IT PUTS BUMS ON SEATS that consulting companies can charge out. They charge more for the latest tech craze/fad and it is more lucrative for a developer to be on that wave. As its more lucrative for the developer to be on that latest tech craze/fad they make choices that move the industry to embrace it. And that's before you add a bunch of Industry Certs to stretch out the process of documenting requirements and testing and its a license to make money. Things don't become simpler because there is no money in making it simpler, and there is no money in making a complete do-everything solution either. Microsoft, Oracle etc have realised that their tech has greater buy-in when they create an incomplete solution on which external vendors must add functionality. This creates a mountain of vested interests in the product/solution. If it were simpler to create apps/programs/solutions then things would get done faster and there would be less money in it. Add increasing complexity to the development process and you can extrend the time it takes to make app/programs/solutions and therefore rake more money in.
> This at least partially explains the endless fad language/platform churn of things like Rust, Go, Dart, Angular etc. I'm not touching web frontend technologies, but Go and Rust each have a pretty good raison d'etre. Go is designed and implemented by people with decades of experience like Rob Pyke and Ken Thompson who worked on Unix. It's designed to replace C for systems programming keeping the simplicity, but adding better and more modern primitives (channels and goroutines for example). Rust's compile time checks promise to eliminate memory leaks and concurrency problems in a unique and efficient way. These are powerful tools that address current world concerns (like our poor history with memory management). The hardware we run software on top of has drastically changed and we need to change the way we implement abstractions on top of it (multi-core processors, memory hierarchy, networking). Not all new things are fads. The world is changing. The internet is changing how and what we build as software developers. The hardware is changing. Our architectures are changing. It's only natural that we search for efficient solutions for the problems we have today.
I loved this, He has my juices flowing again to program. I'm paralyzed from neck down and learn some programing in the early 90' I would like to get back in to programming as much as I can but it's been so long I didn't remember much and have tried only to get overwhelmed. I type slow with a sip/puff before I used a mouth stick and could type 15-20 words a minute, not so with my sip/puff. I do have dragon software. Can someone point me to the right platform, language I should start learning. Thanks,
There are many places you can start, among them edx’s CS50 course by David Malan. It’s a free course, and I highly recommend the college version of it.
Thanks for all the good advice! I want to make some small programs from reminder, and then a capable Environmental control unit. I know there are a lot out there but I want to build a free/ low cost version that work on with other OS like, win, linux
Trying to foresee the future without studying the past is like trying to calculate future trajectory of an moving object without asking where it came from or how it moved before
At the end he laid out the big picture of programming, and that is of a professional body. More than that he brought into realization of software being an industry that could, and probably will, be regulated by the government. That will truly make the software a very inefficient, and draconian industry that will make software cost much more than it does now. However, he made the point of software being ubiquitous and it's inevitable potential for disaster. If you want a similar bleak scenario of computing in the future, check out: digitalfuturelife.blogspot.com/2010/11/future-shock.html
@unclebob you were right with the recent Boeing accident only a few years after this talk. As programmer's we have to take responsibility for what we design and implement. To all who's affected by this horrible accident we apologize and hope not to let anyone down ever again.
Summary: 80s-C/ObjC/C++ story about how Steve Jobs kept ObjC alive says no one is ever happy with their language Male skew/history Female skew goes back to 36 + Alan Turing...+ Annotated Turing book relays, mercury tubes, CRTs, ... 1945- Alan wrote floating point and made a couple statements "We shall need a great number of mathematicians of ability" because "there will probably be a good deal of work of this kind to be done" "One of our difficulties will be the maintenance of an appropriate discipline, so that we do not lose track of what we are doing" magnetic cores, you could actually shut off power and restore it and it'd continue running as if nothing had happened 53- Fortran, penciled coding forms -> punch cards 58- Lisp, functional programming 60- O(1E2) computers in the world, O(1E3) programmers that are 30yo mathematicians,scientists, and the like. No OS, libraries, etc. transistors 65- 10'000 1401 / O(1E4) computers (rent $2500/mo $20k/day), 4000 bytes memory. O(1E5) programmers, still learned adult trusted and disciplined people if not mathematicians, not 22 yo people out of school :) 68 - Dijkstra says goto bad, enter structured programming C - K&R, mathematicians 70- 1E5 computers / 1E6 programmers, 25 years from 1 to 1'000'00 programmers. Now CS courses, new are mostly male students in early 20s Programmers are doubling every 5 years, so less than half of all programmers have 5 years of experience. Hardware has changed tremendously, the iphone would have been the entire world's economic output: 50 trillion dollars and 170 Vehicle Assembly Buildings (the large building at NASA's Kennedy Space Center, At 3,664,883 cubic meters 129,428,000 cubic feet it is one of the largest buildings in the world by volume), would require 500 of the largest nuclear power plants. And once it was built you'd have no one to call with it xD Software hasn't. You'd recognize the earliest code, you wouldn't like it but you'd understand it. You could time travel someone either direction and it'd take "24 hours" to recover from the shock/disappointment but they'd be able to understand and write the code. It's essentially assignments, if statements, and while loops. Any changes are what _not_ to do, structured = don't be crazy, functional = don't assign, OO = don't use function pointers (??, I don't feel like that's quite what was learned but whatever) What must change. Discipline. 2001- Agile manifesto, fixed time, estimate in relative units, customer communication, continuous integration, collboration, ... programmers can't agree on disclipline and technical practices Agile split- Business Practices \ Technical Practices What must change: "we (agile) must grow up", define profesion, choose practices and disciplines, reunify, someone has to lead. 1:11 everything in modern world uses software systems. Software can control breaking, steering wheels, and that _is_ killing people already. Programmers wrote code to "cheat" EPA "if in test mode ...". One day one of us is going to do something stupid that kills many of people and politicians will ask _us_ (programmers) "How did you let this happen?" and if we can't answer well they will regulate us setting what languages and morals/ethics and taking an oath to follow and some body that can discipline and prevent you from being a programmer.
Defenitely the best...movie that I've seen this year. Yes it's such a great story, and listening how he's explaining that, and the succession of toughts, I can recognize that he's a programmer, and I'm proud of being one too. Thanks for the inspiration!
Mr Bob tried to make a point and according to the comments a lot of people have missed that point. The future of programming is in better self regulation in the technical aspect of our profession. We have mass production of programmers and software while Agile slid into the business waters leaving nobody to actually care about the quality and potential disastrous consequences.
*that's not the root though. The word was used before telegraphs, when letters were transported by horses. A relay was the station where the mailman exchanged the horses to get fresh ones, because they were tired after a certain distance.*
We need more people like Bob Martin in all levels of business and government. He is so right. We are so dependant on technology that we'd be thrown back maybe one hundred years without it. For example, I wonderful how many young people can do long division without a calculator. Love Mr. Martin's presentation.
The future is AI assisted programming, where a programming language will be built around what AI is capable of assisting. Right now we call that "static analysis tools", but the problem is the tools are built around the programming languages. When you build a programming language around the limitations of what AI is able to help you with, you will have created a platform of unprecedented productivity.
Imagine how Alan Turing would have reacted to AI writing code. Especially code in which bugs can be really dangerous (for example cars and medical devices).
"The number of programmers doubles every 5 years. That means half the programmers have less than 5 years of experience. We live in a state of perpetual inexperience. We cannot escape this. There aren't enough teachers to teach the new people coming in, and so the new people coming in must repeat the mistakes made by everyone else over and over, and there seems to be no cure for this." "Uncle" Bob Martin - "The Future of Programming" - Starting at Minute 50:57
Half of programmers have less than 5 years experience. Half of programmers have more than 5 years experience. That leaves space for 1 on 1 mentorship which would solve the problem. But such a thing would probably show results after a year or two, and corporates tend to think only one quarter ahead Those are old guys in the management who are at fault, not the young programmers.
@@orokushi5953 Experience alone doesn't seem enough to really get a deep understanding, that only works for those with an extraordinary curiosity and the drive to think deeply about the things they're doing. The rest will vocally defend terrible practices they learned in their first week of programming until they die, no matter how often those practices ruin their day. The other problem I see is that many tech companies are young and tempted by the initial savings of shoddy craftsmanship even if the costs are orders of magnitude higher in the long run. In such an environment any calls for caution will probably go unheard.
Many of my colleagues does not comprehend what Bob Martin talks about hence they are bored by this talk. They enjoy and share the shot and entertaining talks from Richard Feldman. I wish UA-cam would recommend this talk over that of Richard Feldman.
I agree, and that is what I'm doing. That's why teachers say it's always good to do some of your own research. I feel that is where this stuff falls into.
What an amazing talk. I love Uncle Bob Martin. I wish we all could be so much professional and take responsibility of the code we write. I hope in the future, we the software developers will focus more on quality than quantity.
One of the best presentations I've seen on this topic. Now I'm gonna refer to "Uncle Bob" whenever a colleague is arguing for bureaucratic rules and governance over projects. DEVELOPERS! DEVELOPERS! DEVELOPERS! (S. Ballmer) :D
@@aammssaamm , and in that.. AI writing all code and programmers have a hobby to amuse themselves but not to provide sustenance to their lives. All programmers will be out of a job in 20-30 years because it will be vastly less expensive to have AI do the same job, maybe not as well, but functional and that's all that matters to the penny counters. The "future of programming" for "people" is non-existent.
TLDW: In the past, programmers were matured and self-disciplined as they were older(30s-40s). Since 1970s to 1980s, there has been a surge in young programmers(graduates), and this trend has been going on until now. If we do not start having some sort of discipline, such as oath of doctors or lawyers etc, something bad may happen in the future and we (the programmers) will have to bear the consequences. Consequences such as government implementing unnecessary regulations etc..
I don't have patience more than 3 minutes for a talk. I am an agitated guy I may say! But here, i listened ( for real ) every single word. I don't even read my code like that. I do it like : bla.... if( ...aha), than, yep, execute ....that, aha, I read it. A couple of seconds, this is my standard line in patience. And here....an hour, 18 minutes and a bunch of seconds... Wow. This talk really got me into it! Great ! I loved every second of it!
The good stuff: The Agile Manifesto at 1:00:45. Individuals and interactions over processes and tools; Working software over comprehensive documentation; Customer collaboration over contract negotiation; Responding to change over following a plan.
oxied the prediction was not literally. The prediction is that we the programmers are making code without principles and it is leading to people dying. He mentions about a plane crashing into a football field somewhere around 60 minutes into the video. But did not specifically said which plane.
On 14:50 Uncle Bob shows a russian relay. The inscription on the relay contains the thickness of the conductor and the number of turns in the coil and that the relay contains silver.
Incredibly inspiring, thank you Uncle Bob! Maybe only last 20 minutes or so actually are about the future, but I found entire talk fascinating. I guess it's time for a Lisp tutorial.. ;D On a more serious note , until now I 've only known Uncle for his books. As it is said, if you want to read only one book about programming, pick one of his. I found his talk no less interesting and, how to put it, understandable and entertaining without need for several Ph.D.'s or other degrees :P This man is a legend.
I bet there arent many women in beauty salons fretting over why there arent more men painting nails ... dont see why its our job as guys to get women into the industry. Ive never stopped women from joining yet somehow its my job to fix the situation.
Because beauty salons suffer little from the lack of a male perspective but programming and many other fields suffer greatly from a lack of a female perspective. You want a better example to help support your point? Social work. Public schooling. Yes, public schooling suffers greatly from the lack of male staff. Interesting enough though, it isn't women keeping men out. It's men keeping themselves out, just as it's men keeping women out of programming (intentionally and unintentionally) and a great many other fields of great consequence. One day you may gain an understanding of false equivalency and you'll be much better for it.
I agree on the idea about project managers invasion. Before this video, I could not understand why that project managers were needed, I even could not deduce what their responsibilities were. I refuse to accept the idea of having a project manager which does not like programing! and believe it or not, these kind of managers are part of most of the software companies nowadays.
A good project manager is a god send. I've worked with project managers that knew a lot about the business they're in and could explain the needs, manage expectations and properly allocate time for things - and those people are great even if they know nothing about programming. Unfortunately 90% of them are b.a dorks that have no understanding of neither the business or the production floor - all they do is frustrate the devs and the clients/management.
I personally think project managers are hired because programmers are expensive and because delivering a program takes time, then companies feel they are paying thousands of dollars to win a race but they are betting on a turtle. So the project manager is there to rush us and make sure we are actually delivering and not just fooling around. Because in reality, there are many programmers who don’t deliver because they just simply can’t code. The project manager is there to help the company to spot these “programmers” and get rid of them.
He needed that long to establish the authority fallacy. I can understand why. Also it is easier to describe a dystopian future than an optimistic one; ask Hollywood. This lecture fails to deliver.
A good article on the subject can be found over at Quillette, "Why Women Don’t Code". Take a look at the graphs. Martin is just spouting PC lies. Quote "Pictures help to tell stories and this one drives home the point that even as women were taking a greater share of slots in medicine, law, and the physical sciences, they represented a decreasing percentage of computer science degrees. This is consistent with the idea that women simply chose to pursue other interests, but NPR chose to highlight the suggestion that professors teaching introductory courses were creating courses unfriendly to women." and "In 2013, Psychological Science published a paper that explored this question further entitled “Not Lack of Ability but More Choice: Individual and Gender Differences in Choice of Careers in Science, Technology, Engineering, and Mathematics.” The authors included Jacquelynne Eccles who is well known for a career spanning decades studying student motivation and gender differences. They concluded that women may choose non-STEM careers because they have academic strengths that many men lack. They found that individuals with high math ability but only moderate verbal ability were the most likely to choose a career in STEM (49 percent) and that this group included more men than women (70 percent men). By contrast, individuals with both high math ability and high verbal ability were less likely to pursue a career in STEM (34 percent) and this group had more women than men (63 percent women). They write that, “Our study provides evidence that it is not lack of ability that causes females to pursue non-STEM careers, but rather the greater likelihood that females with high math ability also have high verbal ability and thus can consider a wider range of occupations.”" The truth isn't PC and if Martin told the truth, he would probably be ostracized from UA-cam. However, the truth is still the truth.
Fun talk, I wrote my first program on a PDP-8, and in the same year on a IBM 360-30, that was in college, I liked the end result more than the programming, but the day we had to write internal codes, exits for that PDP-8, and the bootstrap loader, then my fun began, the college bought a PDP-11/45, for administration, we got the PDP-8 all for us to play with...I just loved it, I was hooked big time, I liked playing with the internal programs...I became another breed of programmer, a System Programmer, my first job we had an IBM 370-168 machine, a monster of a machine, I was introduced to one language we had a session on in college, Assembler, we really were a special breed, so much that I never heard a presentation on that career path, we had no girls in our groups, sometimes as many of 40 system programmers, not a single woman, we knew why, always on call 7/24, working all the special holliday, doing upgrades, maintenance, PTF's, exits, you name it, nobody in their right mind would like to live like that, getting a call in the middle of the xmas party and having to leave and go to the office....I loved every minute of it, what a life!!!
It’s an interesting observation that functional programming, structured programming, and object-oriented programming about restricting what we do. But I think it is over simplistic. All of these provide not only restrictions, but also alternatives. Functional programming says don’t use assignment, but to make that really useful you need powerful ways of creating functions, which LISP and its successors had. Fortran had functions, but did not provide ways to make new functions out of old. Structured programming, in the simple form of not using unrestricted gotos, only worked because it offered us alternatives: structured ifs, whiles, case statements, etc. On OO, I think Uncle Bob got it wrong. It’s not about not using pointers to functions, but rather about not allowing design decisions to permeate the whole program. Instead we put fences up that restrict how much of the program is effected by each decision - information hiding. But, if you only have the restriction, you get modular programming like we used to do in Euclid, Modula II, and the early versions of Ada. OO languages offer you something beyond just the restriction, they offer interfaces, inheritance, and virtual functions, which go beyond modular programming in separating interface from implementation, because now we can have multiple implementations of the same interface in the same program - something that could not easily be done in earlier paradigms - and something that allows us to write safe polymorphic code.
If we consider what has happened with the development of orchestral musical instruments, it is an extreme version of software industry development. Most of these instruments come from 17th to the 19th centuries but have mostly frozen since then. The reason is that it takes many thousands of hours of practise to master any such instrument. Having invested so much time, most musicians are unlikely to take up anything that varies significantly from the standard design they are so invested in. We're stuck, for the most part, with 19th century materials and mechanics! History is littered with brave but broke musicians and designers who have tried to improve on these instruments! (but to be fair, some very minor improvements have been made to some of them). So, the impasse has been resolved to some extent by making instruments suitable to making completely new musics - electric guitars, electronic and then digital synthesisers. The contemporary synth is vastly different to the originals from the 40s and 50s, because they haven't been shackled by looking to emulate the past. (Well, actually there is a movement to use analog synths that has been emerging over the past decade or so. But mostly the industry is looking forward, driven by commercial reasons. So, it seems to me that as the software industry grows and the programmer base gets bigger, there'll be more people programming in C++ and similar languages in the future and their careers are assured!
Programming languages are easier to learn and to switch around. The difficult part is solving the problem in the best way. And in the beginning the best way is often not necessarly obvious
There are a lot of mind blowing new kind of music instruments. And Rust will beat C and C++. If that program then needs to be on server or web app then compile it to WebAssembly.
I'll save you an hour or so: The future of programming is 'self regulation', where a governing body can declare you to not be a programmer for not conforming to *our* standards. Yeah. Sure. Good luck with that. And considering how much he references the "plight" of how many men are eagerly joining the field, I'm pretty sure I can guess what "our standards" will be. But even assuming it was even remotely sane, good luck getting even a single programmer to recognize its authority. Especially one that didn't conform to "our standards." So now it needs the firepower of a government or 5 to enforce its rules. And now the whole of creative processes and software innovations are controlled by bureaucrats. Incredibly corrupt ones. Who will stifle innovation and control the entire modern world. Sounds great.
wow, I guess he needs an hour to "sell" that. we've had rapid innovation in programming over the last 50 years. remarkable revolutions are happening. all that will come to a screeching halt if we put on those regulatory handcuffs
@José Mário Silva Júnior I think it is quite problematic in some cases as that gives more power to big companies gaining monopole like status, who are focused on making money in the first instance.
Consider it from a different technical field - networking. They face the exact same levels of danger. When networks fail, finances and even lives might be on the line depending on exactly how and when that network fails, and who gains access to it. They have heavy prices to pay and therefor they require a lot of discipline in how they operate. How do they enforce that? Certifications. You *cannot* get a job in networking for any respectable company dealing with sensitive information without well respected certifications such as those offered by Cisco. It's not as simple as "Go get a degree, 8 years of experience, and then apply" - they want *proof* that you can follow the expected conventions. Programming? That doesn't really apply. You can get jobs in the programming field for these same organizations in a position that's arguably just as impactful, if not moreso, than networking because they just want years of experience. That's pretty much it. Maybe a degree from a college. But even those college degrees are all usually pretty worthless because they aren't very standardized, no degree is equal. Self regulation is definitely something that the industry could benefit from, and having it come in the form of certifications is probably the way to go. The problem is that there aren't enough developers, and to require them to go show up with certain certifications would probably mean job listings just never get filled. :/
Many (most?) professions are regulated by (self)governing bodies: doctors, lawyers, engineers, architects, etc. Certainly in engineering innovation continues while at the same time holding the line, it seems to me, on fly-by-night operators. I think governments have left it to the professions to actually define the standards of practice because governments have realized that they don't have the expertise to do the writing. They just know they want order and professionalism. I think a similar form of self-regulation would be a boon for the overall quality of software in the world. Sure it may impact on the number of people actually creating software but there is a great deal of poor software out there and a great deal of useless software out there; a cull of the current herd (or at least a recognition a standard of professionalism for vital programs) and a "you must be this tall to call yourself a software designer" impediment to engaging in professional practice might not be such a bad idea.
Yes it was completely hijacked and 'simplified' to basically let management visualise the lack of resulting progress and point fingers at failed promises, all the while never allowing any time for anything the MBAs don't think needs to be done.
The guy complains and rails about how the women somehow disappeared from the profession, what he doesn't seem to notice is that the work changed. He shows these pictures of women working with the computers, but neglects that many of them were there simply because the men were at war or doing harder labour at the time, and beyond that much of the work was effectively clerical or rote. The reasons that women left the field are straightforward: as the field became more solitary and involved less rote clerical work and more analytical work, and as men were no longer actively drafted into the military, women's interest in the field dropped and the supply of analysts boomed. He then goes on to detail all of the pioneering moments for paradigms in the design of computers and programs, and at the genesis of each of these is a great man. This is no accident, the most significant contributions to the field have been made by the people actually operating in the field at a high level, most of whom have been men, with notable exceptions like Rear Admiral Grace Hopper, who popularized use of compiled high level languages, and was the lead technical consultant to the committee that produced COBOL. There was never a time where that many free financially-stable women in a society at peace chose work like this, and that's not a moral wrong. Let people make their own decisions based on their own values, rather than insisting every woman be more like a man, to hide the fact that labour productivity has been stagnant in many ways for decades. And no, waterfall was not adopted because "programmers were now *boys* in their twenties", it was adopted because it looks like an orderly process for delivering a product that would satisfy a corporate culture, even if it turns out to be unproductive.
Well said. I think the forced diversity quota's of the current AAA corporations stem from the belief that men and women are equally interested in various fields. One of the best examples of a double standards is that a tech company will try to hire more female developers, but a hospital will not try to hire more male nurses.
the discussion of core memory put me in mind of our old DEC-20 computers where I went to school. One of them had a set of PDP-11-based front end processors, which had real core memory (despite most of the rest of the memory in the system being solid state.) The PDP-11 FEPs would crash a lot, and a co-worker's comment was something along the lines of "It's a good thing that FEP has core memory, so it can remember how much it screwed up".
Every IT Services Business members should watch from 59 min till last, Engineers don't sell your time, have hours in your control and be accountable to outcomes you see as the best value.
This is eye opening lecture for programming ethics and moral standards. What an energy Uncle Bob... so inspiring...
I was sick in bed and watching UA-cam. Fell asleep, and woke up half through this. This man is such an extraordinary storyteller, and made for some awesome dreams.
I now feel like a more competent programmer due to listening to this while I slept.
Coming from Bob's generation and relating to 90% of the times, people, technology he so beautifully--funnily-expertly narrated, I MUST admit this is 1 of the top 5 best I ever watched and was humbled by his sense of awe and reality, with an extraordinary ability to look into the future!!
This is a mindblowing talk. I love every part of it.
Good video, tells story of the evolution of programming profession. I can vouch for his story as i retired at age 72 in 2015 after 52 years in and around programming.
What did you like most about programming? Could you share some of your philosophy to a 27 year old man?
A 73 year-old programmer advice would indeed be useful. :)
Perspective is often one of the missing pieces for new software developpers.
You missed the point.
He mentioned the Toyota "unintended acceleration" situation and the court case, but I do not think he properly conveyed the stark danger of what happened there. First off, Toyota followed agregiously negligent practices. Among other things, the auto industry has 94 "required" coding practices and 30 "recommended" practices when it comes to development of firmware code. In Toyotas code, they nailed 4 of those practices. They only even CLAIMED to be doing 9. Their developers did not even have a bug tracker. He mentions that Toyota had to pay out a lot of money. That is either not true or at least we don't know if it is.
What happened is that in a CIVIL lawuit, Toyota was made to pay $1.5 million to each of 2 families of people killed, so $3 million total. Then, after the jury had pronounced them responsible for the deaths, but before the jury could award a punitive damage amount, Toyota settled confidentially with the 2 families that brought the suit. We don't know how much that was for. The purpose of punitive damages is to provide an economic wound so large that the company would have to be suicidal to continue their behavior. It is the ONLY effective way to modify the behavior of a corporation. We know from actual cases that car companies in particular like to simply calculate how much they are likely to have to pay out in lawsuits and compare it to how much it would cost to change their behavior, and do with whichever is cheapest. It's usually the lawsuits unless there are large punitive damages changing that calculation.
However the really scary part is the OTHER court case against Toyota over 'unintended acceleration.' The CRIMINAL case. They were charged with criminal negligence for their business practices which led to their own engineers being unable to produce safe code. And despite how over-the-top terrible their practices were... they were acquitted. Because there are no legally-binding standards when it comes to software. There are no 'licensed software engineers' like there are licensed structural engineers. If they built a bridge with the cheapest talent they could find, deprived them of the tools and time needed to make the bridge safe, and did not give those engineers the ability to make the decisions on when the bridge was ready (instead allowing MBAs to make that decision for business reasons), the executives and managers of the company would go to prison. Not 'the company gets fined', but individuals would get locked in a cage for doing things that are dangerous to people.
But if software is involved? All bets are off. You can be as slapdash as you want and build things that kill people and just pay a few settlements to the few people who can afford to fight a lawsuit against you for years. Much cheaper than hiring expensive experienced experts and much more comfortable being able to treat them like generic replaceable cogs whose judgement any middle manager can override on a whim if it suits the business goals of the company.
And that's why we need self-regulation.
Very interesting summary. Thank you for sharing.
Spot on! The IEEE has been trying to provide the sort of professional body status that Bob referred to for a very long time. Software "engineers" must be the only engineers that don't follow a defined mentoring scheme designed to instil best practices.
The real problem with referencing these cases is that it almost certainly was ‘t a defect in the car’s software. There was a possible problem with the floor mat getting in the way and/or the deaths are almost certainly the result of human error. None of the court cases established the existence of a defect. Toyota has always denied the existence of a defect. And operator error is a real thing., 11 dead in Santa Monica when a 90 year old man doesn’t have his foot on the brake when he starts the car. It moves toward a crowd at a farmer’s market. He panics and slams the brakes only in his panic he actually slams the accelerator. Panic plus disorientation can lead to people holding down the accelerator while they think they’re holding down the brakes. If you’ve ever gotten your fingers misaligned on your keyboard and spent way too long trying to fix it but still writing gibberish then you know first hand how sure you can be that you’re hitting the right keys only to discover that you’re wrong.
How about Boeing max 737 software bug?
This was one of the most sober talks i have seen in a while! I wish that I could show this video to several people, but probably they would not have the patience and the discipline to watch til the end and assimilate the message. Maybe we are faded to become regulated like doctors, engineers, architects and be there for our choices. It's true, no one understands us. Project managers, 9/10 do not understand us. It's our job to assume risks and commit to something greater. Its our job to say no (quite often sometimes). It's our job to stop thinking this profession is just a playground of self experiment and showcases. Too many show cases. Such a nice talk, thanks for the reflection!
Programmers everywhere need to watch this!! Priceless and important
"We didn't get into this business to kill people."
Weapon systems software devs: "Speak for yourself!"
*looks away quickly in Fortran 95*
Megadeth: Killing is my business, and business is good!
ua-cam.com/video/M6eHwe-Obw8/v-deo.html
...yes, but he may be referring to the UNINTENDED CONSEQUENCES or INTUITIVE WARNINGS/ALERTS to the world .....
Last i checked the toyota accelerator stuff is apocryphal. They paid but it likely wasnt software.
@@RaviS-gj7zp Keep in mind this was recorded before the 737-MAX8 problem came to light.
Compelling presentation from a legend.
I am an instant fan. Thank you uncle Bob Martin! My father became an IBM 1401 computer programmer in the 60's and I became a computer programmer in 82. After 30+ years of experience I felt alone thinking I was the only IT professional that saw the whole software industry as a chaotic clusterfuck of languages, code and frameworks from hell. Everyone else seems to adore the nonsense and inefficiency of software development - I call it "bug farms". Thank you for telling it so clearly in such detail and with fun.
So am I. Agree. It's fear and tears to talk to some new-fashioned devs and to see their _masterpieces_. I can bet there are a couple of percent of them who knows what the stack is.
Mauro Dutra I’m currently learning programming and was asking myself the same question. “Why do they have so many programming languages?” It’s honestly really dumb.
I keep thinking on the same lines but I was always afraid that perhaps it's just my laziness or dumbness that's skewing my perception of the modern clusterfuck of programming. I feel so relieved that an experienced professional feels the same.
@@foobarmaximus3506 although i'm in my early 20's i feel very irritated when seeing people are leaving the foundations and focusing on learning frameworks and neglecting the lower layers. The problem as i see it's that a large amount of new programmers jump right on frameworks and never touch the needed skills, propper design and software engineering until its too late.
I find it hard to convince new comers to folow at least the bare minimum process needed to write software.
There is almost always a guy that rant on me saying that's bullshit
By the way assembly is my first language.
Really true
I'm a somewhat retired programmer. I retired for three main reasons.
1) health issues. I'm epileptic. so about once-twice a year I waste a few hours at a hospital after losing conscious. for some reason, I got always fired less than a week after that happening.
2) I didn't want to "finish" my code until I was sure it worked properly. for some reason, my bosses didn't care about that. they do care about telling the client "we did it before the deadline"
3) somehow the people that decide whom to hire got the idea that having worked for over three years in a language (and, goes without saying, four-five companies) it meant you were outdated because there's a newer version of said language.
well, there's a fourth reason. I need a stable job to get a stable income and somehow put food on a plate in front of me. but that's beyond the point.
now, you all may be thinking "why is this guy telling us about his life here?" well... the answer is simple. I wanted to introduce myself before I gave what I believe is the important stuff.
I was hired by a company I'm not going to name as part of a group that had to do a simple task for an insurance company (that I'm not going to name). update the software from an old program that was made more than fifteen years ago to the new technologies.
now, one of the first things I mentioned, at the interview when they explained what was the job, was that I had zero experience on the source programming language, only on the language that was used on the new version. their answer was "don't worry. you won't need it and, even if you need it, your companions will be able to help you"
I though "what a great company. it's a lot better than the others I have worked before. maybe this will be my place" and I couldn't be more mistaken.
what was the problem I found? there was two of them in fact. and I'm not sure which was worse:
1. every few days we found rounding errors over the original code. money quantities were rounded wrongly. and the client wanted us to keep them on. it got shocked me the first half dozen times. until I noticed all of them were in favor of the insurance company (and this is why I don't want to name it) so they didn't want to lose the extra income. it's unethical and made me puke but ok. I could understand it.
2. one day, during a meeting of the group, we got scolded because we were barely keeping the deadlines. we explained that we had to test the code to ensure it would work "properly" (note the quotes due to previous point) and their answer, a couple meters away from the insurance company main responsible for the project, was that it didn't matter if there was a few bugs on the code as long as the deadline was meeting.
now... while I can understand that deadlines are one of the most important things on any serious project what pissed me off about this was this simple fact:
is it really so important to finish a project in less than half a year when the source is a sofware that has been working, with intentional errors, for more than fifteen years?
note: out of the eleven team members only one was female. and over half the team lacked any kind of relevant experience programming. sure, everybody knew the language we were using but, as pointed in this video, that and programming are two completely different things.
thank you all for reading me until the end.
It was a really interesting read. I am epileptic as well but I only have night time fits so I didn't have job issues, also having sick days helped a lot. This kind of practice is still alive, even in the UK. Accounting program that major firms use, have major calculation errors that was known for the last 5 years, yet "somehow" there is never time to fix it.😔
@@NewbOoyNS mine are mostly night time fits with a handful exceptions (never at work until a while ago but not it's not an issue anymore. in fact they prefer that I'm epileptic) but at the hospital they always prefer to keep me a few hours because sometimes I do repeat after 2-3 hours and the second (or even third) is always a lot stronger. to the point that one time I got the second shortly after the ambulance arrived at my home and they called for another ambulance because they didn't feel prepared to deal with it (and, frankly speaking, they weren't and, without the second ambulance I would be dead)
and it's true. there's never time to fix things. only time to make a larger mess by adding useless functionality. sometimes to the point that it's better to redo it from zero instead of trying to fix anything but, of course, those that pay will never see it that way (until the system says "fuck off. I refuse to work" and we see a blue screen with white letters)
@@somercet1 the lousy formatting is, believe me or not, intentional.
Absolute Legend. Every new programmer and CS undergrad should watch this talk closely IMO.
I watched every minute of it and didn't get bored at all.
I must say it is a scary future that Bob Martin showed for us there, and i can't say that we won't get there.
I have always ignored this video for a very long time so today I decided to watch it and uncle sure does have some very valid points very valid.
Woah that was really cool. I did not expect that ending of regulating ourselves but it does sound like it would make us more responsible and therefore more productive and purposeful in our programming.
Just adding a transcribed quote for something I'm writing - one of the highlights for me:
Quote: from 57:45 - "If we have made any advances in software, since 1945, it is almost entirely in what not to do. Structured Programming was in what not to do - don't use unrestrained goto. Functional Programming - don't use assignment. Object Oriented Programming - don't use pointers to functions. What we have learned over the last 70-some years is more about what not to do, than what to do. There have been no radical advances in software technology. The craft of writing software remains roughly the same as it was in 1945 - a little more modern, but not essentially any different." - to 58.43
This! As a novice programmer who has started a year ago. I went into my first year of college with such a huge motivation and respect to the field, until all of it eventually waned. I tried to learn programming as best as I could, until I begun seeing flaws everywhere I looked. Somehow it all went from being very logical in the beginning to very illogical later on. Every project we were told on what not to do, but nothing about what to do. Basically the professor, teachers and even the language itself were restricting us from our own thought process on how we would solve the particular problem. Since then I have been changing from language to language, and never really found the one I liked the most. Most of them had things that I liked and didn't like. I wish people that are veterans in this field would someday make a leap and improve the whole programming and technology overall. I remember the day when I learned to write "Hello world" in Java, and then later did the same in Python in my spare time. I was a little bit shocked of why I had to make so many unnecessary steps to write it out in Java in comparison to Python. I mean why can't we have something simple but complex and especially different from current software technology...
My thoughts exactly. Had the same thing happen for me today, while writing in Python for the first time. Not even sure I will touch Java any longer.
Yes! stay away from Java, more jobs for us. mwahahaha. No but seriously you should read up on the differences between languages.
Jamie Stevenson I agree, when I was a kid I use to play my mother in checkers. She would always beat me. After a few years of losing. I asked "why can't I beat you?" She replied "I takes a great loser to be a great winner." My Point is that we are finding all the want don't to do's. Then we will get to that point when software evolves.then everything changes.
don't use pointers to functions?? wtf ??? lol You can't do inheritance and polymorphism without them. You can use shit like delegates in C# without the concept. Event programming in general is all pointers to functions.
Do you know what a virtual function table is?? apparently not
This is simply the best programming talk that I have ever seen in my life. The way that this great man delivers ideas he have is amazing.
Always good to hear these talks from someone who actually lived it. The Fortran - hole puncher - rubber band /basket - computer operator handoff - 24 hr. delay process really shows how far things have progressed.
When a new market emerges, is profitable, then investors come, profit decreases, competition is higher.
When a new craftsmanship appears, and there are more students than masters the product quality lowers I guess.
Me and most of my fellow programmers were thrown into production from day 1,the only mentors we had were search engines and now stack overflow, there is no wonder that waterfall and OOP were successful, enforces some rules and bring some order in chaos.
And another thing that lowers the standards is that when it wasn't an elitist profession any longer it became a job, just a job to pay for bills, don't want to improve the code, just want to get the task done. This and hardware evolution, programmers lead by product managers and more factors ofc.
Could not agree more!
production from day 1, since what - Education?
You're lucky you had all that. Once upon a time all you had was a reference manual for the language... maybe a book of tutorials or examples.
I wish you good health Uncle Bob! Thanks for the talk!
This talk heavily foreshadows the Boeing 737 Max.
I was just thinking about that. I guess when you are paying Indian programmers $9 per hour, QA is not on the top priority list. I liked the slide from H2G2 showing the planet of middle managers.
This comment is a confirmation bias at its best. and what a casual bigoted response by Roland Lawerence.
If anything software engineering has become more robust and reliable thanks to the openness of the community we have now, compared to dark days of the speaker. And as a result the number of engineering disasters has drastically decreased.
Ashwin Hamal brought to you by an indian programmer making $9/hour 😂
I had to okay?
@@jotty2451 😂 got a big family to feed here on that 9$/hour
Regardless of who wrote the code, it falls on Boeing to thoroughly TEST it.
The last 20 mins were the most valuable what I have ever heard. I thought I am alone with this opinion on the Earth
Iiiiiiiiijiiiijiijiiiiiiiiiiiiijiiiiiiiiiiiiijiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiijiiijiiiiiiiiiijjiiiiiiiiiiiiiiiiiijiijiiijiiiiiiijiiiiiiiiiiiiiiiijiiijjji
Same here
One of the most informative\elucidating talks on programming and its cumulative history I have ever heard, thank you.
you must not have heard too much about programming then, this talk was mediocre at best, anyone can get up and talk about history and then add in some fluff about what should happen in the future
@@johnames6430 You don't understand succinctness and intelligent inference. He has illuminated the very heart of what programming is, how it proceeds and what the outcomes can be. What you want is a pedantic, 24 part series directed at incel nerds. Bugger off...
A masterly and authoratative lecture. Very engaging and a pleasure to listen to.
1:12:28 he started to sound like joker from dark knight lol
also in the first few minutes
astute observation.
ROFL
Yes!
That's when it got good
As a software developers with 25 years of commercial experience I find complexity has also risen exponentially for no sunstantial gain. For instance, one recent fad is javascript on the server, via nodejs....Heck, we were doing Javascript in (Classic) ASP back in 92.
To paraphrase "Due to the exponential growth of developers every year, at least half of existing developers will have less than 5 years experience, and due to a lack of experience are continually destined to clumsily re-invent programming languages, libraries and platforms." This at least partially explains the endless fad language/platform churn of things like Rust, Go, Dart, Angular etc.
Another reason for an endless array of languages/platforms/libraries is because the "inmates are running the asylum". The programmers get to pick the tech in most cases, and the latest craze is always perceived as being better, sometimes by programmers but usually by management, regardless of its practical utility. The more complex the language or tech the more kudos programmers believe they are owed. Many developers seek to become a high priest of a particular tech. When programmers meet, the more geeky ones especially, will try to ascertain your knowledge of a particular tech to work out your status relative to theirs.
It also comes down to greed.
Probably the largest reason for the rising complexity is IT PUTS BUMS ON SEATS that consulting companies can charge out. They charge more for the latest tech craze/fad and it is more lucrative for a developer to be on that wave. As its more lucrative for the developer to be on that latest tech craze/fad they make choices that move the industry to embrace it. And that's before you add a bunch of Industry Certs to stretch out the process of documenting requirements and testing and its a license to make money.
Things don't become simpler because there is no money in making it simpler, and there is no money in making a complete do-everything solution either. Microsoft, Oracle etc have realised that their tech has greater buy-in when they create an incomplete solution on which external vendors must add functionality. This creates a mountain of vested interests in the product/solution. If it were simpler to create apps/programs/solutions then things would get done faster and there would be less money in it. Add increasing complexity to the development process and you can extrend the time it takes to make app/programs/solutions and therefore rake more money in.
> This at least partially explains the endless fad language/platform churn of things like Rust, Go, Dart, Angular etc.
I'm not touching web frontend technologies, but Go and Rust each have a pretty good raison d'etre. Go is designed and implemented by people with decades of experience like Rob Pyke and Ken Thompson who worked on Unix. It's designed to replace C for systems programming keeping the simplicity, but adding better and more modern primitives (channels and goroutines for example). Rust's compile time checks promise to eliminate memory leaks and concurrency problems in a unique and efficient way. These are powerful tools that address current world concerns (like our poor history with memory management). The hardware we run software on top of has drastically changed and we need to change the way we implement abstractions on top of it (multi-core processors, memory hierarchy, networking).
Not all new things are fads. The world is changing. The internet is changing how and what we build as software developers. The hardware is changing. Our architectures are changing. It's only natural that we search for efficient solutions for the problems we have today.
You do know this is what Dykstra already figured out decades before. :-)
All this. Reinvent the wheel, release it as open source and write terrible documentation. Then offer "consulting" services for a fee.
I can listen to Uncle Bob forever. Great one.
This so much more relevant today! Uncle Bob always ahead of the curve!
31:15: That was me, back in the day. The computer operator. Still have the lab coat I wore.
You're not welcome here, sir.
www.imdb.com/title/tt0535587/ ~1970 TV version "Routledge" acted by Peter Sallis
I loved this, He has my juices flowing again to program. I'm paralyzed from neck down and learn some programing in the early 90' I would like to get back in to programming as much as I can but it's been so long I didn't remember much and have tried only to get overwhelmed. I type slow with a sip/puff before I used a mouth stick and could type 15-20 words a minute, not so with my sip/puff. I do have dragon software. Can someone point me to the right platform, language I should start learning. Thanks,
There are many places you can start, among them edx’s CS50 course by David Malan. It’s a free course, and I highly recommend the college version of it.
Some new IDEs auto complete the lines for you, so you just write the first letter and it anticipate what you want to type and it also gives options
what do you want to do? React is cool for web
@@LawleyMark I'll start there.
Thanks for all the good advice! I want to make some small programs from reminder, and then a capable Environmental control unit. I know there are a lot out there but I want to build a free/ low cost version that work on with other OS like, win, linux
This was such a great story telling of history. A must see for young programmers!
Yes very informative. But the title is totally wrong. He talked 70 Minuten about the history of computer science and 5 minutes about the future. :-)
Mitch, if you want to predict anithing about the future you have to master the history.
Trying to foresee the future without studying the past is like trying to calculate future trajectory of an moving object without asking where it came from or how it moved before
True. I wasn't expecting a history lesson, but in the words of a great Senator, it was "a surprise, to be sure, but a welcome one."
At the end he laid out the big picture of programming, and that is of a professional body. More than that he brought into realization of software being an industry that could, and probably will, be regulated by the government. That will truly make the software a very inefficient, and draconian industry that will make software cost much more than it does now. However, he made the point of software being ubiquitous and it's inevitable potential for disaster. If you want a similar bleak scenario of computing in the future, check out: digitalfuturelife.blogspot.com/2010/11/future-shock.html
@unclebob you were right with the recent Boeing accident only a few years after this talk. As programmer's we have to take responsibility for what we design and implement. To all who's affected by this horrible accident we apologize and hope not to let anyone down ever again.
Why I appreciate Robert Martin? Because he is a humanist among programmers, he talks about morality. And that's really valuable, especially nowadays.
Summary:
80s-C/ObjC/C++
story about how Steve Jobs kept ObjC alive
says no one is ever happy with their language
Male skew/history Female skew
goes back to 36 + Alan Turing...+ Annotated Turing book
relays, mercury tubes, CRTs, ...
1945-
Alan wrote floating point and made a couple statements
"We shall need a great number of mathematicians of ability" because "there will probably be a good deal of work of this kind to be done"
"One of our difficulties will be the maintenance of an appropriate discipline, so that we do not lose track of what we are doing"
magnetic cores, you could actually shut off power and restore it and it'd continue running as if nothing had happened
53- Fortran, penciled coding forms -> punch cards
58- Lisp, functional programming
60- O(1E2) computers in the world, O(1E3) programmers that are 30yo mathematicians,scientists, and the like. No OS, libraries, etc.
transistors
65- 10'000 1401 / O(1E4) computers (rent $2500/mo $20k/day), 4000 bytes memory. O(1E5) programmers, still learned adult trusted and disciplined people if not mathematicians, not 22 yo people out of school :)
68 - Dijkstra says goto bad, enter structured programming
C - K&R, mathematicians
70- 1E5 computers / 1E6 programmers, 25 years from 1 to 1'000'00 programmers. Now CS courses, new are mostly male students in early 20s
Programmers are doubling every 5 years, so less than half of all programmers have 5 years of experience.
Hardware has changed tremendously, the iphone would have been the entire world's economic output: 50 trillion dollars and 170 Vehicle Assembly Buildings (the large building at NASA's Kennedy Space Center, At 3,664,883 cubic meters 129,428,000 cubic feet it is one of the largest buildings in the world by volume), would require 500 of the largest nuclear power plants. And once it was built you'd have no one to call with it xD
Software hasn't. You'd recognize the earliest code, you wouldn't like it but you'd understand it. You could time travel someone either direction and it'd take "24 hours" to recover from the shock/disappointment but they'd be able to understand and write the code. It's essentially assignments, if statements, and while loops.
Any changes are what _not_ to do, structured = don't be crazy, functional = don't assign, OO = don't use function pointers (??, I don't feel like that's quite what was learned but whatever)
What must change. Discipline.
2001- Agile manifesto, fixed time, estimate in relative units, customer communication, continuous integration, collboration, ...
programmers can't agree on disclipline and technical practices
Agile split- Business Practices \ Technical Practices
What must change: "we (agile) must grow up", define profesion, choose practices and disciplines, reunify, someone has to lead.
1:11 everything in modern world uses software systems. Software can control breaking, steering wheels, and that _is_ killing people already. Programmers wrote code to "cheat" EPA "if in test mode ...".
One day one of us is going to do something stupid that kills many of people and politicians will ask _us_ (programmers) "How did you let this happen?" and if we can't answer well they will regulate us setting what languages and morals/ethics and taking an oath to follow and some body that can discipline and prevent you from being a programmer.
*braking / brakes
Thanks only lasted 4 Mins haha
Wonderful summary!
Thanks. I definitely just wanted the coles notes on this one...
Awesome👌 Thnx
Defenitely the best...movie that I've seen this year. Yes it's such a great story, and listening how he's explaining that, and the succession of toughts, I can recognize that he's a programmer, and I'm proud of being one too. Thanks for the inspiration!
Every programmer should watch this video. Very inspiring
proud to be part of this great man
Mr Bob tried to make a point and according to the comments a lot of people have missed that point. The future of programming is in better self regulation in the technical aspect of our profession. We have mass production of programmers and software while Agile slid into the business waters leaving nobody to actually care about the quality and potential disastrous consequences.
15:10 just learnt why relays are called relays.
*that's not the root though. The word was used before telegraphs, when letters were transported by horses. A relay was the station where the mailman exchanged the horses to get fresh ones, because they were tired after a certain distance.*
You and I both
@@alexbecker4149 What does that have to do with the mechanical device called relays?
Great talk, I recommend for every programmer.
Absolutely mind blowing and eye opening video. I don't even realize I watched this whole video all at once. Great energy and experience Uncle Bob :)
We need more people like Bob Martin in all levels of business and government. He is so right. We are so dependant on technology that we'd be thrown back maybe one hundred years without it. For example, I wonderful how many young people can do long division without a calculator.
Love Mr. Martin's presentation.
And just how often are you performing long division?
@@lepidoptera9337 I learned long division in school, before calculators. How many kids today do you think can do it or even short division? 🙂
@@kerrykeene6471 The smart kids can (and they can do a lot more things that you can't) and the other kids don't have to.
@@lepidoptera9337 I have a question. Don't you have something better to do than worry about my math skills? 😀
@@kerrykeene6471 Sure, I worry that you are lonely and that you need attention, so I am giving it to you. :-)
this talk aged like fine wine
The future is AI assisted programming, where a programming language will be built around what AI is capable of assisting.
Right now we call that "static analysis tools", but the problem is the tools are built around the programming languages.
When you build a programming language around the limitations of what AI is able to help you with, you will have created a platform of unprecedented productivity.
Imagine how Alan Turing would have reacted to AI writing code. Especially code in which bugs can be really dangerous (for example cars and medical devices).
Uncle Bob is fascinating from beginning to the end :)
Allan Turring , a Great Software Engineer.
Saw ahead of His Time.
ur mom
After some years this real talk still current. Every developers should watch this at some point.
As a designer that worked in a Dev group I can attest to everything he said, except how quickly I will change the way we all program.
I can't believe I watched the whole talk, and got my tears
"The number of programmers doubles every 5 years. That means half the programmers have less than 5 years of experience.
We live in a state of perpetual inexperience. We cannot escape this. There aren't enough teachers to teach the new people coming in, and so the new people coming in must repeat the mistakes made by everyone else over and over, and there seems to be no cure for this."
"Uncle" Bob Martin - "The Future of Programming" - Starting at Minute 50:57
Half of programmers have less than 5 years experience. Half of programmers have more than 5 years experience.
That leaves space for 1 on 1 mentorship which would solve the problem. But such a thing would probably show results after a year or two, and corporates tend to think only one quarter ahead Those are old guys in the management who are at fault, not the young programmers.
Those who fail to learn the lessons of history are doomed to repeat them!
@@orokushi5953 Experience alone doesn't seem enough to really get a deep understanding, that only works for those with an extraordinary curiosity and the drive to think deeply about the things they're doing. The rest will vocally defend terrible practices they learned in their first week of programming until they die, no matter how often those practices ruin their day.
The other problem I see is that many tech companies are young and tempted by the initial savings of shoddy craftsmanship even if the costs are orders of magnitude higher in the long run. In such an environment any calls for caution will probably go unheard.
Excellent speech. Uncle Bob closed it with a golden key... Regulate, create a professional body just like for engineers and physicians.
This is 2019 and I am no Programmer of any kind but still enjoying your speech, very fun and knowledgable talk!
Many of my colleagues does not comprehend what Bob Martin talks about hence they are bored by this talk. They enjoy and share the shot and entertaining talks from Richard Feldman. I wish UA-cam would recommend this talk over that of Richard Feldman.
I would make this talk required watching for CS and EE students at the college level.
I agree, and that is what I'm doing. That's why teachers say it's always good to do some of your own research. I feel that is where this stuff falls into.
William, but they can't take the time away from protesting over social justice...
Quitting my job to dedicate my life to lisp
😂
lol
What an amazing talk. I love Uncle Bob Martin. I wish we all could be so much professional and take responsibility of the code we write. I hope in the future, we the software developers will focus more on quality than quantity.
It's not the developers fault if management want stuff finished within a given time frame, there's not enough time for quality.
One of the best presentations I've seen on this topic. Now I'm gonna refer to "Uncle Bob" whenever a colleague is arguing for bureaucratic rules and governance over projects.
DEVELOPERS! DEVELOPERS! DEVELOPERS! (S. Ballmer) :D
Fascinating trip down computer history's memory lane. What a gem. Big thumbs up!
Professionalism. Discipline. Attention to details.
That's the bottom line.
Automation. Before you know it.
I visualize a language that unify everything
money is the bottom line. close enough is good enough.
I FOUND WALDO
@@aammssaamm , and in that.. AI writing all code and programmers have a hobby to amuse themselves but not to provide sustenance to their lives. All programmers will be out of a job in 20-30 years because it will be vastly less expensive to have AI do the same job, maybe not as well, but functional and that's all that matters to the penny counters. The "future of programming" for "people" is non-existent.
TLDW:
In the past, programmers were matured and self-disciplined as they were older(30s-40s). Since 1970s to 1980s, there has been a surge in young programmers(graduates), and this trend has been going on until now. If we do not start having some sort of discipline, such as oath of doctors or lawyers etc, something bad may happen in the future and we (the programmers) will have to bear the consequences. Consequences such as government implementing unnecessary regulations etc..
This should be called the history of programming. Great talk.
totally. Its just History!
I don't have patience more than 3 minutes for a talk. I am an agitated guy I may say! But here, i listened ( for real ) every single word. I don't even read my code like that. I do it like : bla.... if( ...aha), than, yep, execute ....that, aha, I read it. A couple of seconds, this is my standard line in patience. And here....an hour, 18 minutes and a bunch of seconds... Wow. This talk really got me into it! Great ! I loved every second of it!
I learnt something today. No more "DROP DATABASE" by accident
The good stuff: The Agile Manifesto at 1:00:45. Individuals and interactions over processes and tools; Working software over comprehensive documentation; Customer collaboration over contract negotiation; Responding to change over following a plan.
6:23
We will code objective c for food.😂😂😂
Wow. He predicted the Boeing 737 Max MCAS crash.
oxied the prediction was not literally. The prediction is that we the programmers are making code without principles and it is leading to people dying.
He mentions about a plane crashing into a football field somewhere around 60 minutes into the video. But did not specifically said which plane.
Wish I had an uncle who would tell me this story. I am available for adoption, not to mention.
😂
LoL!!! 😂 😆 😝
😂😂😂😂😂
@@MansoorMazhar thanks for the comment, i mean really :D
Totally forgot about this. Time to rewatch! ;)
On 14:50 Uncle Bob shows a russian relay. The inscription on the relay contains the thickness of the conductor and the number of turns in the coil and that the relay contains silver.
Incredibly inspiring, thank you Uncle Bob! Maybe only last 20 minutes or so actually are about the future, but I found entire talk fascinating.
I guess it's time for a Lisp tutorial.. ;D
On a more serious note , until now I 've only known Uncle for his books. As it is said, if you want to read only one book about programming, pick one of his. I found his talk no less interesting and, how to put it, understandable and entertaining without need for several Ph.D.'s or other degrees :P This man is a legend.
I bet there arent many women in beauty salons fretting over why there arent more men painting nails ... dont see why its our job as guys to get women into the industry. Ive never stopped women from joining yet somehow its my job to fix the situation.
lol.. women in beauty salons?
you're very dense
@Parmesan Came for click bait title, disappointed by the quick scan of this talk.... but shall remember this metaphor 4eva.
You may not think you've stopped them, but you've certainly discouraged them.
Because beauty salons suffer little from the lack of a male perspective but programming and many other fields suffer greatly from a lack of a female perspective.
You want a better example to help support your point? Social work. Public schooling. Yes, public schooling suffers greatly from the lack of male staff. Interesting enough though, it isn't women keeping men out. It's men keeping themselves out, just as it's men keeping women out of programming (intentionally and unintentionally) and a great many other fields of great consequence.
One day you may gain an understanding of false equivalency and you'll be much better for it.
I agree on the idea about project managers invasion. Before this video, I could not understand why that project managers were needed, I even could not deduce what their responsibilities were. I refuse to accept the idea of having a project manager which does not like programing! and believe it or not, these kind of managers are part of most of the software companies nowadays.
A good project manager is a god send. I've worked with project managers that knew a lot about the business they're in and could explain the needs, manage expectations and properly allocate time for things - and those people are great even if they know nothing about programming. Unfortunately 90% of them are b.a dorks that have no understanding of neither the business or the production floor - all they do is frustrate the devs and the clients/management.
You are getting it wrong, regardless of how you company put them in the food chain, PMs are hired by programmers to isolate them from people
I hear that.
I like project management but I love programming. (Perhaps therefore) I feel I'm an adequate project manager..
I personally think project managers are hired because programmers are expensive and because delivering a program takes time, then companies feel they are paying thousands of dollars to win a race but they are betting on a turtle.
So the project manager is there to rush us and make sure we are actually delivering and not just fooling around.
Because in reality, there are many programmers who don’t deliver because they just simply can’t code. The project manager is there to help the company to spot these “programmers” and get rid of them.
0:00 - Introduction And History About
58:40 - Future of Programming
thank's me later..
at 59 minutes now
He needed that long to establish the authority fallacy. I can understand why. Also it is easier to describe a dystopian future than an optimistic one; ask Hollywood. This lecture fails to deliver.
The build-up was necessary. He needed to explain why programming has changed so much because the programmers themselves have changed so much.
Thank you! This was very helpful.
Thanks! :)))
Great talk! Wisdom beyond years. Everything you cover I not only witnessed it, I've lived it. Very good stuff!
Christ, I put this on to fall asleep... didnt expect to be so captivated. Great talk!
Absolutely excellent, thank you for the video.
A good article on the subject can be found over at Quillette, "Why Women Don’t Code". Take a look at the graphs. Martin is just spouting PC lies. Quote
"Pictures help to tell stories and this one drives home the point that even as women were taking a greater share of slots in medicine, law, and the physical sciences, they represented a decreasing percentage of computer science degrees. This is consistent with the idea that women simply chose to pursue other interests, but NPR chose to highlight the suggestion that professors teaching introductory courses were creating courses unfriendly to women."
and
"In 2013, Psychological Science published a paper that explored this question further entitled “Not Lack of Ability but More Choice: Individual and Gender Differences in Choice of Careers in Science, Technology, Engineering, and Mathematics.” The authors included Jacquelynne Eccles who is well known for a career spanning decades studying student motivation and gender differences.
They concluded that women may choose non-STEM careers because they have academic strengths that many men lack. They found that individuals with high math ability but only moderate verbal ability were the most likely to choose a career in STEM (49 percent) and that this group included more men than women (70 percent men). By contrast, individuals with both high math ability and high verbal ability were less likely to pursue a career in STEM (34 percent) and this group had more women than men (63 percent women). They write that, “Our study provides evidence that it is not lack of ability that causes females to pursue non-STEM careers, but rather the greater likelihood that females with high math ability also have high verbal ability and thus can consider a wider range of occupations.”"
The truth isn't PC and if Martin told the truth, he would probably be ostracized from UA-cam. However, the truth is still the truth.
also, back then most men were getting shot on the front lines rather than having the privilege of pursuing a computing career
Why are there fewer women in IT? Because women have become free and are doing what they really want.
Wow, a powerful talk especially at the end
Fun talk, I wrote my first program on a PDP-8, and in the same year on a IBM 360-30, that was in college, I liked the end result more than the programming, but the day we had to write internal codes, exits for that PDP-8, and the bootstrap loader, then my fun began, the college bought a PDP-11/45, for administration, we got the PDP-8 all for us to play with...I just loved it, I was hooked big time, I liked playing with the internal programs...I became another breed of programmer, a System Programmer, my first job we had an IBM 370-168 machine, a monster of a machine, I was introduced to one language we had a session on in college, Assembler, we really were a special breed, so much that I never heard a presentation on that career path, we had no girls in our groups, sometimes as many of 40 system programmers, not a single woman, we knew why, always on call 7/24, working all the special holliday, doing upgrades, maintenance, PTF's, exits, you name it, nobody in their right mind would like to live like that, getting a call in the middle of the xmas party and having to leave and go to the office....I loved every minute of it, what a life!!!
It’s an interesting observation that functional programming, structured programming, and object-oriented programming about restricting what we do. But I think it is over simplistic. All of these provide not only restrictions, but also alternatives. Functional programming says don’t use assignment, but to make that really useful you need powerful ways of creating functions, which LISP and its successors had. Fortran had functions, but did not provide ways to make new functions out of old. Structured programming, in the simple form of not using unrestricted gotos, only worked because it offered us alternatives: structured ifs, whiles, case statements, etc. On OO, I think Uncle Bob got it wrong. It’s not about not using pointers to functions, but rather about not allowing design decisions to permeate the whole program. Instead we put fences up that restrict how much of the program is effected by each decision - information hiding. But, if you only have the restriction, you get modular programming like we used to do in Euclid, Modula II, and the early versions of Ada. OO languages offer you something beyond just the restriction, they offer interfaces, inheritance, and virtual functions, which go beyond modular programming in separating interface from implementation, because now we can have multiple implementations of the same interface in the same program - something that could not easily be done in earlier paradigms - and something that allows us to write safe polymorphic code.
If we consider what has happened with the development of orchestral musical instruments, it is an extreme version of software industry development. Most of these instruments come from 17th to the 19th centuries but have mostly frozen since then. The reason is that it takes many thousands of hours of practise to master any such instrument. Having invested so much time, most musicians are unlikely to take up anything that varies significantly from the standard design they are so invested in. We're stuck, for the most part, with 19th century materials and mechanics! History is littered with brave but broke musicians and designers who have tried to improve on these instruments! (but to be fair, some very minor improvements have been made to some of them).
So, the impasse has been resolved to some extent by making instruments suitable to making completely new musics - electric guitars, electronic and then digital synthesisers. The contemporary synth is vastly different to the originals from the 40s and 50s, because they haven't been shackled by looking to emulate the past. (Well, actually there is a movement to use analog synths that has been emerging over the past decade or so. But mostly the industry is looking forward, driven by commercial reasons.
So, it seems to me that as the software industry grows and the programmer base gets bigger, there'll be more people programming in C++ and similar languages in the future and their careers are assured!
That's an excellent analogy, hadn't thought of it that way before, thanks.
Programming languages are easier to learn and to switch around. The difficult part is solving the problem in the best way. And in the beginning the best way is often not necessarly obvious
If the C language was anything good like a Violin. C language is like putting strings in a shovel. Still the argument remains.
There are a lot of mind blowing new kind of music instruments. And Rust will beat C and C++. If that program then needs to be on server or web app then compile it to WebAssembly.
Watches this video on discipline and standards, then proceeds to 'npm install'
I feel like this is the programming history video I've been looking for.
This is what I am looking for centuries!
Turned the video on and couldn't turn it off until the end. Captivating!)
In light of the recent Boeing plane crashes due to software, the last bit of this lecture is chillingly accurate and foreboding...
I'll save you an hour or so:
The future of programming is 'self regulation', where a governing body can declare you to not be a programmer for not conforming to *our* standards.
Yeah. Sure. Good luck with that. And considering how much he references the "plight" of how many men are eagerly joining the field, I'm pretty sure I can guess what "our standards" will be.
But even assuming it was even remotely sane, good luck getting even a single programmer to recognize its authority. Especially one that didn't conform to "our standards."
So now it needs the firepower of a government or 5 to enforce its rules.
And now the whole of creative processes and software innovations are controlled by bureaucrats. Incredibly corrupt ones. Who will stifle innovation and control the entire modern world.
Sounds great.
wow, I guess he needs an hour to "sell" that. we've had rapid innovation in programming over the last 50 years. remarkable revolutions are happening. all that will come to a screeching halt if we put on those regulatory handcuffs
@José Mário Silva Júnior I think it is quite problematic in some cases as that gives more power to big companies gaining monopole like status, who are focused on making money in the first instance.
You missed the whole point. Did you watch the video?
Consider it from a different technical field - networking. They face the exact same levels of danger. When networks fail, finances and even lives might be on the line depending on exactly how and when that network fails, and who gains access to it. They have heavy prices to pay and therefor they require a lot of discipline in how they operate. How do they enforce that? Certifications. You *cannot* get a job in networking for any respectable company dealing with sensitive information without well respected certifications such as those offered by Cisco. It's not as simple as "Go get a degree, 8 years of experience, and then apply" - they want *proof* that you can follow the expected conventions. Programming? That doesn't really apply. You can get jobs in the programming field for these same organizations in a position that's arguably just as impactful, if not moreso, than networking because they just want years of experience. That's pretty much it. Maybe a degree from a college. But even those college degrees are all usually pretty worthless because they aren't very standardized, no degree is equal.
Self regulation is definitely something that the industry could benefit from, and having it come in the form of certifications is probably the way to go. The problem is that there aren't enough developers, and to require them to go show up with certain certifications would probably mean job listings just never get filled. :/
Many (most?) professions are regulated by (self)governing bodies: doctors, lawyers, engineers, architects, etc. Certainly in engineering innovation continues while at the same time holding the line, it seems to me, on fly-by-night operators.
I think governments have left it to the professions to actually define the standards of practice because governments have realized that they don't have the expertise to do the writing. They just know they want order and professionalism.
I think a similar form of self-regulation would be a boon for the overall quality of software in the world. Sure it may impact on the number of people actually creating software but there is a great deal of poor software out there and a great deal of useless software out there; a cull of the current herd (or at least a recognition a standard of professionalism for vital programs) and a "you must be this tall to call yourself a software designer" impediment to engaging in professional practice might not be such a bad idea.
From 1:03:50 to 1:06:09 yes, agree, Scrum hardly covers any key aspect of Software development
Yes it was completely hijacked and 'simplified' to basically let management visualise the lack of resulting progress and point fingers at failed promises, all the while never allowing any time for anything the MBAs don't think needs to be done.
The work Process is your scope. Your discipline is sticking to that scope.
Blimey I'm the same age as Bob and started only a bit later than him. Fascinating, thanks.
The guy complains and rails about how the women somehow disappeared from the profession, what he doesn't seem to notice is that the work changed. He shows these pictures of women working with the computers, but neglects that many of them were there simply because the men were at war or doing harder labour at the time, and beyond that much of the work was effectively clerical or rote. The reasons that women left the field are straightforward: as the field became more solitary and involved less rote clerical work and more analytical work, and as men were no longer actively drafted into the military, women's interest in the field dropped and the supply of analysts boomed.
He then goes on to detail all of the pioneering moments for paradigms in the design of computers and programs, and at the genesis of each of these is a great man. This is no accident, the most significant contributions to the field have been made by the people actually operating in the field at a high level, most of whom have been men, with notable exceptions like Rear Admiral Grace Hopper, who popularized use of compiled high level languages, and was the lead technical consultant to the committee that produced COBOL.
There was never a time where that many free financially-stable women in a society at peace chose work like this, and that's not a moral wrong. Let people make their own decisions based on their own values, rather than insisting every woman be more like a man, to hide the fact that labour productivity has been stagnant in many ways for decades.
And no, waterfall was not adopted because "programmers were now *boys* in their twenties", it was adopted because it looks like an orderly process for delivering a product that would satisfy a corporate culture, even if it turns out to be unproductive.
Well said. I think the forced diversity quota's of the current AAA corporations stem from the belief that men and women are equally interested in various fields. One of the best examples of a double standards is that a tech company will try to hire more female developers, but a hospital will not try to hire more male nurses.
1:14:00 'we rule the world'; love this!
Awesome talk, he drives the point of responsibility of programmers. Glad I watched this talk
glad that he replied to my message in facebook. A real legend.
uncle bob is a very charismatic speaker, great orator
A very interesting talk. Must watch for every programmer
the discussion of core memory put me in mind of our old DEC-20 computers where I went to school. One of them had a set of PDP-11-based front end processors, which had real core memory (despite most of the rest of the memory in the system being solid state.) The PDP-11 FEPs would crash a lot, and a co-worker's comment was something along the lines of "It's a good thing that FEP has core memory, so it can remember how much it screwed up".
8:04 the moment I got sold on sticking for the entire video
Every IT Services Business members should watch from 59 min till last, Engineers don't sell your time, have hours in your control and be accountable to outcomes you see as the best value.
Best history of programming I have ever seen. And Bob you are so right about the future.