All posts by Steve

Office Worker Essentials

A century ago the majority of people were employed in manual labor: either on a farm or in industry. A small minority worked as professionals. They were the early knowledge workers. Their primary tools were the pen and paper. How times have changed. Today every knowledge worker has a myriad of tools at their disposal and they are expected to master them.

This is the first article in the series on Starting in a Software Development Career.

You have to work with at least two office tools: email and calendar. First things first: resist the temptation to use your office email for personal messages. The company owns, operates, or at least pays for the email system. It should be used only for company business. Find an email provider that you like (Google Mail, Yahoo!, iCloud,, etc.) and sign up for a free account (if you haven’t already done so). Use this account for your personal messages. Even though you will end up with two email boxes and two calendars, you are still better off keeping company business and your personal business separate. This applies to you if the other email is your school or college email, not work.

Setup filters for your incoming email that tag (and sort) your mail. This allows you to focus on the more important messages (either because you tag the important ones, or filter out the less important ones). Setup shortcuts, or just learn the ones your email system already has, that allow you to move the messages quickly into your email archive or the trash bin. Use filters to retrieve tagged messages from the message archive.

A good email habit to get into is to check your messages just a few times a day, only when you are ready to process them. Processing your messages means that you look at the message, and decide on the spot what to do about it. If you can complete the work required by the email in less than 30 seconds, then do it right then. If you think that it will take longer, then schedule time on your calendar to get the work completed. If you need to keep it for reference, then tag it and archive it. Otherwise, delete it. 1

Keep your calendar current with all your scheduled activities. Attempting to keep meetings and appointments in your head will sooner or later result in missing one. Add calendar entries that reserve time for doing your work to ensure that nobody schedules you for something else when you need to focus. Most calendaring apps allow you to color code your calendar to see at a glance what your day or week looks like. Pick 4 to 6 categories, assign colors to them, and color your calendar entries accordingly. You’ll be surprised how much faster you will grasp what your day or week looks like.

As you attend meetings and talk to your colleagues have a notebook so that you can write things down. You will come across well organized and dependable as a result. People will trust you more if they know that they can count on your listening to what they are saying, taking notes, and following up on requests or action items.

For your engineering work, keep a separate engineering notebook where you record your engineering thoughts, sketches, theories, and observations. For both of these uses there are good electronic notebooks for laptops and tablets. If you are not comfortable having everything online or you can’t quite feel that the electronic pad can capture everything that you want to sketch, then you may still want to have a paper notebook. Always date your notes; it is a practical habit to adopt to ensure that you can also find your ideas if at least you vaguely remember when you thought of them.

There is a good chance that your workplace will also have a corporate wiki for collaboration and knowledge management. You need to learn how to use one and get used to working with it regularly. Wikis are a great way to collaborate with your colleagues even if they are in the same office with you (because writing will clarify your thinking), but especially across time (asynchronously) and geography (especially long distances). For more on how to use a wiki see: What Makes a Good Wiki and What Makes a Good Wiki Page. In addition to the collaborative editing aspect of every wiki page, the comments and highlighting on every page are a useful collaboration tool, too.

Another element of every person’s life (both personal and work) is online chat, also known as messaging. In the work setting chat has been elevated from idle diversion to the status of a useful productivity tool. Chat channels are used for connecting people around a common projects, interests, or locations. To be a successful chat user, you must learn how to manage your chat-driven interruptions. There are times when you may not want to be interrupted by chat messages. Let your team know this in advance. Tell them when you are available, so that they can count on you. Most messages do not require immediate attention. A workable strategy is to let people know that if it’s urgent, they should use some other method to contact you, like a phone call, etc.

That takes us to one of the oldest office tools: the telephone. For most software developers the telephone lives on as a device for conference calls, though even in that aspect is getting replaced by online voice and video calls or tools like GotoMeeting and Since these days you are not likely to get a lot of voice messages, I recommend that you check your messages before you leave for the day; you never know, it might be from somebody important.

In almost every knowledge worker role, certainly most roles in software development, from time-to-time you are expected to prepare and deliver presentations. Learn how to use a presentation software, be it PowerPoint, Keynote, Slides, or anything else that your workplace standardizes on. You need to know at least how to: (1) edit and create presentations, (2) put the presentation software in full-screen presentation mode from the beginning and from the current slide, and (3) pick the appropriate screen for displaying your presentation. Practice these skills for a few minutes every week until your learn them, or at least practice it before you present. Make sure that you practice with the equipment that you will present with. Since there is a good chance that you don’t present a lot, during those few occasions when you do, you will have a lot of eyes on you as you fumble with your computer, projector, or the cables that connect them together.

Plan your work and work your plan. It is an old adage and it still holds true. Avoid the desire to make a perfect plan. Your goal should be to make a plan that can guide your work. A good plan will warn you when you are getting off track. When you cannot make a plan for the work, that’s a sign that at this time you may not know enough to do that work. This can be either an opportunity or a problem: if you realize this early, you may still be able to learn what you need to know, but if you find out late that you are lacking critical knowledge, then you might not be able to complete your work on-time. Then you have to ask for help. For details on how to plan, see my earlier post: Brief Introduction to Personal Planning.

Whenever you accept to do any work, even as simple as a task, part of that work is to report the completion of that work to whomever gave it to you. Or, if the work takes more than a day, then it is a good idea to agree ahead of time how often you are expected to report on the status of the work. If it takes more than two days to do, then identify smaller chunks of work that you can complete in a day or half-a-day. As you work through the first few tasks, you will have a better idea about how the work is going. And, you’ll be able to report on your progress.

Lastly, learn to touch-type and dictate. Most software developers spend a great deal of their time in front of the keyboard. Thus it is a very useful skill to learn how to type without having to hunt and peck for every key on the keyboard. Typing at a respectable 30 to 50 words-per-minute is within everybody’s reach.

Dictation used to be a skill reserved for top executives. Today voice recognition is built into almost every mobile phone and computer. As a result, it is possible to dictate to the computer what in the past you would’ve had to type. However, dictation is a skill that needs to be learned. Learn how to do this and you will save yourself a great deal of typing. (As you may have guessed, I dictated part of this post.)

Look through the above list, pick something that you feel you should do next and get going on it. You will enjoy getting more effective, more productive, and you might also have some fun along the way.


  1. For more on processing your messages, see *Getting Things Done*, by David Allen.

Starting in a Software Development Career

In our competitive world people are expected to produce results beginning with the first day on the job. The guidance you get about what constitutes results is usually not as clear as we all wish it would be.1 As a software professional you can improve the odds of being successful right from the start if you are prepared for your first day.

During the upcoming months I’ll publish articles about practical knowledge and useful tools needed for starting out in a software development career. As a recent computer science or software engineering graduate starting your first job after graduation—or even as an intern working through your first programming internship—you might find these articles useful.

Your professors taught you many wonderful and useful things in school. When you get to your first job there are many more things that a company assumes that you’d know, but nobody tells you about them during your school years. I’ll touch on five broad areas to help you prepare and improve your odds of success beginning with your first assignment.

The opening article will target the essential tools that cut across all roles for anyone doing knowledge work in today’s office environment. Next, I will write about the professional relationships in an office, including working on cross-functional teams.

What follows the more general knowledge worker topics are articles about some of the specific knowledge needed from computer science and from software engineering perspective. Lastly, I will close with an article about the tools required to do a competent software development job in 2016.

1. What constitutes results is a large and opinionated topic that will be the subject for another day.

The Essence of Knowledge Work, Part 3

Knowledge workers take in information, process it by applying their knowledge to it, and output information (possibly) in a different format than they received it. You, like many other knowledge workers, produce your output artifacts by applying knowledge to the input you receive. Your knowledge includes everything you know and the input you receive from all possible sources, too. There are three dimensions to the information needs that each knowledge worker has:

  1. Dependencies (who needs your output and who provides you input)
  2. Information artifacts and their format
  3. Timeline for artifact delivery (time frame)

This is the last part of a three part series. Part 1 tackled dependencies. Part 2 looked at information artifacts. The focus of this article is the timeline for artifact delivery.

Life and business runs on commitments. A commitment includes the artifact that you deliver, a timeline on which you will deliver it, reporting on the progress of creating the artifact, and reporting on the final delivery. Businesses small and large run on commitments. Teams run on mini and micro commitments that team members make to each other. You must go to great lengths to meet a commitment you made to a teammate. When you realize that you cannot meet the commitment you made, then you must go immediately to the teammate and renegotiate the commitment.

Sometime this timeline is constrained by needs, contracts, or events beyond your or your colleagues’ control. This agreement is often derived from external commitments that the team made. While many times people would prefer to plan forward, most often you must plan backwards from the commitment date. See: Brief Introduction to Personal Planning for details.

For example, if the code needs to be tested before it can be shipped, and the testing team needs a day to test, and the deadline is COB Friday, then the developers must deliver the code no later than Thursday so that testing has enough time to test. If you factor in the possibility that testing might find a few defects, then maybe the code should be delivered on Wednesday, so that the team has a day to find and fix those defects.

It helps if you think of yourself as “Me, Inc.” and imagine that your colleagues that need to receive your output are your clients. The colleagues that deliver to you their output are your suppliers. You want to treat both your clients and suppliers well. (If you’d run your own business, you’d not make your clients wait or give something that they can’t use, because you’d not be in business for long.)

At times you might be upset that a “supplier” promised something that you need that has not arrived when you needed it. Give them the benefit of the doubt and go talk to them. If they have always delivered before then you should ask “What might be going on with them? What might hold them up?” Maybe they are trying their best, but something is not working, or maybe you just asked for something outside of their areas of competence. Ultimately, you will be more successful if you work with them and help them be successful so that they in turn can help you be successful.

Your value-add. The difference between what you get and what you provide is your value add. This is what your business (Me, Inc.) is providing to its clients. This has to be big enough for you to stay in business. Once or twice a year examine the value-add that you provide and validate that you are still providing a market competitive value in the domain that you are working.

At least once a year audit and measure your productivity. Think of ways to improve it, so that you can provide the same value in less time, or more value in the same time. A productivity improvement of about 2-5% is expected of you in most jobs. Consider that after a while, the only way that you can improve your productivity if you radically rethink not only your work, but possibly the entire work process in which you participate.

Allow time for learning. When you first start defining the artifacts and committing to timelines, make sure that your commitment timelines include time for learning. Keep in mind that nothing that you do for the first time works as you want it to work (true for all of us). Don’t be too hard on yourself. Give yourself a few months to get better at identifying your clients, identifying their needs, and negotiating the format and timeline of the artifacts. With diligent observation of your performance you will get better and better at delivering your work in a way that others will be able to use and appreciate. In turn, your suppliers will also get you what you need.

In Summary

The essence of knowledge work is the realization that knowledge workers must produce an output by applying their knowledge to the input they receive. The output must be in form of an artifact that some other knowledge workers can consume as their input. Understanding this is both empowering and practical. It will help you get better at what you do.

Start by asking who is relying on you and your output to get their work done. Are they getting what they need? Then figure out what do you need and from whom? You are processing information by applying the knowledge and experience you have to the input you receive. Your output must be in a format that your consumers can effectively consume. You must deliver on a timeframe that they expect so they can deliver on their commitments.

The work processes that tie the members of your team together into a sequence of people who deliver their output to one of their peers creates an information supply chain in your organization. A well thought out and executed information supply chain is a key ingredient of successful teamwork, and in turn key to successful organizations.

Enjoy the journey!

The Essence of Knowledge Work, Part 2

Your information supply chain consists of all artifacts that you consume (produced by your colleagues) and the artifacts that you produce (consumed by your colleagues). You produce your output artifacts by applying knowledge to the input you receive. Your knowledge includes everything you know and the input you receive from all possible sources, too. There are three dimensions to the information needs that each knowledge worker has:

  1. Dependencies (who needs your output and who provides you input)
  2. Information artifacts and their format
  3. Timeline for artifact delivery (time frame)

This is part two of a three part series. Part 1 focused on dependencies. This article focuses on information artifacts and their format.

What do your colleagues need from you? Do you know? Did you ever ask? For a software engineer the quick and obvious answer is that they need code. After all, a software engineer writes software, so that’s what others need. True, and it is not the complete answer. Talk to your colleagues to find out what else do they need.

Based on my past experience working on software teams here are two partial list of output and input artifacts that are expected from a software engineer and what a software engineer expects.

Software engineer outputs (partial list of artifacts)

  • Code
  • Code review comments
  • Test case review comments
  • Use case review comments
  • Design
  • Design review comments
  • Documentation
  • Documentation review comments

Software engineer inputs (partial list of artifacts)

  • Code
  • Code review comments
  • Test cases
  • Defect reports complete with reproduction steps
  • Use cases
  • User stories and epics
  • Design
  • Design review comments
  • Documentation

Your team might be different, so you must ask to find out what the other people need. Negotiate both the content and the format. There is a good chance that you are not giving them what they need now.

What do you need from your colleagues? Think through your work and identify those artifacts that you need to get your work done. There will be some give and take until you arrive at a list and definition of artifacts that can be delivered to you.

The need for artifacts. Artifacts are the work product (the output) of each person on the team. This can take different formats. These artifacts manifest themselves as writings, drawings, sketches, movies, pictures, etc. Not just spoken words. (However, spoken words in an audio file might work. Ask to find out if it does.)

For example, for a tester the artifacts created are: test cases, test execution records, defect reports, process improvement recommendations, etc. For a requirements analyst the primary output artifact could be use cases and user stories written in a Wiki, or maybe in an issue management system, like JIRA.

These artifacts could be deemed high quality if the development team can efficiently and effectively use them. They could be deemed low quality if they are too wordy or are missing critical details. The job of the requirements analyst is to take in information, apply their knowledge and experience to it, and produce artifacts that can be quickly and correctly consumed by the rest of the team.

The same thing can be said about many other roles on the team. Each person (knowledge worker) is part of the team because they can contribute something that the others can’t do, or can only do poorly. However, each person must make their contribution accessible to others on the team. If the others have difficulty consuming it, then the person needs to improve their output.

The consumer of each artifact in addition to consuming it, must also provide feedback to the producer and jointly evaluate the format and the quality of the artifact with the intent of improving it. The producer must evaluate their performance at creating the artifact, factoring in the necessary quality requirements.

Some people you work with will not want to create artifacts. They don’t want to write down anything that you ask from them. You have to help them understand that writing forces them to clarify their thoughts and resolve the inherent contradictions that otherwise would not come to the surface. Remind them the quote:

Writing is nature’s way of letting you know how sloppy your thinking is.

Richard Guindon, cartoonist

The need for creating artifacts does not obviate the need to have high-bandwidth conversations about those very same topics. The goal is to arrive very quickly to an agreement on the content and format of the artifacts, so that each person can effectively create their part of the joint work.

Once you identify how best you can serve your clients, and your suppliers identify how best to provide you what you need, your and your team’s productivity will dramatically improve. You will wonder how did you ever work any other way.

… continue to Part 3: timeline for artifact delivery.

The Essence of Knowledge Work, Part 1

Knowledge workers take in information, process it by applying their knowledge to it, and output information (possibly) in a different format than they received it. This looks like the information processing business.

Input —> Processing (by applying your knowledge) —> Output

Information Supply Chain

This basic formula describes the essential building block of information processing. Applying this model to the individual knowledge worker provides some advantages. Allows us to critically examine each part of the model with the goal of understanding and improving the overall effectiveness of the knowledge worker: mostly when applied to ourselves.

That knowledge workers need to be in command of the information they use and produce has been known for well over 50 years, but very few ask the questions that will put them in charge. According to Peter Drucker:

To produce the information executives1 need for their work, they have to begin with two questions:

  1. What information do I owe to the people with whom I work and on whom I depend? In what form? And in what time frame?
  2. What information do I need myself? From whom? In what form? And in what time frame?

These two questions are closely connected. But they are different. What I owe comes first because it establishes communications. And unless that has been established, there will be no information flow back to the executive. 2

Peter Drucker

There are three dimensions to the information needs as described by Drucker:

  1. Dependencies (who needs your output and who provides you input)
  2. Information artifacts (that you provide and receive) and their format
  3. Timeline for artifact delivery (time frame)

In this part 1 of a three-part series, let’s look at dependencies first and tackle the other two dimensions in subsequent articles.

Understanding your effectiveness starts with the critical examination of your own work. Who is depending on your work to complete their work? These are the people who are (sometimes) repeatedly asking for the slides, spreadsheets, design, unit test, component, or—fill in the blanks—from you. Some of these people will be complainers that you can’t please, but let’s not talk about them now. Here let’s focus on those folks who legitimately need your output.

An insightful way to wrap your mind around this problem is to think of yourself as a “company of one person” or as consultant and author Tom Peters put it: “Me, Inc.” Think of the people expecting your output as your clients. Talk to your clients about their needs and identify what you have to do to fulfill those needs.

The same way, think of the input that you depend on. Identify the people who produce what you need. They are your suppliers. You need to provide them with the proper requirements to get what you need. Most likely you will have to iterate with them on the requirements, since you may not know exactly what you need at the outset of any project. Do not over constrain what they should deliver to you (you don’t like it when your clients do the same to you).

Looking at a concrete example: as a knowledge worker in a software company who do you depend on and who depends on you? For example, if you are a software engineer you work with other software engineers, product managers, business analysts, UI/UX designers, testers, sales people, customers, etc. Some of these people expect things from you, and with others you expect things from them. Identify the people that depend on you and the people that you depend on to get your work done.

Sometimes, especially on very small teams, you might be your own dependency, as in whatever you create now, two weeks or two months later you will be consuming it, too.

At the core, the essence of knowledge work is information processing. You are applying your knowledge to the inputs you receive to produce an output. Crisply identifying the inputs, outputs, and the knowledge required will help you understand what you do, and how can you do it better. In subsequent articles I’ll tackle the other two dimensions.

… continue to Part 2: information artifacts.


  1. These days (in the early 21st century) when you read Peter Drucker writing about executives you can replace it with knowledge workers. 60+ years ago the majority of knowledge workers were executives, however today everybody who deals in information fits the definition.
  2. Drucker, Peter F. (2009-10-13). Management Challenges for the 21st Century (p. 124). HarperCollins. Kindle Edition.