Career advice from Larry Smith

Career advice from Larry Smith:

http://economics.uwaterloo.ca/smithdat/career2.html

“Conduct your career as your business”

Make a plan for yourself. Don’t allow yourself to be simply carried along by the currents of the day.

“You never let your employer have full control of your mind’s agenda. Control of the agenda is control.”

Develop yourself uniquely as a product offering:

“The goal is to be unlike others, to be premium priced, to have distinctive function. And there is only one way to do that… Your ideas make you distinctive.”

Market your offering broadly:

“When employed, you distribute your ideas as broadly as possible…”

“You create a resume of distinctive accomplishment. You do not describe routine duties, letting the job title speak for itself. Rather you describe what exceptional work you did…”

Requirements, people, and monsters (part 2)

Requirements. There is an ever growing, massive pile of requirements. This pile threatens to crush the development team under its weight. The agile movement taught us how to deal with this. Well… before that life taught us how to deal with this… one step at a time. The key to dealing with the pile of requirements is focus.

Planning Game

The planning game is one of the main ways to tame the requirements. First it does this by breaking the pile down into a few piles. Talk with the project sponsor about the requirements. Divide them into three buckets:

• items essential for launch

• items that are very important

• items that can be postponed

The names of these buckets are adjusted to accommodate your current project sponsor. The only important thing is that roughly two-thirds of the requirements are moved into a category of things “not to work on”.

Now apply this process iteratively. Take the remaining pile of “essential” items and continue breaking it down into sets of three buckets until the remaining items is small enough that you feel your sanity restored. This should be a couple of months worth of work.

That is the first key to the planning game, it is a form of triage that allows the team to focus on the essentials. The second aspect is related. Divide the essential elements into a series of very small releases, or iterations. Choose an iteration length of one to two weeks and layout the essential requirements into a series of iterations.

As much as possible have the project sponsor make the decisions about what features go in which iterations. The most important aspect of this part is to have the project sponsor make the changes to the iteration schedule. Give them a quota for how much can be in each iteration and then place the burden on them to arrange the requirements such that there is not too much in any one iteration. This is key because it creates a mechanism for the painful truth to be communicated directly to the sponsor. The truth is that 6 days of work cannot be crammed into 5 days.

If the game is setup correctly the sponsor feels this truth as a direct consequence of their actions, not as some arbitrary bad news that the development team has to tell them. So if the sponsor puts five more requirements into the next iteration then they should see that they need to remove five requirements in order to “make it fit”.

Iterations

Regardless of whether you can make the planning game work, iterations are essential for dealing with the pile. Take a tiny set of features from the pile and focus exclusively on them for a week or two and get them done. That is the essence of surviving and conquering the pile. (If you have a steady stream of support issues then leave room for this in your iteration plans.)

Successfully completing each iteration becomes the defining rhythm of the team. It is the basic stroke of the development engine.

Checklists

Completing iterations provides vital motivation to the team. But we frail humans need to be rewarded more often than once every week or two. We need daily reinforcement. So break the features for an iteration down into smaller steps that can be completed in a few hours. Get these listed for all of the team to see. Now developers can feel the satisfaction of crossing something off the list every day. Crossing items off of the list assures the team that the pile is being conquered.

So the team can survive the crush of the pile by dodging it. Don’t try and carry the weight of all of the requirements. Let the weight rest on the ground. Instead take on small parts of the pile at a time. Always take an amount that you can do and you build a pattern of success day after day, week after week.

This is the battle to be fought

As a developer it is easy to look around the web and get distracted by all the cool stuff going on. Maybe you read one of the many stories about the guys starting web sites in their bedroom who are bought out for millions. Or maybe you read about the success of the guys of whom it appears that everything they touch turns to gold. You get distracted and think that if only you were over there then you could do great work.

You have to realize that the place where you are, right here, in the midst of whatever mundane tasks and bizarre organizational issues you face. This is the battle to be fought.

So stop dreaming and fight today’s battles.

If you are caught in an organization that “meets” to death, then your battle is to make the meetings more productive, or make them stop happening, or at least make them short.

If you are on a team where nobody can get organized, not even you, then that is the battle. Fight to get yourself organized and help the team do the same.

If you are wading through piles of legacy code, then that is the battle. Learn ways of getting legacy code under control.

If you develop in a code-and-fix manner, then the battle is to get the discipline to follow good practices.

So don’t get distracted and dream about being in a great job. Don’t deceive yourself into thinking that if it weren’t for these pesky issues you could solve some great problem. And don’t deceive yourself into thinking others have it easy and only you have to deal with a messy reality. Realize that fighting the battle in front of you gives you experience and skills to go on to the next battle. Realize that behind the glossy success story you read, someone has fought the same mundane battles you are facing today.

Fires kill productivity

In order to be productive you need a short list of things to focus on. When you focus on an item you get it done.

Fires are the urgent items that pop-up throughout the day and demand immediate attention. These urgent issues kill productivity. They kill productivity because their urgency encourages us to take on too many tasks. Their urgency almost forces us to multi-task. And multi-tasking kills productivity.

So my question is, why do fire houses always appear so neat and orderly? If firemen are always fighting fires then how do they have the time and discipline to keep their trucks washed and everything put perfectly in its place?

Multitasking does not scale

It is one thing to bear the burden of working on ten things at once. But now apply that to a team. There are five team members. Each working on ten things. The team leader ends up multitasking between fifity different issues! Working on fifty things at once does not work very well.

Failure oblivious computing

Do you really need to understand all aspects of the program you are writing?

Is it more important for a program to be correct or simply keep running?

I certainly have strong reactions to these questions. My natural, strong responses are based on the principles of how software ought to be done.

This paper (link provided to me courtesy of Kyle) challenges my thinking in a startling way.RinardOOPSLA06.pdf

The results are so startling that on this page I was ready to discard the paper in complete disbelief:

Our Philosophy • Should be able to ignore addressing errors • Perform dynamic bounds checks • Discard out of bounds writes • Manufacture values for out of bounds reads • Continue executing • Called failure-oblivious computing

Did you get that? If the program writes to memory that it does not own… just throw away the write (!?). If the program reads from memory that it does not own… just make up some value to return (!?).

But then the author makes a compelling case based on a empirical data.

The startling conclusion is that in many cases we cannot afford to build correct software. When I think about reality, rather than my wishful thinking, this resonates deeply.

Sieze slack time

There is rhythm to life. Times change. One day there is intense pressure to get things done. The code needs to be finished immediately, there are production problems, or some such thing. Then a few days later there is apparent calm. Nothing is obviously broken and there is no immediate pressure to deliver. What to do in these times?

One answer is to work ahead. Attack the list of things to do as if there were immediate pressure. Why? Because there is a good chance that tomorrow things will change and the app will need to be done. If you work ahead now then you can alleviate that pressure in advance.

This is in essence what the planning game is all about. It takes the tremendous pressure that is felt at the end of the project and brings that back in time to the beginning of the project. By forcing hard decisions about priorities to be made early the planning process some of the end pressure is moved to the beginning of the process. In this way, the pressure is distributed and the ultimate pressure is relieved.

What else can you during slack times? This is a great time to invest in some strategic efforts that can shape the entire project and be leveraged for the duration of the effort. For example, invest time at the beginning of the project to establish automatic build servers and automatic testing. These efforts set the project on a trajectory that will become the standard for how the project operates.

Whatever you do, realize that the slack time will not last and seize it to drive the project on to greater success.

Use SlimTimer to track your time

A friend of mine turned me on to SlimTimer and I really like it. It is a web service in which you create a list of tasks you are going to work on. Then you can click one of them to start a timer that tracks how long you work on it. Simply click it again to stop the timer. Alternatively, you can simply click another task to start the timer on another task. It couldn’t be any easier. The application also includes a nice set of reports to analyze your time.

So why would you want this? If you are working as a freelance developer you need to keep track of how much time you work on each project. This isn’t like the old days where you show up at work at 8:00 am and leave at 5:00 pm and record 8 hours of work on your timesheet. These days you are working at any time of day, switching between projects at a furious pace, and switching in and out of work constantly. You need something like SlimTimer to cope.

And, even if you don’t need to track your time for billing purposes you still need a tool to track your time. At some level we are all managers. At a minimum we are all responsible for managing ourselves. You can’t manage yourself without data. So use SlimTimer and collect data about how you spend your time.

You know how it feels at the end of the day, when you say “where did the day go?” SlimTimer will help you answer that question. And, the answer will suprise you.

Besides all of that, there is another reason to look at SlimTimer. It is a very well executed service offering. The author has obviously paid great attention to creating a good user experience, he is blogging about it, and he makes it very easy to get started. If you are working on making your contribution to the web service frenzy, then be sure and check out what he has done and emulate him.

Chart a course

We are surrounded by an apparently endless list of new things to learn, new technologies to explore, and new fields to experience. It could be anything from learning a new class library, to learning a new language, to learning some design skills to make nicer looking apps, or learning how to run a business. It is easy to feel like, “I could just make some progress if I knew what to work on and if there weren’t so many choices”.

Realize that everyone is in the same situation. The ones who succeed are those who are able to focus despite the chaos.

So chart a course. Look around and see what there is to know. Think about your career and what you want to be doing. Think about your skills and how you can round out your experiences or increase your depth in key areas. Decide where you are going and make a plan to get there. You don’t need a detailed week-by-week plan, but at least identify some steps to get where you want.

Maybe you are currently a graphics guy and you want to be a coder. Pick a language to go after. You could target the current market with Java or follow the latest hype with Ruby. Decide on one and pursue it. Learn the language, build a sample app, subscribe to some relevant blogs to discover what the current issues are. Identify steps to meet your goals

If you have no course and don’t know where you are going then you will simply be tossed around by life.

You don’t know everything

A related pathology is the belief that you must know everything. Somebody says something to you. You have only a vague idea of what they are talking. Do you tell them that? Of course not. You say “uh, yeah” and nod your head.

Stop that.

If you don’t know what someone is talking about then say that. Ask them a question. Sure you will show you don’t know everything, but as I said last time… everyone else already knows that you don’t know everything. The only one your fooling is yourself.

Another way of looking at it is that this is your duty to make communication happen. If you don’t understand someone it is your responsibility to let them know.