Recently I took up a new offer to move jobs. These are my learnings from being one of the early employees at a startup.
Photo by Marvin Meyer on Unsplash
Business Impact is Important:
As a Junior Engineer at a small startup that is growing, from the get-go, it is important to be learning and implementing stuff that is required for the business rather than going on tangents and pursuing what seems fascinating tech-wise. In a world where distractions are the new norm, it is quite easy to propose new features and ideas which don't affect the business outcome.
The shift in mindset between doing research at the university with multiple ideas and validation for those ideas is not possible in a company as they cost time and resources which a startup especially are quite lean on. Building products at a startup requires a different thinking process and it is important to adapt and move fast.
Visibility:
Even if you are stuck in doing stuff that doesn't matter to business anymore it is important to be visible to the team. This can be done by performing presentations on what is being worked on with a focus on if and how it can affect the product in the short term, long term or the medium term. So if you are doing some research you can present it in a way that shows a new vision or roadmap. Also, organize some activities for the team to do together like a hike, some sports, cooking for each other etc( if you can cook). This can help show that you are helping in fostering the culture of the team and is an important factor.
Stand out in a crowd — PC Pexels.com
Be agile and Move fast:
By means of being agile, I don't refer to the software development philosophy of breaking things fast and fixing them fast. What I mean here is that if there is something that is needed to be learnt instead of doing a complete course or a certification it can take time. Just learning what is necessary for the task at hand and building a Proof of concept would do you and the company a world of good since there is not much time to learn stuff in detail. When a POC is established and breaks in production then there is a need to learn and implement the other details, not before.
Done is better than perfect:
In Academia we are taught perfection is the way to go forward in life. However, the real world is completely the opposite. If there is a task it is better completed with imperfections that can be creased out later than incomplete with components being perfect. If there is a feature to be implemented, implement it in a brute force method at first and get something working. There will be a time in the future to make things perfect.
“Premature optimization is the root of all evil” — Sir Tony Hoare popularized by Donald Knuth
As you grow in experience it becomes important to turn these initial POCs into something structurally sensible before writing code, but as a junior engineer, it is important to have something rather than the perfect thing.
Communication is Key:
It is important to understand that time is money, it is better off to ask for help when you are stuck at something for more than 4 hours, 4 hours can be the time to check google and implement the plethora of solutions that google offer if the problem still persists it is important to ask for help and resolve the issue as fast as possible as it becomes awkward as a junior to ask for help when you have been reassuring the supervisor that all is well and progress is being done. Asking for help makes you stronger over a period of time. Also at work, there is no test to check who is accomplishing everything by themselves.
Photo by Brett Jordan on Unsplash
Try and document everything possible:
This is a life hack and not just an early-career hack, Maintain a log wherein you can document the process and the approach without delving too much into the confidential details. In engineering, we can always abstract the problem and frame it in a general sense. This log can even be used when we move on to the next company. I started doing this quite late in my job. A better way to implement this would be to include it as a part of the daily routine. At the end of each day’s work just have a personal notebook or any apps and just note down the day’s challenge, situation and solution.
Request responsibility:
It is always unclear on whose responsibility is what in a small group and everyone is expected to pick up something and run with it. It is important to show dedication and commitment by requesting things not under your purview to demonstrate team ability. As a developer, this means that if a team member is sick or on vacation pick up their work and perform it to the best of our ability. This can be solving immediate issues relating to a component, not under your ownership.
What this would certainly do is improve the understanding of the system and leads to better education and self-improvement.
Conclusion
These are the simple things that I have learnt being in an organization for over 2.75 years starting from a student to a full-time employee. Hopefully, this helps in those transitioning from academia to the industry. Some points may be relevant for bigger companies too.