Take any veteran software developer to lunch and they’ll tell you story after story of the things they wish they’d known when they started. And they can fill a second lunch of conversation with things they see new developers on their team doing that are only going to lead to pain later.

A Message to Rookies

A few things we think you should know:

You are awesome: Very few people have the opportunity to send their code across the solar system. Yes, you’re going to work hard to claim that privilege because there’s a lot to know. But you should believe in yourself and your potential because, frankly, to make it this far says a lot about your quality.

You don’t know what you don’t know: Your future self three years from now will laugh at how little you know today. And the version six years from now will be laughing at both of you. And so on. Get comfortable with having a growth mentality and you’ll do great.

Learn from the misery of others: We implore you (and your future self implores you) not to look at frameworks, requirements, testing, and whatever else looks like “a lot of work” and think you don’t need it. Or that you’re going to “write your own from scratch” because “it’ll be easier”. Nobody wakes up thinking, “How can I slow everyone down today?” All those things that “add work” exist because people suffered greatly without them.

Invest in yourself: Experienced flight and ground software developers can make big money in stable, rewarding careers. Achieving those things means things like reading one more manual, diving a bit deeper into the code, and/or getting involved in the community.

Create the Team Framework

People who have suffered through poorly run teams can point to bad decisions made early in the program that haunted the team through the whole project. Here are some things you should fully understand and document before you jump into development. There are five steps:

1. List your goals and motivations

2. Figure out how you’ll make decisions

3. Understand what success looks like

4. Document the tasks are optional when you have extra time

5. Agree to things that will not be done, no matter how much time you have

What’s your Motivation?

When the seas get rough (and they will) everyone needs to understand where the lighthouses are and keep navigating towards them. Sit down with your team and make sure the goals of the project are well documented so you know where you’re going.

Example goals:

• Build trust with our customers

• Create flight software that we can use for multiple missions

• Have documentation that actually helps people

• Make it easy for new users to learn how to control the spacecraft

Note that goals are not “success criteria” or “finish lines” but the guiding light keeping your team on track. They’re usually not things where you can easily say “I’m done”; there’s always more you could do. But they do help you to focus on what really matters. 

Goals are especially helpful at limiting extra work people suggest. If your goal is to “Make delicious sandwiches” and halfway through the hard work your team is thinking about “Making a better bicycle” because it would be fun or interesting or easier, you can point back at the goals and say “no, that’s not what we agreed to.”

How will you make decisions?

Agree on the metrics you’ll weigh decisions with. This one step can save you many (many) hours of pointless meetings.

Here’s an example table of metrics with weights ranging from 1 to 5, with five being the most important:

One of the first meetings you should have as a team is deciding what metrics you care about and the weights they should have. Don’t just list every metric you can think of, though; try to have no more than five to ten key things.

How will you know you’re done?

Many people have a vague vision of what success looks like and they dive into work with excitement for the future. But then they find that the problem is more difficult than expected. They could work for years making the “perfect” solution. But that’s often not needed!

Agree on what success looks like. And don’t use fuzzy ideas like, “Everything works” or “We have zero bugs”. Get specific with things like, “Full compliance with the CCSDS EDS specification” or “The telemetry packets are implemented according to the specification agreed to by program management”.

A common way to do this is to have a requirements review prior to serious development. The requirements can come from many sources so you want a clean, easy-to-interpret set that organizes things in one place. As part of the requirements review, you want to state both the requirement and how you’ll verify that your software will meet it. Will it be unit testing? Demonstration of a mechanism moving? Analysis of the memory usage? 

For some, this may be less fun than just coding but don’t think you can skip it. New developers only ignore this step once. The weeks and months of pain from wishing everyone agreed on things in the beginning is too strong of a lesson to learn twice.

What would be awesome but optional?

Get very specific about this. New teams have lots of great ideas that might make things better but they aren’t strictly necessary. Get all the ideas documented and then decide if they’re required or optional. (Use the goals and metrics above to help you decide.)

You might even rank the optional ideas so, when you do have time, you know which ones get implemented first.

What won’t you do?

This step is easy to overlook! Help prevent misunderstandings later by clearly documenting what you won’t do. This may be surprisingly painful since people may have their favorite ideas and they don’t want to let go of them. Have the tough conversations now, though, about things that just aren’t going to get implemented in this project.