So this may be very Merlin Man (site, twitter, podcast1, podcast2, and podcast3) inspired, but I have to ask it, just for everyone’s sanity: What if you’re actually terrible at what your real job is?
Let’s say you’re hired to build websites. sure. You’re hired to build websites. But as Horace Dediu (podcast) points out, a lot of what we need to look at is the “Jobs to Be Done” and when you look at it in that perspective, your Job to Be Done is really to solve their communication issue.
That’s right. You’re not building a website, but communicating information. Be it “This is good” or “That is bad”, or just “Buy this widget”, the job you are doing for your employer is helping them to disseminate information.
If you get up every day, build exactly what they tell you to build, exactly the way they say, there’s two very, very real possibilities of what is happening:
You’re viewed as nothing more than a production worker
You’re terrible at actually solving the problems given to you, and thus become #1
Sure. You have to be able to make things pretty to be a designer, and you have to be able to code to be a programmer, but you have to be able to problem solve to be effective at either.
So, what do you do if you decide you’re terrible at your job?
So fkrauthan (in #symfony on freenode) ran up against an interesting issue w/ regard to generating paths to other bundles assets.
I don’t personally know much about the problem area specifically, but I worked with fkrauthan to develop a hack that got around the problem.
So, please, take a look at the github repository and chime in your two cents. I’m almost positive there is a more elegant way to do this, but we had no idea what that was.
I have just posted MajaxTwilio to GitHub. It’s essentially just a wrapper around php-twilio providing a little more structure and auto-completion, as well as giving you a structure to build around Twilio with to make your applications testable.
Let me know what you think! It’s a work in progress, but decent chunks of the basics are running.
With no javascript, nothing but the <img> tag is displayed, and everything is happy.
With javascript, we run a system which turns it into the following (this becomes easier if we can evaluate media queries in JS, but I’m not sure if we can do that, so I’m showing an alternate way):
Which should make it happy with screen readers and other similar systems.
This approach has a few distinct advantages:
It leverages existing tools for defining when to load a particular image (media queries)
It provides a graceful fallback for no javascript support
It (hopefully) will be relatively close to whatever is selected for moving forward in a browser integrated solution, as it fits with the patterns already established.
So that’s it. That’s my master plan. What do you think?