early planning and okrs

[earthdok]

A: I feel like we should've found a way to commit more resources to building base code such as emulators and state as soon as possible. Maybe instead of brainstorming solver approaches in our first meeting, we could've discussed what the interface to those things should look like, and how to split the work to have more than one person working on each of them.

I don't think we had a working C++ emulator until Sunday, and the Python emulator was never finished because Vlad switched to building the solution DB. But a Python emulator is not rocket science and we really should've had one on Friday. I could've spent Friday working on it. Instead, my Friday night was wasted waiting for base code to build a solver on top of.

B: I was really hard to figure out at any given time what each member is working on and what kind of progress they're making. (Case in point: until Sunday I had no idea that the python emulator had been abandoned.) The issue tracker is obviously not enough for this, and one shouldn't have to ping people or check the chat history. What we need is a very rudimentary OKR system. Something as simple as a shared google doc which each person could update with a timestamp and a short list of items they've completed, put on hold or are working on. As long as you're actively working on something you should update it fairly often (like once an hour at least), otherwise just put down that you're out or sleeping or whatever.

[kevroletin]

:+1: on OKR system. At some point, I gave up on exploring other people's work and just wrote shitty code without proper abstractions

[Vlad-Shcherbina]

The issue tracker is obviously not enough for this

I don't know what specifically is deficient about the issue tracker, but based on our experience in 2014, 2015, 2016, I have come to accept that people don't keep the issues up to date reliably. No reasonable amount of nagging helps.

Is there some difference between the issues and the shared OKR document that will encourage to keep it up to date?

Anyway, so how I look at it is that I don't care what everybody is working on and what's their status. For example, while setting up the solution DB I really really hoped that people are working on many diverse solvers, but I didn't bother tracking if a particular person is working on a particular solver.

Naturally, I have to care about the status of the things that block me. So I try to limit these as much as possible. Pinging blockers seems appropriate and allows for more nuanced communication than generic status reports addressed to nobody in particular.

[earthdok]

OKRs are a management tool. We have limited time and resources and we need to manage them somehow. It helps to have a big picture to see where we are lagging. You said it yourself: you concentrate on your own problem and hope that people are working on many diverse solvers, and then end up wondering "where the fuck are all the solvers". Meanwhile I'm trying to make a state-agnostic solver work to make use of my time somehow while waiting for an emulator to appear from one of several people I'm hoping are working on one. I wasn't technically blocked by the lack of an emulator, however my time would've been better spent writing one.

That said, for tracking what's already been completed, FJ's approach seems much better.

Is there some difference between the issues and the shared OKR document that will encourage to keep it up to date?

Hopefully a simple rule like "short hourly status updates" would be easier to follow than a vague one such as "keep your issues up to date".

There must be a good reason why your nagging is ineffective. Perhaps it runs counter to people's habits regarding issue tracking. I'm personally used to having many open issues assigned that I'm not actively working on. It's a tool for writing down and discussing ideas just as much as it is for progress tracking. I'm also kinda used to having my commits referenced automatically so I wouldn't expect people to post detailed updates.

[serokellcao]

@earthdok @Vlad-Shcherbina next year we should try automated nagging something like a slack bot that asks one to post an update on what you were doing after they come back from coding intensely. Regarding planning, I agree entirely. It keeps biting us again and again.