Thread by @HugoGiraudel

It’s 8AM and for some reason I am already at the office so here is a feedback thread on building the web team at N26 for the last two years.

Some is technical, some is not technical. This is a morning buffet so take what you like. ☕️

I have said it before, I’ll say it again: using @PrettierCode is the best technical decision we ever made.

It gives new starters confidence being able to write code without worrying about guidelines.

It saves a colossal amount of futile bikeshedding time.

It’s just good.™

I wish someone had told me before how quickly scaling would get difficult.

Not only technically speaking. Scaling infrastructure, work environment, consistency, communication, product… All of it.

Scaling is hard.

Most developers suck at Git. That’s also alright. And that’s also understandable given, well, Git.

This is a good opportunity to dig up that tiny thread about Git, and how I encourage any new dev to take the time to learn.

External Tweet loading...
If nothing shows, it may have been deleted
by @HugoGiraudel view original on Twitter

Senior developers should not be meant to crush code all day. Sure, they can. Sure, they might have to. Sure, that can help. But I believe it’s a waste of talent in the long run.

Senior developers are there to enable the team to work better. To learn. To grow. 🌱

There is more to code than code. 💻

It feels like stating the obvious but it still feels quite astonishing to me how many developers can feel okay not writing documentation, comments or tests.

While this should probably not come from me, I feel like we did a fine job at creating a culture where people can ask questions and make mistakes.

Developers are not stressed to death having to ship code. They can take time to experiment. To learn. To fail. That’s good.

One thing I am pretty proud of is how extensive our documentation is on the web platform:
- 📝~22,000 words of Markdown in about 30 chapters.
- 📄Detailed changelog on GitHub of our ~300 releases with links to PRs.
- 📜Extensive comments where necessary to help maintainability.

Speaking of documentation, having them in Markdown files *in* the repository alongside the code instead of on Confluence was a great idea:

- It pops up in code searches.
- It stays up to date in refactoring.
- It can easily be read on GitHub.

Highly recommended.

Accessibility at scale is not trivial and needs to be tackled on 2 different fronts:

1. Teaching devs what they should know (with documentation, code reviews…).
2. Providing tooling so they don’t have to think about it too much (reusable components, automated testing…).

On the topic of code reviews, encourage new starters and junior developers to contribute to them. Have them ask questions, comment on things, suggest ideas.

Code reviews should really not be restricted to experienced devs. This is some counter-productive utter bullshit. Don’t.