2025-03-02 00:22:43 +10:30
|
|
|
# What I've learned from working on a team.
|
|
|
|
|
|
|
|
|
|
A cordial working environment is more important than getting everything your
|
|
|
|
|
way, or optimal engineering practices. You have to pick your battles and focus
|
|
|
|
|
on fixing just the things that you can't work with at all.
|
|
|
|
|
|
|
|
|
|
Some devs are mediocre programmers. Some devs are mediocre communicators. Some
|
|
|
|
|
are both.
|
|
|
|
|
|
|
|
|
|
Good documentation (comments, readmes, pull-requests) makes everyone's job
|
|
|
|
|
easier.
|
2025-08-30 23:50:21 +09:30
|
|
|
|
|
|
|
|
If you don't trust a dev's knowledge or decision-making then put guardrails on
|
|
|
|
|
their work. Give detailed instructions about how the feature should work in the
|
|
|
|
|
ticket, and check their work against these requirements when reviewing their
|
|
|
|
|
work.
|
|
|
|
|
|
|
|
|
|
A team is only as good as its processes. Engineering processes such as code
|
|
|
|
|
style rules, code review, version control, testing, release planning etc. all
|
|
|
|
|
provide quality control. Without these controls, devs will perform at the level
|
|
|
|
|
they find personally acceptable, which may be below the standard the team needs
|
|
|
|
|
to succeed.
|
