📝 Note: I’m not an academic guru, just a developer navigating the world of research for the first time. Everything in this post comes from what I observed and learned the hard way. Use it as a perspective, not a prescription.
When I decided to build RouteBastion (my SaaS platform for unified VRP solutions) as my Master’s Thesis, I thought the hard part would be the code, and boy, I was wrong.
Entering the world of Academic Research and R&D while coming from a full-time software engineering background was a whole new game. Here's what I learned and what I wish someone had told me earlier.
Searching for Related Work is both easy and hard
Let me break it down for you like I did for my friend Mark:
- Sometimes it’s easy: you find papers solving exactly your problem, cite them, highlight your difference.
- Sometimes it’s tricky: you find papers solving similar problems, still cite them, but explain the nuances.
- Sometimes it’s overwhelming: there are too many directions to explore.
I learned to think of related works in terms of age and citation count:
| Paper Type | Action |
|---|---|
| 📅 Very recent (<5 years), no citations | Cite with caution, it's new, might be unstable |
| 📅 Very recent, with citations | Cite, it's gaining traction |
| 📅 Older (>5 years), with citations | Cite, it's validated |
| 📅 Older, no citations | Avoid, there's probably a reason it’s ignored |
⚠️ Disclaimer: This table isn't a strict rule or academic standard, it's based on patterns I observed during my research process. Your advisor or field might have different expectations, and exceptions always exist. Use it as a starting point, not a rulebook.
And here’s a tip I picked up from a professor: the quality of your research often depends on the quality of the papers you use as foundation.
Everything needs Scientific Backing
When you're building a product in the real world, you're used to justifying decisions with experience, benchmarks, or “it works.” That doesn't fly in academia.
- Want to use gRPC? You better explain why with references or comparisons.
- Implemented a caching strategy? Show benchmarks or cite existing work.
- Picked Go instead of C#? You need more than a GitHub star count, you need research to back it up.
No evidence = no credibility.
And if no one has done the benchmark you need? Congratulations, now you have to do it.
Nothing can be implicit
One of the biggest mistakes I made in my first paper was assuming that the novelty of my work would be understood by the reader, just because I wrote an ok related work section.
Wrong.
In academia, everything must be explicit.
- If your system is novel, say it.
- If no one has combined technologies X, Y, and Z in this way before, say it.
- Don’t expect the reader to “get it”, tell them.
TL;DR: Assume nothing. Explain everything.
Lessons from my first paper
Some lessons hit hard:
- Never leave writing to the last minute, ever: Writing is the research, and it takes way longer than you expect.
- Professors are your best search engine: They know how to navigate Scopus, IEEE, ACM, and Google Scholar like pros!
- Don’t write “we use PostgreSQL”, write “we use a relational database”: Abstract your tech stack, Academia wants generalization, not product endorsement.
Final thoughts
My journey building RouteBastion has taught me that software engineering and academic research speak different languages, and that translating between them is a skill in itself.
But once you learn the rules, academia becomes a powerful tool to validate your work, communicate it clearly, and make a real contribution, not just to users, but to knowledge itself.
If you're a developer considering a Master's or PhD, I say: do it. But bring citations.
I find it strange you didn't know this from writing software project documentation. I know it is not on the same level, but good documentation is hard to get right. In academia there is only one target audience. With software documentation there are multiple audiences, from non-technical to technical.