Hack hack hack...

An open journal-- some of it written for you, but most of it is for me.

7 Righteous Fights

With Heidi Waterhouse

  • Technical debt compounds in a way that is painful


  • get them early, reference labels -> will make it so much easier later
  • no words in logos or images



  • use 3rd party people that do this
  • leave room for encryption
  • sunset your data after a certain period


  • make your work modifiable


  • documentation helps us with onboarding and reduces context switches for seniors
  • production scripts and build sequences need to be recorded


  • tells us what we are doing without documentation


  • have you showed this product to anyone who is like the user (not the financiers) -> need to actually talk to them
  • show them the product and don’t tell them how it supposed to work is the hardest and most important part
  • “Making users awesome” - people don’t want to be using software, they want to be drawing or taking a photograph, software is just an intermediary


  • look at this on a non-retina screen
  • emulators and physical are totally different experiences
  • 8% of men are red-green color blind
  • status updates for nagios use red-green, which isn’t helpful
  • hide your mouse, use TAB instead
  • we are all temporarily able-bodied


  • Learn how to write ROI documents
  • diverse teams will help with these problems
  • money is the root of all business decisons
  • be productively lazy

Databases With Brad Urani

Brad Urani @confoo


  • atomicity: all or nothing. If one of 3 writes fails it rolls it back
  • Consistency:
  • Isolation:
  • Durability: DB survives

  • no-sql aren’t faster because of algorithms, they are faster because they did it because they did away with the guarantees

google spanner - reliable network because it’s with in their own fiber optics

SQL is declarative language

  • don’t give the computer exact instructions. Giving the comp a rough outline and the DB.

index is a tree

  • binary tree
  • doubled the size of the tree but only increased by 33% - O(log n)
  • balanced tree -> rebalancing in order to make it as fast as possible
  • why not add indexes to everything
    • disk space and inserts

Quick sort

  • fastest, but not that fast for records on disk

Merge sort

  • divide and conquor algorithm
  • O(n log n)


  • nested loop JOINs - O(n2)

Hash Join -> O(n)

  • Hash tables -> values are pointers because they are in linked lists
    • building the hash table from the beginning is expensive.
    • MD5? go with a bit key that doesn’t guarantee no collisions
  • good for lots of duplicates

Merge Join -> O(m log n)

  • lists are already sorted.

Query plans

  • explain or explain analyze -> can tune the query to be faster

natural selection process for finding the best query plan

  • like genetic selection
  • doing all this in milliseconds
  • Evaluation -> selection -> crossover -> mutation


  • cache warmup period
  • Least recently used (LRU) in memory cache

Working to Make Myself Obsolete

When I told my mother, an executive of 30 years mostly spent at Crabtree and Evelyn, about my goal to make myself obsolete she flipped.

“You are working yourself out of your job,” she warned. “You need to be doing the opposite.”

My mom fought through sexism for decades to maintain her influential role at the top of the hierarchy. My mother is a scrapper and she clearly had to defend her territory. From her advice on management issues however, it seems pretty clear to me she probably never got ahead of the tsunami of work that consumes managers’ everyday lives. I mostly observe managers fire fighting and doing implementation. This is a trap. We all want to feel important, but if managers are the single point of failure, things will fall apart.

I’ve mused about my take on maker versus manager, it can be hard to let go, but those that never let go of the hybrid role are doomed. The manager may not be, but the team is. We owe it to our reports to make sure we have the time to properly manage them. It feeds our egos to have a full calendar and lots of “important” decisions to make, but if that’s all we do then we will eventually drown in our own self-importance rather than develop the people on our team to help shoulder the load. Scale will break us.

So thanks mom for the advice, but I still strive to make myself obsolete, so the world will continue to spin without me. So I can go on vacation without stressing. So I can dedicate a good chunk of my week to 1 on 1s and so my lieutenants feel qualified and empowered to make the calls shape our team and product. I may be working myself out of a job, but at least I feel like I’m going to do this one right.

New Technology and Developer Happiness

What is the price worth paying to introduce a new technology into the stack? For our heavily junior team of 13 the price feels high. Our JS weapon of choice has been backbone and marionette. This toolset wasn’t determined by me. It was molded and implemented by a talented dev who might be a little short on leadership experience but has talent and intuition in spades. We’ve made some mistakes along the way, but the architectural choices he has made have served us well. Still about 8 months since its we push our first major feature set with marionette, the entire team has yet to be completely onboarded. We may be getting to the size where we can split our squad into front-end and back-end specialists, but to date that has never been discussed as a group. The fact that we all haven’t got there is a problem. It means that some of us aren’t capable to work on parts of the stack, which affects feature assignments and pairing.

This same dev is now suggesting that we introduce React to one aspect of the stack because of its rising popularity in the community. Our team spends a lot of time focusing on happiness at an individual level with 1 on 1s and quarterlies, but my priority isn’t individual happiness but rather team morale. At the moment, team morale is at an all-time high. Will introducing a new barrier to entry positively affect team morale because of its shiney? Will allowing the two JS leads on the team play with a new toy positively affect team morale? They both claimed in their last quarterly that their work brought them high levels of meaning and purpose and they found it challenging enough.

It is a tough call. I don’t have enough knowledge to know if this is truly a better tool or something new to learn for the sake of something new. How will we go about leveling up newcomers on two JS systems?

Goal Setting for Devs

I heard you, goals are important. I get it. I’ve watched the Ted talks and read the zillionth article on the importance of goals. I understand the psychology and the physiology. I’ve got a dirty secret though. I haven’t been able to set goals for developers. We’ve tried KPIs and they don’t seem to filter down to the individual contributor level. When I ran our apprenticeship program two years ago I tried weekly goals, bi-weekly goals, monthly goals and quarterly goals. The problem was, the constants, the areas the goals could be clearly defined were mostly areas of personal development – writing blog posts, learning keyboard shortcuts, giving a lunch and learn, etc. I had a much harder time defining goals for them to improve in their core job function, namely contributing well built features and pushing good code.

Recently we took a shot at changing our criteria for hiring and job responsibilities to being value based rather than bring task or milestone based. This rubric broke down our company values into behaviors and defined the expectations for each level within engineering. The resulting document sat well with the team and I think we are gettng closer, but I still can’t help but feel unfortable about the subjectivity of how to define a good productive dev. What devs do is complicated, which makes promotions and evaluation complicated. I don’t care whether you wrote a blog post this week if you pushed a great feature. I do care that you helped someone else push their feature or jumped in on a tough bug when everyone pretended they didn’t see it. But how do I formulate concrete actionable goals around that? Anything I come up with feels so arbitrary.

When we tried KPIs for the engineering team it made sense to have goals around the product. But for individual contributors who didn’t have a choice about what feature they build or how the product evolves from a high level, I could connect them to the department goal in a meta way, but not on an individual basis. How could they be held responsible for the adoption success a feature set, for example, that they didn’t have much agency in designing or implementing?

The best I can do for goal setting is to pull out actionable points from our longer-arching conversations and hold them accountable on the things that matter to them both. It feels like there has to be something better, but I haven’t been smart enough to figure it out.


Weekly 1 on 1s are not enough. Maybe if I did them better they would be, but mine are all on Fridays and often I’m not able to tease out anything more than the day to day updates and feelings of the past week. That’s not to say that I’m going to stop, 1 on 1s keep me connected to my reports and even if 1 out of every 5 is a breakthrough session then it is time very well spent.

The problem that I see in 1 on 1s as I run them is that it is hard to focus on the longer arching themes on a weekly basis. For whatever reason, it feels awkward to ask about career goals, work fulfillment, etc. with such regularity. Enter the quarterly. I’ve just completed my fourth attempt of quarterlies (not including the annual review). I’m happy with the conversations and the depth of the issues we discuss in those session but my attempt at this didn’t start very well.

Here were the set of questions from the first quarterly survey which I conducted using google forms:

  • How happy are you in labs?
  • I feel like I’m growing my skills
  • I get clear and frequent feedback about my performance?
  • Given the products we are building, what types of things do you want to work on?
  • What skills (on or off the keyboard) do you want to improve that you don’t see an opportunity to do in your current role?
  • I understand why we are building Learn and the related apps
  • If you answer that you get it, please summarize why we are putting so much work into Learn.
  • If you answered you don’t get it, please tell me what needs further explanation.
  • Anything else you want to discuss?
  • What is one thing that would make you happier or more productive?

This caused a lot of anxiety. Why am I doing this? What was I going to use this information for? Many of those first conversations were stilted, even confrontational. Someone actually took this time to give his two week notice. It wasn’t pretty. Even so, I was able to battle through these difficult conversations and pull out a lot of agenda topics that we were able to resolve as a group. This made it all worthwhile. Gathering the team in the room to talk about issues that were affecting all of us and re-focus our direction was incredibly fruitful. I also followed up with the individuals that took issue with the set of questions I was asking and had them help me craft a questionnaire that was easier for them to swallow.

Three month later the process went much smoother. Here were the revised questions.

  • I feel like I’m growing my skills
  • What is one thing that would make you happier or more productive?
  • In what ways would you like to grow your skills? What kind of support will you need?
  • Do you feel like you’re getting enough clear feedback?
  • How do you feel about the Lab’s processes in general?
  • Given the products we are building, what types of things do you want to work on?
  • I find the work that I do full of meaning and purpose
  • I am proud of the work that I do for my team
  • The work that I do is challenging
  • How would you rate yourself in the following 4 tenets of our “shipping culture” (circle one for each category):
  • Velocity
  • Quality
  • Ownership
  • Communication

This one clicked much better. I got great responses and we had a great team discussion. Processes changed, people were engaged and excited to debate with each other. I was able to present the group with statistics on aggregated stats on how challenged individuals felt and where we needed to improve as a group.

A year later, this is the best thing I think I do as a manager. We ask similar long form answers but have dropped the ratings of the department values in lieu of the company values (see future post on Value Based Assessments). With a young team, it isn’t uncommon for me to see career aspirations change quarter along with engagement and performance. I’ve found these quarterlies to be better discussions than the annual review. Some reasons might be, it isn’t as formal or mired in the connotations of a scary end of year process. I use google forms rather than some HR software, which seems pretty natural and lightweight for devs. I choose a venue that seems more informal but is still off-site (recently I’ve been camping out at Au Bon Pain). And yet, much of this conversation is spent on discussing performance, areas of improvement, how to grow, resetting expectations and ways to improve the team and product – all the things that I would imagine a good annual review process is supposed to do. This cycle I’ve scheduled 90 minutes for each session but not one actually was completed in time. People are talking for 2 to 2 ½ hour stretches even though it is basically the same set of questions that I’ve used for the last three rounds. This is a huge investment of time. All said and done I will have done more than 30 hours of quarterlies before preparing a deck we can discuss as a group. But this is working and the conversations have improved every quarter.

Even with its rocky start, quarterlies have served us well. I would have never known many of the team’s process pain points without these conversations and it has saved me when performance slips so that I can get on the record to address it quickly. If annual reviews are broken my first guess would be that even if they are conducted well, they are just too infrequent. Things on my team move too quickly to address on a 12-month cycle. This is my best shot at making it better.

When I Didn’t See It in the Interview

Raw intellect isn’t enough. Just like product market fit we need to see person-job fit. How can we test it? Good people with drive and patience for change and a healthy sense of duty seem to be able to adjust to nearly any job for a short period. We can all do any job for six months and knock it out of the park.

I think about a particular interview where I left so excited about the candidate. They were quirky, but thoughtfully engaged. They grasped what we did here and why it was important. They thirsted for new knowledge and challenge. They were young and ambitious. No work experience of any kind.

But when he arrived it was an utter let down. The focus wasn’t on getting as good as possible as quickly as possible but rather maintaining balance at all times. Never pushing himself to be in the trenches with his brethren in times as the pressure bore down on them or let the passion take him deep into the night when we feel the torment of an unfinished idea demanding completion.

All the raw materials were there. What did I miss? If we hire someone with no work history, does the onboarding process need to be different? Do we need to teach them not only how to do the job but also how to be an employee? What expectations did we set to encourage him to rise to be great?

I cannot move past my disappointment. I signed off on him. I had high expectations. Though not my direct report, I provided course corrections. As time continues to march on the disappointment builds. I notice the small improvements but never the grand about-face for which I hold out hope. That one day when he will wake up, open his eyes to observe and finally be dissatisfied with his mediocrity.


Transparency begets trust and trust begets transparency. It isn’t easy and it feels unsafe to bare your process and sometimes soul. Talking about the thing you least want to talk about has been something that has helped our team address the weirdness that exists between our people and processes. But it wasn’t always like this. We used to ignore or only privately address what needed to be discussed the most.

A few months ago, during a period when a lot of new hires were starting and suffering from imposter syndrome, I tried to reinforce our culture of transparency and honesty by telling my team that I wouldn’t hire myself for our team. I assume that isn’t something that most managers admit and I explained my rationale. I’m not a strong enough coder to hang with them. I don’t complement the personalities we have. I don’t bring enough of a unique perspective as an individual contributor. It pains me to even write this, let alone tell my teammates that this is how I feel. Doing this led to a bunch of other team members describing their version of imposter syndrome and clearly put the junior members at ease. That is all to say, that saying the thing I least wanted to say helped build trust with the newest folks and let them know what I worry about which means they can be more sure when I’m confident. Always acting one way or another isn’t natural. Transparency, therefore, may start with the act of humanizing yourself and being vulnerable.

Team buy-in is tough to earn. It is much easier when the process is created and enforced by the team. As the manager, I can try to keep it on guardrails, but determining it and enforcing it myself would be a mistake. Maybe this isn’t sustainable with a bigger team. What if all the laws in this country were determined democratically by the entire population. It would be way too heavy. But with a team of 13, this is still possible and it is so much stronger when the policing is done by the team rather than me.

Transparency communicates trust. Exposing our vulnerabilities as an individual or an organization encourages candor and self-reflection. Putting a positive spin on everything doesn’t equate to boosted morale because it leads to whispers, eye rolling and eyebrow raising in the hallways. It is human nature to latch onto weaknesses, failures, and negatives and so if these deficiencies are not squashed publicly then they fester. They use rumors as sustenance and mutate in unpredictable ways. Talking about the hardest things right away is painful, but a preferable alternative to passively deferring to hearsay.

Transparency is hard. Generals must be able to make decisions. Soldiers must follow orders. We run into trouble is when soldiers don’t buy into the purpose or mission. Even the most ardent followers will lose enthusiasm over time if they don’t feel like they can influence the decision making process. And so what we find is people will do enough to keep their job. They half-heartedly go through the motions. In short order, that becomes the norm and apathy is a difficult virus to contain. And so while we can’t ask everyone for their input on every decision, if we know what is important to our people, we can ask them at the right times. This requires the decision maker to actually know their people and that takes a serious investment. Do you have time for that? I guess that’s up to you, but second guessing, rumor squashing, and low-morale also eats up time so maybe this would be worth some investment.

Peer Mentorship

Next week I’m going to introduce a new 1 on 1 system on our team. I currently have 8 reports and the other manager on our team has 5. The load of weekly 1 on 1s is quite large if we are truly doing a legitimate check-in. And so, I’d like to try out a system of peer mentorship where peers conduct one on ones with each other for a week to 2 weeks a month. This means we will need to spend time training the team on how to conduct 1 on 1s which I will assume will force us to consider how we currently conduct our 1 on 1s and how they could be better.

Peer mentorship organically already exists on the team. We see natural gravitations along lines of technological specialities and personality types. I’ve done my best to find assignments for these pairs to share a chunk of time working together and I’ve always been impressed with the results. Formalizing this process through this peer mentorship check-in system should further reinforce that natural alliance without forcing devs to be people managers.

We’ll see how this experiment works out, but I’m excited to give it a try. Trusting team members with the task of developing their peers has almost always led to positive results. I expect the same here.

My Take on Maker Versus Manager

I toed the line for months trying to code a little and be the manager I wanted to be. When the team was at 8 I could find time to block off a morning without meetings or distractions. I could be a hybrid. As we grew to 12 it became untenable. The code I contributed was copy and CSS changes. Barely anything that was worthwhile from a contribution perspective. Letting go was the healthiest thing I could do. I’m not a coder anymore and I admitted that to my team in a frank conversation about imposter syndrome a few weeks ago. I’m a conductor. My job is to make sure the symphony continues to play in harmony. To draw out the sounds and rhythms of my individuals through 1 on 1s, quarterlies and conversations in the hallways.

Being an effective hybrid is possible. We have one. He is a great individual contributor and without fail he does his 1 on 1s and still pushes a ton of code. It works and he is getting the reps he needs to be a future CTO. Taking him off the keyboard would make him miserable and so he’ll toe the line for a while. He has 5 reports and I’m wary to give him more.

I’ve heard coders talk about how bad managers are out of touch because they don’t build anything anymore. I agree, which scares me. Which is why I want to try an experiment. I went on a paternity leave in October for a full month. I totally unplugged and trusted my lieutenants to carry the load. It went fine. No fires. Nobody quit. No month long rabbit holes anyone fell into. There was some maintenance and fine tuning to be done upon my return and some of the project assignments were off, but overall things went well. Meaning that if I disappeared for another month things would likely be fine again. Meaning I could become a dev for a month and let my lieutenants run the show again. I think it would be hard for me to resist my natural inclination to push, nudge and otherwise direct how the team runs, but what might happen if I stop going to all the high level meetings? We’ll find out. I’m going to propose we try it next month.

To be the manager my people deserve for a team of certain size I needed to let go of my drive to code. Sure I can nibble on small projects, but my days of plugging in and zoning out are seemingly over. Hybrids can be of value, but if you are running the show and managing anything larger than a team of 7-8 then you are doing yourself and your team a disservice by trying to focus on anything but your people.