What works? What doesn’t? How has that changed as you’ve grown? What’s missing?
Quite a few questions there, but would love some feedback.
Emails. Putting thoughts processes, plan/roadmap, in writing exposes them to be deconstructed, torn down, reconstructed, debated, and assimilated. Strategy, business model, which features and why, what to ignore, what to focus on, tradeoffs, meeting notes they didn't attend with investors, prospect clients or partners, accounting or legal.
Wikis and knowledge bases. Each project has a wiki and whenever someone learns things that directly serve the project, they add it. To make sure I do it, I add issues to taskwarrior to decrease the friction to ingest/acquire info and useful things[0] with issues that say "Add X to Wiki" with tags and by project. Then move them from taskwarrior to the Wiki in a batch.
Working on a company Handbook which is a sort of "Operating Manual" for the company that contains as many details as I can on everything one needs to know to operate it (from legal information, bank accounts, hiring procedure and onboarding, firing, where to pay taxes, how to fill checks, etc.). I wrote these down when I used to do things myself so anyone who would help on these matters would know where to start.
Sharing what I learn with them and learning what they've learned in impromptu conversations or mini hacking sessions or code snippets. Talking shop, code reviews and refactoring, debugging together. Getting help from them debugging something and vice-versa.
Emails. Again. Writing things down. I'd think something has settled in until I'm proven it hasen't yet.
I'd love to know more about your email habits; seems super important to you as you've mentioned it twice. You mention a lot of the content you cover - do you do a weekly update that ties together all these disparate strands?
Also, writing allows others to have time to thing about it, construct questions, etc.
I don't send emails weekly or on a schedule for now. I send three types of emails:
- Synthesis: when a critical mass of information and insights has been reached that I feel we have to consolidate that into writing. What the product is, what it allows people to do, who it caters to, why it is needed, why we believe that, what are the components, what is the initial stack or architecture. This is the result of frequent conversations and spontaneous brainstorming, shower thoughts, night and week-ends musings, recurring frustrations, etc. All we have talked about or imagined is synthesized in that email, that will find its way into the wiki and the product's documentation. It takes the form of a product pitch/pitch/documentation before the product is finished or started. We'll talk about it as if it existed.
- Shift emails: Sent when taking a turn, notwithstanding whether information has reached critical mass or not. As we move along, the product/offering/company shifts. Mini-pivots if you will. Shift emails are essential because we can't afford to have someone building tomorrow's product and another building yesterday's product because they didn't "get the memo". These emails serve to align people and make sure we work in the same direction, whether for a week or a day or a month doesn't matter. Whether we're going the wrong direction doesn't matter much. It is easier to change course if there actually is a course we're following. It's good it is in writing because it's easier to correct something that's written as the thought process is externalized, than it is to correct words in the air.
- Announcements/Status: Meetings with potential investors or partners, why we are meeting someone, what's the objective, and meeting notes so what has been talked about is captured and the actions to be taken can be checked for done/depend on other action-person/cancelled, etc. Changes in work regimen (for instance, I just sent a message to work one day remotely to test a hypothesis of non linearity of recovery time vs commute-free days) after floating the idea that it might be interesting to have one day we work remotely. We usually work remotely from time to time, but not all at once.
Sometimes, we'll have a lengthy conversation on our channels and the exchange is either dense with points, counter-points, and ideas that it will find itself synthesized and in the wiki.
The reason we are doing something, what the problem is, why it's a problem, and what we plan to do about it, are points that I consider important to share.
One thing I have forgotten to include is commit messages and code documentation. We write commit messages to include root cause analysis, why something was changed and how, the lessons learned, the thought process/flawed reasoning/assumption that introduced the bug. I view commit messages as something I can learn from and improve how we make software. When we started doing this, the flaws became blatant as we were fixing similar bugs or making similar changes. Patterns emerged and we fixed the root causes. Here's a banal example:
commit 382afdc5eed2478d8cfa4b6fe5e64eb26e7fdff3 (tag: v1.0.58)
Author: Jugurtha Hadjar <XXXXXXXXXX>
Date: Tue Jan 2 02:13:10 2018 +0100
Closure for #153, #310, #311.
The difference between #310 and #311:
The first case was in the context of `create_form`, which means that it
wasn't until you wanted to create a Task Template that you had a problem.
i.e: it wasn't until `TaskTemplate.create_form` was executed. Which means
you just had a builtin ValueError that's easily fixed.
The second case was in the context of *class instantiation in TaskTemplate.__init__*,
which means that the instance of the class can't be created, which means that adding
the TaskTemplate route to admin in `app.py` will fail, and with it the routes added
after it.
So why was this different? They both should have been ValueError for trying
to unpack the wrong tuple to the wrong variables.
The reason is that, after cleanly handling the case where a database is down by
catching the proper exception (sqlalchemy.exc.OperationalError), that is #153 in commit
3327929d74911b999638e4902a9662366dd42c7d, several other handlers were added.
In a subsequent commit, the exception handling in a try..except clause was delegated
to a custom handler, `db_down_handler`, and the exception caught in the try..except
clause was changed to catch Exception and silencing it without logging.
Silencing exceptions is fine as long as you know why you're doing and explicitly do
so with a safety net of sorts (like logging/warning).