I’m continuing to write about each one of the lessons I’ve learned. However, the list is long and I’m not writing as frequently as I’d like. So for those of you who are impatient and just want to see the bullets, here is a PDF of the PowerPoint slides.
tech, life, and more
Archive for the 'things i wish i knew before working' Category
There is a pretty good presentation by David Pogue at the TED conference. It is a video that runs about 25 minutes long.
He highlights the fact that simplicity is good, and simplicity sells. The message is aimed at the I/T industry and the products it creates. While there isn’t anything mind-blowing in his presentation, he does a good and enjoyable job of driving the point home that technology products have gotten to be a mess, and we need simple things that just work. Makes sense to me.
As an industry we have got to get ourselves out of the mindset that better = more features. The complexity is killing us.
There is a really good article on the security mindset from Bruce Schneier. His basic tenet is that instead of just thinking of how to get things working (yes, I’m guilty of this too) we should be thinking of how to get things to break, so that the things we build are more secure and less prone to failing.
Today I had lunch with IBM’s Chief Privacy Officer. As Bruce talks about the security mindset, I was educated today on the privacy mindset. Some good base principles were developed by the OECD. To give a simple example, a well-intentioned employee built a widget for intranet web pages that would track who visited, so you could see who visited your pages. The widget would display this not only to the page owner, but to anyone else who visited the page. The privacy mindset should ask questions like: “did you tell me you were going to collect this personal information? Did I as a user give you permission collect this personal information? Is this personal information protected? Do I want all my fellow employees knowing which intranet web sites I visit?” I suspect these are questions that did not get asked by the well-intentioned widget author. But I think the lessons from Bruce and the CPO are mind-widening (especially for engineers), grounded in reality, inherently valuable, and necessary.
I like these comments from JP Rangaswami. Stay focused on the customer, not on internal issues. Generate value, not effort.
tech: there is always more than one way to do it. Identify the pros and cons of each, and determine what makes the most sense in each circumstance.
If there is only one thing that you read on my blog in this category, this is it.
There is only one best way to do something. Bzzz. Wrong.
I don’t have any choice. Bzzz. Wrong again.
Let’s start with the first one. As you saw in the post title, there are always many ways to accomplish something. Always. Call them options. Some of those options may be sub-optimal, and some of them may suck, some may be mediocre, and a couple may look pretty darn good, but those are all options. Just because you don’t know about an option or don’t like an option doesn’t prevent it from being an option.
So the first step is to catalog all the options. Dig around and find all the options. I would even propose that the first option to come to mind when you are tackling a problem is probably not the best option. Go back and think critically and look at all the fringes for options you may have initially missed. There are always more options.
Then, for each option you’ve found, identify its pros and cons. Again, you may have bias and gloss over some of the pros and/or cons, but think critically and really dig here. With effort I bet you’ll find some pros you initially hadn’t thought of for initially unappealing ideas, and vice versa for the initially appealing ideas. Either play devil’s advocate yourself, or get someone to do that for you. You need to challenge the status quo and the preconceptions.
Then, which option do you pick? There is no absolute. Absolutes exist only in math and religion (and even those have some wiggle room). So figure out what you are trying to optimize for. Maybe you are optimizing for flexibility, speed, cost, value, effort, strategy, breadth, depth, coolness, stability, bleeding-edgeness, whatever. The best option is going to depend on what you are optimizing for. In other words, it depends. You will probably be optimizing for multiple facets. But you can’t optimize for everything, you need to target.
Once a company PR person called me after I had worked on a dozen projects. She said, “tell me about your coolest project so we can promote it.” My reply was, “Cool to who? The business person, the executive, the CS student, the manager, the middle-aged I/T worker, the intellectual property lawyer, the customer?” I would have picked a different project for each of those people. Each project had a strong point or connected with a certain constituency, there wasn’t one project that did it all. So I was basically asking the PR person who they wanted to optimize for. And that is basically the question we need to ask ourselves: in this circumstance, what I am optimizing for? That will guide you to pick the best option for this circumstance. It’s entirely possible, and sometimes even beneficial, to pick another option in a different circumstance. If you are picking the same option regardless of the circumstance then I’ll bet you are making the wrong choice in some of those circumstances. But on the flip side, realize that churn has a cost too.
Another thing to keep in mind is the difference between project execution and decision making. As engineers, at the beginning of a project we are prone to jumping in and starting execution before making the hard decisions. It is easier to do than to think. However, if you think criticially before you execute, you will end up in a better place. Some level of challenge within a team is healthy and desirable. Also realize that within teams certain people may have the specific role of decision maker instead of do-er, and the decision maker is not a lesser role than the do-er.
So, bottom line, there is always more than one way to do it. Figure out what makes the most sense in your circumstance.
A group has put together a list of programming languages based relative popularity, which they are calling the Programming Community Index. It’s interesting, but of course take it with the usual grain of salt. Even take the definition of “popularity” with a grain of salt. But it should get you thinking a bit.
This cartoon is a great example of the non-technical issues in software engineering. Notice that every situation is wrong, even what the customer asked for. These issues are caused by poor communication, incorrect assumptions, cut corners, optimism, bad habits, etc. The good news is that it is possible to overcome each of these causes, but it isn’t easy and certainly doesn’t happen without a lot of effort. It takes balance, iteration, communication, insight, and good judgment. These are things that can’t be enforced.
You may be familiar with the Pareto principle, otherwise known as the 80/20 rule. When applied to project schedules, the first 80% of the project takes 80% of the budgeted time. Slightly less well known but still true, is the corollary: the remaining 20% of the project takes the other 80% of the budgeted time.
Have you seen this often when writing software, writing a book, painting a room, organizing your finances, or basically any other non-trivial project? Why does this happen? I think it is well-meaning hard-working people who are optimistic. People fail to be pessimistic enough about complexity and roadblocks. As a result, a large increase in effort is needed near the end of the project to keep it on schedule. Our optimism gets us in trouble.
So what do we do? Be pessimistic in your time estimate. Then double it. Seriously.
It’s better to finish earlier than expectations than later. As I keep telling students: with schedules, it’s more important to be accurate than optimistic. Also, take this quote from Star Trek III: The Search For Spock:
Kirk: “How long to re-fit?”
Scotty: “Eight weeks. But you don’t have eight weeks, so I’ll do it for you in two.”
Kirk: “Do you always multiply your repair estimates by a factor of four?”
Scotty: “How else to maintain my reputation as a miracle worker?”
problem solving: build a network of people. Asking for advice is quicker and usually more insightful than learning the hard way.
In school we are taught that we must do things by ourselves. Depending on the circumstance, asking for help is akin to cheating. In addition, control freaks want to do everything themselves anyway. And sometimes pride means not asking for help when you need it. These are some of the drivers for us working in isolation. In happens in the workplace where there is a problem to solve and we are assigned to do it, we do it by ourselves. And when we are in an area that is new to us, it is easy to get bogged down in figuring out the new things. It may be the time required to learn the new tool, time to actually read the manual so we aren’t inept or dangerous, or navigating our first time through a process. The ramp-up times can be significant. But the common thread in these things is that they are things that other people know how to do, but we are new at it. It’s not cutting-edge research in uncharted territory. They are just things we need to learn.
So how do you approach it? There is a balance point. At one extreme is a brute-force exhaustive search across the landscape in a solo expedition. Or build the entire thing from scratch and learn the same lessons that other people already have. Sure, that removes your dependencies on other people and satisfies pride and control freaks, but it is also extremely time intensive. And in some cases, you are reinventing the wheel. Most employers don’t want you to spend that much time on it. Time is money. I’m afraid most of us tend toward this extreme. So my suggestion is to get more in the middle.
Find out who the people are that have experience (or may be the experts in) what you are trying to learn. Spend some time talking to them. You can ask about their experience in that area. Utilize their experience and the lessons they have already learned. They can offer pointers for an accelerated start, best practices, anti-patterns, and most importantly, a net evaluation. The knowledge you can get based on the time invested is a huge improvement over the solo expedition. And the insights that other people can provide may exceed your own capabilities anyway.
At the other extreme is lack of due diligence and not doing your homework and being a burden to other people. Don’t go that far, pawning off your core learning responsibilities to other people. Respect their time. And sometimes take other people’s comments with a grain of salt. But don’t work in isolation either. Sure, it increases your dependencies, but an appropriate level of interdependency within an organization is a desirable thing.
So next time you are working on a big problem, ask around a bit. And be willing to respond to other people’s questions too.
Too often we focus just on the science when we build things. Solutions need to more than just work, they need to be elegant. With elegance comes the collection of ‘bilities (consumability, reliability, extensibility, securability, etc.)
Cooking is as much science as art. Yet we may think about it mostly as an art. But the behavior and interaction of food elements definitely has a science to it, a set of discoverable and consistent properties and rules. But the end product of cooking is appreciated mostly in an artistic context, how it pleases the palette, eyes, nose, and texture. But to get there, the cook had to understand and apply the science of food.
I think software development ought to follow the same model: the developer needs to understand and apply the science, but the science is a tool to build something elegant and pleasing, and which can be appreciated by the user. The end result should be measured in terms of value to the user, not the developer’s ego. In many places it seems that software has lost the art aspect, it can be added back relatively easily if you put a little effort into it. Don’t forget the art in development. Make it elegant for the user.