Development Inspiration Thoughts

Hemingway’s Advice for Coders

I’m an avid reader of Brain Pickings (check it out if you haven’t heard of it), and one thing caught my attention a few weeks ago. In the mid-1930’s a young writer by the name of Arnold Samuelson caught up with his hero, Ernest Hemingway. Rather then cast him away, Hemingway took him on as a sort of protege, and gave him some invaluable writing advice along the way. There was one thing that resonated with me in particular because I find myself in this trap all the time.

The most important thing I’ve learned about writing is never write too much at a time… Never pump yourself dry. Leave a little for the next day. The main thing is to know when to stop. Don’t wait till you’ve written yourself out. When you’re still going good and you come to an interesting place and you know what’s going to happen next, that’s the time to stop. Then leave it alone and don’t think about it; let your subconscious mind do the work.

I mostly write code for a living, not prose. But this rule still applies. I can’t tell you how many times I’ve been coding away when I finally get myself to a good place. Everything’s perfect. The bug is patched, the feature is solid.

Then I go just a little bit further. And that’s when I blow it. I get frustrated and lost. My motivation goes into free-fall and I alternate between my code editor and Twitter every five seconds. And no it’s late. It’s dinner time, or my wife is calling me, or the office is closing.

So don’t be me. Take Hemingway’s advice. It doesn’t matter if you have a little extra time, find that place where you still have some juice left and just stop. If you really need to keep going, go over the code you just wrote and refactor a bit. Or look at the next step enough to get pumped about it, but don’t write any code. When you get up and walk away from your computer, the levers in your brain will keep moving, even when you sleep through the night.

The next morning, when you’ve had a good sleep and you’re feeling fresh, rewrite what you wrote the day before. When you come to the interesting place and you know what is going to happen next, go on from there and stop at another high point of interest. That way, when you get through, your stuff is full of interesting places and when you write a novel you never get stuck and you make it interesting as you go along. Every day go back to the beginning and rewrite the whole thing and when it gets too long, read at least two or three chapters before you start to write and at least once a week go back to the start. That way you make it one piece.

More sound advice. When you start up again fresh, instead of jumping straight into a problem, go back over the work you did the day previous. Take 10 or 15 minutes and tweak little things, just enough to get the ball rolling. When you start developing the next step, you’ll already be in a good place. And by going back over code you’ve written before, you can make sure to keep things fluid and connected.

I’ve started to do this (when possible) and it feels really code. All of this, of course, requires nice blocks of time devoted to your tasks, not distracted by email and social media and meetings. That can be tough, but it is well worth it. You might not write For Whom the Bell Tolls, but your code will be a lot better for it. Give it a go.

Links Thoughts

Bringing Back the Personal Site

There have been quite a few articles recently about the importance of the personal site, and the blogging community. It’s a sentiment I’m super excited about.

Rian Van Der Merwe has probably the simplest point. Blogs are the front page of the internet, and it’s their freedom that gives them their strength.

All this to say that I think it’s time we bring blogging and personal sites back. Some of my favorite sites are the ones that give me a glimpse into everything a person is interested in… It’s a way to get to know someone through their interests, and to learn a bunch of things along the way. So I invite you not just to follow along here as I expand into topics beyond design and technology, but to start your own personal blog up again if you’ve been neglecting it for a while.

Tom McFarlin pointed out that a personal site was a great way to ensure that you own your own data, so that it can outlive and outgrow the third party, walled gardens we’re all used to.

Imagine being able to continue sharing information, but also continuing to own all of the information for yourself by simultaneously bringing it back into a database into an area you own.

Pretty exciting, right? At least for those of us who are tin foil hat types.

Reacting to Twitter’s plan to keep long form content on their own site, Mandy Brown discussed the magic of the hyperlink and the journey that is the open web.

In addition to places to talk… they have also been places to venture off from—you start in your feed, but you end up in a browser, half a dozen clicks away. If everything comes to your feed instead, will you never leave? Will this be like working in one of those startup buildings with their own coffee houses and cafeterias and laundry services, where the streets outside could flood and you wouldn’t notice for days?

Then, Dave Wisner lashed out at Medium, but I think more importantly, talked about the opportunities for a new blogosphere, one that is more connected then ever, (and that the WordPress REST API can certainly play a part in).

But there is another approach, to have WordPress accept as input, the URL of a JSON file containing the source code for a post, and then do its rendering exactly as if that post had been written using WordPress’s editor. That would give us exactly what we need to have the best of all worlds. Widespread syndication and control over our own writing and archive.

As a bit of a retort in The State of the Casual Blogger, Ghost founder John O’nolan was quick to point out that people use services like Medium because they’re easy, fun and simple. And, hey, maybe we should try that, but at the end of the day both will continue to exist side by side:

There is more than enough room in the publishing industry for open and closed platforms to exist in harmony, catering to different types of writers with their individual advantages.

In 2016, I want to start writing again, and sharing things as I come across them. I always want to work on tools that can help personal websites become a central hub for all of our data and content that’s currently distributed all around the internet. Looking around, I guess I’m not alone.

Thoughts WordPress

The Responsibility a WordPress User

Last week, WP Tavern posted an article about how Matt Mullwenweg was addressing concerns over WordPress development moving too quickly. Matt more or less shrugged the question off in his State of the Word, but it is still a rising sentiment. And it’s not just a concern in the WordPress community, but in the larger web community as well.

There was a lengthy discussion that followed the post. It’s worth a read if you’re into that kind of thing, but to me, it highlights a growing divide that gets right down to the core of what’s expected of a WordPress user. 

Several users noted that even small changes can ripple out to larger ones or break expectations without even a remote need. Similarly, users don’t have the time or capacity to keep up with every little development and when things change they have to go through and check the changes against all of their sites and client sites, then update tutorials, then let their clients know. Every. single. time.

Others, including a handful of core committers, pointed out (rightfully so) that even small changes are heavily considered, and that they often solicit feedback about these things on places like WP Tavern and mailing lists.

The response was that these where places developers and coders hang out and WordPress users can’t be expected to check every little thing. But of course, if a site is code to WordPress conventions, it shouldn’t break anyway. And so maybe we all need to just trust WordPress a bit more.

And so on.

I’m (over)generalizing. But time and time again, we see mention of two groups. The first are the end users, the Average Joe with a laptop and a dream. The second are the developers, programmers on the bleeding edge of web applications. So really, the conversation comes down to what is the responsibility of the WordPress user? Is it the user’s job to ensure that their site is up to date, or it WordPress’ job to ensure that nothing ever breaks on existing sites? That’s a trick question, but it’s part of a continuing identity crisis in the WordPress community.

At this point, WordPress is trying to handle two pretty distinct use-cases. For the end users, a better admin experience, a fast install, and a quality controlled theme and plugin marketplace are of utmost importance. For the coder, extendability, speed of updates, and frankly, a trendy toolset are held in highest esteem. The article’s discussion focused on finding a balance and a place to draw the line between these two groups. The central theme being:

How can we maintain a strong pace of development with new features, while still leaving things simple (and relatively unchanged) and for the average user?

Wrong question. To pit two user types against one another implies some sort of mutual exclusion. It obfuscates the nature of the web and website development. And it puts the community at odds with one another.

Think about some of the things that WordPress does well out of the box. User authentication, media management, commenting, routing, and a pretty well thought out admin interface to boot. None of these components are good for just one group. In fact, a lot of the differences between these groups is just about how we want to render HTML on a page. But it’s the open web all the way down.

Let’s stop defining the “average” WordPress user. Let’s work on ways to elevate the WordPress user instead of insulting their intelligence at every turn. Let’s drop the assumption that these users don’t have the will or interest to learn more about how their site comes together. We don’t need to speak in techno-babble or build confusing interfaces. We can use the WordPress admin and site building process as teachable moments, to educate users on the types of things they can do. We can find better ways to reach out to everybody that uses WordPress and gather feedback. The WordPress core community is already working on this, and of course, they could always use some help.

We make it sound as if the REST API is only useful for NodeJS wielding front-end developers. What about the user that wants to use it to wire WordPress to Facebook, or connect to a third-party app, but doesn’t know how? WordPress just brought responsive image potential to 25% of the web. That’s a win for everybody. We have whole teams working on accessibility and localization. There’s no one group that benefits from any of the work that’s done.

As WordPress continues to grow, it will be its diversity of spirit and community that keep it alive. Take a look around at the next WordPress event that you’re at and note the multitude of voices and opinions. Remember that the role of the WordPress user is to make websites, and love doing it. We should encourage that.