Skip to main content


The four dangerous animals of Product Development

 Taken (almost) verbatim from highly informative blog: _____ This is going to be a short walk in the product development zoo, I hope you’ll enjoy the ride! The HIPPO – the Highest Paid Person’s Opinion It can be tempting to give in to the HIPPOs – founders or CEO or VPS who want to make all the decisions – but don’t let them steer you off course. Bring everything back to your vision and objectives. If the HIPPOs aren’t aligned with those, you could be headed for dangerous waters. Don’t let your HiPPO kill your ideas – inform them with data and make them a  Data-driven HiPPO ! Read more about  what happens when a HIPPO runs your company . The WOLF – Working On the Latest Fire The WOLF has a short attention span and a temptation to jump from one problem to the next. They tend to only enjoy fighting fires, This will disrupt your team’s focus and effectiveness, making you easy prey for your competitors. Create a proces
Recent posts

Love's Pensive

The truth is, once you fall in love with a person, you never give up on loving them. Maybe your love never finds the courage to be expressed, maybe it was expressed but never reciprocated or maybe it was reciprocated and still didn't make through. Or all of the above at different times. So your love stays, right there in your heart, never giving up. Some days you cry until your ribs shake like tectonic plates saying it's okay. Other days, you convince yourself that you deserve better. Years pass and time builds a fortress around that chunk of your heart. Love ferments into a sour disdain while butterflies drown in a reluctant resentment. You take charge and distribute yourself in other relationships, that form bricks of your fortress. And you forget it for a while. But then somewhere, you hear their favorite melody in a restaurant. You think of their lame jokes on an uneventful bus ride through the lanes near your old house. In a crowd of strangers, their perfume flits through

Never run "python" in your "Downloads" folder

  One of the wonderful things about Python is the ease with which you can start writing a script - just drop some code into a   .py   file, and run   python . Similarly it’s easy to get started with modularity: split   into   and , and you can   import my_lib   from   and start organizing your code into modules. However, the details of the machinery that makes this work have some surprising, and sometimes  very  security-critical consequences: the more convenient it is for  you  to execute code from different locations, the more opportunities an attacker has to execute it as well... Python needs a safe space to load code from Here are three critical assumptions embedded in Python’s security model: Every entry on  sys.path  is assumed to be a secure location from which it is safe to execute arbitrary code. The directory where the “main script” is located is always on  sys.path . When invoking  python  directly, the  current dir

The missing guide to remote onboarding

  0. Equipment, accounts, access should all be setup BEFORE day 1. If someone starts work without these things you need to make that process better first. 1. First thing should be a video call with your manager. Ideally they will be available for questions for at least the first 1/2 of the day. If you run into problems they should be able to take action right away and not when they're done with meetings 2. The manager should prepare a list of things to read in your first week. Wiki, chat rooms, code, etc. This list should be explained during the first call and sent as an email to reference over the first few weeks. One of those links should be documented expectations. Not informal, verbal information. Documented publicly to make sure everyone is on the same page (new hire, manager, co-workers) Ideally every company >100 people will have an up to date website with org chart information, user aliases, email, phone numbers, etc. This is going to be crucial to new hires to understan

Filtering bullshit

The three way filters to keep bullshit away: 1. As Munger said: “Show me the incentive and I’ll show you the outcome.” Be wary of views coming from people who are not free to speak their minds on the topic at hand, because of their existing incentives. 2. Favour views from those who get paid for being right, discount views from those who get paid for sounding right. 3. The balance of power is being overturned by information technology. Favour people who deeply understand it and work it into their world view.

Permanent skills

Permanent Skills Weir was one of the most popular instructors at West Point in the mid-1800s. This is odd at a military academy, because he taught painting and drawing. Weir’s art classes were mandatory at West Point. Art can broaden your perspective, but that wasn’t the point. Nineteenth-century West Point cadets needed to be good at drawing because cartography was in its infancy. High-quality maps of the United States – let alone, say, Mexico – were scarce, if they existed at all. Military officers were expected to draw maps on the fly and record a battlefield’s topography. It wasn’t a niche; it was vital to the war. Weir’s favorite student, who passed the time at West Point drawing river bends and mountain ranges, was Ulysses S. Grant. West Point no longer offers drawing or painting classes. Its sole cartography course emphasizes mapping software and technology, as you might expect. Drawing was an expiring military skill. Critical in one era, diminished in the next, unmentionable th

Rob Pike's 5 Rules of Programming

 Rob Pike's 5 Rules of Programming Rule 1. You can't tell where a program is going to spend its time. Bottlenecks occur in surprising places, so don't try to second guess and put in a speed hack until you've proven that's where the bottleneck is. Rule 2. Measure. Don't tune for speed until you've measured, and even then don't unless one part of the code overwhelms the rest. Rule 3. Fancy algorithms are slow when n is small, and n is usually small. Fancy algorithms have big constants. Until you know that n is frequently going to be big, don't get fancy. (Even if n does get big, use Rule 2 first.) Rule 4. Fancy algorithms are buggier than simple ones, and they're much harder to implement. Use simple algorithms as well as simple data structures. Rule 5. Data dominates. If you've chosen the right data structures and organized things well, the algorithms will almost always be self-evident. Data structures, not algorithms, are central to programmin

"Trust" as the currency of leadership and its role in middle management

Leaders are successful when they inspire change and build support for ambitious goals. But their efforts fall flat if they are not trusted; followers only follow leaders whom they trust. Trust determines whether people believe what you say and whether they are disposed to support, ignore, or contest your leadership. Most importantly, trust is required to get people to set aside fears and concerns in favor of potential organizational benefits (especially when they may not benefit at all).  As the military demonstrates daily, trust enables people to make sacrifices for the greater good. Trust is not the same as likeability. Leaders can be trusted but not necessarily liked. The key factor in being trusted is to be considered constructively dependable.  Trust is built on followers’ perceptions of three qualities of the leader:  being true to your word;  competence, and  acting in accordance with shared values.  The first quality implies that you are honest in what you say, that you do not