So the company you work for hired a few n00bies to help lighten your load? Sweet! Now not only will the soul-crushing mountain you are tasked with scaling every day be reduced to a rubble-topped mole hill, but you’ll get a kick out of helping your newly-acquired underlings get their feet wet.
Feel the cool rush of power and knowledge seep into your ever-expanding ego and embrace the warm caress of it’s glow. This is your time. Continue reading “5 Tips on How to Train Your N00b” »
Ghost hit the public earlier this week. With all the hubub surrounding the new blogging platform, I’ve noticed that it’s still very-much in it’s infancy.
After I got my first site set up using Ghost, my next logical next was to start hacking into the theme (because why not).
Get started by heading over to the Github repo and fork me! I look forward to growing with this platform and seeing where this adventure takes us.
If you’re like me, you have a litany of side projects and ideas constantly in the hopper, and choosing what to work on next is never easy. Should I pursue that paying gig? Should I write that blog post? What about that web app I wrangled a buddy into helping with?
There’s a thousand considerations to make when deciding to take on new responsibilities, but for me, they usually boil down to a choice between:
Choosing #1 is the safe place to be in the short term. You know the ins and outs of a certain kind of project and can gauge what you expect from it. For example, a quick WordPress site. I know how long it will take, how much I can charge for it, and what I can expect out of it when it’s done. No surprises here, Mr. dependable.
#2 is a bit of a wildcard. These projects are the “wild hair” kinds of things that shoot into frame late at night or over a beer. There’s no dependable roadmap for this kind of project and you don’t know if it’s useful to anyone, but there’s something in the not knowing that makes it exciting as hell, at least at first.
Not too long ago, I was asked by a coworker to illustrate a video she was working on. At first I thought she was at best only half-serious. Sure, I doodle crap constantly, but that’s what it is, crap. I don’t take it seriously and I don’t expect anyone else to. I’m no DaVinci, but I get a kick out of it.
I was reluctant to pursue this new opportunity at first. Self conscious and a little weary of actually challenging myself, I tried to think of excuses not to do it. I mean, “Who the shit am I to be drawing for any real purpose in mind?”
Eventually, having evacuated myself of all my ideas of what could go wrong, I decided to go for it. I didn’t know what I was doing, I wasn’t sure I was capable of the task, and I sure as shit didn’t think it’d turn out well. Then again, it was something different, and there’s value in that.
In the end, the video turned out pretty decently in my humble opinion, and more importantly, I had a blast doing it. I learned a little bit about how to stretch my perceived skills in different ways, and focus under the threat of failure.
Getting out of your comfort zone occasionally can be a good thing.
By the way, here’s the video:
As a 27-year-old web designer-developer, I’m turning the corner between from n00b to someone who feels like they know what they’re doing. Directly after college, I got a design job at a small agency. I didn’t really know what to expect in terms of workload, culture, or routine. It was all new to me, and that feeling didn’t go away for a very long time. Now with a little professional experience under my belt, I’m no longer overwhelmed by the day-to-day drama that most worker-bees seem to take for granted.
About a year ago I became hopelessly addicted to Andy Rutledge’s plethora of writings, web chats and video produced on the subject of professionalism. Throughout his editorial work, he asserts a few basic tenets of Professionalism (as I interpret them): Be accountable, be honest, be confident.
While I love his mantra, there’s a big roadblock to many young professionals that must be overcome before you can really take advantage of this outlook: As a young professional, the overwhelming newness of office life is too distracting to focus on becoming a professional.
Over the last six years, I’ve accrued a few strategies that have transformed my world-view which have helped clear the way for me to focus on what’s important: Transitioning from starry-eyed college grad to professional.
This book started out a rather-lengthy blog post. As I kept writing, it became clear that such a text would be better packaged in a PDF.
Over the last few years, I’ve become utterly addicted to productivity articles. Anything with a juicy title like “Double your productivity…” or “How I grew my business overnight…” would receive an anxious click from me. As I waited to delve into the deluge of secrets the author implicitly promised to deliver in that linked-baited phrase, I’d ponder how effectively I too could install these practices into my daily life and thusly reap the benefits.
I’d even approach their more conservative brethren with the same zealous insatiability. Observations that there’s no “quick fix” for productivity, and assertions that success requires a constant level-headed approach were drank in with the very same gluttonous appetite.
During this self-imposed productivity binge, I’ve developed my own philosophy that’s both increased my daily output, and decreased my anxiety on the subject. It’s made me a much more productive, happy person. I call it the “Mood Method.”
When you feel productive, don’t let anything get in your way. Be a laser-guided jerk and focus on the task at hand. Ride out your inspiration as long as you can and don’t let distractions sully your potential.
That might mean secluding yourself in a coffee shop or office. It might mean closing your Gmail tab. Or it might mean canceling dinner plans and turning your phone off for an hour or two in the evening. In short, everything else can wait.
Personally, I’ve found it very hard to force myself to be productive when I feel sluggish. I find that it’s far better, for lack of a better term, to coast through those periods of exhaustion until that familiar sense of inspiration hits again. The flip side is that when inspiration hits, pay attention to it.
Like most people, I often vacillate between periods of productivity and relaxation. This method requires that you follow your inspiration when it occurs, but never force it. This lets you enjoy periods of rest, and let’s you avoid the anxiety-laced perspiration often expelled by trying to create something when it’s just “not happening.”
When a creative burst of inspiration hits, honor your agreement and hit the ground running.
At the beginning of every project, I set aside half a day to just think about the project, and ask questions. Even when I’ve been prepped during the earlier discovery and design processes, I still have no idea what has changed in the last round of design revisions or what implications those have for development.
As with any creative endeavor, development progresses through the constraints that are applied to it. This is an attempt to help you develop those constraints and get rid of the guesswork that all-too-often accompanies a new project.
What’s this supposed to do?
Project managers and designers are often guilty of not thinking through a problem all the way. Pretty schematics, pages of wireframes and finally beautiful comps make it easy to seem like they’re focused on the right things, but it’s often not until development starts that edge cases eek out and bloat your scope.
Sweepstakes phases seem to be a common transgressor in my experience. “What happens after submissions are closed? How do we tell users the finalists have been chosen?” By thinking through the project like a user, you’ll explore the areas a PSD doesn’t show you.
Who will use this?
In line with #1, it’s not enough to simply know what the application is meant to do, you have to understand who’s going to use it, and how, and when, and through what. Technology today is so varied and nebulous that you can’t simply develop for yourself and call it day, and to develop “for everyone, everywhere,” is just not realistic or helpful.
This is the time to nailed down semantics and get specific. Don’t lets a weary project manager cut you loose without this information. You’ll be surprised what misunderstandings may be uncovered. The difference between you different understandings of the word “responsive” may end up costing you.
Who has the last word?
I’ve been bitten by this bug. You may think you’re talking to the “decider” when you meet with the project manager, but then days before you’re done, you come to find out of of his higher-ups reviewed a spec a wants a “quick change.” Usually these meddlers are so far removed from the day-to-day process that it’s hard to communicate the cost of making any changes at that stage of the project and you’re stuck working double-time to hit your deadline because you failed to make sure you were getting approval from the right person.
What’s the communication timeline?
Often times, a client will want to see the project during the development cycle. What exactly will they want to see, when they’re expecting a glimpse, and how you’re going to show them are all things that should be sussed out before diving into the code.
What value does this create?
“Value” has got to be one of my least favorite words. It can simultaneously mean nothing and everything, depending on who’s reading it. That said, you need to understand what the client/user is getting out of the project in a business sense before you start. Avoid functional requirements during this conversation. “It’s supposed to share pictures,” is not enough. You need to understand why that’s important the client and how that drives their business. Otherwise, you open yourself up for a massively disappointing curtain-drop when you’re ready to show off your hard work.
A typical Colorodan’s fantasy: you’re a rugged mountain man, completely self-reliant, living off the land. You’re exploration knows no bounds. You travel light, and make due with the things that are naturally at your disposal. Sounds pretty awesome, right? Wrong.
I’m my experience, both as a youngish coder and a relatively newbie backpacker, it’s much better to ask for help. By leaning on my friends and cohorts, I’ve been able to do things I would have never imagined possible in both arenas. Sure, being a bearded badass in the forest is an appealing fantasy, but I’ve found I like it in the movies much more than I do in real life. In real life, there are times I need help. There are problems that I’m not sure how to solve, projects that are too big for me to handle, and often issues I need someone else to bounce my thoughts against.
The art of asking for help has been my single greatest skill I’ve learned since I graduated college. Like many young professionals, generally inept and extremely self conscious, I tried to pretend to know things I didn’t. That may work well enough to land a job, but the shortsightedness offered by that strategy is quickly revealed.
If you’re on a hike and you roll your ankle (which has happened to me many embarrassing times), you might feel like calling it day. At that moment, simply sitting down and gorging yourself on water sounds extremely appealing (yet unproductive). Although you may want to quit, it’s an easy urge to resist, because it’s obvious you have little choice but to keep trekking. If you quit in the middle, you’ll just end up cold and hungry later, and that’s no fun. So you simply keep moving, even though it sucks.
The same is true in coding. If you’ve taken on a project and encountered a roadblock, the tendency to check Facebook or email is super-appealing, but it’s obvious what you really should do. Procrastination only delays the inevitable, so why even bother with that clean inbox? You’ll just end up cold and hungry later.
When it comes down to it, whether it’s a tough day-hike or a tough web app, you’ve signed up for it on your own because it’s what you want to do. There’s no gun to your head. You get to sit in a nice office and write code all day, and that’s pretty cool.
I rarely find myself trolling html5 blogs and resources, unless I’m troubleshooting an issue. When I started to research HTML5 more than two years ago, the spec was already well on it’s way (or seemed to be). I took the reasonably complete spec to heart, committed it to memory, and have been using it ever since. Today I got a small reminder that HTML5, and the web in general, is an evolving entity, that requires constant supervision, otherwise, you’ll get left in the dust. Continue reading “The Demise of the Hgroup” »
Earlier tonight I was stopped in a grocery store parking lot by a young man asking for money. He didn’t seem like a bum or anything, he was clean shaven, well dressed, and honestly seemed pretty desperate. “Are you the type of person that would help a person out if they needed something?” he asked. “Sure,” I thought to myself… but all I replied was “What’s up?” incredulously, as I held two bulging shopping bags in my hands.
He said he was traveling with his girlfriend from Austin, TX but had unfortunately ran out of gas a few hours ago. They were “so close” to getting enough to keep moving, and did I have some cash for them? As I reached into my pocket to fish out my wallet, he kept on, “…and we’ve been driving all day and are really looking to get a hotel room.”
He lost me. Did he need gas money or money for a hotel? That incongruous tidbit spoiled the whole encounter. He may have very well been a dude, down on his luck, but I couldn’t really tell. I don’t have a ton of cash usually, and not the kind of hand-out-to-strangers cash that would make such a decision easy, but my mind was made up at the moment he told me two purposes for this phantom money I was to give him.
It’s a fact that’s as true on the web as it is in real life: people don’t like incongruity. If something smells “off,” it’s only natural to bail.