Over the duration of the past two years, I have had the opportunity to work for web dev shops in the software engineering industry, and I loved it. There’s something special about creating a product that people are going to love and it fills me with pride. But there’s a whole other universe of software engineering that is wildly different than mainstream industry careers, and I got to experience a small taste of it at the University of Missouri.
I took a short break from the computer science industry to dive into university research as part of a ten week program by the National Science Foundation. This experience gave me a glimpse into the life of a computer science researcher and what I could be doing if I chose to pursue graduate school at a research-based university.
Coding for research is like floating through the world in a magical bubble where you never have to touch the ground.
In the research environment, you can choose any technology you want to work with and implement it however you see fit. You don’t have to conform to the company style guide, and you don’t have to work in a specific tech stack. As long as you produce some interesting results by the end, your advisors don't care how you got there.
In some cases, you don’t even have to work on the problem that you started with. I began working with Panacea's Cloud planning to implement a prototype of intelligent resource allocation for disaster triaging. The Panacea’s Cloud platform operates on a mesh network fog that serves as a “local internet.” In less than a week, I became interested in the idea of using GPS modules on the routers in the mesh network to increase bandwidth and reliability. This is the concept of Geographic Routing. For the remaining 9 and ½ weeks I studied the improvements geographic routing could provide to the platform as well as many other real world applications. The result of this produced experimental results showing a huge improvement in sustained throughput in a mesh network of medium to large scale, as detailed in my submission to IEEE International Conference on Computing, Networking and Communications in San Francisco, CA.
A failure in research is so drastically different than a failure in industry that it deserves to be recognized as a research perk. In research and industry, you set some goals and hopefully you achieve them before you run out of time or money. In industry, if you don’t finish your product, don’t launch on time or can’t solve the problem you set out to solve, then your company doesn’t get paid. Research is a little bit different; if you can detail the list of failures you have made in your work, then others in the community can learn from that and hopefully find success with the help of your work. In research, a detailed account of failure is actually a success, and success makes everyone happy.
In research, a detailed account of failure is actually a success, and success makes everyone happy.
The research environment is idea based. Teams think up an idea, create an experiment and publish their results. In terms of product development: the idea is the product, not the code. Programming is simply a tool to build that idea and prove that it works.
This environment produces engineers that are spectacular problem solvers, but it doesn’t provide the support to improve your developer skills. The job still gets done either way, but without the guidance and experience of your colleagues like in the industry, it’s a lot like using a screwdriver to hammer in a nail. It’s entirely possible to hang a nail with a screwdriver (or a shoe, or bottle of beer, or whatever you have laying around your house), but you won’t create a maintainable solution to your problem. Instead, you’ll probably develop something like a hodgepodge of python scripts that just “get the job done.”
There are still a significant amount of researchers who do have the coding experience to engineer effective and maintainable solutions. Many people work in the industry and then go back to university life to continue their education. If you’re one of those people with a good heart, I’m sure you will try your best to help your teammates improve their coding skills in every way possible. I commend your generosity Mr. Nice Guy Developer, but it’s not always cost efficient to spend your time teaching others to improve their programing skills.
Research programs are limited by time, money and people. If you spend half your time working on self-development, then you’ll fall very short of what you could have accomplished towards your project.
Think of a regular software company in the industry. Each team member they bring on is a potential long-term investment in the company. When you spend time developing that human asset, eventually their increased skills will pay off in your favor and you get a nice return on your investment. A research team is closer to a contract employee. Your relationship with your research team is usually measured in semesters or even months, so it doesn’t quite make sense to spend the time and money investing on a temporary asset. Instead, you just squeeze out their best effort until the project concludes. It’s a bummer to the nice guy developer who just wants to help the world, but the costs and benefits just don’t add up that way.
My small taste of the research world was wildly illuminating about the life If I chose to pursue a future in graduate research. It’s crazy how different academia is from the industry and I can see how it appeals to so many people.
If you want to improve your skills as a developer, then an industry career is the right thing for you. If you value the freedom to work on your own ideas without worries of financial failure, you should see what opportunities you can find at a research-based institution.
Personally, coding is much more than a tool for me, it’s a passion. In the industry, I have the environment and support I need to thrive as a serious developer, even at the cost of losing the absolute freedom provided by the research scene.
I’d love to hear your thoughts if you’re considering university research, or if you’ve already been there. Tell me what’s on your mind at josiah@jburchard.com or @JosiahBurchard on Twitter