New Heart, New Mind

I used to believe I’d be remembered for my work.

Not anymore.

Life is about relationships with people, not bits. What’s valued is availability, truly caring for those around you, and expecting nothing in return.

I’m being remembered for my love.

When I was a child, I spoke like a child, I thought like a child, I reasoned like a child. When I became a man, I gave up childish ways.
1 Corinthians 13:11 ESV

A year ago, someone great told me: “Do not love efficiently.” 1

What a thought! As an engineer, efficiency comes hardwired.

Loving inefficiently means caring for people when it feels like a waste of time, when it’s with someone outside of “my set”, when it’s someone I don’t understand and honestly don’t want to understand.

I recall this advice in places I’d typically keep to myself. Places like airplanes, coffee shops, and urban sidewalks. Neighbors, baristas, and solicitors.

My selfishness abrades at these attempts. But what is our legacy without love? What else is more important?

If I give away all I have, and if I deliver up my body to be burned, but have not love, I gain nothing.
1 Corinthians 13:3 ESV

These encounters are usually brief. Sometimes they’re awkward. But in engaging, I find myself challenged by the everyday opportunities to love others in this way:

Love is patient and kind; love does not envy or boast; it is not arrogant or rude. It does not insist on its own way; it is not irritable or resentful; it does not rejoice at wrongdoing, but rejoices with the truth. Love bears all things, believes all things, hopes all things, endures all things.
1 Corinthians 13:4-7 ESV

This is hard. It can come easy, but it’s usually difficult. There are cycles of generosity followed by self-serving deceit.

I can’t love like this. These cycles reveal it: human nature is at odds with acting this way. We love for a day, then we fall short. We try not to envy, then find ourselves coveting. We are nice to people until we feel justified to retaliate. And how do we endure all things when we’re broken in the midst of disappointment?

Instead of making adjustments to what’s broken, my old self is being replaced.

1 Corinthians 13 describes the result of radical transformation.

This chapter of the Bible was written to show the fruits of a new life in Jesus, when we’re committed to Him as our Savior and have the Holy Spirit working within us.

There are days where I progress in love and days where I miss the mark.

I don’t understand everything about the Bible. I’m learning, but I don’t know it all. I will always be learning. But I know a few things for sure. I have admitted to myself and God that I can’t love like this alone. That I cannot be close to God merely by being a good person doing good things. That I believe God’s only son Jesus is the perfect sacrifice that allows God to transform our entire soul if we ask Him.

By this, I am accepted before I did anything to deserve acceptance. Adopted. Beloved. Out of this new identity, I am able to share this unconditional love with others. It’s the heart of Christianity.

“Teacher, which command in God’s Law is the most important?” Jesus said, “‘Love the Lord your God with all your passion and prayer and intelligence.’ This is the most important, the first on any list. But there is a second to set alongside it: ‘Love others as well as you love yourself.’ These two commands are pegs; everything in God’s Law and the Prophets hangs from them.”
Matthew 22:35-40 The Message

Old and New

This scene is full of people who compared how they used to live compared to who they are becoming in Jesus.

I’m a work in progress and frequently mess up. We all do. I desire a new heart, a new mind, seen dimly and in part.

By the act of trusting Jesus, I surrender everything to the process of transformation. Every day I’m becoming a new person that can love the way I’m designed to love.

Radically and inefficiently.

The happy man is he who lives the life of love, not for the honors it may bring, but for the life itself.
Raymond John Baughan (1946)

Finally, if you’d like to know more about what I started to share here, you’re invited to check out The Touch of God. It’s a video from my church about God’s love in a loud and busy world. Or maybe just visit a church near you. You can expect to find a bunch of folks who have been through some crap and are figuring this all out together. See you out there.

Build Modules, Not Examples

I’ve been thinking out loud this afternoon about how modules make Node.js successful with @ekashida, YUI’s newest team member.

YUI is a powerful open-source library for developing web apps. Node and YUI both document their APIs very well. Unlike Node, we also have 250 examples to help people get started. Yet lots of people have trouble getting started anyway.

How do we make that easier?

We’re not the only web app library with this problem. Ember has received criticism around getting started and quickly responded with a roadmap to improve it. In their response, Tom Dale said:

Ember promises—and, we think, delivers—tremendous value. But ramping up to that point is not easy, and we received this feedback repeatedly and take it very seriously.

We get the same feedback for YUI. We also take it seriously and a fellow team member is working on better documentation. Ember’s action items include a Getting Started guide, a short screencast, live examples to run demo code, and other things. These are good and will help.

But then, I think about Node. Their official newbie documentation begins and ends with Hello World on their homepage. Node’s newbies do not get started with an example. They get started with npm.

Modules Are The Example

Node has effectively outsourced their examples to the community using npm.

You may be thinking: “Reid, modules are not examples. They are tools you use to build an example, or a real app.” Well, you’d be right. Node’s community has built enough modules to help people build apps they care about with a tiny learning curve. Instead of reading about code, these newbies are building something with a tool—the module—that lets them start building what they care about right away.

Few newcomers to Node.js use require("http") to build their first web app. If the barrier-to-entry was to understand the HTTP module, a lot of people would walk away. They don’t want to learn about that module, they want routing. View rendering. You know, a web app.

The example is Express. Newbies have a project in mind and it’s probably something that needs a router, view rendering, and middleware. Express delivers that. You don’t need to learn about Node yet, you learn Express.

Once you’re up and running, you have real code and real problems. Not theoretical problems in a narrative, but problems that are running on your computer. Problems getting in the way of building what you care about. That’s motivation.

Since you’ve already spent an hour getting the basics setup because the Express API was a lot easier to get started with, you’re now motivated to dig deeper into Node to find the next solution.

Building A Ramp, Not A Cliff

Understanding everything Node has to offer isn’t something you learn overnight. But that isn’t necessary. A lot of people have built modules on top of Node’s core that make all kinds of common problems easy. These modules are easy to download and use. Newbies are engaged immediately. Then, they’re are progressively lured into deeper water. The community grows.

If you need to learn a million things before you can get started, you’ll never start. If that’s your project’s learning curve, you’re presenting newbies with a cliff. Some people will climb it, some will seek climbing experts to get to the top. Some may have the patience to read a book about climbing, or watch a screencast featuring someone else climbing.

But most people want to get started today, so they’ll leave and find an alternative way to the top that’s easier to climb.

Node provides many ramps. They aren’t ramps you merely read about: they’re ramps you walk on, build on, get experience with, and get more complicated as you go up. It doesn’t fix every problem and some people will still be confused. But it works pretty well.

At YUI, I’ll be encouraging our team to focus on building example modules: the ramps to mastery. YUI is already modular, but that isn’t the same. I’m talking about bundling modules in YUI’s core into a fully-baked solution to a common problem. Other people on my team are hard at work on the first product, and now I know why I’m so excited: it’s a ramp.

Write Code That Works

Dav Glass and I visited the Yammer office in San Francisco this week to discuss build & test tools we use at YUI.

We showed off Shifter for building YUI, Grover for testing headlessly, Yeti for testing in browsers, and Istanbul for statement-level code coverage. We use Travis for running most of this stuff in public CI. We now require 70% statement coverage before a new YUI module is allowed to land in the core and nobody can commit when the Travis or internal CI build is broken, unless the commit fixes the build.

This is all very impressive. But @mde was quick to notice that we didn’t drop everything to get to this point—before diving in, you first need to prioritize what you work on. I couldn’t agree more.

When you’re starting from scratch, you start to love the metrics. Green dots for passing builds. Green coverage reports when you hit 80% of your statements. The increasing number of passing tests. I’m all for having good code coverage, but before you go crazy, you should be careful that you don’t start writing tests for the wrong part of your code.

Your code is not uniform

Your code has various levels of quality starting at the first commit you make. You will write some code that’ll last for weeks or months, and some code that’ll need a rewrite next week. You need to embrace this kind of change and understand where it happens in your project.

Node.js solves this problem quite well with the notion of a Stability Index.

Throughout the documentation, you will see indications of a section’s stability. The Node.js API is still somewhat changing, and as it matures, certain parts are more reliable than others. Some are so proven, and so relied upon, that they are unlikely to ever change at all. Others are brand new and experimental, or known to be hazardous and in the process of being redesigned. The Stability Index ranges from Deprecated (0) and Experimental (1) for unstable code to Locked (5) for code that only changes for the most serious bugs.

It’s a good idea for any post-1.0 project to assign a Stability Index to the APIs in your own code. Not only is it a clear message to those using your APIs, but it’s also a clear message for your team. It tells you where you should—and shouldn’t—write tests.

More stable, more tests

If you write tests like they cost nothing, you’re going to find yourself writing tests instead of writing code that works.

Kent Beck’s wisdom says it best:

I get paid for code that works, not for tests, so my philosophy is to test as little as possible to reach a given level of confidence (I suspect this level of confidence is high compared to industry standards, but that could just be hubris). If I don’t typically make a kind of mistake (like setting the wrong variables in a constructor), I don’t test for it. This answer is good and I’ll take it a step further: You should prioritize writing tests for parts of your code with a higher Stability Index. Especially if you’re just starting on a new project.

If you’re writing tests for code that’s rapidly changing, you’re going to spend more of your time writing tests instead of shipping features. For code that’s brand new, I typically only test-first a small amount of code and wait a while before hitting that green bar on a code coverage report.

Don’t get sucked into the allure of metrics too early. Remember what your job is: writing code that works. Code coverage and good testing tools are very important, but not if they get in the way of building what you’re supposed to build.

Best Trumps Easy

I work at Yahoo!, building open source software. I build Yeti, but I work alongside the team building YUI. The engineers who built this team, and continue to work on this team, are the reason I have chosen to stay at Yahoo! building Yeti: they choose what’s best over what’s easiest.

You work with people too. You know your people are not perfect, but they’re going somewhere great, which is why you’ve decided to join them.

I’m going to tell you that building software is very hard, but the most challenging part of my job isn’t building code. It’s building people.

Your people are not a test framework or a programming language: they are human beings. Like your favorite code, they don’t always meet your expectations. They will let you down.

People tell stories. What you do next will define the stories they tell.

You probably rely on these people, so when they fail you, it’s going to affect you. A lot. You probably don’t deserve to be subjected to their actions.

It’s easy to react.

I’m telling you, the best people never settle on what’s easy.

The best people never coddle or spin. They’re honest and speak their mind, but only after giving it 5 minutes. They think instead of react.

The best people deliver criticism inwardly, one-on-one, to the person who needs it. The attitude is service and respect.

The best people will embrace the opportunity to be a mentor instead of the opportunity to stand up for what they deserve.

Next time your people don’t meet your expectations, I encourage you to see an opportunity to invest in people. It will be hard. It may take up a lot of your time and nobody but them will appreciate your investment. Yet serving others this way will reward you.

You never know when you’ll need it yourself.

It’ll also reward them. Honest feedback delivered this way is very desirable and mutually beneficial.

If you want this kind of culture in your team or community, I’d encourage you to be the first one to start. Give more than they deserve, seek to understand what they care about, and after careful consideration, deliver your feedback to them personally.

It’ll be the start of a conversation you won’t regret.

When PHP Actually Is Your First Programming Language

I have read a few articles about how PHP is a perfectly good first language and how it should never be a first. These articles are interesting because my first programming language was PHP and I have been using it extensively since 2004.

One thing is true: it’s really easy to get started with PHP. My first real job was creating a system to log phone call metadata from a PBX. I was able to get a working version up quickly because 90% of it was in PHP. There’s a function for nearly everything, and if there isn’t, you’ll find sample code online quickly. I had the project done in a month with very little prior experience. However, because it was so easy, it was horrible. Procedural, PHP inline with HTML, calls directly to mysql library functions, really bad logic.

When I was brought on to develop on their flagship web application, my coding practices improved from exposure to a better codebase. The biggest improvement was when I started working with PHP code developed by a new coworker that I would later learn was heavily influenced by Java. I went from looking at objects as namespaces to a representation of something. I learned to separate logic from presentation. I started to think about code more logically. I was baffled at problems caused by PHP’s lax nature (such as when (0 == 'hey') is true). However, I had knowledgeable coworkers to explain these problems when the language wouldn’t.

The best thing about PHP is that it takes away the need to manage “stuff” and let’s you get started right away. For me, I was able to more quickly grasp object oriented programming because PHP was more forgiving. This later helped me embrace objects in JavaScript, understand polymorphism, and become a better web developer.

That’s also why it’s so awful. If it weren’t for my exposure to good PHP code influenced by proper programming practices, I would have remained a contributor to the vast amount of bad PHP code out there. The unfortunate problem is that most new developers who use PHP stay in that place, because their stuff works. For most jobs, that will suffice. It’s only when they move to other languages that the frustration begins.

Making PHP my first language made it harder to grasp pointers, strong types, and memory management in other languages. It initially made it more difficult to use OOP properly. However, if I didn’t make PHP my first language, I may have been so intimidated by the “stuff” that I may have given up.

Whatever you choose to learn as your first language, the key is to learn from great code. You will make mistakes and your language, framework, or mentor should be there to guide you. If you don’t, you’re only going to become frustrated and confused later.

Update: There’s a good discussion about this article on Hacker News.

My first languages were actually Applesoft BASIC followed by VB6, but nothing serious came out of my experimentations with them except for a brief stint working on ignitionServer.