I won’t pontificate on the “right way” to involve juniors because I don’t know. However, I have three observations about work that tends to be a good fit for juniors, and some ideas on how to identify such work.

What makes great work for juniors?

1. Meaningful for the team

I tend to get more done and do better work when I’m motivated. If I’m not motivated, well… the opposite is true. Interestingly, this also seems to be the case for other people! So, a motivated team is probably a good idea.

But what causes motivation? I’ve noticed that understanding the importance of a problem tends to make it more exciting. If your team understands the “so what”—i.e., why solving the problem will have a positive impact—your team will do faster and better work.

Even if the impact will be far in the future, having some purpose-based “north star” to steer towards clarifies the direction and importance of what you’re doing.

2. Clear starting point

The easiest place to get stuck is going from zero to something. With a blank canvas, where do you paint the first stroke? With a blank page, what is the first word you write? It’s intimidating!

A solid anchor makes taking the first step easier. Whether it’s an outline of some ideas, a sketch of an architecture, or list of places to look for information, having something to start from makes it easier to hit the ground running and avoid stalling out at nothing.

This doesn’t mean everything must be clear and well-defined, and it certainly doesn’t mean the anchor is an immovable basis for everything else—quite the opposite! Flexibility in where to go is what makes problem-solving exciting, and the process of solving a problem will almost always reveal better ways to frame and approach it.

3. Not on the critical path

Letting down your team is a rough feeling. If your work is the one thing standing between success and failure for the team, it produces an uncomfortable looming feeling of dread (at least for me). What if I don’t do a good enough job? What if I delay the project by working slower than I should? What if I can’t complete the work? It’s stressful to work on stuff that causes big problems if it goes sideways!

There’s also the practical matter that anyone new to a team (of any experience level) will need time to acclimate to the team’s sense of taste. Whether it’s design, writing, analysis, or anything else, each team makes different subjective calls on their voice and style. So, work that requires alignment with the team’s sense of taste is generally hard to get right as a newer member.

How to identify great work for juniors?

Unfortunately, it’s hard to find work that fits within these constraints. Work that is meaningful to the team is often on the critical path, and clearly defining any work is challenging. But it’s not impossible!

Where to look

Work that has patterns — creative pattern-based work provides a historical bank of great examples that form an instruction manual without over-constraining the result. Things like blog posts, demo datasets, and sample projects provide a good mix of clarity and creative freedom.

Improved information and tooling — improving tools used by the team is impactful and clear. This may include technical work, like automating a manual process or building new instrumentation to take better measurements, but it may also include organizational work, like building a sitemap of resources used by the team or consolidating knowledge that’s scattered in various places.

Groundwork for new directions — as outsiders, juniors provide a valuable source of inspiration. They have fresh ideas for how to tackle hard problems, and provide a unique perspective that others on the team can’t offer. This could mean building a proof of concept using a new technology, writing a proposal for a new initiative, or otherwise looking in new directions for the team.

How to curate ideas

Deciding what to do should never be a scramble—especially for a junior. The first work done by a junior will shape their perception of the team, and that perception will impact how they think and work for years to come. A great project sets the stage for a career of positive contributions—and a poorly-thought-out project wrecks it.

So, make sure you are ready to welcome a junior with great projects on day one! Consider adding a “good intro project” tag to your issue tracker, making a channel in your chat system where folks post ideas, or starting a document (perhaps a spreadsheet or wiki page) with a list. Make sure you have a good place to capture intro project ideas when they pop into mind, and actually use it.

Along with the project ideas, write brief phrases about why the work is meaningful and where to start. This will naturally help refine and organize possibilities so that you are ready to pair up your team’s next junior with a great project.

Pairing people with work

A good project for one person could be a terrible project for another. I like to frame the problem as pairing people and projects, rather than assigning work to people (or people to a project). Assign implies a one-directional mandate without feedback, while pairing implies a mutually positive outcome.

As an aside—you can fire ideas that are underperforming. In the process of doing work, it’s natural to discover the work is not worth doing because it’s no longer relevant or will take too much effort. Switching projects is allowed. Ideas don’t have feelings and can be re-hired at a later time. But it’s a lot harder to re-hire a person.

One way to improve the quality of the pairing process is giving people agency in selecting their work. Consider making a shortlist of top ideas, with the final decision in the hands of the person doing the work. A passionate team that’s enthusiastic about doing good work will accomplish great things.

Of course, no advice is universal—but perhaps some of these thoughts are helpful.

What do you think? Did I miss anything? I’d love to hear your perspective!

Alnis

We learned some important lessons:

1. Integrating late = integrating poorly

2. Simple deployability is simply necessary

3. Maintainability is mandatory

4. Shipping is pain

Based on these lessons, we’re doing a number of things differently, detailed below.

1. Integrating late = integrating poorly

Integration is hard in any project, but doing it late makes it even harder.

The COVID-19 pandemic threw wrenches into our in-person R&D work, and delayed integration. As a result, we discovered many integration issues too late to make the necessary overhauls, hindering our ROV’s performance.

For example, our manipulator stuck out of the bottom of the ROV, so we could only set the ROV down on foam blocks (not on the floor by itself). This made servicing the ROV much more challenging than it should have been — and an expensive, teetering robot next to water is never a good idea!

Other integration issues included parts of the robot blocking camera views, thruster exhaust getting blocked by wiring, the tether getting tangled on the frame and thrusters, and reliance on zip-tied floats to try to balance the ROV.

What we’re doing differently:

• Keep our CAD model up to date with excruciating detail (down to the screw!). This lets you…

  • Integrate virtually, earlier, and effectively for free!

  • Verify fastener access, camera fields of view, etc.

  • Measure center of mass and center of buoyancy, and keep them close

• Work cross-functionally over subsystems

  • Rotate people between different subsystems of the ROV

  • Keep the whole team in the loop about the status of the entire ROV

• Add design requirements to catch integration pitfalls

  • “The ROV must be easy to set down”

  • “The ROV’s tether must not interfere with water from thrusters”

2. Simple deployability is simply necessary

Nautilus was challenging to get somewhere and deploy.

It wasn’t just that the ROV couldn’t be set down on the ground by itself — all of the support equipment was challenging to wrangle, too. Every deployment required reassembling the equipment from loose wires, boxes, peripherals, and a laptop.

Setting up the surface station included stacking electronics on a box, routing around cables and plugging everything together, screwing in fiddly connectors, and generally dealing with a rat’s nest of wires. Needless to say, this is not good next to water, nor is it good in a time-constrained competition environment, never mind both!

Other setup issues included a lack of good tether management, complicated software startup procedures, and a lack of strain relief on connections between surface-side components.

What we’re doing differently:

• Explicitly consider deployability as a design problem (not just operations)

• Consolidate surface station into a single, “grab’n’go” object

  • Limit setup activities to clips & plugs (no screwing, cable routing, or assembly)

• Automate software startup as much as possible

  • Clearly document and communicate startup steps that are not automated

• Establish effective tether management

  • Develop protocols and/or hardware and test them!

3. Maintainability is mandatory

You will need to access components for debugging, repairs, and replacements. Robots will break parts, and you will need to service them.

One issue we encountered was a long “critical path” of which components need to be taken off to access something. For example, our pressure hull was held together lengthwise by threaded rods, and these also served to mount the hull to the frame. Seems neat, right? Fewer parts?

Well, it made working on electronics in the housing painful. You could only open & close the housing while carefully juggling wrenches from both ends, while the ROV balances on blocks, all while trying to avoid pinching O-rings.

This wasn’t helped by the hard-to-constrain spaghetti wiring inside the electronics bay which always managed to stick itself into the O-ring seals on the end cap.

What we’re doing differently:

• Standardized fasteners & connectors

  • An upcoming post will describe our choices & justifications for every fastener and connector we use. It won’t be a long post!

• Simplification of electronics to use less wiring & fewer components

• Upgrade O-ring design practices

  • Use largest O-rings possible to minimize pinch & leak risk

  • Follow manufacturer recommendations & standards for O-ring grooves

  • Discontinue use of face seals in favor of radial seals to avoid need for lengthwise clamping of pressure hull

• Monitor assembly & maintenance feasibility in integrated CAD model

  • Can tools actually access all fasteners?

4. Shipping is pain

The ROV will arrive disassembled, regardless of whether you pack it assembled or disassembled. At least, if you use ground shipping and insufficient packaging.

It was not fun discovering this a couple hours before safety inspections when we first had the chance to open up the crate and take a look.

A thruster was broken off of the frame…
…Just about every screw was loose or missing…
…and our electronics bay was a complete mess.

I still don’t know how we managed to get it to pass safety inspections, given how we only had a couple hours, hand tools, and no scrap material for emergency fabrication… but that is a story for another day!

What we’re doing differently:

• Disassemble the ROV before shipping

• Bring critical components as carry-ons on the flight to ensure their safety

• Bring a 200% quantity of 3D printed parts, electronics, and any other components that could become damaged

• Use hard cases & assume any orientation may be achieved during shipping (instead of crates and being optimistic about “this side up”)

5. Bonus lessons

Some other problems we ran into, in no particular order:

• Wires and connectors have drag underwater.
  Keep them tidy!

• Are you sure you’re running those cables at safe currents?
  Check that you’re using an appropriate gauge for wires, especially the tether!

• Strain relief for cables can’t be slapdash.
  Use a proper solution like a wire mesh grip, not string/tape/glue/zip ties.

• Tether cables need to be held together to avoid tangles.
  Use a mesh cable sleeve or some other non-zip-tie-method to hold it together.

Closing thoughts

We learned a lot by building Nautilus.

We took these lessons to heart when building Barreleye, our ROV for the 2022 season. We started with a clean sheet design, came up with something awesome, and smashed all of our team’s performance records while having a ton of fun.

In an upcoming blog, I’ll discuss how we applied these lessons in our upgraded engineering process to build Barreleye, and I think you’ll find it interesting.

Let me know if you have any questions or feedback!

Alnis
UWROV CTO
contact@alnis.dev