Almost everyone close to me has a PhD. I never seriously considered one because I needed a break from school. So I got a job. Having more money didn’t hurt. I remember my coworkers telling me once I work in industry I’ll never return.
They’re right. I never went back.
One skill I developed during grad school was reading papers and implementing the ideas. I didn’t have much time at a startup to tinker with translating theory to code so I had to find an off-the-shelf solution about a specific problem and solve it.
When I was looking at distributed systems, I came across RAFT. I remember reading this paper on a plane and sketching out the concepts.
I didn’t have time to write my interpretation of the protocol. Here’s what I did instead while managing a team – I favored research papers with source code or direct ports by others. I could read the literature to gain a cursory understanding of the math and concepts involved. The source code helped me map the academic jargon into code which I could understand easier. An example was RAFT in Golang.
I never ended up using RAFT in production but I was used what I’ve learned to veto taking this route because we didn’t need that complexity in our systems.
I’d say our team’s ability to read papers was key to developing one of our key technologies for the company. One of my engineers found papers on lock-free data structures to build our streaming technology. We all followed along if he needed technical advice or be a sounding board. I don’t remember the specific papers but if you look for lock-free linked lists and hash maps that’s a good starting point for ideas.
If you haven’t read research papers before, I highly recommend starting with an area your team is working on. Even a paper on load balancing may spark some ideas.
Leave a Reply