Don’t I love you? Don’t I respect you? Don’t I treat you better than any other man ever has? Why do you have to treat me this way?

Don’t I do nice things for you? Take you out to fancy dinners? Make you breakfast in bed on Sunday mornings? Get you things from downstairs when you’re tired? All I ask is a little respect, some recognition that our relationship has give-and-take, and that you use spell check when you email me.

Love is a two way street, and when we’re together, girl, I feel you. That connection. That incredible high I get when I’m near you. I treat you right because I value you as a person. You don’t ask for much, and I’d gladly give you all I have and more just to be with you.

And yet when you send me text messages that say “WHER R U???”, I don’t feel that connection. I feel lost, like I don’t know you, and you don’t know me. It makes me sad, and yet when I tell you how I feel, you don’t listen.

Love is about the little things. When I wake you up in the morning to get ready for work, I don’t wake you rudely. I leave the light off and kiss you lightly on the forehead, because I want you to start your day knowing that I love and respect you. It’s not a grand gesture, and takes only a second, but it makes you happy, just like how checking to ensure you’re not using caps-lock when you email me would make me happy. It would make me so very happy.

Girl, it’s not a lot that I ask from you. Just a little love and respect. Love is all about communication, that’s why I tell you so often that I love you, and why I listen when you talk. Love is built on being able to understand one another, and I want to understand. But when I get emails like,

“? 10.00 for the stand, right? we have basket that useles wihtout the stand…10. no more…”,

I can’t feel that understanding, that visceral love connection I know we both share.

I hope you read this and you feel me, Girl. I hope you understand what I’m trying to tell you.

Because I have no friggin’ clue what your wrote in that last email.

But Girl, I still love you.

Extrapolated from a real-life exchange I had with my wife. Title image by PhotoJonny.

I was originally planning to blog on another topic, but I’ve been trying to capture my thoughts around a specific issue for a while now, and I finally feel like I’ve captured how I feel.

You sit down in front of your computer and you’re uneasy. You’ve got a ton of work to do, but all of it seems pointless. The code open in front of you is awful; worse yet, it’s yours, freshly written last night.

You can’t focus. You troll around Hacker News and all of the articles are about people younger than you doing cooler things, faster, and making millions doing it. You’re frustrated, depressed and unmotivated.

You’ve got the demons.

I am intimately acquainted with my demons. They feed on doubt. That little fear I have in the back of my mind that I made a mistake by changing careers – by trying to become a web developer.

• How can I compete with computer science grads with 10 years of experience on me?
• The web changes too fast. I learn one thing, and suddenly it’s old and out-of-date. I’m always behind.
• I couldn’t handle math back in high-school. Real programming is all math, right?

I used to worry it was just me. It’s not. Lots of people have them. Maybe you do too.

If you’re struggling with demons, I’ve got some good news and some bad news.

Let’s Start with the Bad News

I don’t know that the demons ever really go away. In fact, success seems to make them worse.

I’ve been studying web development for over 5 years now, and I think I’m reasonably competent as a developer. I’m employed full-time as a developer and project manager, I write code that works and people like. I even get paid in my off-time doing freelance projects.

For all intents and purposes, I’ve succeeded. I’m no start-up millionaire rock star, but I make my living working with computers and the web, just like I wanted. Objectively, that’s awesome. I should be overjoyed.

And yet, if anything, I seem to get the demons more now than ever. The more I learn, and the better my work gets, the more I fight with inner demons. It’s like the light at the end of the tunnel constantly gets further away.

Five years on, and I think I’m starting to understand why.

Here’s the Good News

My best guess is that the demons come from ambition. The drive that makes you and I want more than we have. If we didn’t care, our demons wouldn’t bother us.

I set a goal for myself to get a job as a developer. But when I reached that goal, I didn’t celebrate and settle into a comfortable spot, my eyes went higher. Suddenly developer wasn’t enough. I wanted to start a business and run my own show. Back came the demons.

Demons mean you’re capable of more. They are the byproduct of success and possibility.

You’re hungry and you’re capable. That’s a great combination. Even better, just by fighting the demons, you drive yourself closer to your goal.

• When you’re sitting up, late at night, ripping your hair out trying to learn something, you’re winning.
• When you’re writing that code, and it doesn’t work, and you’re frustrated, you’re winning.
• When you’re feeling out of your league, but you push on anyway, you’re winning.

Don’t get me wrong, it’s hard. It’s really hard to buckle down and keep pushing when you get that restlessness and everything feels pointless.

But that struggle is where success comes from. No pain, no gain.

Sometimes you need a break – don’t be afraid to take one. Go watch a movie or go for a bike ride. Take a few days off if you have to. Burn-out is real, and while, at the time, it might feel like you’re losing ground, these breaks are critical opportunities to refocus.

But once the fires subside and your head clears, come back at it. Come back and work harder.

Learning something is hard.

But your ambitions are high. Your demons prove it. Stay focused and push, because the next time those bastards try to catch you, they’ll have one hell of a climb.

Image by matiasjajaja

In brief, within a month of being hired, I spent two weeks building a web page instead of doing the job I was paid to do. The demo to a room full of execs worked as intended, but everyone seemed to hate it. I didn’t hear anything from my boss for days.

I don’t actually remember being told that I was now getting paid to do web work. They didn’t change my title, and they didn’t remove me from the sales rankings (even though my sales were always $0).

In fact, the only follow-up I remember about that meeting was the Director of Marketing coming over after a few isolated days and telling me, “We want you to redesign our lead-generator landing page for next week.”

This new project would require:

• Making the form more usable
• JavaScript validation
• Alteration of some ASP.net code
• Email confirmations

Brain: “NO!!! NO NO NO N…”
Mouth: “I can do that. Yes.”
Brain: “…”

An Unconventional Skill Set

If you ask people what skills you need to be a software developer, they’ll probably give you a list like this:

• Attention to Detail
• Abstract Thinking
• Logic

Don’t get me wrong, those skills help, but I’ve tended to rely on a couple of other things:

• Perseverance
• Coercion
• Delegation

It was these 3 things that saved my job that week, and probably still account for the majority of my success moving into web development full-time.

Perseverance

The role of Perseverance is fairly obvious. When you take on a completely new field, you spend all your time learning.  In fact, more than any other field I can think of, web development moves fast, which means you’re always chasing a moving target.

Worse than that, learning is hard, you actually kind of suck, and you know it.

Ira Glass has a great quote about perseverance (paraphrased for programming),

… For the first couple years you make stuff, and it’s just not that good. It’s trying to be good, it has potential, but it’s not. [...] A lot of people never get past this phase. They quit. [...] We all go through this. And if you are just starting out or you are still in this phase, you gotta know it’s normal and the most important thing you can do is do a lot of work. Put yourself on a deadline so that every week you will finish one [thing]. It is only by going through a volume of work that you will close that gap, and your work will be as good as your ambitions. [...] It’s gonna take awhile. It’s normal to take awhile. You’ve just gotta fight your way through.

I don’t think I could put it any better than that. To bring that a little closer to web development, the best way to learn is to build.

Web Development is all about solving problems. When you start building something, you start solving problems. Your basic knowledge like programming syntax will naturally grow as you bash your head against your particular app or website’s dilemmas.

If you’d asked me if you can learn HTML and CSS in two weeks, I’d probably have told you no. But in the context of a project, you don’t really have a choice. You can’t back away from the bits you’re having trouble with. You have to get it done, and so you do, and you learn.

Of course, sometimes even perseverance doesn’t work, which means you need a fall-back.

Coercion

Coercion is the skill of getting people to agree to things that they don’t want to. It’s a required business skill. Getting that sale from a hesitant customer; getting resources from a stingy manager; getting that meeting from a busy exec.

But before any of that, it plays a critical role in your transition to developer.

In short:

You’ll never move from hobbyist to working developer until you manage to convince someone with money that you can do something you’ve never actually done before. When I said I could redesign the lead-generator page, I had no friggin idea how I was going to make it work, but I was able to look my Director in the eye and say I did.

Now I’ve got a more difficult project, a shorter timeline, emerging HTML skills, and just enough metaphorical rope to hang myself. Now what?

Well coercion ties in nicely with our next skill:

Delegation

Some things you can persevere through, but some things you just can’t. I can’t learn to hack C# and redesign the page and learn JavaScript validation and update the form fields in a week.

So I went delegating.

All of our paid designers were busy, but one of the other sales agents had a decent eye for design and was constantly Photoshopping other employees into funny photos and sending them around. I explained the project, asked for help, and he was nice enough to help me out.

Next on the list was hacking the .Net code. This was simply out of my league. My only recourse here was to go back to the Director of Software Development for help.

I had a fairly antagonistic relationship with the Director of Software when I first started. It was no fault of his, I was constantly meddling with his stuff.

But he was a fantastic guy at heart. He also had a philosophy of under-promise and over-deliver. He told me he wouldn’t change the .Net code, but I got an email an hour or so after work that day with a link to a development server with an unstyled new form with extra fields and an email confirmation system.

Finally, I had to implement the new design on the form and figure out validation. HTML forms weren’t too far out of reach for my meager skills, and JavaScript form validation is not an arcane art – it’s well documented online. jQuery didn’t exist yet, but tutorials did.

I got to work.

Humble Beginnings

It’s not so pretty, is it?

It’s not an epic picture of noble man-against-machine feats of programming fury. A lot of it comes down to relying on people.

I mean really, what have I done, here? I’ve done some HTML, CSS and JavaScript for a couple of simple web pages, while heavily leaning on people of greater skill than I. This isn’t exactly solving P = NP.

And yet, it can work. These first simple projects gave me confidence and credibility within the organization to get stuff done, and that started my transition from sales agent to web developer.

You’ll learn over the course of your journey that the money isn’t in knowing how to do something, but in finding a way to make it happen.

Sure, there are the top 50 tech companies where you have to be a rockstar engineer to solve the problems they’re facing, but for the other 50,000,000 small and medium sized businesses, you can provide value with simpler means.

If you can show enthusiasm and drive, get cooperation from your colleagues, and (usually) deliver on time, your actual technical chops start to matter less.

Sometimes you just have to take the jump.

Job Descriptions Lie. Sometimes the job you want actually doesn’t exist yet. There’s no job title for “Marketing’s Non-IT Web Hooligan”, but that doesn’t mean that skill set can’t work for the organization. Next time we’ll talk about building the job you want in the organization you’ve got.

Photo By ROSS HONG KONG

This first post is going to be a bit long. I’ve got to get a few things out of the way first. Sorry in advance.

The Day I Decided

About 5 years ago, I realized that I wanted to program computers for a living. I had already finished school, had an arts degree and an entry-level job in sales, and although I’d always loved playing around with computers (mostly playing computer games), I thought I was going to be a journalist.

I’d maintained my own website for a few years. Written in Dreamweaver, using HTML4, it was awful, but then most of the web was in those days. In terms of a web development background, I’d read a book on C when I was 15, and never got past chapter 3. I’d tried again with PHP when I was 18, and failed at that as well. So we’re not talking about a huge amount of technical knowledge here.

Right out of school I got a job at a non-profit. While there, I built them a web-based newsletter called “The Beacon”. It was a webpage written in HTML tables that we would update and email out a link to it. It was pretty awful, but it worked.

On my resume, when later interviewing for my sales position, I’d mentioned I had some skill with computers and HTML. They were apparently intrigued. I got the job, possibly because of my interest in the web, or possibly because I low-balled my salary requirements to try to get the job. .

It was in this role that I really decided to become a developer. Today, I make my living managing and writing code for web projects.

If you want it, it can be done.

What I Do Now

Ok, so first let’s get one thing off the table. I’m not a self-made Google Engineer (at least not yet). When I say I manage web projects, here’s what my day job actually entails:

• 33% Project Management (project plans, meetings, more meetings)
• 33% UX Design (Mock-ups, user testing, intuition)
• 33% Front-end Development (HTML, CSS, JavaScript)

Most of this isn’t “writing software”. Ideally someday soon I’ll start to get paid as a more traditional developer. That’s my end goal, but I’m not there yet. It’s a work in progress. You’re coming along for the ride.

Why I Chose This Route

The road from Sales to Web Development wasn’t a straight path for me. In many ways, it couldn’t be:

I Needed a Job

I couldn’t afford to stop working and focus on just coding. I’d already finished school, had gotten married, and had to make money. I couldn’t go back to college. Unsurprisingly, very few people will pay you to learn software development, and of those few, I didn’t meet any of them.

I Needed a Reasonable Learning Curve

With limited technical background, I couldn’t get a job as a developer. I needed the time and an environment that would allow me to learn as I went.

How I Did It

Short answer: I stopped making sales calls and started coding.

My employer had a location finder on their website. 70 locations across Canada, and the only way to find out which one was closest was a dropdown list.

In an industry where you want people to go to the local store, that wasn’t very good, so I walked into the Director of Marketing’s office (my boss, the Sales Lead’s boss) and offered to make a webpage where you could drill down on a map and find the closest store.

He took a chance, said yes, and gave me 2 weeks to build it. He also made me promise that I’d meet my sales quotas at the same time. I was still on my initial probation. If I missed my sales quota, I’d be fired.

I bought a book called HTML, XHTML and CSS Visual Quickstart Guide and started building. I worked 60-65 hours both weeks. I took the book (and the code) home with me each night and worked on it before bed.

Two weeks later, it was demo day. Present in the room:

• The Director of Marketing
• The Sales Lead
• The Director of Software Development

I loaded up the website and gave my little presentation. The site worked.

The Software Director, having never even heard of the project, and having final say over the website content, was angry that an untested kid from sales was writing software for his servers.

The Director of Marketing thought it was too simple and didn’t POP enough.

The Sales Lead was pissed because I hadn’t made a single sales call in two weeks.

While they yelled at each other, I packed up the laptop, went back, and sat at my desk.

And then there was this lull…

In the next part of this series, I’ll discuss the three basics skills you need for that first web development job, and some learning strategies.

Photo by Travelin’ Librarian

Designing Content-First

If you’ve ever been to this site before, you’ll notice that I didn’t have a ton of content. That won’t necessarily change, but the content that is here should be accessible. The new site design focuses on getting the content I’ve got in your hands as effectively as possible.

Better Implementation

Because the old site was a quick hack from flat file over to WordPress, much of the wonderful functionality of WordPress was ignored. The search didn’t work, the 404 page was useless, and the things that make WordPress the best CMS in the world weren’t utilized. You’ll now find that the site makes use of many of the finer things WordPress offers.

Cleaner Code

Another artifact of the old site architecture was the code. The HTML and CSS wasn’t maintainable, as I’d quickly ported the code over from a custom flat file format. The new site code (conveniently available on GitHub for your perusal) is easier to maintain and takes advantage of  cleaner CSS, JavaScript best-practices, and more modular PHP.

Hopefully the site should serve me better moving forward, and that just might give me the little push needed to update more.

Happy 2012!

Conflicts arise when two different branches are working on the same file and then try to commit changes.

...A--
  /
M-------M-----X - Conflict
            /
     B------

Conflicts don’t have to be catastrophic, it simply depends on what’s happend with the file.

Simple Conflicts

Generally, if the changes that cause the conflict don’t affect the same lines of code, git can auto-merge your changes together without too much trouble.

For example, if Branch A  was fixing a typo in a method getPatientByID and Branch B was working on a method called printReport, when the two branches are merged back into Master, assuming no other changes took place, git is smart enough to merge those changes.

Complex Conflicts

Sometimes, however, conflicts arise because two changes modify the same line of code.

When this happens (here’s the part it took me a while to actually understand) Git changes the source code of the file, and expects you to manually do the changes.

Git’s response to a failed merge

And the updated source file

Let’s get a closer look:

<<<<<<< HEAD
         alert("I'm... too lazy to act on my muted outrage!");
=======
        var x = escape("I'm mad as hell, and I'm not going to take it anymore!");
>>>>>>> dev

What are we looking at here?

Git has replaced the offending line of code with the code from both files.

From << HEAD to ===== is the branch you’re currently working with, and from ===== to  >> dev is the branch you’re merging in.

So what’s the resolution? You have to edit the file back to what actually is needed.

So dev represents the new format of that line, and HEAD represents the new language the copywriters want you to use, you’d probably replace the whole thing above with:

var x = escape("I'm... too lazy to act on my muted outrage!");

Once this is done, you’ll likely want to rerun any unit tests to ensure you didn’t break the build, then re-stage the file using add, and commit your set changes.

Done!

(quoted from sciencebuddies.com)

When I first got started with web design, I thought it was an art. That was bad news at the time because if you’ve ever met me, you’ll know I’m not the most artistic or coordinated person in the world.

In reality, however web design, and most web-oriented business, is more akin to a science. Thoughtful, analytical research will drive much better results than pure artistic talent will any day.

That’s not to say that there aren’t some incredible artists in the web design community, there certainly are, and I envy them, but the ability to draw is not required for our craft.

In fact, lifting the scientific method right off the pages of your high school textbook can be a great way to apprach web design.

1) Ask a Question

The question is your client’s business goal. Why did they bring someone in to build a website for them? More sales leads? Higher sales? Increased subscription rates? Launching a new product? There’s a measurable, defined goal that your client has in mind that defines “success” for the website you’re being asked to design, and your first job is to figure out what that is.

2) Do Background Research

Your next step is your market research. Look for best practices in their industry, talk to the target audience about what they want in a site. Do your research and find out how best to meet the needs of your client.

3) Construct a Hypothesis

Your hypothesis is your best guess at the first design. It’s your gut instinct, and it’s both good and bad news.

• For novice web designers, your gut is usually wrong, but you code it as-is anyway.
• For experienced web designers, your gut is usually close to the mark, but you test it to get it right.
• For veteran web designers, your gut is almost always correct – and you test anyway.

Don’t ignore your gut instinct. Gut instinct is your subconscious mind building connections and patterns of the various data points you’ve experienced so far on the web.

But like anything else, don’t rely solely on gut instinct. Good science is based on multiple points of documented evidence. The more you design, and the more experience you get in the field, the better your gut instinct will be.

4 and 5) Test -> Analyze -> Repeat

This is the heart of good web design. Here, you test your hypothesis against the problem from step 1.

Your tools for this are mockups and user testing. Do some wireframes. Put them in front of people that resemble your target audience, and carefully watch their reactions.

The question you’re trying to test isn’t “do they like the design?”. The question is “do they meet the goal criteria set out by the client?”.

Are they clicking the “Buy Now” button? Are they successfully getting through the shopping cart? Are they quickly finding the information they want? Are they successfully entering the contest?

Whatever that call to action was – the goal your client’s trying to achieve, that’s what your design has to accomplish.

Iterate. Build on your idea based on the feedback you receive.

While your first idea won’t always be right, it doesn’t mean that you’re a failure as a web designer. The standard by which good web designers are measured is results. Are you solving the problem your client gave you? If so, move on to step 6; if not, try again!

If it takes you five tries to get a design that works, that’s a success. You meet the goals laid out in Step 1, and your client is happy.

If you sell a client the first thing you think of and it doesn’t work, your client won’t be coming back.

6) Publish your Results

Once you’ve got a working design, build it. This part you should be familiar with.

Conclusion

Web Design is a beautiful science. You start with an idea, and create something beautiful as an outcome. A little bit of science can go a long way towards making that beautiful thing more successful.

Like what you’ve read? Follow me on Twitter.

The best advice I can give someone who is just getting started in responsive design is to starting thinking responsively right from the start. Don’t create a site for one device and scale down, think about all devices the whole way.

“But that’s a lot of work!”, you say.

It doesn’t actually have to be. Here’s a simple hack I use for wireframing sites that I want to be responsive, and it doesn’t take much work at all.

Tools

All you need for this is:

1. a sheet of 8.5 x 11 paper,
2. a pen,
3. and if you’re a slightly OCD like me, you might want a ruler.

Step 1

Fold your sheet of paper in half height-wise. You want two fat rectangles, not two long, slender ones.

Step 2

Fold the closest rectangle up. When pressed totally flat, the paper should look like 1/4, 1/4, 1/2.

Step 3

Open your paper up, and it should look something like this:

Step 4

Rotate your paper 90% and fold it up lengthwise. We’re trying to create thirds here, so with the backside of the fold hidden and pressed completely flat, you should be looking at two equal halves.

Step 5

Open your paper back up again and use your pen to draw along the folds so your paper looks something like this:

You’re done!

Now you’ve got a single sheet of paper ready for simple wireframing that gives you approximate dimensions for Monitors, Tablets and Smartphones, while leaving a little space for a Site and Page Name, as well as some Notes!

The dimensions aren’t exact, but they’re close enough, and at this point, you’re just wireframing; you shouldn’t be focusing on details anyway!

Using a tool like this, you can ensure that non-PC devices are first-class citizens, and your responsive with purpose, not as an afterthought.

Do you have any cool tricks that help you with web design like this one? Let me know!

If you like stuff like this, you can follow me on Twitter and drop me a line!

A Horrible Idea

Reinventing or reskinning the scroll bar isn’t exactly a new phenonmenon. Ever since Flash became a popular medium, we’ve seen lots of different attempts to make scrollbars sexier.

Altering the scrollbars creates two problems:

1. Scrollbars are a central part of the application
2. Scrollbars are normally uniform across the OS of computer.

Scrollbars are Central to the application

Scrollbars are a tool to give access to content that normally wouldn’t fit on the user’s screen. They’re particularly important because screen sizes vary so widely. Altering the design or function of the scrollbars leaves you in danger of discouraging or disabling access to some of your content – content that you presumably want people to see!

Scrollbars are uniform across an OS

For most applications, scrollbar design is set by the OS, not the individual application (similar examples would be the minimize and close buttons, or with window chrome). Changing scrollbars for your particular application or website can be confusing because your UI will be an exception. Even if your design is good, you’re causing an initial element of confusion with your alternative view.

Examples

Ubuntu 11 and the Unity UI

The most notorious example of Scrollbar UI gone wrong is Ubuntu’s new Unity UI. Linux distributions have never been particularly pretty from a design point of view, but Unity was Canonical’s attempt at stepping into the 20th century with UI design and bringing Linux closer to Windows and Apple in visual appeal.

Unfortunately, the scrollbars in the new UI are particularly bad. As a slim coloured bar with no iconography, they’re largely hidden when not in use. The pop-up overlay is particulaly confusing, as it moves with your cursor even when not actively engaged.

Google Docs

I’m a huge fan of the clean design of Google now that they’ve launched Google Plus, but the scrollbars in Google Docs are not effective. Similar to Ubuntu, they’ve gone for the slim coloured bar with no iconography. There are also no buttons at the top or bottom as with traditional scrollbars. These scrollbars literally disappear into the screen noise. Not good.

Gawker

Gawker – The only indication that more content exists…

Worst of all designs is the new sidebar of Gawker. Their idea? No Scrollbars. They made the decision that between the scrollwheel and cursor (assuming the scrollbar has focus), the user should be able to figure out how to scroll.

This is awful for many reasons, but the biggest of which is that the user has no visual clue that more content even exists. Unless you magically happen to scroll while hovering over the scrollbar, you’ll miss that content. That’s downright awful.

I think I read somewhere that they’re planning on changing it back, and I certainly hope that’s the case.

Conclusion

Look, I get it. Scrollbars are dull and kind of ugly, and everyone would really be much happier if they were just a little more elegant, but please, do your users a favour, unless it’s absolutely mission critical to your application to modify the scrollbars AND you’ve done a ton of research and user testing on the new design, just leave them alone.

Please.

Not a complicated little project, but certainly satisfying.

• Download the Chrome Extension
• Download the GreaseMonkey Script
• View the Source on GitHub