I am designing a new relationship management system that I hope will stand out from existing solutions by encoding facts and reasoning about them. I want a system that both understands a near-English description of a person’s life and can build that knowledge automatically into a timeline of information and cross-person links. It will understand that some bits of info are facts at the time it was recorded and others create new contexts of knowledge.
Lesson: An experienced engineer makes better guesses and checks them faster than a new engineer, letting them find a problem faster. There is no magic or special ability they possess, and with effort you can reach the same quickness.
An engineer 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 starting from scratch means use the scientific method:
- Reread the problem statement, that “When the user does X, no data is submitted, but no error message is given either”. It mentions the web page responsible.
- I made a guess about where to start looking and explained the guess.
- We inspected the code for ways it could fail. This pointed at a helper function.
- We guessed that A was happening and tried to prove it wrong.
- We made a better guess based on that knowledge.
- Do #4 again.
This process took us from a vague description of an error to finding the exact error, which was fairly convoluted. Neither I nor the engineer knew the code initially, yet we found a subtle logic problem in a half hour, during which we gained a working knowledge of the code. Then we proposed a solution and tried to invalidate it. We failed, so we considered our final hypothesis as correct: Inserting this piece of logic repairs the logic hole and lets the code successfully handle this bad data.
I could have done this investigation on my own and appeared like a magician with my deep knowledge of arcane sections of our code. Instead I showed them how any engineer should approach the problem: guess and check, guess and check. This process if followed by an experienced engineer and should be followed by a new engineer: it’s engineering and it is scientific.
The only difference between a new and an experienced engineer is the speed of the progress. An experienced engineer knows more of the code’s structure, its history, its architecture, and past problems. They will jump from guess 1 to guess 10 in a few seconds. Each subsequent guess will be faster and more sure (more accurate) than a less experienced engineer. If there are 25 steps to puzzle out, the experienced engineer may go from 1 to 10 to 13 to 17 to 20 quickly then take 21–25 one by one, while a new engineer 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 exercise between me and the new engineer: they saw there is no magic in my knowledge or my process and there is no fundamental difference between our skills. The only difference is in experience and how quickly each of us can reason about and test code. And experience is there to be gained by anyone. I hope when the new engineer becomes an old engineer they also don’t hide the process.
It is important to know there is no magic in your elders: you can become them.
I am starting a series of posts based on the mentoring I do for new engineers. When mentoring engineers it is important to teach both specific skills, problem solving, and mental models. The first two are self-explanatory evolutions of the basic skills of engineering. By “mental models” I mean ways of framing a situation, such as from a customer point of view or a product manager view, which can help one think about the correct handling of a situation.
Some of these points are from my own thoughts and conversations but I don’t own them nor are they wholly original to me. Some points come from my current and past managers who have helped me grow as a leader and engineer. Some are from materials and discussions from the MBA I completed last year. Some are from readings on the internet. To summarize: I don’t own this knowledge. I am sharing it and I hope anyone who encounters it will share it as well and contribute comments, feedback, and other ideas.
It would be really interesting if a hacker found a way to harvest new passwords and passwords being changed and faked a huge data breach to get millions of people to change their passwords.
Threatening fake data breaches if not paid a ransom could be the next profitable hacker market. It would probably work a few times, and certainly muddy up the waters for both organizations and people. Imagine trying to figure 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 massive frustration.
Wikis are interesting. I love the page interlinking and editable nature of them. In the past I have used TiddlyWiki for a personal wiki long before Evernote or OneNote came along. That must have been back in 2004–7, though I check in on it now and then. It is a single HTML file that works like a wiki, modifying itself. It is very impressive. It makes it easy to sync via DropBox too and backup as snapshots in time.
I just visited that link for the first time in a year or two though and found it’s been revamped, modernized, and updated. It looks great! Might have to play with it again.
However today I came across 3 other wikis that I may want to use for my personal notes or for ArtsFuse knowledge sharing with my colleagues. I don’t know much about them yet other than the current trend is to use git for data storage and be easily hostable with nginx on a python/ruby backend.
Realms - Git based wiki written in Python Inspired by Gollum, Ghost, and Dillinger. It is Markdown-only which is a painful limitation. But it has live collaborative editing.
Branchable — This is a hosted solution starting at $10/month
Gitit — Git-based wiki that can be edited in many markup languages and export to many more including PDF, EPUB, and MediaWiki format.
If these can be customized without a ton of effort I may try them over OneNote which is my current favorite. Wikis may be a better solution to sharing knowledge with coworkers than shared OneNote folder, but they also have to compete with Dropbox and Google Drive for collaboration.