How I Avoided Becoming the Flavor-of-the-Month Intern


Last year, I had the amazing opportunity to intern at a NASA center. They

were looking for someone with JavaScript experience to update a data

collections tool that had been underutilized because it was not searchable

and had a poor UI. The plan was to rebuild it with a shiny new graph-based

database and to update the frontend to use React. Basically, modernize it

and clean it up.

All this was what my supervisors and their bosses wanted. They lacked the

time to build it, so they had requested me, the intern.

Unfortunately, when I arrived and we started moving on the project, the

technology provider for our department had other ideas. We were told that,

while we were welcome to build the tool with whatever technology stack we

wanted to, they could not support anything other than .NET.

I wanted to make a lasting impact, which meant providing something that

would stick around and improve people's lives for some time. If I forced

them to learn something new, they wouldn't. They just didn't have the time

to do that (that's why they hired me in the first place). If nobody knew

or cared about what I'd created, there would be no reason to support it

anyway. I needed to accomplish three things:

  1. I needed to create something that could be easily integrated into

existing systems and expertise.

  1. I needed to get other people outside our team excited about the project

so that they would want it, and therefore dedicate time and resources

to keeping it around.

  1. I needed to make myself replaceable, so that the software was not

dependent on my presence and could be supported, extended, and used by

anyone, without me around.

Create something easily integrated

The guy in charge of the technology team supporting us told me about all

the past interns who had come in with new technologies and cutting edge

industry ideas, built excellent and shiny tools to solve everyone's

problems, and then gone home, leaving him with a product he couldn't

support. The tool would fall by the wayside and things would go back to

the way that they had been.

I faced a dilemma. I didn't know how to code in C#, much less build an

entire .NET content management system from the ground up, including

everything from user authentication and login up to records customization

and even a comment and notifications system. I didn't even know C# syntax

or conventions!

But if I stuck with JavaScript, I would leave them with a non-solution.

Someone would have to support my app after I went home, and the contractor

NASA had for that team was trained in .NET.

Sure, I could argue that the internet had moved on and they needed to

update their practices, but that attitude was denying the reality of their

restrictions. My priority was to solve a problem, to help the team that

had hired me, not to impress anyone with my JS chops and shiny new

technology. If that meant using a clunky .NET server-side app, that would

be the way to go. I buckled down, found a good .NET Core tutorial, and

spent the first two weeks of my internship teaching myself how to create

a .NET Core web app, using as close to industry best-practices as I could

discern.

I made sure to work closely with the support contractor whenever I found

myself making a decision about something they would need to interact with,

and I tried to anticipate ways that users would expect to be able to

configure the software.

I did the latter as I earned buy in from others outside our office.

Earning Buy In

The tool I was asked to fix was one that everyone was familiar with

because they were required to use it. It was also one that nobody liked

using. The rationale behind the tool was appreciated, and most people

agreed that a skillful execution would be invaluable to them as

individuals and to the center as a whole.

Thus, when I came by asking what they would like to see in such

a renovation, people were excited to talk to me. I asked for specifics

regarding what they would like to do with such a tool and what they wanted

it to do for them.

Then, I built as much of those requests into the design as I could. I even

added "attachement points" in the code for features that weren't in the

core request from my supervisor, but which a lot of the folks

I interviewed seemed to want. These later proved useful because after

I finished the core of the product, I was able to expand it to serve

a whole new set of use cases. I also made it possible to turn on and off

these bells and whistles so that the same software could fill as many

roles as possible.

The other aspect of my conversations with people on center was to get as

many people as I could to feel a sense of ownership of the software I was

building.

Making myself replaceable

I didn't want to be irreplaceable, because I would be leaving and if my

software depended on me being there, it wouldn't last very long. From the

very beginning, I tried to get others invested in the project. If not the

software specifically, then in what we were trying to do as a whole.

I worked to build a team of advocates, partly to have a wide base of

support, but also to distribute the emotional and mental burden of being

an advocate.

At the end of the project, I put a ton of time into documenting not just

the code, but also the ways to configure and use the software. I also

didn't just go off of what I thought needed to be documented and

explained. I would have other people use it and let me know where they got

confused or stuck. Once I helped them out, I would add the explanation to

the README (or sometimes make a change to the software to make it more

intuitive).

I can't say I was as successful in this as the other goals I had for the

project. People at NASA just have a lot on their plates. But I do know

that my replacement has been successful and that many others on center at

least know about what we have built.

Summary: Focus on helping others, from devs to users

All this worked. My internship was extended from 4 months to 12 so that

I had the opportunity to extend the software to ensure it was fully stable

and ready to be deployed into a production environment, with all the

features that had been requested. I also had the chance to extend it into

a more general tool which was deployed by another office for two of their

own projects. My succesor has reported that he has found the code easy to

understand (after a learning/training period) and to support. It's the

biggest thing I've built, and I had the opportunity to really dive into it

thanks to focusing on making it useful and usable for as many people as

I could.

I've even had people tell me explicitly I was the first person to provide

a solution that actually stuck and addressed a problem that had been

plaguing them for years, which several interns had attacked without much

success. I feel like a lot of what enabled me to be successful is the

organizational momentum built up by previous interns, but I was happy to

know I had provided that final push that broke through the barriers

holding back progress.

I hadn't really considered the support team to be users in the past. I had

always sort of figured that they were there to enable whatever tools the

real users wanted to use. But in this case, they held a lot of

decision-making power. That's a lesson I will take with me to my future

projects; even if they didn't have that formal power, they will always

have the ability to drag their feet and increase the friction of an

organization.

And then there is the next team of developers who take over my work. They

will need to find the tool easy to work with or else they might want to

build something themselves (which I'd be okay with except it just costs

the organization time and resources in the long run). So yeah, devs are

users too.

I learned a lot from a technical standpoint on that project, but at the

end of the day, it wasn't really that bad to learn .NET. I already

understood most of the rationale behind the way .NET was set up, since

most JS frameworks and stacks do the same job. I just had to learn some

new paths and syntax. Much more valuable were the human lessons I learned

about focusing on all the users and building something that would be

easy to support, extend, and utilize.

-K