What I Learned Working At StartUps…
StartUps are the best launchpads for interns, freshers and other less experienced professionals to gain valuable experience while working on the latest technologies and leading teams and processes.
In my experience, I’ve seen a very stable trend among startups. The earlier you get in, the more decisions you affect or contribute to. Trust me when I say this, but this can be good and bad depending on what expectations you set when you join.
I’ve worked at three startups, two of them as an intern, and my latest appointment, a full-time role as the Technology Lead. I can easily say, the amount of learning that has happened through working at start-ups is far greater than any online course or college degree.
Fast-paced development, building production-level applications and services, optimizing for cost, pivot in terms of direction, are all extremely valuable learnings you take away from working at startups.
In terms of Software Development, there are a few things I can share that will definitely help you during your internship/job at a startup:
1. Learn version control well
Version Control is one of the fundamental things every software engineer must know and know well. I’ve come across so many students who even after years of development still struggle with version control which is a mandatory skill in the real world. The most popular version control system, “Git” is what I recommend you learn if you’re just getting started. But just knowing how to add files, make commits, make changes to remote repositories is not enough. After mastering the basics, learn advanced concepts like branching, resolving merge conflicts, pull requests, logs, reverting to previous commits, etc. You can choose any cloud provider as a remote location for your repositories but the most popular service by far is GitHub. Other providers include BitBucket, GitLab, etc. A good learning resource for an introduction to the advanced topics is the GitHub Professional Guides:
2. Don’t be afraid to try things you haven’t done/used before
In all of my experiences at startups, there hasn’t been a single instance where I’ve gone in knowing everything about the technology in use. In fact most times, I had to learn things from scratch. But there will also be situations where the company has opted for some other technology for a task that you know how to do but not with the technology that the company prefers. For example, let’s say the task is to build a REST API using Node.js, but the company wants to go the Serverless route and deploy to Amazon Web Services, which in fact is a widespread production scenario in many companies. Now, most people building REST APIs with Node.js use Express or another similar framework like Hapi, or Loopback, or Koa which use the traditional server-based approach.
DO NOT SHY AWAY!
Take this opportunity to learn the Serverless way of things even if you have no idea what Serverless is. This will expand your knowledge base and make you more confident in your skills and problem-solving abilities. Just that initial courage to take up the task is required and then making sure you complete it well. It may not be perfect, but that’s the point. The fact that you realize it’s not perfect has expanded your knowledge about the technologies and given you more things to explore.
3. Write documentation for everything you do
Code documentation is something that even experienced developers often neglect and if you develop a habit for writing good documentation for your code from the start of your software development career, you’re more likely to continue that habit rather than having it forced upon you further down the road.
How would you know whether your documentation is good? Rather, what is good documentation? To be honest, I wish I could give you a straightforward answer, but there isn’t one. But a good idea is to look at other similar, reputed open-source projects and see how they do their documentation. You do not have to follow that exactly, but it can spark decent ideas with regards to your own project’s documentation.
Most projects start with a good README file that explains the project and the folder structure and how to run/test and deploy. For JavaScript, jsDoc is pretty standard in the industry. For REST APIs, Swagger is widely accepted, while apiDoc is also an alternative.
Well, there are also some points you should definitely avoid or try to resolve at the earliest.
1. Lack of transparent and honest communication
Cannot stress this enough but communication, and honest communication at that, is extremely vital to your growth. Let’s be real. Everyone makes mistakes, wrong choices, misses deadlines, you name it. But having transparent communication with your teammates and superiors will help analyze the problems and come to a solution that works for everyone. When you’re starting out, do not be afraid to ask for help if you’re stuck and cannot figure out something. There’s nothing to be ashamed of in asking questions and definitely nothing to be ashamed of if you don’t know a particular thing.
Good communication also ensures a great relationship between your manager and you and helps to plan and set good, achievable targets with acceptable deadlines. It also ensures that everyone is aware of what is going and nobody feels left out of the process.
2. Avoid getting caught in the learning loop
This is a very common issue among people just starting off and getting into the world of Software Development. The general idea becomes,
“Let me finish this course/tutorial, and then I’ll be ready to take on projects”
And by the time you come to the end of the course, there’s something else that you need to know/find interesting, and you start learning that tool/technology. This never ends, unfortunately. Some people also call this, “Tutorial Hell”.
The easiest yet most challenging way (see what I did there *wink*) to get around this is to do real projects while learning itself. Yes, you may not know how to write optimized code, you may not know how to do a particular thing, but what you will learn is, “how-to figure it out” and I think that is way more valuable than completing a course and getting a certificate. Doing projects this way may take more time than expected on your initial attempts, but things will only go upwards and you will have total confidence in your skills.
I hope this helped you’ll get some insights from my experiences and I’m sure they will benefit you’ll in your Software Development journey. Thank you for being so patient and reading this till the end. Cheers!
Visit my website to connect with me on other platforms:
