26 Lessons From Being a Developer at a Startup

在讨论之前，每个人都需要先说说自己的看法，避免被"loudest"声音所淹没。

We regularly sat together as a team to reflect on the last iteration. The importance of looking back and evaluating cannot be overstated. Each participant was required to think about the things that went well and things that need improvement on their own first. The group discussion started only after everyone had presented their thoughts. This way, everyone was able to bring up important issues - much better than the kind of meetings where the 'loudest' dominate the conversation.

In a busy startup environment it might be hard to justify just talking to your manager for an hour each week. But that is what we did and it worked brilliantly. You can discuss issues in-depth, timely and simply feel more valued as an employee. There is no replacement for that.

体现对开发人员的重视

For computers, every GB or MHz contributes to being able to work faster. For software, every useful tool that makes you more efficient counts. Giving the developer a fast, modern toolset also shows that the company values him/her. There should be no discussion about that. Period.

We visited our local customers regularly and had an annual company trip to customer hot spots (New York and San Francisco, for example). This made all the difference. It is one thing to exchange emails with customers, but it is a completely different experience to meet them and hear their pains and successes first hand. It has a powerful and lasting effect on the way you think about your users when you are back developing.

加快构建速度可以提高反馈速度，提高开发效率。

You know you have acted too late when the slow build becomes a running gag in the office (XKCD anyone?). There is hardly anything more frustrating than having a slow feedback cycle. We have worked with Java in the backend and Webpack in the frontend. Both were getting slower and slower by the week. In the end, it made me want to smash my head against the wall. In the long run, slow builds cannot be fixed by buying faster machines. You need to think about the structure of your application to deal with it; modularising it, for example. There is no quick fix.

把不同能力的人放在一起组成团队，的确能产生许多想象不到的效果。

Before we had formed cross-functional teams, we were only able to effectively tackle small projects. Once we had a team consisting of designer plus frontend and backend developer, things took off. It allowed us to work on much bigger, more impactful features. It brought its own set of challenges but overall it was a crucial step in the evolution of the startup.

We have used Trello to manage our bugs. I love Trello but I always felt it fell short. It was difficult to search and only scaled up to a certain point. The same goes for project management. At a certain point the simplicity and ease of use fade away and it just becomes too overwhelming and ineffective. I prefer dedicated tools that actually support and facilitate what you are trying to achieve.

最后一句看上去有点像我现在的处境

To be successful at any company you need to take on responsibilities. The bigger the better. The difference to a corporate environment is that it is quite easy to do so: roles are not set in stone and it is easy to grab unclaimed or unwanted responsibilities. You must become the guy/gal for something to improve your standing. You need to be proactive and shape your own image - or others will do it for you. Bonus points if you align this with the company goals. You can be a great code architect - but when the company only values feature development, you are betting on the wrong horse.

You might disagree with your management on certain things. In that case, you need to decide how important these issues are to you. If it is very important, you can take on the challenge and fight to stand up for what you believe is right. But often it will be an uphill battle. If hardly anyone around you supports you, or worse, does not even share your views, then you need to ask yourself if it is worth it. You can either ignore it and play along or look for another job.

公司的福利不是最核心的利益，公司的快速成长才是。当然每个人是有自己的情况的，要尊重差别。

A lot of startups boast with heaps of benefits. Some take pride in their ping pong tables, some want to impress with an open bar on Friday nights and some show off their selection of high-fructose corn syrup candy. It's a trap! Look for meaningful benefits like lunch and learns, an education budget or health benefits.

整个公司指望一个或者是几个人的话，是非常危险的。

When a startup is growing, the CEO has to give up more and more responsibilities since a single person cannot scale along with it. Basically, the CEO has to replace himself/herself step by step. A good indicator if this is working out is him/her deciding to go on a vacation.

We used Slack and while it was fun at times, I think it killed a lot of the productivity. We did not have a shared mindset about how the tool should be used. It is very important to clearly define what should end up in a chat and what is better left to email, face-to-face conversations or the wiki.

如果你希望同事怎么看你，那么最好一开始就塑造好形象，否则印象一旦形成就很难改变。

Whatever you say and do will shape how others perceive you. If you work weekends, you will become 'the workaholic'. If you come up with new features, you might become 'the wonder child'. And the thing is: it sticks. Often, the early impressions are the most important. It becomes increasingly harder to change how you are perceived by people around you.

In the backend, we almost only had senior developers with a combined number of 55+ years of experience. But to my surprise, this led to a plethora of discussions that rarely yielded great results. Those discussions were fierce. Sometimes I wondered whether everyone would make it out alive. On the other hand, in the frontend everyone was junior level. They displayed a lot of enthusiasm and creativity which - while meaning well - would often miss the bigger picture and lack high-level best practices. The key is the right mix of junior and senior people.

在开发之前，消除误解，明确开发目标，以及设定正确预期。

A new feature has many stakeholders. There is the project manager, the designer, the product owner, the CEO, the developer and the customer, for example. All of them have their own expectations and agenda. The best way to communicate the vision for a new feature seems to be a visual representation as close as possible to the final result. Again and again this has helped us preventing misunderstandings and bringing everyone on the same page.

It has been shown again, again, again, again, again, again, again and again that an open-plan office is a bad idea. I think a company usually wants to save money on office rent and sells it as a collaboration and creativity heaven. From experience I can tell you that you need a quiet environment to get work done - but you still need to be able to communicate easily with your team mates. I found the 'one office per team' rule strikes a good balance, if you keep teams small.

For an introverted person like me, the workplace can be challenging. Extroverts like to talk and write - a lot. Introverts usually cannot compete. We are at a serious disadvantage since extroverts can respond quicker, more confidently and more elaborately. Any company that does not address this issue loses out on great ideas and contributions by its 'silent minority'.

团队可能每个人的思维差异很大，如果这些思维没有办法统一起来的话，或者至少在某些方面存在共识的话，那么很难协调好团队。这些思想需要体现在开发活动中，比如code review, coding style, development culture等等。

Once you go from a single developer to a team of developers, there will be conflicts. Everyone is different. That is why it is so important to share a common mindset about things like code style, architecture, development and bug process, code reviews and so on. Simply writing down rules in a wiki does not work. It needs to be lived, understood and changed when circumstances require it. There is no substitute for regularly talking about it.

Knowing that, at the next day's standup my entire team will listen to what I have worked on motivated me. Even more so for weekly status updates. When our startup was still small, everyone shared last week's successes and failures in a few words. When the company grew bigger and only the team's joint efforts were presented, it was not as motivating anymore.

Although we have had a learning budget, it was hardly ever used for something other than attending conferences. Workshops can be a hit or miss - often there is not even one for the latest technologies. But like many of my colleagues, I am able to learn new things from blogs, books and videos just fine. So I propose to allow developers to invest a few dedicated days a year to learn things on their own. It is what we have to do anyway - often on weekends - but this way the company can support these efforts directly.

A nice tool to share knowledge across team members or even across teams is pair programming. Personally, I find it more effective than reviews. The interactions and discussions during coding are invaluable. How good it works often depends on how well the two developers can get along - from experience I can say that putting together very different people can actually yield the best results, though.

This one might seem obvious but can easily be missed. I have witnessed features stuck in limbo for months because nobody really knew how to progress with a finished feature sitting in a branch. It is paramount to have a clear understanding about who has which responsibilities or, even better, have someone who's job it is to take care of that.

Giving developers the opportunity to work on things on the side can become a powerful source for innovation. When a company supports this natural drive excellent developers have, great things happen. If it does not, the most dedicated developers will make their own opportunities anyway (e.g. working overtime or weekends) which can lead to unhappiness or even burnout in the long run.

You have an important message you want everyone to understand, share and remember. You cannot just say it once. Or just put it on a slide, in bold letters. You need to repeat it, again and again. It needs to be crystal clear. There should be no doubt about what you say. For further advice read the excellent book Make it Stick.

Hack是necessary evil的，但是不要过度使用它。

A startup always has more things to do than resources to do it. Prioritization is essential. And this often means to quickly hack together a solution that barely works. Sometimes for good reasons, like prototyping a feature and seeing if it sticks. But if it does, you rarely have the time to go back and make it better. However, what I have always found very irritating was how much a hack can be celebrated. It always felt like cheating to me. But I have come to terms with it: Hacks are a necessary evil at any startup. Just don't overdo it, please.

不顾一切地为了meet deadline的确是很糟糕的想法。

In today's ever changing world, a deadline is an artifact of the past. Deadlines only make a manager feel good, but kill everything that is good about software development. The further the deadline is a way, the more ridiculous and dangerous it becomes. The only thing that is worse are deadlines plus a set of requirements. This brings us back to the ancient beginnings of software development. There is no place for deadlines in the future.