Intro
In January 2021, for the first time in my life, I joined a fast-paced tech startup, as rather inexperienced Frontend developer. I have been programming for a couple of years, but did not have much relevant production experience for the required tech stack,which was mainly React, Redux and TypeScript.
With this article, I want to summarize my experiences in trying to survive entering a startup as a junior-ish developer. What -- over the course of the first few months -- worked out well and what didn't, focussing on what I could control: myself.
Hopefully, this might be of help for anyone in a similar situation. I’ll share this as advice I would give to my past self, while also providing concrete examples from my experience. So while some or most of those points may sound like no-brainers to you, I wish I had these when I started. Each point is deliberately opinionated.
Start relaxed
Starting a job with a different tech stack and paradigms means one has to find out how all these new things work. At best, there is time and space to do this during working hours. However, checking on a few things beforehand might reduce the cognitive load (and thus stress) during the first weeks.
As always, the quantity makes the poison. I was overambitious in that regard. I could not start with a fresh mind. If you can, I'd advise to also take a few days off to relax, so you can start fully charged.
Drive your onboarding
For some reason, people like to think of companies as ships. The company you are jumping aboard to will either have a – more or less structured – process to help a new employee get familiarized with their new work environment – or not. It might just be in an early stage, and these things usually evolve over time.
If you do not encounter a big master plan for that purpose on your first day, do not despair. That gives you the chance to get creative and shape a process that fits your needs. The measures might just be the blueprint for the future onboarding process.
As a first step, you can explicitly seek a buddy and/or a mentor. Not only for the first days, but until you have a shared understanding of the things you are working on. Setup a “work agreement” on how you two want to do the knowledge exchange: Shall you bombard them with questions the second when they arise? Or should you rather buffer them and talk once or twice per day?
Having a close contact like that drastically lowers the threshold to ask questions, which is important to understand philosophies and histories behind the projects you see. Nicely, this gives you a chance to bond with a new colleague. In a remote work setup, getting socially acquainted to new colleagues is sometimes more of a challenge than when you have the chance to chat over lunch or run into one another at the coffee machine. Later on, a mentor might continue to steer you in the right direction, when it comes to solving engineering problems, but also in managing your professional growth.
For myself, I luckily paired up with a great (and kind) senior dev. We had a chat of about 15 minutes per day, for which I collected questions. Being forced to prepare my points in advance, and then making best use of the time together, encouraged me to have well-structured points, which could effectively be discussed:What is the problem/uncertainty? What research have I already done, what do I think? What are resources (screenshots diagrams etc.) that facilitate reasoning?. Also, buffering these questions made some evaporate on their own,because I could answer them myself at some point, which made me take less of the precious time of my teammate.
I also created questions, tried to answer them myself and shared my findings in order to correct them. An example: How do we issue http request client-side, how is that layer built? Later I fed these (as well as advices) into the compilation of an onboarding guideline.
Don't push yourself too hard
Those first weeks are a challenging time, full of input and often a lot of self-made pressure. To reduce the latter,try to get clear expectations from your engineering manager. Until when should you be "up to speed"? I for myself found out that expectations in terms of "when will I be planned in with full capacity" where pretty realistic, which helped.
A symptom of over-ambition can be to rush into trying to get first features done as fast as possible, without trying to get a real deep understanding of the problems or tools at hand.
Are you using some new libraries/patterns/languages? Try to really understand the gist of it. Just making it work for the sake of being able to deliver quicker will only delay the problem or create new ones. Take the time to learn what is needed to solve a problem properly. A non-toxic workplace should IMO encourage that, which luckily was true for me. That will make you grow. And with competence comes confidence comes speed. I want to iterate more on managing ones resources further below.
Understand the business, product, customer and the internal roles
It might be tempting to only rush into building things, because that feels familiar. What should not be skipped is getting context: What is the business value you create? What knowledge gain or automation does your product offer? Who is doing what to create that? This context is always (not only initially) needed in order to produce the right value.
Get your hands dirty with the code base early on
Technically, that is what you're here for: The codebase as object of profession. Getting used to it in order to start delivering is the primary goal for new developers. But just staring at code won't do the trick.
Sketch it: Drawing a diagram of the system architecture might help to make out building blocks and layers, allowing a high level view early on.
Trace it: What I found super useful is to pick a (seemingly) simple feature in the app and check out how it is built,by using browser dev tools and full text search in the IDE. Sketching the data flow and responsibilities of components/layers will contribute to getting a clearer picture of how stuff usually gets built.
Talk about it: Share your interpretations. e.g. on why a specific file structure has been chosen. Your first assumption might be wrong or incomplete. It also might reveal inconsistencies, which are worth knowing about.
Question it: Ask tons of questions about patterns you don't understand. Still, some encountered designs might just keep on confusing you. If you think you can improve something, write that down and -- when there is the appropriate time and space -- raise it. But do not start to fling around critiques from day one. No one likes it if you are too much of a now-it-all. You don't know all constraints which led to the result at hand. But actively thinking on how something can be improved and pitching this is (hopefully) encouraged and well received. But the way you say it, matters.
During my first weeks, I took a ton of notes. For example, I had a "What to improve upon " section that grew more and more mature over the first weeks. When the time was right, I proposed them as actions (e.g. extending our lint rules or co-locating co-located things).
Last but not least: If you see some small, easily fixable glitch, try to fix it right away, in the spirit of "boy scouting". For me, I could commit small improvements to tooling and documentation within the first days. Such a "first blood" PR no matter how small it is, feels really good.
Document to amplify your knowledge gains
When trying to get an understanding of how an application is run/built/deployed or internally structured and taking notes while at it, it is only a small additional step to transfer your findings to written documentation, be it README.MDs, Confluence or similar. It might be of great help to the next developer in the same situation to access up-to-date resources that help with getting started. Sure, a general absence of documentation is a problem, but again: Here, and generally, I want to focus on what I can do to improve the situation.
Connect and seek feedback
Depending on one's self-esteem, the first weeks in a challenging work environment might feel like walking a path full of potential pitfalls and thus uncertainty: Am I doing good? Do I meet the expectations of colleagues and my manager? Do I fit in? Luckily, there are short term measures to prevent or mitigate that uncertainty.
First, trying to bond with the new colleagues. Use lunch and coffee times to get to know them, not only as professionals, as human beings. Working remote? Try to find formats mimicking "the real thing", e.g. a "virtual coffee". Thereby, humor and just being oneself helps to sympathize and connect. People usually appreciate being straightforward and authentic and find it enriching to engage with different personalities on a daily basis.
Last, but not least structured 1on1 feedback sessions are a great tool to exchange mutual appreciation (which strengthens relationships) and to get insights in how to improve as an individual contributor. Respective expectations ("working agreements") can be made explicit, which can lead to more effective and personalized collaboration. When conflicts are dwelling, such a format might help to clear the air and strengthens confrontation skills.
Of course the results depend on how open people are approaching this. And it is worth to reading into techniques supporting such exchange, for example non-violent communication.
As it is with getting to know your colleagues, such structured exchange can improve psychological safety within the organization, which then benefits the team's performance.
I can confirm all the mentioned benefits for myself. By promoting the value of these 1on1s, I could initialize a company-wide format. Driving and owning such a process was fun and contributed to my standing in the company.
Learn to communicate effectively
One thing I learned from a co-worker during the mentioned feedback session, is that she hates it when people write "hey" in the chat, thus grabbing your attention before taking another 2, 3 minutes and a couple of messages to say what they want. Or asking for a call, without saying what it is about.
Reflections like that, as well as getting inspired by strong communicators in the company made me sharpen my communication skills, which helped me to deal with problems more effectively. I love reading into and promoting topics such as Slack etiquette, because it can directly improve everyday collaboration.
Manage internal and external expectations
No matter the amount of attempted self-optimization, the set and setting must be right.
External pressure might be coming from un-aligned expectations from (product) management towards the development team. One constant problem I faced was the stress caused by trying to deliver within the estimated time with all means. Just programming tactically and getting the feature done is always an option, but in a good dev team like I had,people are constantly fighting against entropy in the code base and accumulation of too much technical debt, which means there are high standards for code quality. Also, a growing codebase just needs maintenance and constant refactoring. That, as well as the usual "unknown unknowns" not detected in groomings, sometimes results in stories taking longer, which sometimes dashed expectations. What really helped here is to openly talks to product managers, picturingthe described challenges, in order to improve the process of estimation and planning. Instead of getting snarky, we stayed in discussion and could establish more buffer time for the unknown and for maintenance. As usual, communication was key.
But when listening to where "felt pressure" is coming from, one might detect that super-elevated expectations come from the inside. While ambitious goals can help you raise your personal standards and grow as an engineer, over-ambitious ones can do more harm than good. Taking deadlines way more serious than they are opens oneself up to take unsustainable shortcuts.
I discovered that I put too much stress on myself, and developed a false sense of perfectionism in delivering in time.
Manage your health, stay focussed and get it done calmly and properly
Overcompensating by working longer does not scale, I learned that the hard way. Combined with the challenges of having two young kids and the general COVID situation, I scraped past a burnout. Luckily, I meanwhile know better and learned some tricks to help mitigate stress.
Let's start with setting boundaries. Starting with defining and trying to stay within the daily time frame. There might be an occasional engineering problem that needs an evening session, but only out of positive stress and the will to crack the nut. That way there is enough time to relax, work out, meditate etc. Another boundary is a physical one: sick means sick. There is no point in pushing yourself over it. Other boundaries are less obvious and harder to set: Your workload and pseudo-non-work obligations. For the first point: Don't say yes to every task that needs to be done, when your task list is already full. There is always enough work, and saying no does not make you lazy. The second point refers to social happenings like after-work-beers, which are common in startups. Of course, they are fun and can really help to connect to people, but you should not feel obliged to participate. In the end, those things are not really work, but they are hardly (and much needed) leisure either. You have other obligations? Declining does not make you socially incompetent.
Taking breaks is also important during the work day, as well as allowing oneself to work without multitasking. I personally found much help with centered.app, a tool that
- reminds me to take breaks, working as "tomato timer" on steroids. Imagine a friend that regularly encourage to stop, get up and drink some water
- brings me to structure my work to work in slots (working as task planner), where I focus on specific chunks of work, which I then execute with full focus.
- helps me with the large amount of chat and email messages by enabling the OS-wide Do-not-Disturb-mode. Basically I read and answer a queue of messages every half an hour, which is fine by most people. I expect no one to reply right away, so I am not pressuring myself to do so.
Shit has already hit the fan and you feel overworked? No shame in that. Talk to your manager early on. Your manager should listen to that, maybe take some weight off your shoulders, and work out a strategy to tackle it. Talking early on, before a problem grows too big, is always appreciated. Ideally, it strengthens the bond between you and that person and helps you to mitigate or overcome the initial problem.
With the measures described, I am confident and transparent about my limits, I get more stuff done. I am not as exhausted at the end of the day as I could be.
Work remote whenever possible
In order to reach a better balance between work and non-work duties, working from home as much as possible has helped a lot. Instead of wasting time commuting, I can run small errands or exercise or just finish earlier. Having an extra room with professional equipment helped to establish a physical boundary between work and all the rest of what is life.
Grow and shine - Conclusion
Enjoy the ride, you are in for the marathon, not the sprint. I mostly did. By "putting in the work" and having great and experienced colleagues, I learned a hell of a lot and became a confident member of the dev team. I even made interim team lead. I also made a ton of mistakes, leading me to develop strategies for better stress management. Now I am heading to new, less start-up-y adventures, but continue to value the time I had.
Thanks to my reviewers Guilherme, Karina, Lukas, Fredi, Patric and Hannes.
Top comments (0)