Podcast Pick: A16z

I have been enjoying the A16z podcast for the last couple of years. It’s regular, dense content on a wildly varying set of technical subjects. I love hearing Benedict Evans talk about, well, anything–I find him quite insightful. But the podcast is not so dense I can’t listen to it on 1.4x speed.

I tend to listen to the more software specific episodes on APIs and on B2B2C business models (which seems to have been deleted). But every so often it’s nice to be jarred out of my world and listen to an episode about product or space or investing.

You can listen to past episodes here and get the RSS feed here.


AWS documentation now open source and on Github

TypewriterThis was announced recently. The AWS docs are now available on Github for everyone to review and improve. I love documentation (have for years). I think it’s great that AWS is now allowing PRs against their documentation. Some products have not yet uploaded their docs, ahem. It can only improve the speed of change.

I think it will also give a good glimpse into usage stats of AWS services. If a service doesn’t have any PRs or issues opened, it’s unlikely to be widely used (or, alternatively, it could be totally stable, or have users that don’t use Github). It’d be a fun project to pull the number of contributions to these repos via the Github API and publish that data.

I still feel that guides like og-aws have a place in the world of AWS documentation–opinions and real world stories fit better there than they do in official AWS documentation. And this is still too new to know if PRs and fixes will be pulled into the docs in a timely manner. But it’s great to see the AWS teams experimenting with ways to improve their documentation at scale.

Useful Tool: Intercom

Intercom In WallIntercom has been extremely helpful in allowing targeted messages to help users gain knowledge of The Food Corridor application. (Thanks for the recommendation, OTL!) What I’ve found most useful about Intercom is that it allows non technical users to build rulesets to target specific messages. This helps you help your users uncover new functionality, but only at the moment when the functionality is useful.

For example, if someone has signed up but not created a booking in TFC, we can send them a message a week after they sign up with a helpful link. This message can be via email or an in-app message, and if they respond to the in-app message, it notifies customer support just as if a chat was started any other way.

As a developer, all I had to do to get this data (which lives in our database) up to Intercom was to craft a javascript object. I added a method in the application_controller and have it cached for a while, because we ended up sending dozens of attributes up, and they are slow changing. From then on, the message targeting is done entirely within Intercom, where the non technical user can build rules based on this custom data plus any data that Intercom collects by default (last login, etc).

If you do want to target messages specific web pages (only pop up a message on page XXX, but not page YYY) you need an understanding of regular expressions. Depending on how comfortable your non technical users are and how complicated your site is, a developer may need to write the first regular expression and then have the other users extend it.

I’m skipping over other pieces of Intercom, including a knowledge base and in app synchronous chat. I think those are valuable as well, but the real win for me was allowing non technical users to control in app messaging with minimal software development investment.

Heroku and SSL

Heroku is a great hosting platform. Using it lets you focus on your application and not worry about operations tasks that might otherwise take developer time. Tasks like updating the operating system, patching the web server, and configuring third party services like monitoring. There are limits of course–once you reach a certain size it can be pricey. And if you have a app that has special requirements (example here), you might have to jump through some hoops. But if you are building a typical web app backed by a relational database, I’d highly recommend Heroku.

SSL is the technology which ensures that data sent over the web is transmitted untampered. Heroku has a number of offerings helping to make SSL easier to install; here’s a page to help you decide between the offerings. Last year Heroku announced support for free, automatically renewable SSL certificates. It does have some limits (no wildcard support, for example).

I just finished updating our system from an older SSL solution to the automated certificate management offering. Other than a slight hiccup around DNS being set up incorrectly by me (quickly fixed after a helpful answer from Heroku support), this update went swimmingly. Now rather than having to deal with SSL updates once a year (reviewing my notes, googling around and paying for a third party certificate), the SSL certificate is updated automatically.

This is just another example of Heroku taking something that is key to operating a web application and making it trivial. What a relief.

Pact Testing

PadlockI attended the Google Developer Group meetup last week and enjoyed many of the talks. It was a lightning session, so there were ten speakers. In particular I really enjoyed “Pact Contract Testing” by Claire Chen. The idea behind Pact Testing, which has been around since 2013 and has had four major specification releases, is to formalize the contract between an API consumer and producer and allow each side of the API conversation to be developed independently. You can record the interactions between each consumer and producer and re-play them during testing to verify that no regressions have occurred. It’s really designed for a situation where you control both the consumer and the producer and want to verify that there are no breaking changes when either of them evolve.

So, this seems like mocks and stubs on steroids with the additional benefit of being cross platform (many languages are supported) and exercising the entire producer or consumer independently. You can also run an external server to maintain all the pacts independently.

If you are running a microservices architecture, I’d strongly recommend taking a look at this. Next time I’m involved in an API consumer/producer project, I’ll definitely be using this, and will report back then.

See also “convince me that Pact Testing is a good idea” and “what is Pact not good for?”.

Departing The Food Corridor

Life is full of endings as well as beginnings. It’s easy to celebrate the latter, but the former are just as important. I joined The Food Corridor just about two years ago. This Friday is my last full day with the company. The company is left in very capable hands and has some exciting new plans. I look forward to cheering their success from the sidelines.

I am a firm believer in saying thank you, so I’d like to give some thanks to folks who have helped me out on my TFC journey.

The customers: Like any startup, we had to search to find our niche (“ideas are nice, but execution is a bitch”). But I’m glad to have been able to help shared use kitchens “spend less time in the office and more time in the kitchen”. What great people. They are working every day to help their clients (food businesses) build sustainable economic businesses. I learned so much and have a tremendous appreciation for the economic, regulatory and every day challenges kitchen managers face. Our clients were also forgiving of my mistakes, especially around matters of money and user experience. I appreciate their trust and patience.

The investors: A number of Colorado based angels and funds took a chance on TFC. Thanks for the rigor of your due diligence, the support you gave, and of course for the cash that is helping take TFC to the next level. But thank you most of all for your belief.

The informal advisors: TFC had a tremendous crew of folks helping out in many many ways with advice and connections and cheerleading. You all know who you are, and I appreciate every minute you gave to help TFC get where it is.

The formal advisors: We had a number of advisors who took hours and days out of their busy schedule to help out a newbie company, whether by reviewing documents, spending time at an all hands or investing. Thank you Christine, David and Mick.

The team: Small, nimble and potent. I learned something from each and every one of you. Charlie, thank you for the dashboard concept and your time. Lindsay, thank you for volunteering your time to make TFC better, and to help me see the system in new ways. Stephanie, I appreciated your questions and willingness to try new things and I’m so glad you found the right spot for you. Julie, I appreciated your focus on process and customer support. Chad, thanks for making those cold calls. Ben, thank you for your financial rigor and patience, as well as the ‘bigco’ perspective. Jim, Marcus and Joe, thank you for your early support and enthusiasm. Rachael, thank you for your good humor, food business perspective and constant attention to the TFC public image. Meghan, thanks for your attention to detail, your humor, your endless drive to get it right, and of course for your wicked intercom chops. Nenad, Luka, Michael, Seamus and Luciano, thank you for relentlessly putting the customer exactly where they should be–front and center. (If I failed to mention anyone above, please accept my apologies.)

My co-founder: Ashley, I wish you (aided by the TFC team and support system, of course) all the best in taking TFC to the heights I know it can achieve. Thank you so very much for the opportunity to hike alongside while I was able.

My wife: I can’t imagine pursuing any startup without the support of my spouse. The journey is crushing at times even with enthusiastic help. She’s been a sounding board, supporter, cheerleader and true believer. Thank you so much.

The joy of removing code

I am working on a project right now where my main task is to remove code. “What? I thought developers were supposed to add code, not remove it?” Well in some cases removing code actually can help a project. Some reasons to remove code: if the code doesn’t serve any purpose, if it isn’t executed, if it is for an edge case that never happens, if it has been superseded.

Removing code is easier with automated tests, but I still find myself using a combination of automated tests, manual testing, and the find command. (This codebase is ruby, if I was using java I’d use the type system.) It’s painstaking work, but will be good in the end.

My steps for removing code:

  • Start with a plan and and end goal in mind. Otherwise it can get overwhelming if you are dealing with a system of any size.
  • Create a feature branch
  • Identify one piece of code you’re going to either remove or keep
  • Make sure you know where it is called. If it isn’t called anywhere, remove it.
  • Remove any tests and associated functionality (views, helpers, etc).
  • Examine any state managed by the code for removal (database tables, etc)
    • Oftentimes I’ll just note that this should be removed in a few months, and focus on hiding the UX. It’s a lot easier to resurrect UX if you make a mistake than it is a dropped database table.
  • Commit the changes with a good commit message.
  • Fan out from there and see if you need to add anything to your list.

Take your time, don’t rush it.

Code that never runs can’t have any bugs, and is super fast. Think about removing some code today.

A follow up to “Deeply problematic but practical advice”

I linked to the first article Charity wrote, and wanted to link to her follow on piece/”post mortem”. (In technical terms, a post mortem is an examination of a problem or system failure in hopes of avoiding the situation in the future.) From the post, she encountered some very harsh words from the Internet:

I have never received textual scrutiny of this type before, where every single word was turned over and macerated and peered at for evidence of traitorous views. It sucks.

Lots of good stuff there about the reactions to her original post, her takeaways and how she would do some things differently next time. Worth the read.

When you manage, do unto others as they’d have you do unto them

A famous person once said “do unto others as you’d have them do unto you”. That is, treat others like you’d like to be treated.

As a manager, heck as someone who wants to get things done in an organization, that’s the baseline. If you can’t treat other people with respect and empathy, you’re going to have a hard time getting anything done. You might be able to get some stuff done by yourself, or via transactional behavior, or via fear. (By the way, if this is common in your organization, I’d look for new work because this type of motivation is symptomatic of a toxic workplace.) To really build a strong team, you need to, at a minimum, treat others as you’d treat yourself.

However, to be effective as a manager, this isn’t enough. Rather than treating others as you’d like to be treated, you need to learn how others would like to be treated. And then treat them that way.

What does that mean? Well, within the context of a software development team (where I have had direct management experience) you need to figure out what motivates each member of your team and, within the limits of your organizational capacity, give that to them. “Jane” may be motivated by the opportunity to work on the front end, whereas “Biyu” may want to focus on her algorithms. Some team members may want to start new projects, others may want to refine processes and make existing applications work really well.

This motivation changes over time, of course. This introduces additional complexity. When “Bob” joined the team, he might have been motivated by the opportunity to work with new technologies, but a few years in he may be more motivated by really impacting user experience.

The best way to figure out what motivates someone is to ask them. Hence the emphasis on 1:1s in the software business, where the employee controls the agenda. Another good way to decipher motivation is observation. Does “Olaf” spend extra time working on project A but is dragging his feet on project B? If so, why? Is one more UX focused, and the other more algorithmic? Such observations can also be starting points during the 1:1: “you seem to really be enjoying project A. What do you like most about that work?”

If your team or company can’t offer what someone wants, then it may be time for them to move on. The best managers I know were excited when I moved on because I judged it’d make me happier. This isn’t easy for the organization, but if you are playing the long game, the former employee will be an ambassador for you. Whether that is referring business or other employees, the goodwill can benefit the company. Contrast that with a company that holds on to a valuable employee even if they are unhappy (with golden handcuffs or other less savory mechanisms). When the employee finally leaves, there will be no reservoir of goodwill. Even before linkedin and glassdoor, this was no good. Now that folks can look up where people previously worked (and possible employees should do their research), the way you treat folks will be shared.

Overall, the key is to realize that what may excite you, or would excite you if you were an individual team member, or what might have excited you at a particular stage of your career, may not excite a team member. So, rather than put them in your shoes, put yourself in theirs.

One hundred days of blogging every day

This is a meta post, but it’s been 100 days since I started blogging every day. I wanted to celebrate! And I just wanted to note some lessons.

When you blog every day, it doesn’t have to be as good

Before I started the streak, I blogged at least once a month for the previous year or two. During that time, I often spent a lot of time working on my blog post. Not necessarily days, but hours. This was, after all, the only blog post I was writing, so it needed to be really good. But once I committed to writing once a day, I was focused on getting something out. I still wanted to be proud of it, but there wasn’t as much pressure. It could even be something really short, or just a pointer to a different piece that I thought was interesting (like here or here).

Having a streak forces your hand

A streak makes you make time. There were definitely times when it was after dinner and I still hadn’t blogged. If I wasn’t trying to keep a streak going, I’d have skipped that day.

Opinion pieces are easier to write than technical pieces

It was easier (and more popular) to write a piece on the nature of the CTO/co-founder or what a senior engineer is than it was on an interesting rails gem like after_party or the nuances of Stripe Connect integration. Interviews were the easiest post to write, but required a bit more planning.

More content means more readers, but mostly from one offs

In the months before December, I averaged about 4200 visits/month. In the months after, I averaged about 6300, but most of the elevated traffic came on specific days from referral traffic due to posts I had made to Hacker News. Still, the increase in traffic was about 7% even for months when I didn’t have a post that “went viral”

I feel so lucky to have a place to spout off. Thanks for reading.

© Moore Consulting, 2003-2017 +