In November, I gave the commencement address for Neumont University, a school in Salt Lake City dedicated to teaching computer science where my coauthor lectures. This is that speech.
So here you are, about to be unleashed upon the world. This is a lot like taking someone and teaching them all the parts of English speech and then saying "go out and write stories," but it's probably all any school can do. And a more theoretical background wouldn't help; this is not to say theory is bad because you'll need some eventually but there's a recent movement that preaches "practice before theory" and I, apparently like Neumont, find that knowing how to do something is very helpful when trying to understand the theory behind it -- for me, the theory takes a lot longer to grasp and it's very useful to be able to be functional while my brain is catching up.
There's only so much you can learn in school, and it's only tenuously connected with what you will end up doing in your work. So I'm going to try to soften the blow a little, and arm you with a few insights that will help when you crash into the actual world of software development.
You've come from very structured learning. We even call it a science. It promises that there will be the same kind of structure and activities in the world. More importantly, you've come to expect a certain high level of success, similar to what you've experienced with your projects and assignments. But the world will not behave.
The statistics are sobering: 50-80% of programming projects fail. These numbers are so broad because people don't brag about their failures, so we have to guess. In any event, this makes the world sound pretty unreliable. Engineering gets better results, mostly because it has to. Bad software usually just annoys people but bad engineering can kill.
An even more fascinating metric is this: 5% of programmers are 20x more productive than the other 95%. If this were a science, like it claims, we could figure out how to get everyone to the same level.
Let's say that this follows the 80-20 rule. Roughly 80% of programmers don't read books, don't go to conferences, don't continue learning, don't do anything but what they covered in college. Maybe they've gotten a job in a big company where they can do the same thing over and over. The other 20% struggle with their profession: they read, try to learn things, listen to podcasts, go to user group meetings and sometimes a conference. 80% of this 20% are not very successful yet; they're still beginning, still trying. The other 20% of this 20% -- that's about 5% of the whole who are 20x more productive.
So how do you become one of these mythical 5%?
These people are not those who can remember all the moves and have fingers that fly over the keyboard erupting system commands. In my experience those in the 5% must struggle to get there, and struggle to stay there, and it's the process of continuous learning that makes the difference.
Because of what I do, I've met more than my share of these people. They read a lot, and are always ready to tackle a new concept if it looks worthwhile. I think if they do go to conferences they're very selective about it. Most of their time is spent being productive, figuring things out.
The big issue is knowing that you're going after that 20x productivity increase. Which means getting leverage on everything you do. Never just "bashing something out," but using the best tools, techniques, and ideas at your disposal. Always doing your best.
And deeper than that, understanding that the leverage point doesn't always come from the obvious thing, or from what we've been told, or the commonly-held belief about what works. Being able to analyze and understand a situation and discover the hinge points of a problem is essential; this takes a clear mind and detached perspective. For example, sometimes the choice of programming language makes a huge difference, but often, it's relatively unimportant. Regardless, people will still spend all their time on one decision while something else might actually have a far greater influence. Architectural decisions, for example.
So you must learn continuously and teach yourself new technologies, but it's not that simple. It's definitely good to learn more about programming, but you can't just learn more about programming. For example, just in the world of code, here are two of the biggest pain points:
Code is read much more than it is written. If people can't read your story, they can't improve it or fix it. Unreadable code has a real cost, and we call it "technical debt."
Code reviews are the most effective ways to find software defects, and yet we usually "don't have time for them."
Coming from the world of ones and zeroes we'd like to believe that things are deterministic, that we can provide a set of inputs and get the same outputs every time. I know because I believed this for a long time, and it took some hard knocks when I was a physics undergraduate to begin -- only to begin -- to wake me up. Many years later I was in a workshop and one of the other attendees told me what I had been learning all those years; she said "All models are wrong. Some are useful."
We are in a young business. Primitive, really -- we don't know much about what works, and we keep thinking we've found the silver bullet that solves all problems. As a result, we go through these multi-year boom and bust cycles as new ideas come in, take off, exceed their grasp, then run out of steam. But some ideas seem to have staying power. For example, a lot of the ideas in agile methodologies seem to be making some real impacts in productivity and quality. This is because they focus more on the issues of people working together and less on technologies.
A man I've learned much from, Gerald Weinberg, wrote his first couple of books on the technology of programming. Then he switched, and wrote or coauthored 50 more on the process of programming, and he is most famous for saying "no matter what they tell you, it's always a people problem."
Usually the things that make or break a project are process and people issues. The way that you work on a day-to-day basis. Who your architects are, who your managers are, and who you are working with on the programming team. How you communicate, and most importantly how you solve process and people problems when they come up. The fastest way to get stuck is to think that it's all about the technology and to believe that you can ram your way through the other things. Those other things are the most likely ones to stop you cold.
In my first jobs, I saw lots of managers making stupid decisions, and so, logically, I came to the conclusion that managers and management was stupid. It's a commonly held belief in our profession: if you're not smart enough to deal with the technology, you go into management. Over time I very slowly learned that the task of management wasn't stupid, it's just very, very hard. That's why all those stupid decisions are still being made; management is much harder than technology because it involves virtually no deterministic factors. It's all guesswork, so if you don't have good intuition you'll probably make stupid decisions. Napoleon wanted lucky generals rather than smart ones.
Here's an example: some companies have adopted a policy where at the end of some predetermined period each team evaluates everyone and drops the bottom 10% or 20%. In response to this policy, a smart manager who has a good team hires extra people who can be thrown overboard without damaging the team. I think I know someone to whom this happened at Novell. It's not a good policy; in fact it's abusive and eats away at company morale from within. But it's one of the things you probably didn't learn here, and yet the kind of thing you need to know, even if it seems to have nothing directly to do with programming.
Here's another example: People are going to ask you the shortest possible time it takes to accomplish a particular task. You'll do your best to guess what that is, and they'll assume you can actually do it. What you need to tell them for an estimate like this, and for all your estimates, is that there's a 0% probability that you will actually get it done in that period of time, that such a guess is only the beginning of the probability curve. Each guess needs to be accompanied by such a probability curve, so that all the probabilities combined produce a real curve indicating when the project might likely be done. You can learn more about this by reading a small book called Waltzing with Bears.
You need to pay attention to economics and business, both of which are far-from-exact sciences. Listen to books and lectures on tape while you commute. Understanding the underlying business issues may allow you to detect the fortunes of the company you're working for and take action early. When I first started working I looked askance at people who paid attention to business issues -- that was suit stuff, not real technology. But those people were the smart ones.
A great new source of information is podcasts. Anyone can do these so many of them are bad, but there are some real gems out there, podcasts that specifically cover topics in our profession. I learn a lot from these, and they help me stay current.
Here's another thing you probably didn't learn here. Both the world of business and the world of programming is legendary for flailing about with fads that promise to get things done better. The easy fads are patently ridiculous, or become so in short order. The harder ones to spot contain some reason or truth that prevents you from quickly dismissing them. Sometimes you need to pick out the good stuff and throw the rest away, and to do this you need to exercise critical thinking.
I saw a grocery bag that said "studies show children and teens who eat dinner with their families at least 5 times a week are 50% less likely to use alcohol." The bag's conclusion was to start eating dinner together and that will prevent alcoholism. Is eating dinner together the dominant factor? Or is there something else that causes both eating dinner together and reduced alcoholism?
Here are some more which many people have seriously believed:
Companies don't have to make a profit anymore. It's the new economy.
Real estate always goes up, even if salaries don't.
Or even: A university must be a traditional campus and not an office building.
It's even harder when you come from the world of ones and zeros where we really, really want to believe that everything can be deterministic. It's harder than that when you understand that adding people into the mix and scaling up a system changes the dominant factors, while everyone around you still believes it should all be deterministic.
There's a book that uses studies to debunk beliefs about managing people and projects; it happens to be software-based but the thinking could be applied almost everywhere. This book is called Peopleware; it's small and fun to read and I recommend it to almost everyone. Alas, it really isn't a book of answers, it just firmly destroys many closely-held ideas about how people work in business situations that involve programming. The best thing about it is that it reminds you how easy it is to take a wrong idea and build a bad world around it. It helps you ask questions.
So when you go into your new job with your head filled with technical knowledge from the last couple of years, and you add what I've told you today, you may be tempted to assume that everyone at the company has foolishly gotten themselves trapped with bad ideas. But there's one more very important maxim from Gerald Weinberg which doesn't really answer anything as much as gives you a way to understand what happens. He says: "Things are the way they are because they got that way ... one logical step at a time." It's the legendary frog in the saucepan. So from your fresh new perspective things might look ridiculous, but remember that each decision on the way was made by someone weighing the issues and making what seemed like the best choice at the time. This viewpoint doesn't solve the problem but it can make you more compassionate about the people who are stuck there.
You'll need to make a lot of mistakes in order to figure things out. So be humble, and keep asking questions.
>>The other 20% struggle with their profession: they read, try >>to learn things, listen to podcasts, go to user group >>meetings and sometimes a conference. 80% of this 20% are not >>very successful yet; they're still beginning, still trying
"Code reviews are the most effective ways to find software defects, and yet we usually "don't have time for them.""
Pair programming is one way round this. It has lots of advantages (plus a natural cost of course - but I and many others think that the benefits outweigh the costs) and this is one of them. Continuous review (particularly if you swap pairs regularly - we do it daily - so that everyone gets familiar with the whole codebase) is part of your development process.
It also has a great effect on the 'people problem', the social dynamics of a development team. Problem people don't want to work in a paired environment and pairing is a fantastic way to mentor people.
Fantastic! The only other thing I'd add is that the "management" thing isn't just what other people do; you need to participate in the management process to help ensure it succeeds. Too many times managers just throw up their hands and declare that they can't understand software so they shouldn't be expected to do so. (This is especially true in companies where software is not their primary business--or so they believe...) Keep educating yourself and educate management, too. Learn to communicate your ideas and your problems. Yup, it is a "people thing".
Finally, the "all models are wrong" quote is from George Box and is one of my favorites. The other mantra I repeat is, "The model is not the thing your modeling."
I'm forwarding this link to a bunch of people who will enjoy it as much as I did. Nicely done. Thanks!
"...there's a 0% probability that you will actually get it done in that period of time..."
In my experience, this isn't quite right. Someone who's good enough can hit any arbitrary deadline by taking on some level of technical debt, just as a good salesman can always make his quota for this quarter: by draining the pipeline for next quarter. The positive spin is that I can always hit the deadline, if the deadline is important enough to hit.
I've made the conscious decision to miss many deadlines because they weren't sufficiently important. Sometimes that happens because of misestimation, but more often it's because of changing business priorities - we're choosing to miss this deadline on this project because another project got more important. And we could have dealt with this by taking on more technical debt on the first project, but it wasn't important enough to warrant that.
The real point, of course, is right on the mark. I just saw "technical debt" and "chance of hitting a deadline/estimate" in the same article, but nothing tying them together...
I disagree on the fact that technical issues are not critical. IMO, a programmer not paying attention to business and people issues will always accomplish nothing, but a programmer not paying attention to technology issues will repeatedly accomplish very little.
A nice definition of efficiency and effectiveness I once read comes to mind: suppose you have a ladder, a four-sided yard rounded with a concrete wall surrounding it, and have to climb up one particular portion of the wall. Leaning the ladder towards the wall and climibing it up in no time means you're efficient, leaning the ladder against the right portion of the wall means you're effective.
IMO, both efficiency and effectiveness are critical success factors for a programmer. Efficiency can be increased by permanently acquiring new technological knowhow and wisdom, and is a let's say "traditional" learning process. Effectiveness comes through experience, IMO, and there is no other way of acquiring it. And it deals mainly with business and people issues.
The effectiveness of individual members of a team is the one and single factor which makes up the efficiency of the team as a whole. More precisely: a team made up of not so efficient but highly effective programmers is likely to be signficantly more efficient than a team made up of brilliant, highly efficient programmers, which write a thousand bugfree LOCs a day, but which aren't effective in the way they work together.
I'd go a bit further in defining things. AFAIK, the chaos reports uses three criteria for evaluating the success or failure of a project: budget, deadline and actual functional content/matching the business needs. IMO, the first criterium is determined by the efficiency of the project team, the second is determined by a mixture of efficiency and effectiveness, and the last one is always a matter of effectiveness. Anyone agreeing/disagreeing? I think this definition is important for team leaders/project managers/senior programmers, since they are the ones responsible for project success in most organizations, and having a more precise, defined view on the factors that influence project outcome should help them optimize where needed - some sort of rough profiling criteria on software development.
So all in all, it's complicated. But we cannot ignore the technology factor, or place it so much behind the business and people factors as it seems to me it is placed by the initial post.
@Sebastian Kübeck @People don't have time for code reviews because because they'll use all their creativity to find other things to do. here are the reasons: @2. There's no real reward. The best you can get is not finding a bug and the feeling not having accomplished anything.
Then synthesize a reward.
This idea was suggested by either Will David Mitchell in Debugging Java or Allan M. Stavely in Toward Zero-Defect Programming. Whoever the idea came from, the anecdote was quite good: The code review team had a pile of candy in the center of the table, and anyone who spotted a bug would get a divvy of the overall candy pile. The original author of a block of code had to explain what it did to the code reviewers. The author related the effectiveness of this approach by mentioning that half way during the explanation of the code, the original author was explaining the code to everyone... when, suddenly, he bear hugged the entire candy pile and pulled it towards him. Everyone was dumbfounded, and then they realized that he found a silly, trivial bug.
You're wrong, Bruce, because software is a team sport. A couple hotshots don't make a winning team.
You're wrong again, Bruce, because undermined morale is the number 1 cause of failed projects per Steve McConnell's list, and the myth you're propagating does just that: undermine morale, whenever it's asserted. The myth consists especially of the suggestion that there are only two levels of productivity: very high for the few, very low for the rest, and no in-between.
You're most of all wrong to propagate in an intensified form (Peopleware only speaks of a 10:90 ratio) this myth about software development that undermines professionalism within our industry and damages its reputation in the world at large. Successful software projects are not carried out by a few gifted or obsessed individuals despite their colleagues, but by teams that work well together. Software is not an art form for mavericks but an engineering activity for team members.
Great article, but I beg to differ on a couple of points.
> <p>Let's say that this follows the 80-20 rule.</p>
Of course, this is pure liquid nonsense -- the 80% and 20% of the 80-20 rule are actually taken from different quantities ;)
> Over time I very slowly learned that the task of > management wasn't stupid, it's just very, very hard.
True, but quite unfortunately, this doesn't make management itself any smarter :)
> What you need to > tell them for an estimate like this, and for all your > estimates, is that there's a 0% probability that you will > actually get it done in that period of time, that such a > guess is only the beginning of the probability curve.
I agree about the curve, but you're contradicting yourself -- if you hit the business part of the curve at all, the probability should be well over 0%.
> <p>Listen to books and lectures on tape while you > commute.</p> > <p>A great new source of information is podcasts.</p>
Recorded books and lectures are a waste of any experienced reader's time, and so are podcasts.
Oh, and I really hated having to sign up to post an answer.
@boo gy @Recorded books and lectures are a waste of any experienced reader's time, and so are podcasts.
Dogmatic statements like this are how people make poor decisions. Your statement is far worse than Eckel's, because not only does it fill impressionable minds with silly nonsense, but it is actually countering really good advice.
You are taking Eckel's comments out of context. For example, my friend had a really hard time communicating his points to others. He was extremely bright, but had a hard time persuading others. I told him it might be a good idea to read a book, but he insisted he had no time to do so. "Well", I said, "How long is your commute to work?" 45 minutes each way, he told me. I suggested he get Andrew MacMillan's narration of Dale Carnegie's book How To Win Friends and Influence People. At least then he wouldn't waste 1 hour and 30 minutes of his day. Eventually, he came back to me and said, "You were 100% right. I love this book."
Experienced reader or not, most of us are not crazy enough to read a book while driving a car. Narrated books are superior during this time, and this appears to be precisely the context Eckel was speaking in.
Another one of my friends wanted to read the collected works on Project Gutenberg. So he fed the files through a text-to-speech translator, and listened to them on his commute.
Apologizing to Yogi Berra, I'll end on this: Wasted time is wasted time; it's using that wasted time effectively that separates the 5% from the 95%.
> You're wrong, Bruce, because software is a team sport. A > couple hotshots don't make a winning team.
Depends on the project. Whipping up a few thousand cut and paste web pages might not require "hot shots" (your term). However, hard technical problems don't get solved by "teams"; they get solved by extraordinary thinkers.
Don't believe everything you read. I have known more than a few software developers working at NASA on software for the shuttle ..
> Successful software projects are not > carried out by a few gifted or obsessed individuals > despite their colleagues, but by teams that work well > together. Software is not an art form for mavericks but an > engineering activity for team members.
You are half right: "Successful software projects are not carried out by a few gifted or obsessed individuals despite their colleagues." However, in my experience, when I see "teams that work well together," there is often "a few gifted or obsessed individuals" who make up the spinal column (or insert your own analogy) of that team.
> Software is not an art form for mavericks but an > engineering activity for team members.
Frankly, it works well when it manages to be a bit of both.
Great speech! I especially liked the part about the management. In the some IT Services sector in India, the belief is that only dumb guys end up in management - and technologists are the ones who manage to write "Hello World" in anything that's latest.
This leads to a disconnect where some people treat others as things and the project never has a real team but a bunch of people working to polish their own technical skills.
Flat View: This topic has 29 replies
on 2 pages