Add
Private Notes
This video introduces our series on software professionalism.
Let's imagine that we all live and work in a giant O'Neil habitat, plying the orbits between Earth and the Asteroid belt; gathering solar energy and mining the asteroids for volatiles, minerals, and metals. Such a vessel requires a lot of software. The software teams on board are led by "The General".
In our imaginary world safety is paramount. Software problems could endanger everyone aboard. And so the General has established a code of standards, ethics, and disciplines that all programmers on board must profess. It is their adherence to that code that defines them as professionals.
This series will investigate those standards, disciplines, and that code of ethics. We'll use it to compare and contrast with the kinds of professional standards we might need here on Earth.
In this series we'll talk about the issues that affect your ability to write software. We'll talk about tests, estimates, and schedules. We'll talk about how to say "No", and when to say "Yes". We'll discuss ways of dealing with pressure and the unreasonable demands of users.
We'll also talk about softer issues, like how you write code after a big fight with your spouse. How you focus your mind in the midst of a battery of distractions. How to pace yourself for a long project.
We'll talk about honing your skills, managing your time, collaborating with others, and mentoring new programmers.
Overall, we'll talk about what it means to be a professional. We'll discuss our ethical standards, and the disciplines that put actions to those standards. We'll talk about the lines we won't cross, and the promises we make to ourselves, to our employers, to our team mates, and to our craft.
Welcome aboard The Clean Coder!
The code that I produce will always be my best work. I will not knowingly allow code that is defective either in behavior or structure to accumulate.
What does this mean; and how are professional developers supposed to keep this promise in the presence of schedule pressure and deadlines?
As programmers, what is our role and responsibility in keeping the software systems we create safe, stable, and worthy?
Defects in behavior are visible and obvious to our users. Defects in structure are hidden from our users. Of the two, which is the most important? How should programmers prioritize them? What bad things happen when we get this priority wrong?
In this episode of Clean Code Uncle Bob addresses these questions and discusses the moral and ethical elements of managing defects as a software professional.
I know, I know. 102 minutes! Yikes! But, boy-oh-boy did I have a lot of fun making this one. I mean, I really got my geek on to make this episode.
After all, this episode it about Dijkstra, Edsger Wibe Dijkstra! One of the very first programmers in the world; and the father of Structured Programming.
This episode is all about proof. It begins with the third promise from The Programmer's Oath:
I will produce, with each release, a quick, sure, and repeatable proof that every element of the code works as it should.
Then it explores what Dijkstra thought those proofs might be, and how those thoughts led him to Structured Programming and the elimination of the goto statement.
We'll discuss how Dijkstra's ideas about program structure led, in the long run, to Test Driven Development. We'll also discuss how his ideas about proofs eventually failed; and the scientific concepts that replaced them.
And get ready to see a lot of code -- some of it old, and some of it new, some of it borrowed, and some of it (well, yes, there is a sad story in here) blue. Also get ready for some math, and some logic, and a fair bit of the history of our profession.
So, without further ado, let's get started on: PROOF.
Now of course you realize that an episode entitled Small Releases would be all about source code control systems -- right? Not just about source code control, but about the history of source code control. Makes perfect sense, right? Well, that's what you've got in store in this episode.
This episode is all about the fourth promise in The Programmer's Oath
I will make frequent, small, releases so that I do not impede the progress of others.
Over the next hour, you're going to learn about the tortuous path we programmers took in order to shorten our cycles from days and hours, down to minutes and seconds. You'll learn why that shortening is so important; and you'll learn just what needs to be shortened. (Hint: It's more than you think.)
So buckle up. Because after we talk a bit about Gravity Waves, we're going to uncover the history, and the future, of short cycles.
42!
Don't Panic.
Grab your towel and settle in; because this episode is a two parter.
You knew it had to be this way, didn't you. I mean: 42!
Life, The Universe, and Everything.
That's the question we are answering in this two part episode. I've given this a lot of Deep Thought and this episode is the answer. Really. I mean it.
And I'm not going to fall back on the question of the question. No mice. No dolphins. No sperm whales and flower pots. No cat lullabies.
Nope. This time it is right. This time it will work; and no one will have to get nailed to anything. And no Vogons will wreck it all.
The answer: The answer will be given in the first few moments of the video. I promise. And it is the answer. Once you hear it, you'll know it.
The rest of the two part episode will be about how to apply that answer to software. And to do that we're going to look at a lot of code; and a lot of coding and testing techniques.
The focus of all that code will be Ward Cunningham's FIT framework.
Part 1
Segment 1. The Answer.
Short, sweet, but right.
Segment 2. The phases of matter.
Our obligatory science lecture discussing why matter (water in particular) exists in three different phases: Solid, Liquid, and Gas.
Segment 3. Code Coverage.
Do you now how much of your project is covered by tests? Do you know how much should be covered by tests?
Segment 4. Covering Action Fixture.
A deep dive in which we cover some untested parts of Ward Cunningham's FIT framework with tests.
42!
Don't Panic.
Grab your towel and settle in; because this episode is a two parter.
You knew it had to be this way, didn't you. I mean: 42!
Life, The Universe, and Everything.
That's the question we are answering in this two part episode. I've given this a lot of Deep Thought and this episode is the answer. Really. I mean it.
And I'm not going to fall back on the question of the question. No mice. No dolphins. No sperm whales and flower pots. No cat lullabies.
Nope. This time it is right. This time it will work; and no one will have to get nailed to anything. And no Vogons will wreck it all.
The answer: The answer will be given in the first few moments of the video. I promise. And it is the answer. Once you hear it, you'll know it.
The rest of the two part episode will be about how to apply that answer to software. And to do that we're going to look at a lot of code; and a lot of coding and testing techniques.
The focus of all that code will be Ward Cunningham's FIT framework.
Part 2
Segment 5. Mutation Testing
How do you know that the covering tests actually test anything? Here we use the PiTest tool to find parts of the code that are "covered" but aren't actually tested.
Segment 6. Cleaning.
Now that it's covered, and we know the coverage means something, let's clean it up.
Segment 7. Semantic Stability.
For software, this is the answer: Tests that truly stabilize the semantic behavior of the system.
Segment 8. Conclusion.
Tying things up in a pretty bow.
What makes you productive? The music in your headphones? The size of your screen? The integrity of your test suite?
What makes you unproductive? Meetings? Time management? Emotional Distress?
In this episode, we deal with productivity. What makes you truly productive. What truly impedes your productivity. How can you be more productive and help others to improve their productivity as well.
You will likely be surprised at my advice and conclusions; but they are based on my nearly 50 years as a programmer. If there's one thing I know, it's the things that impede my productivity.
Do you want to go fast -- I mean really, really fast? Then pay close attention. Because the things that make you go fast, and the things that slow you down, are not what you think they are.
Estimates. Oh no, not Estimates!
Yes, it's estimates. We're going to talk about estimates. We're going to talk about what estimates really are, and how to create them.
We're going to talk about the fact that estimates need to be honest, accurate, and precise. And we're going to define those terms.
We'll learn how to properly find, and specify, an accurate estimate. We'll also spend a lot of time understanding what it means for an estimate to be precise. And we will stress, over and over, that the most essential quality of an estimate is honesty.
During parts of this lesson we'll get really techie and mathy. We'll study the statistical tools from PERT that can be applied to estimates. I'll walk you through the math. I believe you'll find it both fascinating and useful.
But in the end, whether you use the math or not, whether you follow the techniques and procedures I recommend or not, the real lesson of this episode is about honesty. And how to present, with appropriate accuracy and precision, the most honest of all estimates:
"I don't know."
Why do we need an oath? Why do we even need a profession? Why can't we just go on being happy-go-lucky programmers for the rest of our days?
In this episode we will walk through the history of our profession. From its humble beginnings in the late 1940s, until today. We'll track the growth of our industry; and its relationship to society at large. We'll watch as society's view of programmers grew from shadowy figures behind the scenes, to naive socially inept geeks, to modern day heroes -- and villains.
We'll discuss the role we currently play in society; and the unwitting trust that society puts in us. We'll talk about our own ethics, and our own standards, and the risk of continuing on our current path without establishing and enforcing those values.
Take care. This episode is not for the faint of heart. There are some tough questions asked here; questions that we shall need answers to in the not too distant future.
