In fact, the problem has gotten so serious that the top admiral of fleet operations ordered a temporary halt of all Navy operations in the area where these tragic incidents occurred, until he felt confident enough that there were no other immediate and imminent dangers to current fleet operations.
The article goes into depth as to possible causes that have contributed to the alarming rate of at which the Navy has been losing lives and significant damage to their fleet.
It doesn’t boil down to one certain thing, but to several factors.
- Lack of core operational skills
- Lack of training
- Lack of experience
- Too much reliance on technology
- Lack of transparency
- Lack of ownership
But on second thought, as I finished the article, these factors did seem to share a parent root cause…
A Mentorship Vacuum
The article’s primary thesis is that many of the officers and enlisted responsible for key duties on the ship — including the very important skill of navigating ships safely through crowded shipping lanes on the high seas — are lacking basic seamanship skills
It all seems to stem from the Navy’s decision to cut back on the time and money investment in hands-on training and mentorship of junior-level seaman by more experienced sailors.
It appears that the Navy has eschewed mentorship of junior sailors by senior members, in favor of the new “read this documentation, good luck, you’re on your own” training program.
I think the author made a very compelling argument, based on my own experience learning the ropes as a software engineer.
The author makes the argument that the loss of the act of mentorship and hands-on training, has left the Navy in a condition that has contributed to a tragic loss of lives and millions of dollars of devastating damage to the Navy’s fleet of active duty ships.
I find his arguments very compelling.
It makes me remember my early days of my software programming career.
The Value of Mentorship in Programming
I landed my first programming job, almost by accident. I was always interested in technology, since the very first generation of personal computers came out in the early 1980s. I still pine for those early days, hacking on those primitive 8-bit home computers like the Tandy TRS-80, Apple IIe and Commodore 64 (my personal favorite).
I thought I was going to end up studying computer science in college but it didn’t turn out the way I expected.
Yet that technology bug stayed with me, to this day.
In Norman MacLean’s famous story “A River Runs Through It”, he says he is “haunted by waters”.
I am haunted by technology. I keep coming back to it, and I eventually ended up programming computers for a living, though in a roundabout way.
I was lucky enough to land my first entry-level job, having come from a technical support help desk position. It was actually a very good place to build up my foundation of computer software and hardware skills.
But I was still way in over my head. I was dropped into the deep end of the swimming pool and expected to swim.
It didn’t take long in my new position as junior programmer, to realize I wasn’t going to be able to succeed in my job without help. In fact, I recall being in a sort of panic, with actual thoughts about quitting and going back to my original tech support job.
But my manager at the time assigned me to a senior developer from my team, and asked him to act as my mentor.
I have both my first manager and my mentor to thank for my continued success and lifelong career as a software programmer (thanks, guys!).
My mentor shadowed me as I worked on my first assignments and projects. He showed me best practices of programming, the value of loosely coupled code. Of the “KISS” principle (Keep It Simple Stupid!), which is still one of the most powerful and relevant design principles of software design to this day.
As much as technology, programming languages, frameworks and development tools have improved over the years, we software engineers still make lots of mistakes. We forget golden principles like KISS, which result in great messes of code that are hard to comprehend and more importantly, hard to change … not a good recipe for success.
He was there to answer all of my questions, no matter how silly they sounded. I made every programming mistake possible.
My first applications were embarrassingly bad. I didn’t understand the concept of modularity and the importance of separation of concerns. I basically was programming by the seat of my pants.
And it showed. My programs had TONS of bugs.
Even worse, I often ended up with deliverables that didn’t do what the business customer had requested from us.
I didn’t know how to analyze project requirements.
My mentor knew better. He had the years of experience under his belt to know better. But instead of just TELLING me the way to do things, he helped me realize my own mistakes. And he led from the front. He showed me the way he designed applications. The way he tackled gathering project requirements.
There’s a big difference between knowledge gained from a book, and first-hand knowledge imparted by someone more experienced and knowledgeable than you.
Knowledge gained from a book is “happy path” type knowledge. It’s usually structured in a way that teaches you how to do things in the proper way.
What it doesn’t usually do, is talk about the WRONG way to do things. Or what to do when things go wrong.
Which is what inevitably happens.
To this day, I always encounter unknowns, when tackling new project assignments. Or gaps in my technical knowledge that impede my progress on the project … but my mentor taught me how to cope with that. Above all, he taught me not to panic and the value of methodical testing and research.
Sure, I continued making lots rookie mistakes as a junior programmer. But I can confidently say my journey from junior to senior programmer would have taken much much longer, had I not had a senior mentor showing me the ropes along the way.
Sadly, many organizations don’t value the practice of mentorship. It simply takes too much time, resources and money to invest in people to actively mentor junior level software engineers.
This mentorship gap in organizations will continue to be a serious problem. The author of the article about the lack of mentorship in today’s Navy certainly thinks so, and so do I.
Could Luke Skywalker have become the master Jedi he became, without the help of his mentors, Obi-Wan Kenobi and Yoda?
Somehow, I doubt it.
