Filip H. — Coworker’s Manual

If you've been sent this link, you’re probably about to work with Filip. Don’t panic. Despite the length, nothing here should be too surprising. It’s just to set expectations, sync terminology, and make things clear.

Development philosophy

1. I am a pragmatist. I try to follow best practices and find elegant solutions — but I have no problem murdering them when they get in the way.
2. Akin's Law of Spacecraft Design #36: “Any run-of-the-mill engineer can design something which is elegant. A good engineer designs systems to be efficient. A great engineer designs them to be effective.”
   • “Effective” here translates to “provides customer value”. In gamedev terms, that’s mostly how fun the game is to play. I’m often surprised how common it is to sink time and talent into stuff that ultimately has no bearing on actual gameplay.
3. I try to be acutely aware of trade-offs. Not just space/time, but also flexibility/usability and others.
4. In readability vs writability/elegance, I prefer readability. A few months from now, you won’t care how easy something was to write or how smart you felt writing it — you’ll care about whether it’s clear and easy to follow.
5. As for the question “functional or imperative paradigm?”, my answer is: “yes”. (They both have advantages and can work well in tandem.
6. YAGNI (with exceptions).
7. Avoid the second system effect — the urge to throw it all away and start from scratch. Understanding complex (and inevitably flawed) existing code takes time and seems unproductive. But it’s still more productive than the seemingly thrilling alternative of rewriting from scratch.
8. Avoid premature optimization.
9. Prevent bit rot. For example, don’t introduce new dependencies unless you absolutely need to.
10. Fail fast (e.g. put your assumptions into asserts).
11. Manually formatting your code is a waste of everyone’s time. Use automated tools.
12. Be aware of the different refactorings and use them, especially when they make the code simpler.
13. Follow good API design. For example, if calling some method is expensive (i.e. takes a long time to execute), it should look expensive. In Dart, that’s the difference between something like int get count (cheap-looking) and int computeCount() (expensive-looking).
14. Be your own Product Manager (software engineers are sometimes forced to, and often used to, outsourcing the unpleasant decisions to a PM, then bitching about it).
15. Know that finishing is a skill.
16. Embrace the power of boring.

If you need more depth to the ideas above, I recommend Paul Boyd’s The Cargo Cult of Good Code, Chris Keihl’s Software development topics I've changed my mind on, tef’s Write code that’s easy to delete, Tess Snider’s tidbits for programmers, John Salvatier’s Reality has a surprising amount of detail, André Staltz’s don’t rewrite everything, Joel Spolsky’s Things You Should Never Do, Lidwell’s book Universal Principles of Design (I have the pocket edition on my table), much of the rest of Akin’s laws.

Mode of work

1. I avoid IM (instant messaging) when I can. I think IM is almost always better for the one asking than for the one being asked. That said, I have to admit it’s sometimes good to be in IM communication. Possibly at set times or in predetermined bursts. We’ll figure it out. I just want to prepare you for my tendency to use asynchronous communication (such as email) — i.e. communication where the recipient can choose when to receive.
2. For productivity and personal health reasons, I utilize what is sometimes called the “lion approach” to work pacing. I am productive in bursts, with periods of relatively low productivity in between. Sometimes, migraine forces me to only do the most basic stuff for 1-3 days in a row. Other times, I get a ton of things done in a single, long, inspired day. I realize this is not ideal, because it’s not very predictable, but that’s how things are with me.
3. In communication, more frequent is generally better. Don’t be afraid to send an email even if all you want to say is “I tried to fix A today - but no luck so far.” It can seem extraneous but I think it’s better than no communication at all. Reading an “FYI” email can be finished in seconds.
4. When video calling, I find it very important that both parties have good and reliable internet connection. It is often the difference between a productive chat and an awkward catastrophe. To me, it’s generally better to wait until both parties can have good reception than to try to force a video call despite bad connection.
5. It’s not enough to be correct. You must also be helpful. (Example: When I say “this UI is shit”, I may be correct. But I’m not helpful. On the other hand, if I say “we could improve this by X and Y, and here’s how we’ll get the time & resources to do that”, then I’m helpful.)

Conclusion

I wanted this as a document so that you can call me out on these things. It’s a bit harder to break my own rules and ideals when they’re written down and a single click away.

If you have things that you'd like to clear out with me, the way I do above, please do! This is intended as a conversation starter (not ender).

See you soon!

— Filip Hráček