Return to Answer

If you are assigned a task that has no design done for you then doing the design is part of your task.

This is not unusual. Design may have been done at some level but now the task needs it's own design.

Now please don’t take this as license to spend weeks alone doodling UML. You should create enough design so that you can see and communicate your plan. Nothing more.

You should also be prepared for the plan to fall apart. When you code and test you learn. Don’t rob yourself of that time to learn by making perfect diagrams no one asked for.

Done well, a design ensures you're pointed in the right direction before you put tons of effort into something no one wants. It's a check on how well you understood your task. Don't defeat this by putting too much effort into the design. Do just enough to show your thinking.

You know the design process is working when you’re discovering mistakes, disproving assumptions, and discovering work. If all you’re doing is making pretty pictures it’s time to move on.

A great way to do that is to show your design to the team. Communicate well and they’ll help you find mistakes, bad assumptions, and hidden work. Listen, learn, and when needed, try again. It’s like making popcorn. When the popping stops it’s time to move on.

Presenting a design can involve the whole team but devising one is usually one or two people working on some small bit of territory that’s been carved out for them. Be sure to learn how to communicate with the other territories and you’ll find you don’t need the whole team for every detail.

Design is important regardless of the task or the teams development methodology. Even in agile. Even in chaos. It may be a screen mockup. It may be pseudo code. It may be stating your task in your own words. But, like every other development step, it must be useful, or it’s a waste of time.

If you are assigned a task that has no design done for you then doing the design is part of your task.

This is not unusual. Design may have been done at some level but now the task needs it's own design.

Now please don’t take this as license to spend weeks alone doodling UML. You should create enough design so that you can see and communicate your plan. Nothing more.

You should also be prepared for the plan to fall apart. When you code and test you learn. Don’t rob yourself of that time to learn by making perfect diagrams no one asked for.

Done well, a design ensures you're pointed in the right direction before you put tons of effort into something no one wants. It's a check on how well you understood your task. Don't defeat this by putting too much effort into the design. Do just enough to show your thinking.

You know the design process is working when you’re discovering mistakes, disproving assumptions, and discovering work. If all you’re doing is making pretty pictures then it’s time to move on.

A great way to do that is to show your design to the team. Communicate well and they’ll help you find mistakes, bad assumptions, and hidden work. Listen, learn, and when needed, try again. It’s like making popcorn. When the popping stops it’s time to move on.

Presenting a design can involve the whole team but devising one is usually one or two people working on some small bit of territory that’s been carved out for them. Be sure to learn how to communicate with the other territories and you’ll find you don’t need the whole team for every detail.

Design is important regardless of the task or the teams development methodology. Even in agile. Even in chaos. It may be a screen mockup. It may be pseudo code. It may be stating your task in your own words. But, like every other development step, it must be useful, or it’s a waste of time.

If you are assigned a task that has no design done for you then doing the design is part of your task.

This is not unusual. Design may have been done at some level but now the task needs it's own design.

Now please don’t take this as license to spend weeks alone doodling UML. You should create enough design so that you can see and communicate your plan. Nothing more.

You should also be prepared for the plan to fall apart. When you code and test you learn. Don’t rob yourself of that time to learn by making perfect diagrams no one asked for.

Done well, a design ensures you're pointed in the right direction before you put tons of effort into something no one wants. It's a check on how well you understood your task. Don't defeat this by putting too much effort into the design. Do just enough to show your thinking.

You know the design process is working when you’re discovering mistakes, disproving assumptions, and discovering work. If all you’re doing is making pretty pictures it’s time to move on.

A great way to do that is to show your design to the team. Communicate well and they’ll help you find mistakes, bad assumptions, and hidden work. Listen, learn, and when needed, try again. It’s like making popcorn. When the popping stops it’s time to move on.

Presenting a design can involve the whole team but devising one is usually one or two people working on some small bit of territory that’s been carved out for them. Be sure to learn how to communicate with the other territories and you’ll find you don’t need the whole team for every detail.

Design is important regardless of the task or the teams development methodology. Even in agile. Even in chaos. It may be a screen mockup. It may be pseudo code. It may be stating your task in your own words. But, like every other development step, it must be useful or it’s a waste of time.

If you are assigned a task that has no design done for you then doing the design is part of your task.

This is not unusual. Design may have been done at some level but now the task needs it's own design.

Now please don’t take this as license to spend weeks alone doodling UML. You should create enough design so that you can see and communicate your plan. Nothing more.

You should also be prepared for the plan to fall apart. When you code and test you learn. Don’t rob yourself of that time to learn by making perfect diagrams no one asked for.

Done well, a design ensures you're pointed in the right direction before you put tons of effort into something no one wants. It's a check on how well you understood your task. Don't defeat this by putting too much effort into the design. Do just enough to show your thinking.

You know the design process is working when you’re discovering mistakes, disproving assumptions, and discovering work. If all you’re doing is making pretty pictures it’s time to move on.

A great way to do that is to show your design to the team. Communicate well and they’ll help you find mistakes, bad assumptions, and hidden work. Listen, learn, and when needed, try again. It’s like making popcorn. When the popping stops it’s time to move on.

Presenting a design can involve the whole team but devising one is usually one or two people working on some small bit of territory that’s been carved out for them. Be sure to learn how to communicate with the other territories and you’ll find you don’t need the whole team for every detail.

Design is important regardless of the task or the teams development methodology. Even in agile. Even in chaos. It may be a screen mockup. It may be pseudo code. It may be stating your task in your own words. But, like every other development step, it must be useful, or it’s a waste of time.

If you are assigned a task that has no design done for you then doing the design is part of your task.

This is not unusual. Design may have been done at some level but now the task needs it's own design.

Now please don’t take this as license to spend weeks alone doodling UML. You should create enough design so that you can see and communicate your plan. Nothing more.

You should also be prepared for the plan to fall apart. When you code and test you learn. Don’t rob yourself of that time to learn by making perfect diagrams no one asked for.

Done well, a design ensures you're pointed in the right direction before you put tons of effort into something no one wants. It's a check on how well you understood your task. Don't defeat this by putting too much effort into the design. Do just enough to show your thinking.

You know the design process is working when you’re discovering mistakes, disproving assumptions, and discovering work. If all you’re doing is making pretty pictures it’s time to move on.

A great way to do that is to show your design to the team. Communicate well and they’ll help you find mistakes, bad assumptions, and hidden work. Listen, learn, and when needed, try again. It’s like making popcorn. When the popping stops it’s time to move on.

Presenting a design can involve the whole team but devising one is usually one or two people working on some small bit or territory that’s been carved out for them. Be sure to learn how to communicate with the other territories and you’ll find you don’t need the whole team for every detail.

Design is important regardless of the task or the teams development methodology. Even in agile. Even in chaos. It may be a screen mockup. It may be pseudo code. It may be stating your task in your own words. But, like every other development step, it must be useful or it’s a waste of time.

If you are assigned a task that has no design done for you then doing the design is part of your task.

This is not unusual. Design may have been done at some level but now the task needs it's own design.

Now please don’t take this as license to spend weeks alone doodling UML. You should create enough design so that you can see and communicate your plan. Nothing more.

You should also be prepared for the plan to fall apart. When you code and test you learn. Don’t rob yourself of that time to learn by making perfect diagrams no one asked for.

Done well, a design ensures you're pointed in the right direction before you put tons of effort into something no one wants. It's a check on how well you understood your task. Don't defeat this by putting too much effort into the design. Do just enough to show your thinking.

You know the design process is working when you’re discovering mistakes, disproving assumptions, and discovering work. If all you’re doing is making pretty pictures it’s time to move on.

A great way to do that is to show your design to the team. Communicate well and they’ll help you find mistakes, bad assumptions, and hidden work. Listen, learn, and when needed, try again. It’s like making popcorn. When the popping stops it’s time to move on.

Presenting a design can involve the whole team but devising one is usually one or two people working on some small bit of territory that’s been carved out for them. Be sure to learn how to communicate with the other territories and you’ll find you don’t need the whole team for every detail.

Design is important regardless of the task or the teams development methodology. Even in agile. Even in chaos. It may be a screen mockup. It may be pseudo code. It may be stating your task in your own words. But, like every other development step, it must be useful or it’s a waste of time.