Meltdown and Spectre Computer Vulnerability Cubicle Magnets

When something bad happens, like Meltdown or Spectre, or Heartbleed, your engineers end up having late nights,  grueling daily update meetings.  At the end of the day when the dust settles, we don’t get a Service Ribbon that shows your involvement in those days of battle.

With the security industry creating well-recognized brands and logos some of the bigger vulnerabilities, we might have those opportunities to make sure those that join the firefight get the tech equivalent to the service ribbon.

At Badgly, we’ve created some cubicle magnets that allow for a commemoration of those days when you lots lunches, nights and weekends to solve some of your companies biggest and burning issues.  We’ve got a set of Vulnerability badges for Meltdown, Spectre, and Heartbleed.  We’ll update this post with images when they get back from the printers.  Some sample renderings are below.

For geekiness points, all the vulnerability badges will be golden-ratio rectangles.  Is there a vulnerability that you’d like to see memorialized?  Post comments below.




The Evil Genius of the Amazon Six Page Narrative

One of the leadership tools that Amazon uses internally is the Six Page Narrative.  This is where a decision that needs to be made is presented as a narrative document, restricted to six pages, with appendixes.  The outcome of the narrative is a go/no-go on the subject.  The meetings that discuss the narratives are typically 15 minutes of silent reading/note taking followed by 30-45 minutes of deep dive questions and clarifications.  The best possible outcome is 5-10 minutes of discussion and then a “Good narrative, I agree, go do it!”.  A bad outcome is “I now have more questions than I started with, let’s stop the meeting now and meet again in two weeks.

The narrative is actually fairly evil in its construction. The six pages and the structure of the document itself are ultimately fairly arbitrary.  It is the forced revision/improvement/validation that is forced to fit into six pages that is critical.  As many a good orator has mentioned conveying detailed content concisely takes longer to prepare than long form.

The six pages is a hard limit for the narrative (and no, you should drop to 6 point font with 0.25 inch margins, that defeats the point).  By forcing a limited set of pages it forces the author (or authors) to go through numerous drafts to reshape the document, polishing it by ejecting, rewriting abstracting and summarizing as you go along.   This forces a reasonable taxonomy and structure of information within the subsections and a good ordering of information. This repeated revision to fit takes the mental work that the reader must undertake to correlate and rationalize the information.  If the document takes the reader is taken through a clear path where the questions are almost immediately answered, it shows clarity of thought and understanding, increasing confidence in the author far more than a set of bullet points on a powerpoint.

One final part that is overlooked in the six-page structure is the appendixes. The appendixes carry the data, the validation, the information that feeds into the narrative that isn’t needed to support the narrative, but is needed for completeness and cross-reference.  You can say “our data supports this information as follows”, the appendix allows the reader to dive deeper into the data to ensure that they would draw the same conclusion, but assuming that the data presented in the narrative can be taken as interpreted correctly, then the narrative can still hold it’s own.

This approach is common when needing to write a concise 1 or 2 paragraph email. You write what you want, re-work, re-work, re-work.  Placing a sometimes arbitrary boundary on an output forces a deeper consideration than would otherwise be delivered.

Other Amazonian documents have a similar templated structure that to some extent is inviolable structure.  The 1 pager, the working back document, the root cause analysis, all structured to force the presenter to think, structure and organize their thoughts.  For communicating business information, I don’t think I’ve seen it necessary to present a Powerpoint for quite some time.

The narrative form still has some risks.  To stick with the narrative form, authors are sometimes tempted to inline what is better communicated with tables a) option a – 15, b) option y – 25, c) option z – 10.  By its nature, this information is tabular in form.  A small structured table can carry a lot more information and take considerable cognitive load away from a reader.  The narrative author must balance the use of prose with other information dense methods of presenting information.

What other documents does your organization use to communicate ideas?  Are the powerpoint templates still the ruler of your domain?

This is a Quora crosspost from this answer.  I’m reposting my popular answers here for posterity.  Obviously in a different context it has been modified slightly primarily putting context inline

Towards a Skate-Dad (Day 1)

So this Christmas, we bought our 10-year-old a skateboard.  As part of ensuring there is a bit of extra commitment, I’m joining them in learning to skate.  So let’s put it into context here…  43 years old, 225 lbs, mostly sedentary lifestyle tech geek…  so that probably paints the picture.

So why am I doing learning to skateboard?  The first part is to do the whole role model thing.  I have reasonably high expectations for my kids to be resilient through adversity, to put in the time to practice to get good at things.  If I expect them to get up after hitting the pavement, I can expect them to…  They are a hell of a lot less fragile than I am and should be able to get up and move after a fall that would wipe me out.  I’m also doing this as part of a general effort to get fit and ensure that can learn new physical skills.

What’s my end point?  Realistically, I currently have little interest in doing tricks, I’ll probably declare personal victory when I can push, tic-tac and pump on a half pipe and turn…  We’ll see how much further it goes from there.

This part of this blog will give periodic updates on my quest to get to the endpoint.   Today is day 1…  My kit is an 8.5″ board, 54mm wheels, from the local Skateworks shop.  I’m a bit of an analytical geek, so I’ll also be writing up some of my thoughts, most likely ill-founded, for others to pick on.

So Day 1…  Practicing pushing, very simple tic-tacs… Becoming kind of comfortable.  Of course, day 1 something has to happen.  If my memory serves me right, my front foot wasn’t in the right spot, I tried to do a push, and it all went downhill from there.  I ended up rolling my left ankle and landing on my right hip.  No bruising on the hip, but the ankle is now strapped.   We’ll see how the healing goes, but I’m eager to help the kids out on the park again before the new year break finishes.

Fortunately, or maybe not so, fortunately, it took a few hours before the pain from the rolled ankle to kick in, so I got about another hour of practice at the skatepark.


We’ve all done it, sat around a table dissing the previous generation of our product.  The previous set of engineers had no idea, made some stupid fundamental mistakes that we obviously wouldn’t have made.  They suck, we’re awesome.  You know what, in 3 or 5 years time, the next generation of stewards of the system you are creating or replacing now will be saying the same thing – of you are your awesome system that you are slaving over now.

So what changes?  Is the previous generation always wrong?  Are they always buffoons who had no idea about how to write software.  Unlikely.  They were just like you at a different time, with a different set of contexts and a different set of immediate requirements and priorities.

Understanding Context

The context that a system is created is the first critical ingredient for a system. Look to understand the priorities, the tradeoffs and the decisions that had to be made when the system was first created.  Were there constraints that you no longer have in place, were they restricted by infrastructure, memory, performance?  Were there other criteria that were driving success at that stage, was it ship the product, manage technical debt or were there gaps in the organization that were being made up for?  What was the preferred type of system back then?

Understanding these items allow you to empathize with system creator and understand some of the shortcuts they may have made.  Most engineers will attempt to do their best based on their understanding of the requirements, their competing priorities and their understanding of the best systems that can be implemented in the time given.  Almost every one of these constraints forces some level of shortcut to be taken in the delivering of a system.

Seek first to understand the context before making the decision that the previous team made mistakes.  When you hear yourself making comments about a previous team, a peer team or other group not doing things in the way that you would like to see it, look for the possible reasons.  I’ve seen junior teams making rookie mistakes, teams focused on backend architectures making front-end mistakes, device teams making simple mistakes in back-end systems.   In each of these contexts, it is fairly obvious why the mistakes would be made.  Usually, it will be within your power to identify the shortcoming, determine a possible root cause by understanding the context and shore up the effort or the team to help smooth things over and result in a better outcome.

Constraining Your ng-Whatever

When faced with frustration on a previous system, consider carefully a full re-write into a ng-whatever system, or incremental changes with some fundamental breakpoints that evolve, refactor and replace parts of the system.

It is almost guaranteed that the moment a system gets a “ng-Whatever” moniker attached to it, it becomes a panacea for all things wrong with the old system and begins to accrete not only the glorious fixes for the old system, it will also pick up a persona of its own.   This persona will appear as “When we get the ng-whatever done, we won’t have this problem..”.

These oversized expectations begin to add more and more implicit requirements to the system.  Very few of these will be expectations will be actually fulfilled, leaving a perception of a less valuable ng-Whatever.

Common Defect Density

I’m going to come out and say that most engineering teams, no matter how much of a “Illusory Superiority” bias they may have are going to be at best incrementally better than the previous team.  With that said, their likelihood to have defects in their requirements, design or implementation will be more or less even (depending on how the software is being written this time around).

The impact will typically be that the business will be trading a piece of potentially battle hardened software with known intractable deficiences, with a new piece of software that will both have bugs that will be only be ironed out in the face of production.  Even worse, there will always be a set of intractable deficiencies that are now unknown – only to be discovered when the new software is in production.

When the original system was created, it is highly unlikely that the engineering team baked in a set of annoying deficiencies.  Likewise, the new system will, to the best of your teams understanding,  not baking any deficiencies into the system.  You need to make a conscious decision to take the risk that the new issues will be less painful than the old issues are.  If you can’t make that call, then sometimes refactoring and re-working parts of the system might be a better solution.


What have your experiences been with ng-Whatevers?  Have you found that your team can reliably replace an older system with a new system, and see that in a few years time the new system is held with a higher level of esteem than the original system?  Follow this blog for more posts, or post comments below on this topic.


Onboarding, Technical Debt and The Future Self

Any organizational leader is always challenged by the ability to quickly get new engineers active and effective as they join the company.  This is commonly called “onboarding”.  Common approaches include

  • Boot Camps similar to Facebook,
  • Intern style mini-projects
  • The dreaded fix-a-few-bugs in the first week
  •  The sink or swim, here is your desk, hit the ground running

All of these approaches (except the last one) attempt to

  • Familiarize a developer with the code base
  • Do generally low-risk changes and get the code into mainline or production
  • Start to understand the systems and tools that the team uses

Generally, the stated intent of on-boarding an engineer is to bring them up to speed and be productive.  In this post, I’d like to turn this on it’s head and ask the industry to not look at the onboarding process as a way to get an engineer started, but rather a way that the existing engineering team showcases the code, the architecture, the behavioral norms and the vibe of the engineering team.

I’ll lean on the analogy of an rich elderly aunt visiting from out of town throughout this post.  The onboarding process is like that awkward first few minutes where you walk through the house showing the washroom, kitchen, where they are sleeping and other items that are needed to make the stay welcoming.  However that five minute tour is usually at the end of a few days of frantic cleaning, scrubbing, removing trash, setting rules for how the kids should act, and so on.  After all your familial reputation is on the line here.  Who want’s an awkward Thanksgiving or Christmas where there are the little comments, the glances and whispering from the aunt who has formed her opinion of  how you operate as a family.

When a new engineer arrives at a company, the deepest scrubbing we usually do is to make sure their desk is clean and the computer is there.  It leads to an awkward recruiting moments when the reputation of the company is passed on to other engineers as the new engineer is asked ‘How’s the new Job’.  In the same way the elderly aunt is associated, but not vested with you. So is the the new employee who hasn’t quite felt part of the team.

Inverting Onboarding

Turning the onboarding process on it’s head also has some material impact on the way the engineering team see’s itself.   When you have a visiting relative, you want to show that you are a the good part of the family, and have your things in order.  Use the onboarding experience as a way to ensure that the team presents a real demonstration of how the team is awesome.  You can’t fake awesome for very long.

Make your leaders of the organization accountable for how the team is presented to the new hire.  Make those leaders ensure that the 2-4 week honeymoon period for the new hire sets the basis for a long term relationship.    The discussion shouldn’t be whether an engineer is now productive for the company, it should be whether the company has made an engineer productive.

That inversion goes a long way to extend that honeymoon from a few weeks to a few year.  That inversion helps engender an organization that fosters growth and development during an engineer’s tenure.  That inversion changes the way the organizational leaders look at how they run the organization.

Make Your Leaders Accountable for Onboarding

The critical part of this inverted view of onboarding is making the leaders of your engineering team responsible and accountable for the onboarding of the engineering team.  Some indicators of issues to consider when examining the onboarding  process.

  • Can the new engineer checkout and build with no major hiccups?  Typically there is a verbal tradition that carries engineers from the written references to being productive.  (“Oh yeah, you need to this or that, we should update that”).
  • Does the new engineer need to talk to other engineers for a basic bootstrap of their environment?
  • Does the new engineer need things explained on a whiteboard?

Realistically, the new engineer doesn’t have the ability to influence how quickly they come up to speed.  There will be an intrinsic ability that the new hire carries, but the largest influence of how the new hire onboards is carried by the organization.

By making the hiring manager and their lead engineers responsible for the effectiveness of the new engineer, it forces introspection on the team about how they manage their development how much of the way the team operates is transparent, captured, and communicable and how much is opaque and a form of verbal tradition.

Some measures that I push my teams to meet for a new dev are:

  • After the initial orientation and first login, be able to sync the code and start a build within 1 hour.  (This forces the hiring manager to ensure the permission groups, environments and access is all done before the hire starts.)
  • Have the engineer be involved in a code review within the first day, but before their first change. (This sets the bar for how the code reviews operate and the expected conduct for the engineers on the team).
  • Have a problem or proving task able to be resolved and pushed to a staging environment, device, into a build within the first day. (This drives an understanding of the way the development goes from the developer to production).
  • Have a debrief after the first day and the first week about the questions, points of confusion, suggestions and best practices that the new hire misses.  (This helps drive introspection for the team for the next round of hires).

Equivalence to Technical Debt

A lot of these negative indicators and the difficulty in achieving the measures are driven by the technical debt that an organization is carrying either consciously or subconsciously.  Finding opportunities to spot the technical debt that is causing friction within an organization are golden.

Technical debt in a development team is most visible to a new hire.  They walk headlong into it with open eyes and an inquiring mind.

Helping the Future Self

The future self concept covers the lack of familiarity that an engineer will have with some code or a system that you are currently working at some point in the future when you need to go back to it.  Over time, poorly written code – even written by yourself, becomes that code written by the clueless engineer a few years back.

Technical debt is usually correlated with old crappy code.  However while the engineers are writing the code, there is not the assumption that the code that is going in is crappy.

A new engineer being onboarded to a new system is in exactly the same place that a future self or a new transfer into the team will be seeing.    They don’t have the history and so it will always be more jarring to them.  Future selves and new transfers will have enough history that they will orient themselves back to familiarity very quickly.  Warts and all.

Learn From the New Engineer’s Honeymoon Period

Engineering leaders, should look closely at the questions, feedback, and interactions that a new hire has with their new code, systems, and team.  They don’t have the history or familiarity with the code that helps them skip the opaque or confusing bits of how you do development.  This will help not only with onboarding new hires, but also the engineer’s future selves, and people switching into the team.

Those first few weeks of a new engineer are extremely valuable, use it as a barometer for how effectively the team is managing technical debt and creating maintainable code and systems.

Don’t squander those first few weeks.  Also, keep your house in a state that your elderly aunt would like.

As always, vehemently opposed positions are encouraged in the comments, you can also connect with me on twitter @tippettm, connect with me on LinkedIn via matthewtippett, and finally +Matthew Tippett on google+.  You can also follow me on Quora, or simply follow this blog.

#ByMoonlight – Yosemite

Unfortunately it was a new moon when we where in Yosemite for a mid week getaway.  So I traded the moon for a flash or phone LED torch to do some light painting.  Enjoy!

Your typical landmarks –

  • Half Dome (from Glacier Point) just after sunset, with a painted tree in the foreground.
  • El Capitan, just after sunset (note the two lights which are climbers camped for the night) with the meadow in the foreground highlighted by passing cars.
  • The Yosemite park sign, much later in the evening, painted with phones in torch mode with stars in the background.

All photos are as captured, with no post-processing.

Feel free to comment below or reach out to me if you want to discuss.

Using Google’s “+” Email For Opting Out and Catching SPAM

Fortunately, with strong spam catching features in most of the mail systems, the bother of spam is considerably less than it was 10 years ago.  It is clear that the perennial concern about opting out being a magnet for new sources of spam is well and truly founded.  Fortunately, you can use the “+” option for email to opt-out safely as well as getting a solid read on the how the opt-out either cuts down on or increases spam. Read more of this post

%d bloggers like this: