Home of the Boogie-Woogie Feng Shui

A new knowledge system about people

I am design­ing a new rela­tion­ship man­age­ment sys­tem that I hope will stand out from exist­ing solu­tions by encod­ing facts and rea­son­ing about them. I want a sys­tem that both under­stands a near-English descrip­tion of a person’s life and can build that knowl­edge auto­mat­i­cally into a time­line of infor­ma­tion and cross-person links. It will under­stand that some bits of info are facts at the time it was recorded and oth­ers cre­ate new con­texts of knowledge.


There is no magic

Les­son: An expe­ri­enced engi­neer makes bet­ter guesses and checks them faster than a new engi­neer, let­ting them find a prob­lem faster. There is no magic or spe­cial abil­ity they pos­sess, and with effort you can reach the same quickness.

An engi­neer came to me for help today. She was unsure how to fix a defect she had been assigned. I could not point her at the answer because I didn’t know either. So we started from scratch. And start­ing from scratch means use the sci­en­tific method:

  1. Reread the prob­lem state­ment, that “When the user does X, no data is sub­mit­ted, but no error mes­sage is given either”. It men­tions the web page responsible.
  2. I made a guess about where to start look­ing and explained the guess.
  3. We inspected the code for ways it could fail. This pointed at a helper function.
  4. We guessed that A was hap­pen­ing and tried to prove it wrong.
  5. We made a bet­ter guess based on that knowledge.
  6. Do #4 again.

This process took us from a vague descrip­tion of an error to find­ing the exact error, which was fairly con­vo­luted. Nei­ther I nor the engi­neer knew the code ini­tially, yet we found a sub­tle logic prob­lem in a half hour, dur­ing which we gained a work­ing knowl­edge of the code. Then we pro­posed a solu­tion and tried to inval­i­date it. We failed, so we con­sid­ered our final hypoth­e­sis as cor­rect: Insert­ing this piece of logic repairs the logic hole and lets the code suc­cess­fully han­dle this bad data.

I could have done this inves­ti­ga­tion on my own and appeared like a magi­cian with my deep knowl­edge of arcane sec­tions of our code. Instead I showed them how any engi­neer should approach the prob­lem: guess and check, guess and check. This process if fol­lowed by an expe­ri­enced engi­neer and should be fol­lowed by a new engi­neer: it’s engi­neer­ing and it is scientific.

The only dif­fer­ence between a new and an expe­ri­enced engi­neer is the speed of the progress. An expe­ri­enced engi­neer knows more of the code’s struc­ture, its his­tory, its archi­tec­ture, and past prob­lems. They will jump from guess 1 to guess 10 in a few sec­onds. Each sub­se­quent guess will be faster and more sure (more accu­rate) than a less expe­ri­enced engi­neer. If there are 25 steps to puz­zle out, the expe­ri­enced engi­neer may go from 1 to 10 to 13 to 17 to 20 quickly then take 21–25 one by one, while a new engi­neer has to make each of the 25 or more guesses to get there. This is just speed from experience.

And that was the point of the exer­cise between me and the new engi­neer: they saw there is no magic in my knowl­edge or my process and there is no fun­da­men­tal dif­fer­ence between our skills. The only dif­fer­ence is in expe­ri­ence and how quickly each of us can rea­son about and test code. And expe­ri­ence is there to be gained by any­one. I hope when the new engi­neer becomes an old engi­neer they also don’t hide the process.

It is impor­tant to know there is no magic in your elders: you can become them.

Notes to a New Engineer — Kickoff

I am start­ing a series of posts based on the men­tor­ing I do for new engi­neers. When men­tor­ing engi­neers it is impor­tant to teach both spe­cific skills, prob­lem solv­ing, and men­tal mod­els. The first two are self-explanatory evo­lu­tions of the basic skills of engi­neer­ing. By “men­tal mod­els” I mean ways of fram­ing a sit­u­a­tion, such as from a cus­tomer point of view or a prod­uct man­ager view, which can help one think about the cor­rect han­dling of a situation.

Some of these points are from my own thoughts and con­ver­sa­tions but I don’t own them nor are they wholly orig­i­nal to me. Some points come from my cur­rent and past man­agers who have helped me grow as a leader and engi­neer. Some are from mate­ri­als and dis­cus­sions from the MBA I com­pleted last year. Some are from read­ings on the inter­net. To sum­ma­rize: I don’t own this knowl­edge. I am shar­ing it and I hope any­one who encoun­ters it will share it as well and con­tribute com­ments, feed­back, and other ideas.

The next data breach will be fake

It would be really inter­est­ing if a hacker found a way to har­vest new pass­words and pass­words being changed and faked a huge data breach to get mil­lions of peo­ple to change their pass­words.

Threat­en­ing fake data breaches if not paid a ran­som could be the next prof­itable hacker mar­ket. It would prob­a­bly work a few times, and cer­tainly muddy up the waters for both orga­ni­za­tions and peo­ple. Imag­ine try­ing to fig­ure out how to respond when 10 major groups have a data breach per week, but 2 of those are real and the rest are fakes. Chaos and mas­sive frustration.

Potential Wikis

Wikis are inter­est­ing. I love the page inter­link­ing and editable nature of them. In the past I have used Tid­dly­Wiki for a per­sonal wiki long before Ever­note or OneNote came along. That must have been back in 2004–7, though I check in on it now and then. It is a sin­gle HTML file that works like a wiki, mod­i­fy­ing itself. It is very impres­sive. It makes it easy to sync via Drop­Box too and backup as snap­shots in time.

I just vis­ited that link for the first time in a year or two though and found it’s been revamped, mod­ern­ized, and updated. It looks great! Might have to play with it again.

How­ever today I came across 3 other wikis that I may want to use for my per­sonal notes or for Arts­Fuse knowl­edge shar­ing with my col­leagues. I don’t know much about them yet other than the cur­rent trend is to use git for data stor­age and be eas­ily hostable with nginx on a python/ruby backend.

Realms - Git based wiki writ­ten in Python Inspired by Gol­lum, Ghost, and Dillinger. It is Markdown-only which is a painful lim­i­ta­tion. But it has live col­lab­o­ra­tive editing.

Branch­able — This is a hosted solu­tion start­ing at $10/month

Gitit — Git-based wiki that can be edited in many markup lan­guages and export to many more includ­ing PDF, EPUB, and Medi­aWiki format.

If these can be cus­tomized with­out a ton of effort I may try them over OneNote which is my cur­rent favorite. Wikis may be a bet­ter solu­tion to shar­ing knowl­edge with cowork­ers than shared OneNote folder, but they also have to com­pete with Drop­box and Google Drive for collaboration.