Creating less work

    Jason Fried:

    Does that matter? Is that really worth doing? These are important questions that you should be considering often. Getting the right work done is almost always about creating less work to do.

    Adding this one to my “read every 6 months list.”

    Fear more

    Focusing your time on a narrower set of priorities is the biggest gut check you can experience in business and life. It is a never-ending fight with your primal self. Feature bloat, mass marketing, and “do it all” are driven by fear, and the internet age enables that fear like no other medium devised by humanity.

    Before you decide to spend time making more instead of making something better, ask yourself: what am I afraid of?

    Begging the question

    You should listen to this episode of the You Are Not So Smart podcast because it’s an episode that you really need to hear. OK, that’s actually a terrible reason to listen to it because…

    In this episode, three experts in logic and rationality will explain how circular reasoning leads us to “beg the question” when producing arguments and defending our ideas, beliefs, and behaviors. You will also learn how to identify, defend against, and avoid begging the question, or restating your beliefs without arguing for or against them.

    Yeah, that’s a more rational reason. This is the most nuanced, yet most widespread, logical fallacy I’ve heard in a while.

    Overcast link

    I'm sorry, I forgot to introduce myself

    A huge part of my job involves reading actuarial and insurance-industry-related articles. Mic drop: If that sentence doesn’t hook 999 out of 1000 readers, I don’t know what will.

    But anyway, virtually all of these articles are written by people who have three universal things in common:

    1. They are super smart
    2. They aren’t professional writers
    3. Their articles receive little to no editing before publishing

    These three traits lead to a number of structural problems in most articles that I don’t want to nitpick now, but one of the most common (and easiest to fix) is the introduction problem.

    The introduction problem

    The introduction problem, put simply, is the objective fact that introductions in shortish 3–5 page newsletter articles are universally terrible, if they exist at all. But the irony is that the introductions really do exist. They just end up in the last paragraph of the article in a section that’s usually called “Conclusion.”

    The typical conclusion section of an unedited article is something the author wrote very last, meaning the author wrote it at the point when he or she had finally figured out what they wanted to say by writing the preceding words of the body.

    In almost every case, a “conclusion” paragraph can be cut and pasted to the beginning of the article—completely overriding the original introduction—with almost no additional editing at all.

    Why am I talking about this?

    People don’t have a lot of time these days, and editing resources are increasingly scarce. If you’re asked to write something for a newsletter or industry publication (in any field), try moving your conclusion to the introduction after you write your thing. It will make your article significantly more accessible and relevant from the moment time-pressed readers lay eyes on it.

    See what I mean? If I had just put that paragraph first, wouldn’t this have been a better and shorter blog post?

    Ascertaining one's immortality

    Venkatesh Rao:

    Give a man a fish, and he’ll eat for a day. Stock a lake with fish, and he’ll fish till he’s 40, at which point it’s generally not critical to anyone else that he continue to eat.

    If you aren’t subscribed to Ribbonfarm at this point, shame on you.

    Twitter is back on my phone

    Back in December, I removed all Twitter apps from my phone. I felt that maybe Twitter was causing me to look at my phone too much, and I wanted to see if my phone habits changed as a result.

    This experiment is over, and Tweetbot is back on my phone—and not because I wasn’t able to resist looking at Twitter.

    It’s because I created a worse problem by removing Twitter. My desire for news and information didn’t die when I took Twitter away, and I began using the Apple News app. This turned out to be a horrible idea because no matter how much I tried to curate and tell Apple News what I wanted to see, it filled my “You” tab with mainstream headlines of death and disaster. The unfortunate reality of a news aggregator is that by the time you cover every tragedy in the last 24 hours, there’s no room for anything else.

    It took a few months for me to truly realize the effect this was having on my mood, especially if I was foolish enough to look at it first thing in the day. I feel like the Apple News app itself is as much a tragedy as the headlines that flow through it, and I’ve moved it as far away from my home screen as I can get it.

    So anyway—yes, Twitter, and all its attention baggage are back on my phone. Twitter will always have good and bad elements to it, but it’s the best all-purpose source of curated information I’ve found.

    Outsmarting the smart dash

    I like writing dashes—both the en dash (–) and the em dash (—). But I don’t like the way OS X “smartly” converts certain patterns like -- to . I would rather have direct control over these patterns for at least two reasons:

    1. If I’m writing something that will ultimately end up in a LaTeX document, I need to preserve -- and --- strings because LaTeX is designed to turn those into and , respectively, in the resulting PDF. LaTeX will usually choke on actual en and em dashes in the .tex file. People unfamiliar with LaTeX would probably see this as a limitation, but I truly believe it’s a great feature because it ensures that all hyphens and dashes are composed of - as a base character, making it very apparent what I’ve typed in plain text.
    2. Even if I’m writing something that won’t end up in a LaTeX file, I can easily create en and em dashes manually by preceding the - key with Opt for an en dash and Shift-Opt for an em dash. Both work system-wide in OS X.

    In other words, I don’t need OS X to be “smart” enough to make these symbols. I can instantly create them myself according to how they’ll be used.

    Before OS X Mavericks, you could explicitly turn off smart dashes in System Preferences. Beginning with Mavericks, however, dashes and quotes were forced to share a common check box.

    I don’t really mind curly quotes showing up in places because even if I’m writing something for a LaTeX file outside of a .tex environment (e.g. in an app like Ulysses), I will normally run everything through Pandoc to generate proper LaTeX code. Pandoc is pretty good with translating quotation marks of all kinds into proper LaTeX syntax:

    ``quoted text''
    

    It’s not so good, incidentally, with en dashes, which are more ambiguous in meaning—some people use them in place of a subtraction symbol, while others use them in contexts where em dashes are more appropriate.

    All that to say, it’s unfortunate that you can’t separately turn on/off smart dashes and quotes in System Preferences. Fortunately, though, you still can through Terminal with:

    defaults write 'Apple Global Domain' NSAutomaticDashSubstitutionEnabled 0
    

    This command turns off smart dashes, allowing you to preserve --, etc. in any document, but it allows smart quotes to continue functioning. Interestingly, System Preferences will show the smart dashes and smart quotes box unchecked after this change even though smart quotes still work.

    For more on dash usage, see The Punctuation Guide.

    The foot hammock

    Being somewhat old fashioned, I sit at my desk a lot instead of standing at it. I also have carpet in my office, so I usually don’t wear shoes. The First World problem that this creates is that I tend to put my feet in what are apparently ergonomically disastrous positions without thinking about it.

    Experience has shown me that putting unnatural pressure on my feet for extended periods of the day—while not painful at all when I’m doing it—tends to cause my feet to scream at me the next day. As I’ve gotten older, the screaming has gotten louder and lasts longer.

    My solution: I bought a foot hammock, which I highly recommend.

    A water cooler gone wrong

    AgileBits is leaving Slack:

    Slowly but surely this addiction has been killing my sanity and sapping our productivity as we simply used Slack for too many things. We decided it was time to try a new approach for communication at AgileBits.

    Honestly I agree with everything here. I like Slack, too. A lot of people seem to like Slack. But my experience with Slack is that it’s a Markdown-supported chat client on steroids. Right now I’m only using Slack to keep in touch with a couple of friends on work breaks. I can’t imagine working with Slack open all day. I definitely can’t imagine scaling it up for more than a two- or three-person team and not spending time talking all day.

    I feel totally different about Basecamp, especially the new Basecamp 3. To me, it feels like more of a virtual office space, and it’s partitioned into a more logically-productive way. I think AgileBits is going to like Basecamp 3 a lot. I can’t recommend it enough for working with a small-ish remote team.

    I use it, but would I recommend it?

    Now that the smoke is clearing and Smile’s dastardly attempt to charge more for its product has been “adjusted,” we can talk about more important aspects of this transition. Specifically, Gabe describes Smile’s decision to not encrypt TextExpander snippet data as:

    A design choice like that has consequences that I’m not comfortable with. It’s not something I want to use or recommend.

    The word “recommend” zeroes in on the fundamental thing I’m struggling with as more developers abandon Dropbox and iCloud in favor of their own syncing platforms. It’s not really about the cost of the services to me. That’s something that I feel I can objectively evaluate myself.

    The more difficult decision process now is:

    1. Am I OK using it? And if yes,
    2. Would I recommend it to someone else?

    Before data privacy became such a thing, Decision No. 2 was almost always naturally a yes if Decision No. 1 was a yes. It’s not so simple now.

    An even better case study than TextExpander is YNAB, which shifted from a pay-per-upgrade / desktop app / Dropbox sync model to a subscription / web app model earlier this year. While I’m using the new YNAB and still feel that it is lightyears ahead of any other personal finance software because of its budgeting philosophies, actually recommending the new version is a far more complex decision than it was when user data wasn’t stored on YNAB-controlled servers and bank data didn’t sync “through the cloud.”

    Now, the recommendation decision is a function not only of the benefits of the software but also the risk management implications on the data side. The reason that I am ultimately comfortable with the tradeoff has less to do with my perceived security around the YNAB servers and more to do with:

    1. How selective I am with which bank accounts I sync
    2. Other backstops I have in place at the bank level (transaction alerts, fraud alerts, how I distribute savings across different accounts, and even my decision to keep my credit frozen)

    I can’t expect that other people will have the same things in place, but those things are now inextricably linked to my personal experience of the software—making my experience far more singular, nuanced, and much less “lift and move” to someone else’s life.

    So. Software is getting better. Software is maybe getting more sustainable through subscription pricing models. But the psychological benefits and costs of using software have never been more complex. As I’ve said before, software is fundamentally a knowledge resource—an abstract layer on top of the physical universe created by humans for humans to grapple with. Software is truly as human as it gets—a medium through which problems are solved and as many new ones are born.

    And software and data are now more inseparable than ever. This was inevitable: They are made of the same stuff. Software is a developer’s knowledge; my data are my knowledge. Where should they be allowed to play together? The developer’s house? My house? Or some sandbox in the sky?

    I can answer these questions for myself. But for someone else?

    I still wear the Apple Watch

    In case you haven’t heard, the Apple Watch has now been declared a failure because of at least two categories of shortcomings:

    1. It has failed humanity: It has not cured cancer, curbed the incidence of global terrorism, and it has neither confirmed or denied the Big Bang theory
    2. It has failed developers: No one can program around the same splash screen: a 60-second spinner

    Maybe I’m a Watch apologist, but the Watch’s failures have not made me wear the Watch any less or feel that the roughly $400 I spent on the Watch was wasted.

    Considering the frequency with which I’ve used the Watch every day for nearly a year now, the graph of my investment in the Watch per unit of utility is an asymptote teasing zero. For me, all of the following have been enough in Watch version 1.

    • The time on my wrist. I foolishly let the iPhone replace previous wrist watches. The Watch fixed that.
    • Weather. The Apple weather complication is always current, forecasts load quickly, and I find the clockface-like weather forecast superior to virtually every iPhone and desktop weather app UI.
    • Next meeting complication. It’s useful.
    • Activity. I move more when I know how much I haven’t been moving.
    • Notifications. I’d rather see most of them on my wrist than have to fish a an ever-growing iPhone device out of my pocket.
    • Hands-free calling. This was the most unexpected benefit, but the Watch is my preferred way to take calls in private, especially in the car.
    • Easy Siri questions. “What time is the sportsball game tonight?” or “when is Easter this year?”

    I’ve all but abandoned using third-party apps on the Watch, but the breaking of that promise hasn’t made me want to discard everything that does work.

    A contrarian theory about software developers

    I don’t know why I wrote this post, but after seeing all the vitriol spewed at Smile for changing their business model, I started having these crazy thoughts in my head. This is all stupid, but for what it’s worth…

    What if the typical developer isn’t a rich Wall Streeter making a money grab? What if developers are girlfriends, boyfriends, or partners? Maybe moms and dads? Maybe developers have mortgages, rents, car payments, and health insurance.

    Maybe they’re wondering if they will ever have a dollar to spend on themselves after they scrape up enough to save for their kids’ college—or take care of an aging parent.

    I guess what I’m saying is, what if developers are just human beings. Normal people?

    And what if they’ve been failing? What if they keep getting up at one o’clock in the morning to open their laptop to take one more look at a spreadsheet, desperately hoping they’ve made a mistake. Maybe there’s a formula error somewhere. Maybe, just maybe the sales are there after all. Maybe they won’t have to take another contract job. Maybe they won’t have to let an employee go—another normal person with a mortgage, a kid, or a family to take care of.

    Maybe they’re sick to their stomach thinking of what has happened to developers before them that “fixed” the same problem by

    • Letting the app die
    • Letting the app languish
    • Putting ads in their app
    • Selling their customers’ information to marketers
    • Selling the whole business to a giant tech company

    Maybe they’re dreading the one-star shame that they know will come with any of those decisions.

    So what if they decide to do the unthinkable. They raise the cost of their product to stay alive another year. To fight the good fight one more season. To keep their homes, their kids’ college fund, their family’s health. To secure their dignity—the very essence of their identity as an independent human being.

    What if developers raise prices not out of greed and malice but out of necessity? And what if they don’t deserve to be spit on for asking to be paid? Like us?

    Told you it was crazy. Forget I said anything.

    Software as a perception

    Like so many other apps-turned-services in the last year, Smile is moving TextExpander to a subscription model that will cost $4.95 per month (or something less if paid annually).

    Macstories:

    Pricing is hard to judge because everyone values software differently. By the same token, TextExpander is not a new app – it has been around for many years as a paid-up-front utility, which is what this new pricing model will be measured against by existing customers. I can’t help but feel that those customers will be unhappy, perhaps very unhappy.

    I’ve been quietly observing the shift from “pay once” to “pay ongoing” in the world of software but haven’t said much about it. There is, however, so much to say, and I think for me it fits messily into two overlapping psychological circles, which I discuss below.

    We use software, but we haven’t figured out what the hell it is

    People usually talk about “software as a product versus software as a service.” The conversation, however, should be about “software as a perception.”

    What is software?

    I can’t touch software (only hardware). I can’t smell software. I can’t taste software.

    But I can look at software. I can use software. I know software when I see it. I can sense the benefits and experience of using software. I know that software exists—at least in my mind.

    Even though anyone can plainly understand that software isn’t a durable good or a product in the physical sense, that’s how it was priced in its first era in consumer markets. Like cereal, we used to buy software in boxes off the shelves of physical stores. Such silliness was never going to last, nor will the silliness of paying once to download a .dmg file.

    The reality is that software is knowledge: words and bits and instructions conceived by humans and experienced by humans. Software obviously requires a hardware infrastructure (both locally and networked) to exist, but software is fundamentally an abstract knowledge layer on top of a physical infrastructure. We need both the hardware and the knowledge layer to get the full benefits of software, but understanding the difference in these two layers is crucial, I think.

    Is knowledge a service? Most of the time—probably. But certainly not always.

    If we think of software as a knowledge service, then charging an ongoing fee seems to be a market consistent approach. In other words, it boils software down to its elements (knowledge), and we can observe how knowledge is priced and bought in other areas of the economy. For example, consultant fees, retainers, etc. No one would expect to pay a lawyer a one-time fee for unlimited support until the lawyer died or became replaced by a newer, faster lawyer with a flatter and less skeuomorphic face.

    But that’s what we expect of software developers, right? Pay them the cost of a counter service meal once for the right to email them and require support indefinitely? At best, this kind of business model scales to masochism. At worst, it drives software into either abandonment or acquisition by tech giants that shit it out in unrecognizable pieces and privacy violations.

    Software is infinite. Disposable income is not.

    Back in January, I randomly tweeted:

    $5/month is a reasonable charge for your service. Problem: your customers also need 100 other non-competitive subscription services.

    I think this resonated with a lot of people who hopefully got what I was trying to say, which is that the software economy is out of sync with consumers’ disposable income. This is not the fault of developers or people who buy software. We’re just living in a REALLY different world than I think humanity has ever experienced, and we won’t even fully understand how fundamentally different the world is today than it was even twenty years ago for probably another hundred years. In other words, we’ll probably never get it. We’re just living it.

    Fact: I can’t work without apps like TextExpander, and from a purely rational economic perspective, there’s no reason not to pay Smile $50 a year. It hurts me more not to continue using TextExpander.

    There are many other pieces of software for which I feel the same. And there will undoubtedly be many more in the future. This highly heterogenous set of services will not compete with each other so much in quality as they will compete for access to a homogenous resource of dollars—my finite income.

    How will we align consumer incomes with the Age of Services? Can we really afford all the services we want with income alone?

    Of course not.

    Maybe future software markets will paradoxically revert to more traditional economic structures where we trade services for services instead of income for services. Maybe coding will become as fundamental a skill as building your own home was a few hundred years ago so that we can build our own services more easily. Maybe future generations will shift more disposable income away from materialistic goods to services. Who knows—I don’t write the future.

    For now, we’re living in transition, and we’re arguably just now repaying a knowledge debt we’ve been accruing. We’ve been living on borrowed knowledge. The bubble is bursting. It’s time to either pay or default and live with the consequences.

    Static and free

    My time with Squarespace ended today. It was never an entirely happy marriage between us, and it’s not worth spilling every detail why, but I will say that the main thing that ultimately drove me from Squarespace for good was its poorly implemented Markdown editor.

    I feel that I should qualify that “poorly” because I really do mean poorly for me, and I don’t have any fantasies that I’m a typical Squarespace user or that I know more about Squarespace’s user base than Squarespace knows. I fully believe Squarespace has designed its user interface with its primary customers in mind.

    But as it stands now, Squarespace is not a place for lovers of Markdown, and that is who I’ve been for years and likely always will be. Even though Squarespace was among the first major blogging platforms to welcome Markdown-based blogging, I don’t think the Markdown functionality in Squarespace ever got past “add-on” status. It is a window within a window within other windows and will likely never be front and center in the user experience.

    All of these things have been said before about Squarespace, and I can’t think of anything to add to Claus Wilke’s take on it:

    While Squarespace posts can in principle be written in Markdown, Squarespace’s Markdown capabilities are limited and buggy. In particular:

    • Code blocks are buggy. Specifically, Squarespace doesn’t properly escape special characters in code blocks. This can make embedding code into Markdown posts a big headache.

    • Images cannot be inserted directly from the Markdown.

    • To insert images, one has to break the Markdown into two parts and insert an image block in between. As one does so, Squarespace rewrites the Markdown and turns all inline links into reference-style links. While this doesn’t alter the page output in any way, I prefer to use software that doesn’t randomly rewrite my source code.

    • The online Markdown editor Squarespace provides is slow and buggy. For longer pieces of text, the cursor is often displayed at the wrong location, so that it becomes difficult to edit the text at all.

    Life and content go on… to Jekyll

    It’s fitting to quote Claus above because he was writing about why he moved from Squarespace to Jekyll—footsteps that I’ve now followed.

    As blog nerds and GitHub power users know, Jekyll is a popular static blogging platform that lets you write and maintain all post content in Markdown. Like other static frameworks, Jekyll basically builds a database-free, static HTML website from Markdown and other configuration files. Though the setup takes some nerdery, the final result is as basic and pure a thing as you can find on the internet: a folder structure of HTML files.

    Jekyll is not the first static platform I’ve attempted to move to, and I’m grateful my previous attempts to move to other static frameworks failed because I can’t think of a better place to be than Jekyll now—although many, many good static site options now exist.

    Ultimately I chose Jekyll over other options because:

    • Jekyll is very popular and well developed.
    • GitHub—the center of the developer universe—loves Jekyll and uses Jekyll to power virtually all of its user-editable pages.
    • Since GitHub is so Jekyll-friendly, I was able to host the whole site there for free. At some point I may move to my own server, but it’s super convenient to have a powerhouse like GitHub take care of running Jekyll to re-build the site when something changes, not to mention the obvious local syncing benefits with any GitHub repository.
    • Jekyll’s framework for Markdown files with YAML front matter is substantially the same as other popular static platforms making it easy to switch to something else down the road if necessary.

    A static site is very close to the antithesis of Squarespace in terms of user skill set required. Many people will rightly question the value I’m gaining by simply being able to write and maintain my site directly in Markdown. If that were the only criterion, I think fair arguments could be made against my moving.

    But for me, the value of the move is much longer-term in nature.

    • I got to sharpen my Shell and Python scripting skills while cleaning up my old posts to make them Jekyll-ready.
    • Converting all of my older posts into Markdown files means I now truly own the things I’ve written and can easily move them anywhere. They’re out of the black box.
    • I learned a little Ruby, which is what Jekyll runs on.
    • I learned much more about GitHub than I used to know and plan to put that knowledge to work for other projects.
    • I learned more CSS tricks and discovered the power of SASS, which actually makes me not hate working with CSS anymore. So useful.
    • I’m in the process of learning some cool tricks in iOS that I plan to use for iOS-based publishing.
    • I no longer rely on first-party apps for publishing.

    Overview of how I moved

    There’s no such thing as a boilerplate list of steps for moving from Thing A to Thing B on the internet. To each his own sub-steps. And it’s in those sub-steps where both dragons and fun be alike. But for those that care, here are the primary steps I took over the course of several nights and weekends:

    1. I exported my Squarespace site to a WordPress XML file (the only option).
    2. I used this godsend of a Ruby script by Evan Walsh to convert the XML file into individual Markdown files. This was a major leap forward, but in reality this is where the real the fun began.
    3. I wrote several Python scripts to clean up the Markdown file names and insert YAML fields for things like redirects. This was a major step, and I think I’m going to put these in a different post because they were fun to make and worth saying more about on their own.
    4. I installed Jekyll on my Mac so I could build the site locally on my Mac and experiment with things. I highly recommend this even though GitHub can build it for you too.
    5. I spent a lot of time reading the Jekyll documentation and learning how to work with the Jekyll framework, which can seem intimidating at first if you’re not a web developer, but it quickly collapses into a beautifully intuitive framework. It’s so worth the time to learn if you want to empower yourself with a static site.
    6. I spent a few nights tweaking the CSS of the stock Jekyll theme to make it look like I think Practically Efficient should look.
    7. I moved the files to my GitHub account, flipped a few DNS switches, and was done.

    Other good resources:

    You may be wondering about images. Fortunately I have local copies of nearly every image I’ve ever posted, so I didn’t need to pull those off Squarespace.

    Some thank you’s framed in bigger pictures

    Even though I didn’t solicit much direct help in this move, I’m so grateful for the inspiration I’ve gotten from Gabe Weatherhead, Ryan Irelan, and Dr. Drang. They’re all much handier than I am with static blogging and web things in general, but I’ve been influenced heavily by what they’ve done. In particular, I’m convinced I would not have the basic Python skills I have now if it weren’t for all the exposure I’ve gotten to it through Dr. Drang’s posts.

    Thank you all for being you.

    Even though indie blogging has been relegated to third-, fourth-, maybe fifth-class citizen status on the internet in the last few years, I’m still grateful it lives on through the people who won’t let it go. I’ve seen so many talented, passionate bloggers move on to other mediums like podcasting or get sucked into aggregator-ish, socially-charged platforms like Facebook and Medium to chase the high of extra-instant attention, only to find that individual thoughts quickly wash away in a relentless social tsunami that leaves no trace of individual identity or permanence.

    If static sites increase the longevity of indie web writing, that’s just one more reason to support static blogging and the individuals that freely share information that empowers others.

    New RSS Feed

    Practically Efficient’s RSS feed has changed to:

    http://www.practicallyefficient.com/feed.xml
    

    Please update your favorite RSS reader if you’d like to stay subscribed.

    Clickable RSS link