Engineering Preflight Checklist
Key questions for getting started on the right foot and in the right direction
Before I start, I need to give credit to Morgan J. Lopes for giving our team this presentation and taking the pain out of starting a new development project.
I’m going into my 3rd month as a junior software engineer at Polar Notion and one thing that I’m glad I’ve learned early on was the importance of planning. Making sure everyone is on the same page before you start can’t be stressed enough. But if you’re new to the software development world, chances are you don’t know what questions to ask to get clarity. Here is a list of questions I’d recommend you try getting answered before you start any project.
What does DONE look like?
Make sure that everyone on the project is on the same page with regards to what the final project needs to look like. A great way to check this is by going over the user stories. If you’re new to SCRUM and are not sure what user stories are, here is a great article to get you up to speed — https://resources.collab.net/agile-101/what-is-scrum.
What are the Roles and Requirements?
Who owns the final PR (pull request) review?
Make sure you know who is responsible for checking all code that gets pushed. For smaller teams this is easy to find out, it’s normally the senior developer on the team but on bigger projects that may not be as simple. Make sure you’re never in a situation where you’ve sent a pull request to the wrong person and are waiting unnecessarily for your code to be reviewed.
Who merges PR and who deploys to staging?
In most cases, this will be the same person as the person that is reviewing your code but not all the time. If you are working in a big team, make sure you are clear as to who this person is if it’s not your lead developer.
How often is staging pushed?
Will you need to be showing your client regular updates or will they only be expecting updates at the end of the sprint?
When is the internal demo?
At Polar Notion, we always have an internal demo before a client demo, usually with a few days between to make any changes if needed. Plan to have your project ready to demo internally at least a day before the actual internal demo date.
What are the Languages and Libraries?
What language and markup, gems, libraries, and third-party integrations will be used?
Make sure you have this conversation with your team AND the client before you start any work. Don’t assume that everyone in the team agrees on this or is comfortable working with a given technology. This also needs to be documented and signed by all parties.
Which past projects are similar?
Check if there are projects that you or the team have worked on in the past that are similar. This is gold! I’ve just started working for Polar Notion and I’m already pulling bits of code from previous projects.
How complex are the objectives?
What is the Crux?
This seems like a given but are you sure that you know what the most important function of the app is? Spending time getting everyone on the same page with this is going to save your hours of frustration further down the road.
What needs more clarity?
Are there details of the project that are unclear? And if there are, what sort of impact are they likely to have on the way you design and build the project?
What is your confidence level of the task?
This one is especially important if you’re new to software development. I’m lucky enough to work at a company that encourages growth. They have a great apprentice program and it’s very common for people at various skill levels to be working on the same project. Being upfront about your skill level will help the rest of your team foresee any “speed bumps” and you’ll gain their respect.
Is there a clearly defined System Architecture?
What is the database schema?
Planning out what your database schema is going to look like is one of those things that can be changed if needed, but having a clear understanding of the planned database will help you in understanding how the app is going to work.
What are the routes?
Make sure you understand the flow and site map of the project. Most projects will already have some sort of site map attached to the designs but if not, create one and get everyone to agree to the basic functionality. There are a lot of free resources online. I like to use https://bubbl.us.
What is the right order of events?
Another important point to remember when writing software is getting things done in the correct order. Imagine if you vacuum your house BEFORE you dust the ceiling fans. You’d have to vacuum again. Engineering follows a similar logic. If you built in the right order, you shouldn’t have to touch things multiple times.
Which migrations do I need?
Migrations are a change to the database. You should have a clear idea of how you’re changing the database before you start. It’s not going to be perfect, but altering the database structure can have lasting implications — if you dump data, it’s often gone forever.
How does this work with everyone’s schedule?
As a developer, this may be one of those things that may be out of your control but still something to try being mindful off, especially when you work with a team that often works remotely. Check everyone’s schedules and try to start a sprint when everyone is in the office. At Polar Notion, we start sprints on Wednesdays so everyone tries to schedule remote work or time off around that.
I’m new to the development game and these articles are meant as a guide and observations I’ve made over the last few months working as a junior software engineer. I enjoy getting feedback from more seasoned developers so please free to make comments or suggestions.
Become passionate about what you do and everything else will follow.
