Let’s design a car that has square wheels and no windows because it will look really cool. Then let’s put the steering wheel on one side of the car and the foot pedals on the other side of the car. While we’re at it let’s forget to put a door on it so that you can’t actually get in to drive.
Now let’s give the design to the mechanic and tell him to build it.
It’s a sure bet he will tell you where to put your designs in no uncertain terms. Why is it then that designers/clients feel they can take the same approach to building a website? Mysterious unfathomable menus, text too small for the human eye to read and graphics the size of a bus.
I should stick to my guns and tell them to change the design, and although I complain about it at the start, I usually end up coding it much like the client wanted from the start. So the next time you visit a site and can’t work out how to navigate and where the text is too small to read then that will be my fault!
Past Thoughts: May 2012
Recently, the internet delighted in petty squabbles between developers over what I’ll generically refer to as ‘technical style.’ I’m going to skip the sideshow of specifics, but they each involved punctuation, to a greater or lesser degree. Wound up inside these arguments over technical style are preferences over tooling, education, expected competence, different interpretations and experiences of interoperability.
As people learn, they document findings, either adding to the common school of thought, or rebelling against it. There will be both right and weak conclusions. With time and experience, the better writing turns into more substantial references, like books. Then those articles and books depreciate as the examples within them age.
Here’s our problem: In each generation of web development, we are leaving people to relearn the same lessons of the last. There are techniques backing various aspects of technical style that should be stable and constant by this point. There were strong reasons for one style to be advocated over others in the first place, right?
Two two noisy tribes: One experimenting with their web technology, fluency and productivity through variations in style. Opposition to this starts with a legitimate technical hurdle, but is followed by a torrent of establishment and dogma. Given that research over ten years has gone into establishing the style guide of the web, surely someone would be able to simply reference an earlier work? Everyone interested could revise the issue, reestablish the conclusions, and move on.
But nobody referenced anything in these debates.
Instead we got superiority complexes, and snark, and trolling, and image macros. In vacuum of authoritative references, some rushed out to write new ones, immediately muddling technical worth with ego, and vapid condescension. Elsewhere, a banal portmanteau is uttered with hair-brained sincerity. A kitten dies.
We’ve taken our knowledge for granted, passed it on with examples and well-meaning advice, but failed to establish our references. It’s a different kind of archival shortcoming. We often think of redundantly storing all of our web content, but here we’ve failed as librarians. We knew the knowledge was out there, we trusted the knowledge, but when it was challenged no-one had a robust answer. In its place, dogmatic presumption undermines a lot of the effort around education and best practice, and the cooperative attitudes of our community.
Besides insufficient cataloguing, one reason for uncontentious, enduring references on technical style to evade us is because they’re attached to otherwise ephemeral writing. These patterns we take for granted aren’t being documented well enough. Because the examples we use age. Because the contexts they’re presented in become obsolete and confusing as browsers. Because we don’t have time to be librarians, because we’re building new stuff, because we’re teaching by example. This is all defensible, but it’s evidently not good enough. We can’t work from the prescribed style to a full understanding of the language. If we believe in the web, we have an obligation to support the education of our peers and ourselves; the technology we use is always changing, no-one will ever stop learning. Perhaps this requires a kind of reference writing that blogs and magazines have neglected, but which is done well in other technical writing efforts that avoid issues of style: API documentation, for example.
Technical style is just one small piece of building a successful technical platform from the web. If we care about style—and apparently we do—we need to do better at recording it. We need to build better teaching materials, we need to ensure that people can establish a full understanding of the web and its technology, not just the pieces we ring-fenced as ‘safe’. We need to write for our industry’s encyclopedia, not just its tabloid.
Gmail is free, but they have all my email data and probably know me as well as my wife. Twitter is free, but I feel compelled to keep saying something to hold my following—even if it's just blather. Zaarly is free, but if posting costs me nothing, then I'm more likely to have a weak commitment to my request. Most content on the web is free, but it costs me time to keep up with the incredible mounting pile. Do you feel the cost?
My colleague and friend, James Weiner, brought to my attention this fascinating read from IBM: Designing for Usability. I think what's most interesting about it is how sound the advice is some 30 years later, and also their conclusion that what may seem like common sense is not always intuitive. I think it's worth challenging your own views and critiquing whether you really do always follow your own best advice.
I first gained access to the internet on the cusp of adulthood, a few months before I graduated high school in 1994. In the years that followed, it steadily gained presence in my daily life, and in tandem with higher education and venturing timidly into “the real world”, the internet helped expand my universe far beyond its humble origins.
Today, I live in a major metropolitan hub, have personal and professional relationships on almost every continent, and have a wide variety of interests spanning social, cultural, and political affairs the world over. Obviously, the internet is central to my ability to keep up with it all (to the extent that I can), and the argument could be made that there wouldn’t be as much to keep up with if there was no internet, that my universe would be smaller and simpler.
On those days when the inbox is overflowing, a smaller and simpler universe certainly sounds appealing, and there are plenty of resources like Cabin Porn designed to stoke fantasies of leaving it all behind. But as much as I enjoy the occasional quiet respite from the rapid-fire buzz of digital urbanism, for now, I only want my universe to grow larger.
In The Elements of Style, Strunk and White caution writers to omit needless words. While Strunk and White wrote this advice for writers and editors, consider how you might apply the concept to your life and your work. Consider the following:
- Omit needless meetings
- Omit needless commitments
- Omit needless distractions
- Omit waste
How would your life, work, and productivity improve if you applied this simple thought? What is needless in your life and work? Omit it.
When I was younger, my mother always told me ‘don’t worry what other people think’. I always thought that was pretty good advice but lately I’ve decided it was pretty flawed.
What other people think does matter, sometimes it’s really important. Blinkering yourself to that can cut off your ability to empathise and to respond appropriately.
Now I’m a mother, the message I want to send might be something about finding the value in the things you do that makes you different and really embracing it. Understand yourself better, and understand others as much as you can.
I recently did a Q&A for .net magazine (June 2012, issue 228), answering a few reader questions. One person inquired about my experience going full-time freelance. In my answer, I discussed how I'd always been fearful about going out on my own because of the sales process.
Having spent the majority of my career in the marketing and sales departments of various employers, I hadn't seen much in the way of “sales” that appealed to me. Particularly the aspects of it that always struck me as sleazy.
I just couldn't see myself being that kind of person. Pushy, fake and even dishonest. I also couldn't see myself as the confident “people person” I thought you had to be in order to be successful with sales, sleazy or not.
My first year freelancing, I avoided sales. And, fortunately, I was able to get away with it… but only for so long. This year has been slower for me so far, and that means I've had to take more action in terms of generating new opportunities. Ick. Even writing “generating new opportunities” feels like the kind of sales-speak that bothers me.
But this is the problem. My perception of sales.
Thanks, in part, to speaking with Brad Parscale on the EE Podcast, my perception is changing. I'm not only learning to embrace the sales process, but I'm learning to re-think what sales really is. And, even better, my business is benefitting from this shift.
I'm discovering that true sales is about the prospective client and the fact that I can help them achieve their business goals. It's about the need to establish a relationship so they feel secure to trust me with their business. It sounds like common sense, I know, but re-defining sales from this perspective has been key for me.
I'm now spending more time with prospects, not only trying to learn more about their project but also building a relationship. For example, I created a project questionnaire that I ask all prospects to complete. It has been a fantastic tool to give me a big- and small-picture perspective of the prospect and their needs.
The questionnaire has also impressed several prospects (one of which is now a client), who appreciate the more professional fact-finding tool than a simple email. And, for those who don't want to fill it out, the questionnaire has served as a red flag for prospects who may not be a good fit for me.
Beyond the questionnaire, I'm also taking more time to research prospective projects and clearly define what I can deliver before following up with a call. I take more time to ask questions about a project that the prospect, perhaps, didn't address or didn't consider.
This preparation, though a bit time-consuming, is worth it. Every single time, the prospects I speak with are impressed with how well I know their project and how prepared I am to deliver. Even for those prospects who don't become clients, I've left a positive and professional impression that could lead to work in the future or a referral.
I won't lie and say that I like all the extra work this now involves for me. I'd much rather write HTML and CSS all day long. But there is a rhythm to it, and it is nice to constantly fine-tune my communication skills and materials.
Also, by investing in this upfront time with a prospect, when I do win a project, I'm so much better prepared to execute and my estimates are much more on-target. I've also found that the clients I've earned with this considered sales approach are more committed to their projects and invested with the vision we've come up with during the sales process.
What I realize now is that if you are doing sales well, you don't even think of it as sales. It's building relationships, understanding a client and a project, and demonstrating you can deliver. Nothing sleazy about that.
Web Design < Interface Design < Interaction Design < User Experience Design < Customer Experience < Service Design.
Seems to me that a lot of the drama over job titles stems from a classic outflanking strategy: wanting to appear more strategic than the other guy. We jostle for ascendency in this supposed value chain, trying to appeal to more senior sensibilities in the hope of winning broader, richer projects. In the meantime, our language becomes ever more grandiose, our deliverables more abstract, and our expertise even harder to define.
Eventually we'll run out of abstractions, and this euphemism treadmill will creak to a halt. The only thing left then will be to judge designers by our work; by the things we bring into the world. Hallelujah.
I never make long-term plans. Life is an unpredictable adventure. Concrete plans restrict this amazing journey. Stressing over a series of mental checkboxes you need to check until a certain date shifts your focus away from making awesomeness. I have long-term dreams instead, and they are all the compass I need. They give me the drive to constantly strive to improve, while still allowing room for surprises. I learned to trust chaos, and so far, I was never disappointed.
The most sage piece of advice I've ever received was from my father-in-law. I often find myself referring to it in all sorts of situations, at home, work or elsewhere. He said this:
"You can't change people, you can only change their attitude towards you."
I was teaching a workshop this past week at AccessU, an excellent, highly focused event surrounding universal design, usability, accessibility and Open Web methodologies and philosophies. After a lovely morning of passionate discourse and learning, we went to have lunch. Upon my return, I was horrified to find an email from my youngest brother telling me my mother had been taken to the hospital and was possibly having a stroke.
Of course this is deeply upsetting to me, and being far away from all my family members the need to connect with them, and most especially my mother, was immediate and extreme. Fortunately, via email, tweets and yes—even Facebook—the family rallied around as did many other friends and colleagues. This outpouring of love and consideration is what is keeping me strong right now.
As I said my goodbyes to the workshop to go and figure out what the next steps are going to be in terms of my Mom's health and well-being, I thanked everyone and began to cry, speaking from my heart. This is why we're here. This is what the Open Web and open communications technologies are for - to connect people across the world. To strengthen, to educate, to empower and most importantly, to love.
Mortality reminds us in very cold, frightening terms how fragile our life and times truly are. The Web, which is a naturally social and interactive communications platform, can help bring us all closer. The fighting, the drama, the debates - they all become irrelevant in these very mortal moments. Let us all reach for the greatness within ourselves and put it into our Web work every day, because even on those days we feel it's overwhelming or doesn't matter, it really truly does. One world, one Web, one love, my brothers and sisters.
I would be curious to know how design discussions, reviews, brainstorms, happen within other teams. Few things are more fascinating than seeing the process other designers go through to get to their results, but the documentation is often limited to iterations of visual prototypes. I wish there was a way to listen to the discussions, the argumentation, the things people say when an idea is still evolving, or when someone strikes gold.
Ever notice how the things you slave over and work crushingly hard on get less attention, sometimes, than the amusing things you threw together in a couple of evenings?
I can't decide whether this is a good thing or not.
The pixel is no longer relevant in web design in 2012. It's all about ems, percentages and proportions. A two column layout is no longer a content and sidebar 'div' that are 600 and 200 pixels wide; it's now a two column layout where the content area is three times wider than the sidebar.
So when is the best time to write a book (or give a presentation or start a blog or…) on a subject you're particularly interested in? While you're learning! Putting words on a page isn't a commitment (trust me). You'll be able to add to, edit, and refine your ideas along the way–but only if you take the time to write them down. Also, there's a certain amount of fidelity to your thinking that fades over time; write in the moment and you won't lose the burrs and barbs that stick with readers. And, if you share what you're learning with others along the way, all sorts of people and projects will present themselves; you'll have more information and learning experiences than you could have imagined-- all while you're curious and enthusiastic, all while you're a student of your subject.
But, if you wait until you're an expert (which you'll never feel like you really are), one of several things will happen: One, everything you've learned will seem mundane and not worth writing about. Two, you'll be so bored of the topic that writing a book on the subject will be the last thing you'd ever want to do. Three, your interests will have led you to new, entirely different subjects. Or four, your interests will have led you to a new perspective from which it's no longer possible to write about the things you learned.
I'm proud of the book I wrote, and the card deck I self-published. Others have found them quite useful. But, had I waited until I felt competent about the subject (psychology and design), these things would never have been created; my ideas would have never taken a form that could be shared with others. These things would have been another casualty in the lineup of ideas I'll never work on.
It's human to create and learn. Doing isn't a commitment, it's just a step that keeps your ideas in motion and your options open. What are you working on? What are you learning? What are you creating?
I’ve written about this before, but I pace like crazy when I’m on the phone. I don’t know what it is, but I think my body has to wander a bit so that my mind doesn’t. So to stay focused, I walk little loops around the living room; I trace figure eights around my kitchen; I walk up and down the front hallway.
This is, I’ve realized, kind of the inverse of what I do most of the day: sitting mostly immobile, staring at glowing glass panes of various shapes and sizes, my mind racing up and down and through Photoshop, CSS issues, todo items, and inboxes, running without moving until the evening, when rest comes.
Walking while thinking; mind racing while sitting. I need a middle ground: more walks without phones, more focus in front of my computer.
I'm not following any trends, I'm just trying to do my own thing. If people say you can't use rounded corners anymore because they are overused, that type of info doesn't have any value for me. If I'm working on something that I feel is better suited with rounded corners I will use them, trendy or not. Just like with anything else, I feel it is okay if it fits the project or when used in moderation. That's why I almost never look at web site galleries, because they often kill inspiration.
About a year ago, I left day rates and job rates behind and started estimating, billing and working on projects on a weekly basis. A year on and I’m better organised, more productive and less stressed than ever before. Our accounts are in better shape and no one owes us money for longer than a week. It was one of the best business moves I’ve made.
On a World Wide Web, sometimes your customers come from unexpected places. Let's take the dating web site, Ignighter (now called Step Out) as an example. Set up by a group of New Yorkers, it was founded in 2008 and, after an advertising blitz, by the end of that year had 50,000 registered users in the USA, which wasn't really enough for "critical mass".
In April 2009, the marketing manager noticed that there was a lot of traffic to the site from Singapore, Malaysia, India and South Korea. By June, they had more visitors from India than any other Asian nation. In January 2010, Ignighter made the decision to re-launch itself as an Indian dating site. It gains the same number of Indian users a week as it gained in America in its first year. (Read more about Ignighter.)
If Ignighter had only been coded with single-vendor prefixes and browser-sniffed to work only on iPhones, it probably wouldn't have been able to grow like this, as that's a highly aspirational product in India where it costs many times a professional's monthly salary. But it was a website, capable of being looked at on the feature phones that are so widespread in Asia.
Obviously, there's no guarantee that you'll have similar success if your website works across browsers and across devices. But if your website doesn't, it's pretty much guaranteed that you won't be able to develop a market in the fast-growing economies of India and China, where 40% of the world lives.
I enjoy reading books by successful people in different types of business. In our very new industry I think we can learn a lot from more established industries. I recently read Strong Woman: Ambition, Grit and a Great Pair of Heels, an autobiography by Karren Brady, a UK businesswoman who became the Managing Director of Birmingham City football club at just 23 years of age. Her story is really inspiring, but I highlighted one quote in particular.
And, if you are the first woman anything, and I'm told I'm the first woman in football, then that's something to take heart from–because you have opened a door. The trick is to hold that door open as wide as possible, for as long as possible, to allow other women to march through it.
I couldn't claim to be the first woman in anything, but I know a thing or two about working in male dominated industries, and this idea of "holding open the door" really appeals to me. When we talk about wanting to get more women into tech, that's exactly what us women who are already here need to do, we need to hold open the door. We need to show that this is a fantastic industry to be involved in, we need to support those who are taking their first steps and we need to be visible so that other women and girls know that they are not alone. That they won't find themselves without female friendship. That they won't have to fight battles just to be accepted.
It is important that we point out as inappropriate the examples of sexism that we do see. However we should also take care to reassure those who might want to walk through the door that these examples are actually few and far between. Yes, sexism has been directed at me, but not often. I don't believe that being a woman has disadvantaged me in my work or career. We need to get a balance between showing that sexism is not welcome here and demonstrating that in general we work in a welcoming and friendly industry. We need to show those looking through the door that most people here are only interested in what you can do, share and contribute, and that there are great opportunities and a whole lot of fun to be had.
This month’s thought may be a rant or two, and a plea, or rather, a dare.
Flash died, I heard. The only thing is, suboptimal interaction design wasn’t some kind of child of Flash. It was the offspring of designers; the decisions some of us make. Some of those offspring are still very much alive. The only difference now is that instead of those decisions being encapsulated in Flash, they’re being coded into HTML, CSS, and JS by wily front-end developers at the mercy of their agency overlords for their daily bread: Animations that just…won't…stop. Un-mutable music (hello Geocities, again). Sliding, jumping, bouncing, parallax-ing, hiccuping, flatulent decorations and controls. Force-fed, on-message advertising, masquerading as interaction, with accessibility something that might be mindfully included if the developer has time. Stop it! Please!
Let me pick up on one more bug in the system: The white-labelling of freelancers and subcontractors by agencies. That insidious situation where, under the dubious restrictive practice of perma-NDAs, some companies hoover up the credit for every aspect of a piece of work, and do not allow the freelancer to talk about what they’ve done. Stop it! Give credit. Let folks own the right to talk about their work as long as everyone else gets a mention, with a link, and a note to say exactly who did what at the start of the case study.
Let’s create an ecosystem of credit where it’s OK that ad-hoc teams come together around a project. In fact it’s something to be proud of! That’s the reality after all. That’s the truth. It’s OK to say so-and-so did this bit, but we did that. It worked out fine. No reputations were harmed in the making of this website, app, or service by an ad-hoc team. In fact, they were all the better for it. If companies like the ones I’m scolding dare to give a little credit, I’d bet they’d find it comes back with interest. Go on agencies, I double dare you with extra whitespace.
Here's a conversation that occurred on a train:
"How do you decompress from work?"
Reading through Twitter, blog posts and various other Internet correspondence, I've noticed a common theme. Call it what you prefer: "venting", "complaining", and/or "reality", but a lot of us seem to be tired, overworked, and/or stressed out.
At the same time, wellness seems to be a theme gaining popularity. This is probably not a coincidence. We are encouraged to balance our work and our personal life as to not get burned out on either. We see articles about how sitting is killing us and contemplate purchasing monitors that can tell us we have bad posture.
But how exactly do we do that? It's been nice to see some solutions to these issues, such as dimming our screen every hour, reminding us to get up and walk around. Or booking a private villa in Spain for when your team needs to work overtime. Not so shabby ideas. I hope to see these more of these coming.
My front-facing portfolio only shows about 20% of all the work I've ever done. Why? Because the rest is crap. We web designers are changing the world around us—it's up to us to provide the quality control. We can make a huge difference with our work, and it's up to us how good a difference that is.
Don't design crap. And when you do, let it go. Shove it away where no one can see it but you, and let it remind you where you once were and where you're headed. Keep that bar high.
When I'm working on a project for a client, it's rarely the wants of the client I focus on. Instead, it's the needs of their clients. I can't even begin to count how many arguments I've had with my clients (or designers) about type that's too small or colors that are too distracting or "make the logo bigger". The next time one of your clients tells you "the customer is always right", ask him if he'd make that argument to a pilot or surgeon.
In the last 12 months or so, I've had a number of quite specific online conversations about the performance of web technologies. Indeed, some of these conversations go back quite a bit before that.
Most recently, I critiqued a spate of articles arguing that localStorage suffers from performance issues (well, might in theory, though evidence suggests otherwise).
9 months or so ago, for reasons best known to myself, I posted a point by point critique of one of John Gruber's typically fact free pieces asserting that native apps are inherently better than apps developed with web technologies. At the heart of these arguments is the issue of performance.
Developers care a lot about performance. The mark of a quality application is responsiveness. Not in the sense we've come to use it recently, but in the sense of the perceived lag between a user's action and the outcome.
But this is essentially a meaningless observation, because performance is just one small, although of course very important, piece of the puzzle. Lower level, more highly performant languages may well impact time to market, cost of development, platform reach, and more.
Practical developers typically care not about overall performance, but the bottlenecks where performance becomes an issue—often because it impacts the user experience. Developers optimize for those bottlenecks, and it's only when after all optimisation, performance remains below a certain threshold that we have a real issue.
In essence, at present most conversations about performance take place at an ideological level. Where we need them to take place is the practical level.
When someone observes something lacks performance, is "slow", or however this is characterised, hand waving like "compiled is always faster than interpreted" or "synchronous is always slower than asynchronous" miss the point. What we need to do is:
- Identify the specific, measurable performance issue
- Benchmark this, so as to meaningfully compare it with alternatives, and also to derive a measure of what is adequate (in performance, as elsewhere, the perfect is often the enemy of the good)
- Look for optimisations which can help provide adequate solutions in the given circumstances
We have a genuine issue when we can't do the third step.
Too often we fall into black and white thinking, which is anathema to engineering, the art of making stuff work. In engineering being right isn't as important as solving the problem. Sure, rhetorical discussions may be engaging, but they don't really solve much.
When it comes to development, we have so much to learn. Glibness won't help us do that.
On Pricing: The Object Value System
Few people talk about pricing in our industry, and for good reason. There's hardly a straight answer for "What should I charge?" It depends on many factors: the value of the project to your client, the amount of inquiries you currently have, the type of project, who the client is, the services needed, the amount of time necessary to complete the project, the amount of time you have available, and many more.
For even the greenest of designers, gut reaction is often disregarded for logic, to their own detriment. Trust your gut; it can tell you many things that a spreadsheet cannot.
Here's a system I use to help qualify my gut reaction. Ask yourself what object you would barter for this project. Let's choose a website redesign as an example, a type of project many likely get. Choose an object to represent the value of your project. If your client offered you a new iPod touch instead of cash, would that be fair to you? Probably (hopefully) not, which means you value this project at a higher rate than $199 (currently the going price for an iPod touch). What about a Playstation 3? An iPad 2? Dinner at your choice of 3-star Michelin restaurants? A Canon EOS 5D Mark III? A week-long all expense paid trip to the resort of your choice? Rent for a year? A new Volkswagen Touareg?
Let's say you thought the Canon EOS 5D Mark III was a fair trade for this website design. Since the current price for that camera is about $3500, that gives you a good sense of the minimum you would charge for this project. While I certainly don't suggest making this the only way that you evaluate value, it can definitely help you to hone in that gut reaction to get a sense of where you really place the value of your project.
If you're interested in learning more about how to price a project, check out these excellent resources:
- Why we are getting rid of our hourly rate, by Teehan+Lax
- Pricing Strategy for Creatives, by Jason Blumer
- The Dark Art of Pricing, by Jessica Hische
- The 'Hows' of Pricing Your Design Work, by Brian Hoff
- How much to charge for design work? by JUST™ Creative
- Designers' Hourly Rates: Are You Charging Enough, by HOW Design
- Tiered value-based pricing, by Teehan+Lax
Plugins are one of the main reasons I enjoy using WordPress. Here are four I end up using in nearly all WordPress related projects. I hope you find them useful.
- WP Super Cache - Simply activating this plugin will increase the load times of your site, especially on shared hosting environments.
- Maintenance Mode - A great utility plugin that allows you to activate a branded "maintenance" page, ideal for when you are deploying big changes or updating your data.
- Advanced Custom Fields - A recent addition to my standard library. This plugin allows you to add groups of meta boxes to your posts, pages and custom post types. Field types include date pickers, text, HTML editor and many more. Spend $25AUD on the "repeater field", you won't regret it.
- Custom Post Template - This plugin allows you to selectively choose templates for any individual post. For example, you can assign an entirely different template to posts in a particular category. Your chosen template will replace single.php for the specified post.
I had a fairly recent DM conversation with Nishant Kothary (@rainypixels) about our love-hate relationship with Twitter (you can read his thoughts in detail here and here). For me, not only can Twitter be addictive, it is more often than not the promulgator of a down-spiral of self-flagellation based on comparing myself with the perceived achievements of others.
My anecdote to this pernicious virus? Boundaries. Rules. The first is a physical practice: to maintain my equilibrium, I only read @mentions and DMs. The second is a mental practice: be self-referential. There is a saying that you can’t judge a person’s outsides to your own insides. So, instead of beating myself up over what I have not done yet, I make a concentrated effort to look back and give myself props for the things that I have done and the progress that I have made in my life and career. If your inner critic is working overtime (I’m working on firing mine), then focusing on your own process and how you feel about it usually helps.
Somehow, I keep managing to forget the benefit of switching off. Not checking email. Letting that iPad stay on the table. Every time I do switch off for a while—perhaps even just a weekend—I feel so much better prepared to go back into work. I feel rested. And yet I'll forget this feeling, go back to being connected nearly all the time, and suddenly be reminded of how great disconnection is once I try it the next time. This is a reminder to myself and to others to switch off way more often than we do. I'm going to try and not touch email at weekends from now on.
As programmers, who are we programming for? On the one hand, we're writing code to be interpreted by machines; considered this way, code should be logical, consistent, and machine readable. But unless you're writing code in Assembly, the fact of the matter is that the code you're writing will never be directly interpreted by the machine—a compiler will take that code and make it machine readable.
So, in the case of interpreted languages, who is the code for, in the end? I'd argue it's for you, the developer, and those who will be maintaining it later.
As such, I've always taken Larry Wall's aspiration for coding in natural language to be a lofty and noble goal (despite the fact that idiomatic Perl is considered a write-only language). Name variables meaningfully, instead of using short, cryptic names. Follow natural grammar when you can. Use white space to separate discrete ideas and concepts in your code.
Code can be poetry, if you work at it.