The Startup Experience: Lessons from a Year of Work
Maturing and growing as a software engineer.

Just a guy who loves to write code and watch anime.
Search for a command to run...
Maturing and growing as a software engineer.

Just a guy who loves to write code and watch anime.
I guess that's not a bad choice :3
Happy to!
Qualities that make outstanding builders.

Bipedal vs quadrupedal: how many legs This is about the number of legs the creature walks on. Bipedal. Two legs. Humans, ostriches, T-rex, kangaroos, most fantasy humanoids. Quadrupedal. Four legs. Do

Intro You hear "lerp" and "smoothstep" everywhere in game dev. They sound like math jargon. They're not. Both are small tools that do the same job: smoothly move from one value to another. The problem

What is Kinematics Kinematics is the math field. It's the study of how things move without worrying about forces (which would be dynamics). FK and IK are the two branches: forward kinematics and inver

Intro Textures are usually the biggest cost in a 3D scene. Memory, bandwidth, and load time all get eaten by them. Resizing them is the obvious lever. There's more. This post is about the less obvious

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. ๐ฟ
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 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.
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.
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. 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!
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.
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.
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 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 public calendar wisely. Use it to your own advantage and let it help you become more productive.
For example, scheduling deep work sessions.
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.
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.
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.
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.
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.
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!
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.
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 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! ๐