Cognitive Bias Poster

The human brain does an amazingly good job at simplifying the real world into a mental model it can handle. I made a poster of some of the tricks it uses.

How to do pair programming badly

I tried to do "pair programming" as a teacher/student relationship and it didn't work very well. It was better than nothing but it was extremely stressful for the "student". I suspect that trying it again would quickly lead to burnout.

How to do pair programming right: http://wiki.c2.com/?PairPromiscuously

Why it should be OK to watch youtube at work sometimes (not all day)

https://medium.com/@nilssalzgeber/why-working-in-sprints-maximizes-human-productivity-e8f2eba3d98b

Devlogs are good

I started writing a developer log several years ago when our task tracking functionality was not up to scratch and I was working on an extended project. I wanted to be able to prove that I was working hard, even though I initially had nothing to show for it. However, devlogs actually have several major advantages that make it worthwhile:

1. How did I fix that last time?

Every time I get an error, I copy/paste it into the devlog. Later, I can then search and deal with the same error much more quickly (or at least rule out stuff I tried last time). This makes it easy to answer others' questions when they say, "hey, have you seen this error before" -- I can definitively say "yes, here's what I did" or "no, never seen that".

Every time I fix a problem by googling it, copy/paste the helpful website link, with a few keywords about the problem. This makes it much easier to find the fix if it comes up again.

2. Where was I?

When I get interrupted, it is easy to resume what I was up to, because my mental stack is no longer in my head -- it is written down. If it is not fully up to date, it is at least a hint about what I was doing before I was interrupted. I have found this extremely valuable because getting interrupted while in a high-mental-flow state is no longer a terrible frustration: Getting back into the state now requires a few seconds' reading over my notes instead of (potentially hours) going over old decisions to rebuild the state from scratch.

The devlog has actually become my anchor. Whenever I finish something or resume after an interruption, I scroll back up a little or look at the list of todos maintained at the bottom of the file. It is very comforting knowing that it is always there.

3. Stress management

It is well known by psychologists that identifing feelings by name makes them less intense. I find that documenting my work makes it less stressful, which has become my primary method of dealing with stress. Previously, the only way I could deal with it was by deciding that I didn't care if the project failed, as the concept of caring and having it fail was too much to deal with. Writing down my todos, thoughts, problems, and swearing about them a little in text that others won't read without my permission has been very positive for my mental state and mental health.

4. I don't want to worry about that right now

My time management is better. Apart from being able to easily resume flow after interruptions, I also manage subtasks better. Whenever I have a problem that I can't solve immediately, I describe it and add the word "todo" somewhere. This triggers me to think, "can I fix this in five minutes?". If so, I fix it immediately, and then resume flow by reading over what I was doing beforehand, and so hardly lose any time. If I start it and then it takes more than five minutes, I just abandon it and leave the TODO. If it is important I will add it to a real to-do list somewhere (perhaps at the bottom of the file) so it doesn't get lost. Sometimes I search for the word "todo" and then change the ones I have done to "done" (which is satisfying) and make sure the others are still not urgent, either deleting the word or moving them to a better-tracked list.

The end result of this is that I no longer come back to an old problem and say "oh yeah, I meant to fix that but I forgot.". I now forget intentionally, and don't forget the important things.

5. What did I do this month?

I have a record of what I did. This lets me tell other people what I have been doing -- we got audited last year for research tax breaks and I could provide evidence of the research I was doing. This saved everyone lots of effort in trying to reconstruct how much of my time had been spent on research.

6. Why did I do that again?

When working on an extended project, there is a complete record of all the design problems I considered and all the sources and external resources I investigated as part of the design process. This can be extremely valuable later on, either for onboarding new developers or handing over the project to someone else.

This is partly so important because many projects do not have great test suites. A thorough test suite, with each test's reason for existence well explained, is also very useful. Tests that you don't know why they are there can't be modified. If you understand the requirements, you know what you need to redesign when they change.

7. When did I first think about that?

This approach is standard practise for research scientists (which I used to be, and is where I learned it).

If there is ever a patent dispute or argument about where something came from, I have some evidence about where my ideas came from.

Further reading: https://simpleprogrammer.com/bullet-journal-productivity-programmers/

PostMortem: Why the GIT/Conan toolchain migration took a year instead of the original estimate of a week

1. There was actually quite a lot of development to do. During the course of this project, Jonathan:
    * learned Kotlin and TeamCity's DSL (through several iterations)
    * learned conan and fixed some issues with it (it evolved from version 0.26 to 1.3)
    * wrote many lines of code, generated many more. Often several hundred lines per day for months.
    * ran hundreds of test builds in teamcity, and debugged each one
    * debugged through many problems with Git, GitVersion, and Git-Tfs
    * documented everything
2. We kept changing the design. Each time it changed, there was a cumulative amount of other things to fix. icu, build.py adjustments, package.py adjustments (still going on), is2c changes, re-migrating projects, etc.
    * Keeping the list of projects as a static list (is2c/proj_names.py) was a really good decision, as it was very quick to make changes and basically did not require testing
    * This was partly unavoidable (we are designing something new, after all) but there were several possible mitigations here.
    * Adding people to the project before it was ready introduced more dependencies before the foundations had solidified. This caused a lot of unnecessary work (maybe a cumulative total of three months).
    * Trying to migrate all the ti dependencies was a bit of an effort. There were actually lots of dependencies (51, currently) with a very complicated dependency tree, 9 levels deep. This is pretty wild for c++ libraries; most open source projects do not seem to handle this well. The only reason we got away with it until now was the monolithic architecture; unfortunately we are now deeply embedded in the obvious maintainability nightmare that results from that approach. It would have been better to pick a project with only a few dependencies (say, three or four) to do first, and once that was solid, then automatically migrate many more. Unfortunately, Jonathan worked on the REDACTED team so it was politically justifiable to aim for REDACTED projects initially.
    * It didn't help that conan was evolving with us. In some ways that was good (they were very responsive to pull requests, often accepting and releasing within 24 hours); but it would have been better to let others evolve conan and pick up a more mature product once it had stabilized. Conan still does not have support for modifying multiple dependencies at once.
3. There were lots of existing problems that needed to be fixed before dependencies could be migrated.
    * The monitoring tool was still on an old build of a base library 14 (this took several days to fix, the architecture of that project was chandlerized)
    * The python wrapper of our binary protocol was using a checked-in copy of baselibrary.dll because it was initially deemed too hard to set up properly (this is now good, with a conanfile.py to build the dll and then setup.py to package it into a .wheel)
    * The python test library still required 3.4 so I implemented support for this and then removed it when the python wrapper turned out to need Python 3.5+ and we had to fix the python test library instead
    * Various other minor issues taking hours to days to deal with
4. Writing documentation was not allowed for in the original estimate. Jonathan hadn't written much user documentation in the past and it is quite laborious.
5. Jonathan had other demands on his time from his team. Getting pulled off repeatedly to work on team support or client work meant that the adjustments introduced by c and s were not immediately dealt with and took significantly longer to fix when they were finally discovered. Additionally, it made merges from TFS to Git significantly more involved as many more commits had been made while the merges weren't happening (this could have been handled a lot better by discovering the git-subtree merge process sooner). An additional complication was that the aim was for a solution that would work for most of the company's 1000+ released c++ projects – keeping things simple and flexible was always an additional consideration.

Normal conversation

I had a close friend tell me that I am very awkward in conversation. They tend to die.

Here is a short guide about how to do it better:

http://www.improveyoursocialskills.com/conversation/conversation-flow

I'm not sure how I've gotten away with not having internalized all this stuff for so long.

Addendum

I later got some very good advice about this -- focus on the situation. A useful technique for getting over the anxiety of a stilted conversation is to express an opinion of something nearby ("I hate that building, it's oppressive" or "these chairs are comfortable, I like them") or something that is happening. Getting over that first-sentence hump was a big deal for me -- I would get anxious about not talking, and the feeling of almost panic made it even harder to think of something to say. Focusing on the local environment or current situation and picking something out to discuss helped a lot.

Sharing an opinion also effectively invites the other person to share their own opinion.

The anti-jerk reading list

Start with "Nonviolent communication" , then read "How to talk so kids will listen and listen so kids will talk", and finish with "the seven principles for making marriage work". If you want to go all out, also read "Emotional intelligence".

http://www.improveyoursocialskills.com/conversation is short and good, although it skips the fundamentals above.

Related, although it will only make you seem like less of a jerk: "How to Win Friends and Influence People".

Datetimes are hard

This is a pretty epic bug discussion: python datetime.timestamp doesn't support leap seconds

related https://zachholman.com/talk/utc-is-enough-for-everyone-right

Copenhagen is confusing

The word "collapse" is confusing, it is better not to use it.
Just say: the measurement apparatus becomes part of the superposition.

Git merge moved folders

Short version: make a patch, change paths, apply patch, resolve merge conflicts, done.

Commands:

# git checkout master

# git pull

# git checkout mastertfs

# git pull

# git tfs pull

# git format-patch `git merge-base mastertfs master` --stdout > ../latest.patch

# script-to-change-paths--see-below ../latest.patch

# git checkout master

# git merge -s ours mastertfs --no-commit

# git apply ../latest.patch --ignore-space-change --ignore-whitespace --3way --whitespace=fix

# git commit -m "merge from tfs"

# git push origin master mastertfs

sed --in-place --expression 's|Modules/19.0/main/AAA/|Modules/AAA/src/|g' $1

sed --in-place --expression 's|Modules/19.0/main/BBB/|Modules/BBB/src/|g' $1

sed --in-place --expression 's|Modules/19.0/main/CCC/|Modules/CCC/src/|g' $1