I have written about programming careers, the virtue of hard work, and other similar stuff in the past few weeks. This week I wanted to write something different. Something more inspiring and less practical. While scratching my head about what to write, I remembered a Quora thread I had read a long time back about weekly wisdom Professor John Ousterhoust gave to his students at Stanford. Professor Ousterhoust's classes are weekly wisdom are much sought after among Stanford's CS students. I'll summarize his weekly wisdom and link some of the points he makes, to software development and similar stuff others have said, but be sure to also read the thread to get his raw transcribed words.
A little bit of slope makes up for a lot of Y-intercept:
I love this one because it's for those of us who feel like we somehow started with a knowledge disadvantage. if you've ever felt like you started life with a disadvantage, this wonderful advice will show you how to set the record straight.
What I mean is that how fast you learn is a lot more important than how much you know to begin with. So in general I say that people emphasize too much how much they know and not how fast they're learning. -- Prof Ousterhoust
Fear is more dangerous than evil:
Let me give you an example. People who are afraid will do things that they know are wrong. For example, when people cheat on assignments, in most cases, it's when people are up late the night before an assignment is due and they get desperate and afraid and made a silly decision to steal somebody else's work. In industry, CEO's are afraid to announce that their company had a bad quarter, so they allow their salespeople to report sales from the next quarter. Then in the next quarter, they have to cheat even more and eventually it all comes tumbling down. -- Prof Ousterhoust
Software developers are often as guilty as the CEO who allowed the sales staff to report profits in advance to make up for a bad quarter. In software development this sort of stuff is called technical debt. Here's a very nice article that articulates the concept of technical debt and shows a way out.
The greatest performance improvement of all is when a system goes from not-working to working:
We've all read and heard about why premature optimization is (usually) a bad idea, but I just love the way Prof. Ousterhoust explains it.
Programmers tend to worry too much and too soon about performance. Many college-level Computer Science classes focus on fancy algorithms to improve performance, but in real life performance rarely matters. Most real-world programs run plenty fast enough on today's machines without any particular attention to performance. The real challenges are getting programs completed quickly, ensuring their quality, and managing the complexity of large applications. Thus the primary design criterion for software should be simplicity, not speed. -- Prof Ousterhoust
Use your intuition to ask questions, not to answer them:
Intuition is a wonderful thing. Once you have acquired knowledge and experience in an area, you start getting gut-level feelings about the right way to handle certain situations or problems, and these intuitions can save large amounts of time and effort. However, it's easy to become overconfident and assume that your intuition is infallible, and this can lead to mistakes. So, I try to treat intuition as a hypothesis to be verified, not an edict to be followed blindly. -- Prof Ousterhoust
I have to confess that I have made this mistake umpteen times. I started getting a certain grasp of things related to software development soon after I started programming and my early thoughts (or intuitions if you will) fortunately proved to be correct. These early successes at guessing and extrapolating from my existing knowledge made me bold to the point of over confidence. Those early successes were soon replaced by incidences where I burned my fingers - often pretty badly. The sad part is, it had to happen an awful many times before I realized that my extrapolations were increasingly more incorrect than correct. I think this is great advice, especially if you are a young developer prone to over-confidence.
Facts precede concepts:
Another piece of excellent advise for those who might be prone to jumping the gun. But that's just one case he covers in this pithy but hugely relevant tip. The part I found most interesting is the one that deals with teaching. I think you will find this advice very useful if you are a team lead or an Agile Coach and have often wondered how to effectively explain a concept to your team.
This has implications both for teaching and for working in unfamiliar areas. In teaching it's crucial to give lots of examples when introducing a new concept; otherwise the concept won't make sense to the students. Edward Tufte describes this process as "general-specific-general": start by explaining the concept, then give several specific examples to show where the concept does and does not apply, then reiterate the concept by showing how all the examples are related. -- Prof Ousterhoust
If you don't know what the problem was, you haven't fixed it:
It's fascinating how equally messed up we all are regardless of age, gender, or continent. I was tasked with fixing a bug, years back, in the early days of my career as a software developer. I couldn't find out the exact cause of the bug, but after a few trial and errors I changed some code which somehow magically fixed the error. Quite foolishly I declared victory and marked the bug fixed. I am not going to tell you what happened next because it's way too embarrassing, but you just have to read this piece of Prof Ousterhout's advice yourself to understand why this is such a bad thing.
Nine times out of ten this approach doesn't really fix the problem; it just submerges it (for example, the system timing might have changed so that the problem doesn't happen as frequently). In a few weeks or months the problem will reappear. -- Prof Ousterhoust
The three most powerful words for building credibility are "I don't know":
This IMHO is simple and super powerful. If you are a regular reader of our blog you must have read previous posts which discussed why you should not try to be a fast gun in an interview and the perils of trying to confidently give incorrect answers in an interview. The programming concept of KISS (Keep It Simple and Stupid) applies to real life also. If you don't know something, just keep it simple and say that you don't know.
Many people worry that not knowing something is a sign of weakness, and that if a leader seems not to have all the answers they will lose the confidence of their team. .......However, this approach ultimately backfires. Sooner or later people learn the truth.......On the other hand, if you admit that you don't know the answer, or that you made a mistake, you build credibility. People are more likely to trust you when you say that you do have the answer, because they have seen that you don't make things up. -- Prof Ousterhoust
If you enjoyed reading this summary then you must absolutely read the entire thread. It has transcripts of the full weekly wisdom which I have excerpted here and a few more tips on topics such as change, relationships, coherent systems, and personality .
facebook
twitter
linkedin
blog