Profile picture
Hugo Giraudel @HugoGiraudel
, 11 tweets, 3 min read Read on Twitter
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.

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.
Missing some Tweet in this thread?
You can try to force a refresh.

Like this thread? Get email updates or save it to PDF!

Subscribe to Hugo Giraudel
Profile picture

Get real-time email alerts when new unrolls are available from this author!

This content may be removed anytime!

Twitter may remove this content at anytime, convert it as a PDF, save and print for later use!

Try unrolling a thread yourself!

how to unroll video

1) Follow Thread Reader App on Twitter so you can easily mention us!

2) Go to a Twitter thread (series of Tweets by the same owner) and mention us with a keyword "unroll" @threadreaderapp unroll

You can practice here first or read more on our help page!

Did Thread Reader help you today?

Support us! We are indie developers!


This site is made by just three indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member and get exclusive features!

Premium member ($3.00/month or $30.00/year)

Too expensive? Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal Become our Patreon

Thank you for your support!