Starting in a Software Development Job

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.

Writing Crystallizes The Thought

Agile Teams often hold the belief that we should not write anything down because that’s waste. From a human perspective though we need to write things down because that’s the mechanism that allows us, or maybe even forces us, to think things through.

Even the Romans knew that “verba volant, scripta manent,” meaning “the spoken words fly away, written words remain.” So maybe the real question is not “Should we write anything down?” but rather “How much should we write down?” The face-to-face interaction should be followed up with the creation of an artifact that captures what the conversation clarified. This will serve as the basis for further decisions or conversations, or maybe assists in the reexamination of this decision when more data becomes available. Interspersing face-to-face conversations with written thoughts firms up ideas and speeds up the road to shared understanding and clarity.

Usually at this point somebody will jump in to say that all that writing is taking time and that writing a 100-page requirement or design document is a waste. Yes, 100 pages might be a waste most of the time. I think that the artifact produced should be a piece of focused and processed information. If it is 100 pages then it should be indeed a very complex issue, or somebody hasn’t done enough thinking about this. But I’ll leave this topic for another day.

This belief in writing things down was confirmed a few weeks ago as I talked to a new co-worker, Steve Feldman, who writes the Seven Seconds blog. He mentioned that he routinely asks his dev teams to blog about their work. The part of the work that is general in nature can be blogged on their outside blogs, while the company and product specific work should be blogged on the inside blogs. The act of writing things down externalizes the person’s thinking and opens up the ideas for a conversation with the rest of the team.

The blog entry with one’s thoughts will generate further conversation, both online and face-to-face. Each conversation should bring the team closer to identifying and solving the problem that they have set out solve.