I'm in Lambda School. 2 weeks ago I 'graduated' to the Lambda Labs where you work in a team on an 8 week project. The design and planning phase ended today and we transitioned into principle coding.
Today was the 2nd of 2 presentations of our plan showing Release Canvases (milestones, basically). I led the presentation with a teammate.
It was off the chain.
We showed the paperwork they wanted filled out. It was OK paperwork, but seemed to be missing a component between the generalities that they wanted us to describe and File > New of starting the project.
In the past, my planning phase of personal projects was to create a Design Document, in outline form, where I go into detail on the parts of the app that need to be created. For example, I'll put "User Onboarding" as a top level item, and then underneath that break it out into Registration and Login. Then underneath that, detail say Login with "Email field". Then again underneath that put what field validation library I'll use . . . stuff like that. That's just a single tree example of how the entire outline in the Design Doc would be laid out. No code, but generally getting down into the middle details. Sometimes, if a detail sounds tricky I may get into pseudo code, but not often.
We did that kind of doc as a team. We called it "Scope of Engineering -
Technical Specifications and Design", and detailed the 3 progressive milestones/Release Canvases, with a 4th, super general, wishlist milestone.
The project heads loved the plan. They had zero questions (IMO the true mark of completion), advised on how to avoid feature creep, and sent us on our way.
It felt great, especially since I was about 12% unsure of what exactly they wanted in the presentation.
// , “It is not so important to be serious as it is to be serious about the important things. The monkey wears an expression of seriousness... but the monkey is serious because he itches."(No/No)
My latest Lambda School post
I'm in Lambda School. 2 weeks ago I 'graduated' to the Lambda Labs where you work in a team on an 8 week project. The design and planning phase ended today and we transitioned into principle coding.
Today was the 2nd of 2 presentations of our plan showing Release Canvases (milestones, basically). I led the presentation with a teammate.
It was off the chain.
We showed the paperwork they wanted filled out. It was OK paperwork, but seemed to be missing a component between the generalities that they wanted us to describe and File > New of starting the project.
In the past, my planning phase of personal projects was to create a Design Document, in outline form, where I go into detail on the parts of the app that need to be created. For example, I'll put "User Onboarding" as a top level item, and then underneath that break it out into Registration and Login. Then underneath that, detail say Login with "Email field". Then again underneath that put what field validation library I'll use . . . stuff like that. That's just a single tree example of how the entire outline in the Design Doc would be laid out. No code, but generally getting down into the middle details. Sometimes, if a detail sounds tricky I may get into pseudo code, but not often.
We did that kind of doc as a team. We called it "Scope of Engineering -
Technical Specifications and Design", and detailed the 3 progressive milestones/Release Canvases, with a 4th, super general, wishlist milestone.
The project heads loved the plan. They had zero questions (IMO the true mark of completion), advised on how to avoid feature creep, and sent us on our way.
It felt great, especially since I was about 12% unsure of what exactly they wanted in the presentation.
In my experience this is not the case with real customers, but I'm impressed. Design docs are handy tools for thinking.