datamcfly

[datamcfly]

Claire Lew:

I remember thinking this when I became the CEO of Know Your Company back in January 2014. Sure, I’d started two companies beforehand — but one was with close friends, and the other was by myself. With Know Your Company, it was the first time I was to lead a team of people who weren’t friends of mine.

At the time, I hired one programmer part-time to help me out at Know Your Company. And while he was just “one direct report,” it was imperative to me to be the best manager and leader to him, as possible.

Here’s the first thing I noticed in this process: Being a manager feels different than being an employee. And, it feels very different than working by yourself.

Your words carry more weight than before. Your actions are watched more closely. You aren’t accountable just for your own results, but also the results of others. How you handle tough decisions sets the tone for “This is How We Do Things.”

It can be a bit terrifying. If you’re currently a manager, you know what I’m talking about. If you’re a new manager, brace yourself :-)

Now, I share this not to overwhelm you! Rather, it’s to underscore how hard this is for all leaders, whether you’re new to the role or not. Personally, with almost four years as a CEO under my belt, I still consider myself a “work-in-progress,” and constantly aspire to be a better leader.

Where to start? Over the past few years, here are ten things I’ve learned from observations and conversations with hundreds of managers and CEOs. It’s what I try to keep in mind each day as I lead, and what I believe the best managers do…

[datamcfly]

Most web apps set up a healthcheck, it’s usually an endpoint that tells you that your databases are up, and websites are up.

I’ve even got a repo ready to go that I install on servers and enable quickly, based on another middleware healthcheck but with a few changes to make it easier to use, and with endpoints already in place for mongodb, redis and elasticsearch if needed.

We use healthchecks heavily here at Flybase to monitor all our services and let us know in case of any issues.

These work great, if one thing goes down then your monitor will alert you.

But what about all those third party APIs your app uses?

Or if you use a microservice architecture, how do you ensure everything continues working as expected?

This is where heartbeats come into play, and are a slightly different take on healthchecks.

For example, let’s look at an e-commerce site that sells spoons:

User picks an item to purchase

Item goes to cart

User logs in (or signs up) and pays for item

System registers purchase, and signals warehouse and shipping company about shipment

Shipment gets picked up

Users gets his new spoon.

So there are several APIs involved here, we have the payment processor (maybe Stripe), we have the shipping processor, we also have internal APIs such as user management, inventory control, order management and notifications.

In this scenario, let’s say the shipping processor never gets notified? or the inventory control doesn’t adapt the numbers and we end up showing more in stock than there actually is?

Nobody likes ordering a sold out item thinking they’ll have it in a week, and actually waiting a month or two.

Or worse, ordering an item and the shipping system never gets the pick up request.

So we set up a heartbeat. Which is a simulated order that is run every so many hours.

In this case, we can create a special item that never gets seen anywhere else, and a user account that is called heartbeat.

Then you would have your heartbeat user walk through the order system using automated scripts and if any errors occur, for example an email never arrives in the heartbeat box, or the order page never shows sucessful order.

You could add some extra checks to make sure the db updates and check responses back from the various end points, heartbeats are allowed to be slower than the actual order process as they are checking everything involved, but the end result…

You get a snapshot of your system every so many hours and can get a heads up in cases of any issues.

Also, most important, perform clean ups once done, this is also why you should use a dedicated user (or even users).

The End?

This wasn’t a code heavy post, I shared a repo I use on several projects for healthchecks and mostly explained ways to do a heartbeat.

It’s hard to code a demo heartbeat as the code is so different based on projects.

So all I can recommend in building a heartbeat is monitoring every step you can. It’s the heartbeat of your app and an unhealthy heartbeat is very dangerous.

This post was originally published on Coded Geekery, my blog on various topics from cooking to work life balance.

[datamcfly]

Gustaf Alstromer, YC’s newest Partner (formerly product lead for Growth at Airbnb) joined a panel with Ed Baker, (former Head of Growth at Uber), to share tips on growth experiments and team dynamics at a scaling company.

Topics discussed:

What is a north star metric for growth? If you talk to anyone on the growth team, and ask them, “what number are we trying to grow.” They’d be able to say that number. And if they aren’t working on something that could grow that number, they’re probably working on the wrong thing. At the time Ed was at Facebook, retention and user engagement contributed even more to the north star metric (MAUs) than new user acquisition.

Paid acquisition can further accelerate growth: Growth isn’t only about organic growth — especially for companies who charge for their products. In a competitive market, it can make sense to pay to acquire up to the potential value of a customer if it’s important to grow quickly (this was true for Uber, who had to beat competition to market).

Is there a channel with particular upside right now? Nothing beats building a great product. Beyond that, most great companies get really good at one specific channel — so figure out what your product is best suited for and double down on it (make sure it’s a channel that can scale — meaning that channel potentially has 100s of millions of people coming through it).

You should be seeing things that are counterintuitive in your data: If you aren’t, you probably aren’t experimenting enough.

A little wording change can matter: As an example, Facebook saw low growth in Japan, and went and talked to people in the local market and found that people felt it was rude to “invite” friends to Facebook. They found through a growth experiment that changing the wording to “announce to your friends you’re on Facebook” (instead of “invite”), they immediately began to see growth there.

Make it easy for users: The simplest thing you could do today to help strengthen user data is to not log people out. This practice is bad for growth, and Amazon is a great example of doing it right.

Eventually, the whole company is a growth team: At Airbnb today, every big team uses data to fuel decisions. That’s the goal. The growth team should not only be collaborating across the business, but you should start to see most areas join in on a cadence of experimentation.

Definitely click the link and watch this video, it’s great, and covers a lot in the 34 minutes.

[datamcfly]

Industries often experience evolution less as slow and steady progress than as revolutionary shifts in modality that change best practices and methodologies seemingly overnight. This is most definitely true for front-end web development. Our industry thrives on constant, aggressive development, and new technologies emerge on a regular basis that change the way we do things in fundamental ways.

Today, we are in the early stages of such a revolutionary shift, brought about by CSS Grid Layout. Much of what we know of the possibilities, limitations and best practices surrounding web layouts is effectively rendered obsolete by this new layout module, and in their place we find new possibilities, limitations and best practices that will take us into the next era of web design.

Much has already been said about the technical aspects of CSS grid and its one-dimensional cousin flexbox by people smarter than me. In this article, I want to bring these concepts into practical use. What you’ll get is a starting point for exploring what new layout opportunities and challenges CSS grid brings, what old problems it solves and how to start using the module in production websites today.

We’ve been adopting CSS grid here as we redo our home page and love it, so wanted to share this post.

[datamcfly]

Here are the 9 promises of Uncle Bob’s Programmer’s Oath, from his original 2015 blog post:

I will not produce harmful code.

The code that I produce will always be my best work. I will not knowingly allow code that is defective either in behavior or structure to accumulate.

I will produce, with each release, a quick, sure, and repeatable proof that every element of the code works as it should.

I will make frequent, small, releases so that I do not impede the progress of others.

I will fearlessly and relentlessly improve my creations at every opportunity. I will never degrade them.

I will do all that I can to keep the productivity of myself, and others, as high as possible. I will do nothing that decreases that productivity.

I will continuously ensure that others can cover for me, and that I can cover for them.

I will produce estimates that are honest both in magnitude and precision. I will not make promises without certainty.

I will never stop learning and improving my craft.

This is just the beginning. As software powers more and more of the world, developer ethics will become increasingly important.

The Programmer’s Oath is something we strive to live by here at Flybase, all our code is written so that anyone can jump in and take over at anytime.

Since the guys at freecodecamp posted a new take a on it today, I thought I’d share both the oath and their post.

[datamcfly]

Scared of saying the wrong thing, resulting in unwanted spotlight from an unintentional blunder? The chances of showing up on the trend list on Twitter are lower than you think. PR specialist Lyndon Johnson warns entrepreneurs about being too risk averse, and the real damages done by acting without caution.

“Blunders are strange. People think there’s a huge risk in doing something that will embarrass the company or individuals or upset customers. The blunder I see more often than not is people trying to activate relationships before they’ve built them, to the point where they’re randomly shouting at people, ‘do this, help me, buy this product’ before they have the relationship in place.”

Lyndon Johnson is the Founder and Strategic PR Specialist behind the platforms ThinkDifferent[LY] and Comms.Bar. He moved to Toronto Canada from the UK, marking the creation of his first public relations business. Lyndon saw an opportunity to innovate public relations and created his company to embody such innovation as well as tailor it towards modern business. More recently, his work in redefining how companies value and define public relations continues with his new platform, Comms.Bar.

In this week’s #StartupPodcast, host Rivers Corbett talks to Lyndon about his unique approach to PR, his approach to helping his clients, and the stories behind what drove him to create his business.

I like catching episodes of the Startup Canada Podcast, and this one has been particularly interesting.

[datamcfly]

Nathan Konthy:

Quite a few years ago I found myself in a situation where I wanted to start my own business. I was sick of working at the places I was working at, and I wanted to get out on my own. Problem was… I had no idea what that was. I didn’t have any obvious breakout ideas. The experimental ideas I did have seemed impossible to market, as in, I had no idea how to sell anything. The thought occurred to me to try to raise money to build something, but I didn’t even know where to begin.

It was an awful unmotivating place to be.

If you’re looking for inspiration on getting started with building a startup, then Nathan’s post is a nice read.

[datamcfly]

Will Schroter:

Long before you set up shop and hang your shingle, your job as a Founder is to spend as many cycles as you can validating whether your business idea even merits a logo.

Validating your business idea isn’t a dark art. It’s literally asking people whether they would use or buy what you’d make.

The challenge is: How exactly do you go about doing that?  Since most Founders are only validating a business idea for their first time, they don’t have a great sense for how to validate a business idea well or how to interpret what they are learning.

The result is often a heavily skewed view of what the market thinks—or worse—no view at all and a long run into the abyss.

As it happens, there are really only a few parameters to consider before you put a lot of effort into pursuing your idea.  It’s all about that early validation. The good news it doesn’t take too long and it’s generally free.

Another great post from Will and the gang at Startups.co, I recommend checking out their blog if you haven’t already.

Startups.co also runs a slack channel that has a founder giving a live chat every day about work, life, and everything in between.

[datamcfly]

One of the pioneers of personal computing, Alan Kay thought of laptops and graphical interfaces years before they were realized. At XeroxPARC, Apple, HP and Disney, he has developed tools for improving the mind.

Alan gave this lecture as part of Startup School at Stamford and his lecture was great so I wanted to share parts 1 and 2 here.

[datamcfly]

Claire Lew:

I hate the word “empowerment.”

I never think I should “empower” anyone — especially our employees.

Why? The definition of the word “empower” is:

to give power to (someone); to make (someone) stronger and more confident.

The key words here are “give” and “make.” Empowerment means you’re transferring power to someone else. You think someone else needs you — your permission, your influence, your talents — to do something. And I don’t ever believe that’s the case.

Our employees don’t need me to do anything.

When it comes to motivation, everything people need they already have inside them. Each person has something unique, special and important to offer the world. And as a leader, it’s my job to merely create the best environment that allows them to come into that themselves.

[datamcfly]

Richard Kenneth Eng:

There are many programming languages today vying for your consideration, especially the “hot” (or “cool!”) new languages like Ceylon, Crystal, Dart, Elixir, Elm, Go, Haxe, Julia, Kotlin, Rust, Swift, TypeScript. And new ones seem to be popping up every month!

Even some of the not-so-new languages are grabbing attention, languages like Clojure, Erlang, F#, Haskell, Lua, OCaml, Scala. Some of these languages are decades old!

So it got me wondering: What makes a programming language, regardless of age, trendy and exciting?

[datamcfly]

Tara Mann:

Most people struggle with confidence at times, especially in the workplace and I’m no exception. I often find myself presenting my design work and my opinions with a variety of qualifiers, as if pointing out my perceived flaws before someone else can will negate them. This is just as much a reminder to myself as it is to anyone else, but please, present your work without apologies.

Here are a bunch of unnecessary qualifiers and why they’re unnecessary. When I find myself typing one of these, I take a step back, read over what I was trying to say, and rewrite…

Interesting reading from Tara with several key take aways.

[datamcfly]

Cameron Moll:

Years ago as a high school student I was driving to school and Bruce Springsteen came on the radio. Except he wasn’t singing. He was answering questions from a local radio host.

At some point in the interview, Springsteen shared an uncanny observation about parents, paraphrased as best as I can I recall:

The best way I know how to honor your parents is to take all their good attributes and incorporate them into who you are, and leave behind all the bad ones.

That observation has stuck with me for more than 20 years.

No one knows how to Boss like the Boss himself, Springsteen.

[datamcfly]

This post was originally posted on Coded Geekery, my personal blog about finding a work-life balance, but I wanted to share it here as well since it’s about the Flybase status page.

Overview

We built our own status page for Flybase, you can see it here.

It was built as a static HTML page on Github Pages. It uses Github Issues to report any incidents and Uptime Robot to monitor our sites.

This idea is based loosely on the statuspage repo created by @pyupio, but simplified, as I wanted this to be pretty much automated, plus we already use Uptime Robot for monitoring, so combining Uptime Robot with Github Issues works great.

To get started, you’ll want two things:

An Uptime Robot account

A GitHub repo where you can throw your site up and use the issues system.

Create a branch in your repo called gh-pages, this is where your files will sit.

Ok, let’s build our status page:

1. create index.html

First, create our index.html file:

2. Create script.js

Next, we’ll create script.js, this is the file that talks to our services.

Replace the following variables with actual lines:

YOUR-UPTIME-ROBOT-API-KEY-1 and YOUR-UPTIME-ROBOT-API-KEY-2: Uptime Robot’s default API key is universal, but is also read and write. We want this monitor to be read-only so we have to create an API Key for each site we are creating. This is an array of keys.

To add more sites, just add a new line and add a new monitor key.

YOUR-GITHUB-USERNAME: Your Github username where the repo you created lives.

YOUR-GITHUB-REPO: The Github repo you created to use.

2. Create style.css

Finally, we want to create our style.css file. Just copy this entire block into the file.

4. Git it Going

Once you’ve created your files, you want to put them on your repo, you can either create them directly from the github.com interface, or you can create them locally and commit them.

If you want to add this to a specific domain, then create a file called CNAME and store your domain or subdomain in there.

Finally, create a file called .nojekyll which tells Github Pages that this is a strictly static site.

To customize Github Issues, we set up labels to identify issues:

operational means all systems good.

investigating means under investigation.

outage to identify an outage.

degraded to identify an issue causing degraded performance.

On top of that, you can add labels that start with system: and they will show what system the issue is related to. For example system:blog would show an issue with our blog.

Labeling an issue with any of these tags will reflect on the status page.

This status page works pretty well, and was useful last week with the AWS outage that happened. It showed the status of our various services, and let us push updates via Github Issues that showed up below.

I do plan on making an update at some point to take into account comments inside issues.

This is a basic status page, but it helps show people what is happening with your sites, and keep everything nice and transparent.

Originally posted on Coded Geekery, my personal blog about finding a work-life balance

[datamcfly]

Claire Lew:

A few years ago, a CEO told me how she was struggling to get honest feedback from her board.

No one seemed willing to be critical or give her pointers on things she could improve. After every board meeting, she would turn to them and ask directly:

“What feedback does anyone have for me?”

She’d hear crickets. Every single time.

Good advice for getting feedback.

[datamcfly]

There are two real problems with this attitude:

First, drawing lines. Problems aren’t linear, people don’t fit into boxes. Lines are not nuanced, flexible or particularly well-informed. A line is a shortcut, a lazy way to deal with a problem you don’t care enough about to truly understand.

Most of all, drawing a line invites the other person to cross it.

Second, the sand. Sand? Really? If you’re going to draw a line, if you’re truly willing to go to battle, you can do better than sand.

Seth Godin

That saying has always bugged me too, and we never draw lines here at Flybase.

[datamcfly]

Paulina Welnic:

When it comes to customer support, great product knowledge and technical skills go to waste if we’re answering the wrong question.

Customers reach out to you when they hit a roadblock in using your product and getting their job done. So getting your customers answers not just quickly, but correctly, is key.