From the words of wisdom department:

Ten years ago I was working as a software engineer for a small company in Los Angeles. (The company was located on Pacific Avenue in Venice but that’s another story.)

Jerry was the company’s Vice President and I had great respect for him at the time. He understood that software development is a nonlinear open-ended creative process. He would often say “Know what you know and know what you don’t know.” In a former career he was an attorney with the Department of Justice and I can see the same advice being applied to preparing for a trial.

In the context of software development his adage has, for me, become shorthand for a number of related ideas that I have internalized:

Be well prepared. Read the RFP and the business requirements. Listen to the customer. Ask lots of questions.

Test assumptions. Verify what you think you understand. For example clarify that different parties are not using the same words for different concepts.

Get the lay of the land. Get a feel for the feature set and how the project will sub-divide into tasks and how the tasks will fit together.

Look for problems early. Turn over as many rocks as you can as early as you can. Look for issues in the requirements and specifications. Experiment with any required but unfamiliar APIs and libraries. Look for the stuff that can bust your schedule.

Give yourself permission not to know. In the short term knowing what is unknown is more important than solving the unknown.

Understand where your risks are and manage the risk. The unknown can harbor a lot of potential risk. Where on your evolving mental map of the project do you note “here be monsters?”

Build research into the project plan. Create project tasks that are to write test programs or prototypes for issues that are deemed difficult or just poorly understood.

Tackle the unknowns and the hard problems first. Front load the project plan with the tasks that have the greatest chance of going wrong. Every project will have unexpected setbacks. Wouldn’t it be great to have all the setbacks up front and have the project get easier as you race to the finish?

Understand that the process is iterative. You may recognize most of these points as design activities. Design doesn’t stop when coding begins.

More from the words of wisdom department:
constructive nonconformist: Get Off The Critical Path