The Startup Experience: Lessons from a Year of Work

The Startup Experience: Lessons from a Year of Work

Maturing and growing as a software engineer.


6 min read


It's been a year at Bobsled. ๐Ÿ˜

The year has been phenomenal. I began working last year in March. The first six months were a blast already. I joined as the first employee, and now we are more than 20 people! ๐Ÿคฏ

It's a place where I get to wake up excited every day. Compared to my last job, I find it strange that I'm more excited about work than side projects. Although it depends on what I'm doing that day, it's true for many of my days at Bobsled.

I'm super fucking happy. Waking up and doing work that makes me more energetic, not work that drains me. It's been a hell of a year. I learned a lot. ๐Ÿคฉ

Here are lessons I have learned through practice, mistakes and observation. ๐Ÿฟ


Don't chat over the weekend (Discord, Slack)

It's not that you should never chat over the weekend, but try to avoid it. Chatting over the weekend may come across as if you're getting work done on the weekends. This may lead to others feeling pressured to do the same. As a result, people may not feel well and become stressed out.

And of course, don't work on the weekends unless it's urgent.

Don't always build new solutions

Don't build new solutions for every problem you encounter. Instead, your first question should be: How could we've avoided this problem in the first place?

It's not always the right approach, but see if you can change the design or the constraints, so the problem disappears.

Celebrate productive disagreements

Disagreements are exciting. That's when we tend to learn interesting stuff. So many cool things were created because of disagreements.

Don't ever take it personally in disagreements. Instead, embrace them and have a productive discussion with your colleague.

Don't block pull requests over minor things

The lesson speaks for itself. Don't block PRs over minor things. Leave a comment and get the PR merged.

Ask your manager for feedback regularly

Ask your manager for feedback regularly. You may not have the traditional weekly or bi-weekly 1:1 meetings in a start-up. Make sure you stand up and keep track of the 1:1s you do with your manager yourself. Take ownership of receiving the feedback you need to grow.

Of course, take action! Feedback is feedback, but the action is where you actually grow!

Make people feel heard

It's good to drive things forward. It's good to get things done. But if a solution affects the entire team, it's good to begin by bringing up the problem first.

Ensure the entire team understands the problem and agrees that it exists. From there, make sure people can propose solutions and have a discussion.

You don't want people to feel left out when important decisions happen, as if their input weren't necessary.

I've found it's productive to start async. When it's time for the discussion, you schedule a meeting.

For instance, after having brought up a problem, share a digital board where team members can already propose things and schedule the meeting next week.

Ask questions in public Slack channels

Ping the people you'd like to ask and shoot your questions in public channels. This way, if others have anything to add or correct, they can easily do it, making it more productive for everyone. It also helps spread the knowledge in case anyone else has the same questions.

Listen and think more before speaking

Don't try to answer things immediately. Think before you answer. Try to understand what the other person is saying and how they understand their point.

You may have an understanding of what they're saying. But they've their own understanding and perspective.

Give kudos

Give more kudos in public. Whenever someone does something that aligns with the company's values, do it:

  • Show that you understand and are aware of the company's values

  • Support and lift your teammates

  • People may feel encouraged to give you and others kudos when they recognize good work

Use your calendar wisely

Use your public calendar wisely. Use it to your own advantage and let it help you become more productive.

For example, scheduling deep work sessions.

Do work that has more impact

Be aware of the work you do. If you could do other work that would've more impact on the business, do that instead. In a start-up, there are loads of things to do. Not everything is planned. So make sure you prioritize what's on your plate.

Don't discuss it for too long

I mentioned productive disagreements. This point relates to that. Don't discuss things for too long. Try to compromise and get to the action. You can always change something later if it isn't the right solution.

Software engineering is a process of discovery and learning. You will learn more by implementing a solution than by discussing endlessly.

Dig deeper into the problem before proposing

You may propose unuseful solutions if you don't understand a problem well enough. This is awkward. A thorough understanding of the problem will make you realize your proposed solution doesn't work.

Before proposing a solution, step back, think about the problem, and ask a question instead.

Don't use boolean states

I did not write an article about this, but my friend Damian did: Bool considered harmful?

Avoid them if you can. The state is often more than two, not a simple boolean state. Even if it's just two, the state could quickly grow.

Changes happen all the time in software engineering.

It's not your work

The work you do isn't your work. It's the team's work. Don't attach yourself to the work you do. You're a part of the team. If someone improves something you did, be happy. The team's work has been improved, and the team's work is what should be your concern.

Stick to the single-responsibility principle

Literally, every time I see myself or someone not sticking to the single-responsibility principle, the code gets super complex.

Just stick to the single-responsibility principle. Stick to it hardcore. Pieces may change for many reasons, but try to minimize the reasons as much as you can. It won't always be a single reason; software is never perfect.

Remember to refactor code you notice could be improved!

Ask instead of preaching

This relates to the point about making people feel heard. Don't start preaching answers. Even if you know what's right, spitting the answers in someone's face isn't the best approach. A better approach is to ask questions and try to understand the other person.

Ask questions that help you and the person come to the same conclusion. This is so much better.

Make sure you answered the question

If you answered a question, it's good to check with the other person if you actually answered their question.

What's even better, before you answer the question, you clarify your understanding of the question.

The worst thing: When someone asks you something, you respond with an answer that doesn't answer the question. You never want to be in this situation. It's a situation that can almost always be avoided.

Be an effective communicator!

Ask peers for feedback

Ask peers you've worked with for a while for feedback. It's a cheat code to growth. Most people only ask their managers for feedback, and not their peers. You literally have an entire team around you to help you grow!

Seek growth, not just from your manager, but your entire team.


Join a good start-up, you won't regret it! ๐Ÿ˜ˆ