First, here are the slides from the talk:
A language that was built in 10 days,
as a prototype,
is literally eating the software world.
Have you heard it’s been used in space?
When Brendan Eich convinced Netscape that it should have its own scripting language,And Internet Explorer and every browser after that followed suit:
The internet wasn’t going to wait for something else to catch up.
Now, the language is catching up.
Marc was almost ready to implement his "hello world" React app pic.twitter.com/ptdg4yteF1
— Thomas Fuchs (@thomasfuchs) March 12, 2016
1. Keep it (stupid) simple.
As product teams, we need to realize the debt that any line of code or dependency adds to a product as a whole, and consider that debt a liability. If there’s one skill you should focus on in 2017 to become a better developer, it’s to learn how to gauge the value code actually gives to your product, and whether that value is greater than the debt you take on by adding it. It’s an abstract thought, but so important to be thinking about.
2. Write readable code.
Code shouldn’t just be optimized for a machine, it should be optimized for other humans to read it. I’ve heard of this expressed as the “WTF factor” - reducing the number of times you mutter “WTF” when reading code. I like to think of code as a story - I love telling stories. As a species, we’ve been telling stories for thousands of years. It’s one of our earliest activities, and we’ve had a lot of practice at it.
We’ve also built up a ton of science behind storytelling. Did you know that people emit very similar brain activity when they are consuming the same story? This is called neural coupling and causes people to think of the same things, at the same times, in the same way. It’s amazing. Our brains also release dopamine when consuming engaging stories, triggering our brains to commit to memory not just the details of the story, but what we were thinking about at the time.
Wouldn’t it be great if we could trigger the same things in our code?
3. Don’t try to be an expert in everything.
Pick your tools (wisely, using the advice above) and become an expert in those. It’s okay to have niches, and it’s important to not continually jump ship. After our session, someone asked me what I thought of Angular 2. I should’ve answered “that’s a dumb question.” It doesn’t matter what I think. Angular is being worked on by terrific people and can be used to build terrific products. The question should be: does Angular communicate well to your team?
We stuck to our guns early on with Meteor. We still use pieces of Meteor today because it communicates well with our team and allows us to focus on the story of our product. When we feel that there’s choices that better adhere to the advice above, we certainly choose it over Meteor. But it’s not because someone blogged about it. If we wouldn’t have kept up with Meteor we also wouldn’t be where we are today with Apollo and GraphQL, which is becoming an amazing initiative, and a great benefit for our partners.