I want to take a moment to talk about the early part of my experience of working in a startup. This includes what I learned, the challenges I faced, and what I would do over. I read somewhere that the startup life is one of two things:
My passion is taking an idea and creating the first iteration of how the end user will interact with that idea. Similar to gardening, I love planting seeds of code and helping it grow into a functional easy to use user interface. The advantage of working in the early stage of a startup is you are helping to grow an idea, part of the decision-making process, and wear multiple hats.
In June 2020 I started working for a startup that created a product name veva.ai. The goal is to allow users to take a short assessment test to get a tailored list of online resources. There was a product owner, project manager, front end team, and a back end team. I was on the front end team as a developer. My area of responsibility was supposed to be the UI. I was dead wrong.
In a startup you will wear different hats.
My first hat was that in every meeting of the startup I represented the development team. I had to state what we had accomplished, current issues, and what we plan on doing next. I had to give a virtual presentation of the UI at each meeting. I didn't realize that being a developer would take so much communication and presentation. These opportunities gave me a chance to learn project management and how multiple teams work together to build something fantastic.
A second hat was when someone thought of a cool and great feature, I needed to design and create wire-frames/mock-ups of what that idea would look like so that the development team can build with the end goal in mind. Ideas are great to talk about but the way one person imagines it will be different from a different person's imagination. It became a personal priority to constantly demonstrate where we are in development of those features/ideas with a GIF and screen-shots so that there is no miscommunication.
A third hat was taking the responsibility to review and merge all development branches into a master production branch. While I thought this would be simple, this required a lot of reading of code and learning other developer coding styles. I screwed up several times when I deleted something during merge conflicts because I didn't take the time to understand or ask questions.
In a startup you will overcome lots of challenges
One of the biggest challenges was working with developers on the other side of the world. I had to constantly consider that the person I was communicating with at 3pm in the US was asleep at 2am in the morning where they lived. The solution was to be mindful of when I expected a reply to a question or help with an issue. This experience taught me to establish good communication time frames, methods of communicating, and a regular contact schedule.
I had to overcome the feeling of a goal post that is constantly moving. It was a challenge getting used to the increasing amount of priorities from the product owner or product manager. The constant updating of the user interface or adding of a feature was really frustrating.
In startups there is a constant need or desire to pivot. I learned from this startup that this desire needs to be tempered with the willingness to replace an idea/feature with something else of equal time/complexity. The thought process is to weigh how much time are you willing to add to development to include a feature or to start over.
A tough and embarrassing lesson I learned was that merging code without testing never ends well. I had a time constraint and needed all development branches merged into the production branch to be tested as a whole. First, this was a mistake because it made the entire application buggy. Second it was disrespectful to other developers whose work is now being questioned when it wasn't finished.
A new cardinal rule is to be willing to read someone else's code, have a beneficial conversation about it, and be able to understand it. This became a challenge simply because the developer who wrote that code would be in a different time zone so couldn't have a meaningful conversation. On the other side of the coin, it is a rewarding experience to fail at developing a feature and then get the chance to read someone else's successful coding of that feature.
An important issue for me was in communicating to another team that their documentation in my opinion was lacking. While this was my opinion, it prevented the building of the UI quickly and efficiently. In hindsight, I should have requested if I could work with that team to make the documentation more beneficial for my team.
What I learned from this Wonderful Experience
Ask questions or review early in the development stage regarding resources that other teams or developers provide. An example is if the back-end team provides a list of API endpoints then the expected inputs and outputs should be included. Make it a priority for anyone suggesting a new feature that affects the design to show visually how that design will look across multiple screen sizes.
Set up a routine, from the beginning, of the developers doing a brief meeting just for developers. When you include other teams, the conversation tends to favor adding features instead of solving problems. A meeting with just developers is a great opportunity to learn from each other about common coding practices, shared road blocks, and reaching the end of a list of problems.
Schedule time to walk through a problem with someone. The point of having a team is that you are not alone in fixing problems. If that is not possible, make a demo or screenshot pictures of the issue so others will be aware of the problem.
Do better code reviews. The main idea is to test if the new code has broken the application, fixed a bug, or add a new feature. Code reviews needs to go a step further in documenting how the new code affects the flow of the application, does it conform to coding standards, and how does it affect state.
From day one I should have suggested and insisted upon a product release schedule that included the release of the MVP, major deploys, and hot fixes. Each of these items on the schedule should include a set planned number of features and a visual road-map for the user interface. The main idea is to avoid having a plan then the week before launch someone asks for 5 more features but to keep the same schedule.
While a startup must be willing to change based on its user's feedback, how much and the tempo of change reflects on it being organized chaos or just chaotic.
As a by product of a release schedule each release should have a list of features to be developed and can be assigned to developers. My main focus is to avoid constantly moving the goal post further because of the constant need to add new features.
Trello is a tool we set up at the beginning of the journey but never used. This was a huge mistake. We needed a tool to communicate who is working on what and to relay additional information. The most important task is to avoid developers unknowingly working on the same issue.
I grew a lot as a developer during this two month journey and is excited about how much more I will learn. Thank you for reading about my journey. As always, let's have fun coding.
Top comments (2)
I recently came across your blog and was really impressed with the insights you share, I thought you might be interested in something I’m working on. I’ve developed a platform called Feedback Base, which helps businesses gather and manage customer feedback seamlessly.
It’s AI-powered, easy to integrate, and fully customizable. We're still in the early stages, but we’re offering early access with a 40% discount to help businesses get started.
No pressure, but I’d love for you to check it out:
Feedback Base Early Access
If it aligns with your needs, it’d be great to get your thoughts or even share it with others who might find it useful.Thanks again for the valuable content you provide!
Great writeup!