I did my undergrad studies at a large, research-focused university (30K+ students) and went halfway through a master's degree in Computer Science at a similar one. Both have a tradition of incentivizing students to take on research projects. I, for one, have taken part in many of those. It was a great experience: I managed to work in many different fields - from virtual reality to machine learning and from electrical engineering to disinformation and hate speech.
That experience also led me to develop an incredibly inquisitive mind at times.
"No, I cannot start that weekend project I have in mind unless I'm comfortable ruling out every other possibility on how I can explore this"**
Then I'd go on to the hypothesis phase. I'd list out every conceivable way I could approach the problem. Only then I'd start to figure out a viable solution for it. Such a way of thinking is reasonable for scientific projects. The more literature review you do before starting the project, the better.
It is a terrible approach for the day-to-day life of a software developer in general, though. If you're working in a startup environment - or at a place that resembles one - that's even worse. In such an environment, getting the perfect answer is sometimes impossible. Several factors count towards this—time to market, business requirements, customer pressure, and the macroeconomic environment. A company should - theoretically, at least - deliver value to the customer quickly before someone else does.
This way, if you're a developer from a research background, I've got some unrequested advice to throw at you. These are things I wish I had had someone to tell me a few years ago, so I hope it might be helpful in your transition from researcher to software engineer.
1 - Ship, ship, ship
It doesn't matter which tech stack you're learning. You should exercise it by implementing projects as early as possible. Small tasks will help at this point - and I mean even tiny ones. Don't just read about Python. Exercise Python. Fire up a code editor and write that Flask hello world app you're reading about. Or that iOS sample code you're seeing. But don't let it pass untouched. Otherwise, your anxiety might kick in and convince you that you've done the work. "But I've read the whole documentation for the API." Yeah, sure, that's no use if you don't hit up the endpoints and notice the minor bugs that might affect you later.
2 - Reading may be an advantage though
Having the above said, I always advocate for reading. The more, the better. I have a feeling that reading is not encouraged in the developer community as a whole, and in some circles, it might even be frowned upon. As if a developer can only be as good as a god-given ability to write code that regular human beings just don't possess.
I disagree with that. Coding is as much of a science as it is an art, and as with all arts the more references you have, the better your creativity gets. Good ideas might come from technical references. If you follow me, you know I'm currently doing a review on The well-grounded Rubyist book. It's one of the best resources to learn the language and it's really well written. While reading literature on a specific language or framework is great, other texts might bring you different perspectives which will make you become a better developer in general.
Ever since I subscribed to the Pragmatic Engineer newsletter, for example, I found something I had been looking for a long while - a career mentor outside of the context of the company I happen to be currently working for at the moment. I always wanted to find someone who could provide me an external view of my trajectory and put it in perspective against the rest of the industry. How does my current company compare against the rest of the industry regarding career growth? Or what's happening across other companies that might affect me, but I'm unaware of? The newsletter works for me in that sense. I'm able to grasp a much bigger picture of what's happening around me just by reading Gergerly's texts. That's tremendously valuable to someone who lives far away from Silicon Valley.
I believe that reading good quality resources give you an unfair advantage career-wise. You'll be able to tap into the intelligence of the crowd without having to live the same experiences as others in order to learn from them. Once I heard that engineers who master design patterns often gain ten years of experience in only two or three. I'm not sure how much of that is an exaggeration, but I intuitively feel that learning from the mistakes of others and not repeating them is extremely powerful.
The catch here is that you don't have to limit yourself to design patterns. With the number of resources the internet offers, you can learn pretty much about anything from the very best people in the field for often a negligible cost. Take the talk given by Louie Bacaj - it's years' worth of growth pain and real-world experience packed in two hours of content. Sure enough, it's a video and not a text, but the point still holds.
3 - Learn to work collectively
Academic master's or doctoral degrees are in-depth training to assure you'll be able to take on independent research endeavors after you finish your degree. While many skills are definitely transferable, I feel that developers coming straight from academia into the software development world often struggle with working with others.
I know - research is growing to become more of a group effort than an individual one over the years, especially for some areas of Computer Science. I'm definitely not saying that researchers can't work well in teams. I have, however, felt that my ability to work with other people in a software team was one of the areas I needed to work on a lot in the beginning. If pushing your code directly to main in your personal projects might suffice, you'll need to learn how to unblock colleagues that need to test their code if you're holding the staging environment. This will be accomplished by learning how to rebase your branch against main and deploying it without screwing their work or yours while doing so.
Sure enough, it's not terribly difficult. But it involves negotiating priorities with other people in different teams. Sometimes you'll be able to get their code ready right away and everyone is happy, but you might come across a scenario where that's just not possible. Learning to manage expectations, as well as yours and other people's anxiety is a skill in itself that I don't feel is talked about enough in traditional Computer Science curriculums.
4 - Don't jump at work just because it looks interesting
One of the mistakes I made during my career so far I credit to the excitement I felt while doing research. If a problem looks tricky enough that it gets my two neurons excited, I couldn't escape the urge to explore it. This isn't necessarily a problem in itself. However, focusing on your growth as a developer should be your top 1 priority if you're at the beginning of your career.
In many cases, startups and small teams will offer you a multitude of high-priority problems to be solved and you can have a major impact if you act quickly enough on them. However, this might not be always worth it. I feel I could have used a little more focus on a few occasions. I feel I could have learned the tech stack or the codebase faster and with more efficiency. This would most probably have led me to even more exciting challenges and I wouldn't have had to take on three things at once instead of one. So if I can tell you one thing I wish I had done differently is: Don't take additional work if you're not 100% on top of your current. Yes - this might mean you won't get to work on every exciting problem that comes your way, but this approach will pay dividends in the future.
5 - Don't forget to have fun
Lastly, I want to remind you and myself that coding can be a lot of fun. Sometimes the pressure of having to deliver a client-facing feature in a blocked amount of time gets in the way of appreciating what we've just created as software engineers. This is an absolute killer for any joy a builder-minded person might have. Don't let this happen to you. Take the time to build projects that will solve your own personal problems. Scientific research and software development are two activities that can be highly engaging for curious people, so don't forget to get lost in the jungle every once in a while.
I hope some of the points I've touched on during this article resonate with you. I'm passionate about scientific research and programming almost equally and figuring out the internal fight is sometimes non-trivial. Writing about it helps me see the whole thing through clearer lenses and I'd appreciate it if you could drop me a note on what you thought about what I wrote here in case you've faced a similar situation. I'm curious about how other people have dealt with this kind of thing. My contact info is available here.
Thank you very much,
Teo
