Internal Tools Are The Worst
One of the first pieces of career advice I received when looking for an internship in software development was to never, ever take an internship where the project is for internal use only. The conventional wisdom on this is so strong that companies often tout the lack of internal projects as a highlight of their internship program. “Do work that matters!” they say. “Our interns never work on internal tools like at those other companies.”
Four years later, I’ve had four different software internships with four different project types. Two of them have been on internal tools, both coincidentally at Nebraska Global. The first was for Don’t Panic Labs, the summer after I learned to avoid working on internal tools at all costs. This led to my next great insight: sometimes conventional wisdom is flat-out wrong. Culture can make all the difference, no matter what type of project you’re working on.
Working on a project management tool for Don’t Panic Labs was a great experience not only because of the great mentors who taught me the foundations of software engineering, but also because my team developed a product that our users desperately wanted. Our humble team of interns had our first production release one month after we started – a little over a month after the first time I ever even heard of ASP.NET. For the next two months, we had real people using our product and giving us feedback. Though we did our best to ensure quality, having our users as fellow employees instead of paying customers took the pressure off of us and our managers. We had the freedom to be flexible, take risks, and make mistakes. It was a fantastic learning environment.
Nearly three years later, I’m back at Nebraska Global working on more internal tools. This time I’m an intern at Ocuvera, where I work on tools for the video tagging team and the mathematicians that develop our computer vision algorithms. Popular wisdom says I should be miserable.
Instead, I love going to work each day. I know my work matters, and will be used almost as soon as it’s deployed – if not sooner. When there’s a bug, I hear about it right away. The features I’ve worked on may never be seen by the public, but they help my teammates iterate on computer vision algorithms more quickly. Even though I’ve never created a sensor or analyzed a decision tree, I feel like I’m contributing to the innovation that’s occurring at Ocuvera.
When they tell you internal tools are the worst thing you could possibly work on, I suggest looking at the culture that produced that statement. Does the person saying “never work on internal tools” really mean to add “for our company”? A company that values their interns will put them in an environment where they work on products people care about, get frequent feedback, and know why the code they write is useful.
If a company can’t provide that internally, why would they expect it from outside customers? Whenever you hear “You wouldn’t ever want to work on internal tools,” pay close attention to who’s talking.
