how did you get started in web development?
web development caught my true attention in 1997. for those web developers that remember, 1997 and 1998 were the years that the web really began to change and take shape to become the web as we see it today. i was in my 3rd year of studying architecture in uofa's 5 year program and up to that point had dabbled here and there with basic markup and i was using some netscape wysiwyg editor -- pretty horrendous stuff -- but it was still way beyond the boundaries of what my contemporaries were doing.
enter flash: my good friend toby one day came along to show me this new technology called "flash". he proceeds to bring up gabocorp.com on my laptop, and i'm just blown away. i think my wording was along the lines of "dude! it's like tv on the internet!". for kicks, the fwa has archived the site because it was just that awesome at the time:
it might look cheesy by today's standards, but this was truly amazing stuff. actually, it was beyond amazing. up to this that point, the internet was a very utilitarian place. no google. no facebook. no wikipedia. no youtube. css was nonexistent you had internet explorer - version 3. the most-blowing tool in your arsenal as a web designer/developer was the animated gif. as a matter of fact, even with today's technologies, i don't think you could make something like gabocorp without flash to this day. never before had i ever been so engaged and fully immersed in a website -- i had to learn more. and thus ended my brief fling with architecture, and began my obsession with the web! (thanks toby!)
what are your earliest memories of being interested in the technology?
i had the ambiguous fortune of having parents that were afraid of technology, but they also understood it would be a fundamental concept in the development of their children. so instead of atari, my sister and i got some crazy game console you had to program the game before you wanted to play it. we would spend (what felt like) days writing in basic or whatever to play space invaders. and while cool kids had macintoshs, we had the apple iigs: the ultimate in geek computer. so, thanks to my parents, i've been around computers and programming since i can remember. i was always the one who had to fix the computer ...
what was your favorite project web development or design project? are you willing to share a link or screenshots?
that's really a tough question to answer because i'd like to think i have such a personal (and borderline obsessive) attachment to just about anything i work on. not to mention, it's been over a decade -- that's a lot of stuff. i'll narrow it down to 2:
favorite, professionally: vend
vend is the current photocart application that our company (intothedarkroom.com) sells to professional photographers as a photo proofing tool for things like weddings, photoshoots, etc. i think this product is basically the culmination of everything i have been working on, learning, and developing over the course of 10 years.
it's not just for americans. this thing can be translated to any utf-8 compatible language. it works with any country's address system, and it is fully sales tax ready in almost any economy including countries like canada that have a three-way gst/hst/pst tax system (shakes fist at prince edwards island).
the installation is completely automated. no mysql necessary, as the whole thing is run on a flat-file storage system that i wrote from scratch. vend can run on just about any traditional lamp stack and can be up and running start to finish in 5 minutes.
server-side resampling. if i were some, like, powerful person in the web industry that had some kind of "pull", i would make this a feature for web developers everywhere. it's a super-crazy robust image delivery and refinement program i've been refining over 3 years. the idea behind this technology is that we deliver exactly what's required, no more. so you can have image source files that are huge, but when vend makes the call to "get" the image, it knows what the final display size will be, and it resamples, resizes, crops, watermarks, caches, sharpens and obfuscates the url all in one shot. this way people looking at vend with bigger monitors will be downloading bigger files than people with smaller resolutions. here is an example:
it breaks the barriers. i'm not going to name names or trash talk about our competitors, i am sure they work very hard on their projects and their versions of photocarts are just as much labors of love as vend is to me. that said, from an external standpoint, it's like they all got together in 2003 and decided how proofing was gonna work, and they have all stuck to the same formula -- from the visual layout, to the ui, to the interactive, to the immensely over-complicated admins. when we created vend, we thought about the entire user experience, and that informed the project as a whole. there is nothing quite like vend out there, and we're proud of that fact.
after graduation from uofa, and after doing a year of professional flash development, in 2001 i sat down with three of my best friends from the architecture program: nathan colkitt, david schafer and gregory depena, and we entered an international competition to design a "virtual museum". it was a radical concept for the time for the planners of this competition due to the historical oppression of burgeoning young architects in italy -- hence the group's name "new italian blood". all entrants had to submit a web-based entry.
our group name was "opera: operation propaganda engaging the revolution of architecture". manifesto's were big in 2001.
i'll admit, it may have been slightly unfair, as at the time, i was operating at an extremely high level, and was a professional web developer, whereas most of the other entrants were probably amateur at web even if their ideas on architecture were excellent.
anyhow, we won the competition, along with 10000 euros. it was a big deal for all of us. we got to go to rome, and we spoke to (and got translated into italian to) a huge crowd of our peers, we were published in a book and in a magazine. it was a real boost for all of us, we were proud of the work we were doing, and for me, ironically, it gave me real validation to the work i left architecture to pursue i went on to be a finalist in 3 different flash-foward events in 3 different categories in 3 different cities. good stuff!
you’ve worked at some pretty big companies (disney and bristol meyer squibb). do you have any recommendations for freelancers who are hoping to land a job at a high-profile company?
actually, i haven't worked for them as an employee, as they have been clients for my company or the small start-ups i worked for. so i'm not really that versed in working at large corporations working in their web departments. all the biggest clients our company has earned contracts with have been through the tireless work of my business partner anthony ronga. and i think there is a lesson there: if you're not good at generating leads, find someone who is. like everything in life, you need to play to your strengths. i'd be absolutely terrible at being a project manager or a sales person as i'm almost always "too close to the project".
having said that, i do have two pearls of wisdom that every freelance developer should know.
the three click rule.
it's simple: if you're a developer, you have to face facts that people don't read text, and that includes people trying to vet you for a design/developer position. there are three clicks you need to focus on: the first click is the first link in the email you send. the second is the first link on that website that says "portfolio" or any obvious term (like "work" or whatever). the third click is the first project in your portfolio. if, by that third click (or if there is no such third click), you haven’t blown my mind, we're done. on the other hand, if i have been intrigued, i will then go back and read the text of the email, check out your website, and see if you're a fit. your work will almost always trump your experience, your past employment, your schooling, or how awesome your cover letter is. you aren't trying to apply to be a lawyer after all. harvard means nothing in the real world. always, always, always, put your best project first. if you can do it in 2 clicks, even better.
the performance increase.
you know what you're worth. they might know what you're worth. salaries and compensation is a part of the interview and hiring process, and you can't ignore it. but you're an unknown variable in terms of ability, company fit and billing. some companies bill time and materials, some bill on a per-project basis -- all companies scrutinize the cost/benefit scenario of hiring new employees. my advice is to take a lower pay for say, 3-6 months -- to show that company what you're made of. tell them so. tell them that you're willing to come in at a bargain price if -- and only if -- you can prove you're worth what you're asking for. and after a set amount of time you both agree on, you want to be reviewed for a "performance increase". this is NOT a raise. this is you telling them in no uncertain terms you're willing to show them what you're made of, you're willing to prove it, and they have to recognize it. it puts you in the upper hand, since after 3-6 months of you being part of the development cycle of their company they also will have a vested interest in keeping you. it's a win-win.
what are your biggest frustrations as a web developer? do you have any recommendations for how others might deal with the same problems?
oh my lord, almost everything is a frustration. from hosting, to tracking bugs, to dealing with over-zealous clients, the frustrations never end. it's just kind of the way things go. no matter what you're doing, there is going to be a level of tedium and/or frustration. that is just the way it goes.
i have to say though, my #1 frustration is dealing with bugs -- especially if you're working with code. if you have ever written a huge amount of code, you know that a missing semicolon, or miss-matched quote can be an entire day of tracking down something that isn't working. the frustration comes into play is that you spent an entire day (or two!) tracking down some completely stupid error in coding. that just kills me. time is money. time is life, and spending 12 hours tracking down a simple typo in 1000 lines of code can be a traumatic experience.
that is, however, something you have a certain level of control over. learn best practices. learn what namespaces are. learn how to write strict code. these things will help when it comes to tracking down an issue. actionscript has come a long way, so has PHP. you should use the strictest mode possible, as it will give you the most contextual information when it comes to tracking down bugs. oh, and always, always try to make your code OOP (object oriented programming) where applicable, as procedural code is more vulnerable to bugs, and it's inherently more portable.
what training and preparation do you recommend for someone looking to get started creating websites?
wow. i have no idea. my "training" was architecture -- go figure. i honestly think you just need to want to do it, and then do you're due diligence to master it. i also think this is required reading for anyone that is considering being a programmer:
although, technically speaking, coding isn't exactly creating websites. again, i think you need to play on you're individual strengths. coding not your thing? maybe design is? more specifically, UX design, which is way more valuable than strictly "web design". knowing how people interact with websites, knowing the limitations of people and their patterns, is something that is very valuable. people who design and know about UX are heads and shoulders above people who make pretty pictures. as the web gets more specialized, so do job requirements.
school is important, but it's only one path. i have known both school/college/trade school individuals and people who didn't even graduate high school. the beauty of this industry is that the end-product is king, not where you studied.
what are your favorite sites on the web for tips and tricks?
i honestly no longer have any "goto" websites for tips and tricks -- other than google. when i can't figure out how to do something, or if i think someone has already done the work (or the bulk of it anyway) for me, i just do a google search for what i am looking for. there are hundreds -- if not thousands -- of forums, websites, and tutorials on the web for just about anything you can imagine, and if what you are looking for doesn't exist, take that as a nod that it's your opportunity (or possibly opporunity!) to figure it out on your own.
What other skills should a web developer have besides being able to write code?
i think the things that make a truly successful web developer is -- even if it's thin -- a general understanding of all the bits and pieces that make a website work. you don't need to specialize in everything, of course. obviously marketing or ROI or database relationships are very, very specific knowlege sets, but knowing what makes a website tick from beginning to end can make all the difference. designers that don't understand usability, or developers that don't understand design are always going to be at a loss. at the very least, you should know the difference (and want to build on the platform of) separation between content, display, and functionality -- there are 3 different layers of development that should be distinct from one another. it's the conceptual basis of CSS, and the way the web works. in fact, the entire web is (and should be) based on the model-view-controller pattern. you can read more about it here, but basically, it treats each individual aspect of software development as a singular entity, and it's really what OOP (object oriented programming) is based on:
this is important stuff!
there are four extremely important concepts any developer has to understand, at least in time: inheritance, recursion, namespaces, and eventually regular expressions. i'll be first to admit, that after 10 years of programming, i have yet to master regular expressions. they are confusing, impossible to read, and they take a certain mind to completely master. the other three are simply a matter of practice.
namespaces will allow your code to run and live without conflicts of other people's work. if you have a function called getData() -- unless you are 100% positive there is no other functionality that uses that function, you're ok -- but it's almost always better to wrap your code in a unique namespace lie mynamespace.getData() -- it avoids errors, and it avoids confusion. make a namespace for yourself, and save yourself the headache.
both the concepts of inheritance (like cascading style sheets - CSS) and recursion basically mean let the computer do the work. CSS and recursion allow you to do repetitive things in a couple lines of code that otherwise might take hundreds. if you are going to loop through something, or have lots of things that have similar properties, let the browser and/or platform do the work, it will be easier to read, and easier to maintain.
as far as regular expressions, you're on your own.
Anything else you would like to share?
yep! i'd like to take this moment to talk about the great development divide. don't be a part of it, if you can help it.
as time progresses, i have been witness to it, and it truly is a very serious problem that very few people either recognize, or want to deal with. the truth is, most people coming into the web development community have so many options available to them that essentially do almost exactly what they want to accomplish straight out the box, using other people's work. whether it's using jquery, or codeignier, or wordpress, or flex, or any of the other plethora of what is essentially today's "WYSIWYG" editors that allow you to do anything you want without understanding the core competencies of what it's doing under the hood.
the more time goes by i see people using libraries without really understanding what's happening beneath it all -- which on the surface sounds appealing -- after all, someone else did the work for you, and all you have to do is include the library, and be done with it.
but i truly, honestly believe that it's a bad idea. i think it's a bad idea to use a plugin that uses json if you don't know what json means, or what makes it better than XML, YAML, or name-value pairs. i think it's a bad idea to use a program like flex (adobe's insanely proprietary fXML language), and think you are a flash developer. i think it's a bad idea to use code igniter if you don’t understand the fundamentals of what a server header request is actually made of -- do you know the difference between a GET and POST server call on a fundamental level? these are important lessons to learn!
the problem is that the further down this path we as developers go, the fewer people we will have that actually write these kinds of libraries than the people using them, and at some point there is going to be a fallout. i can't say when, or if it's certain, but rest assured the people writing these libraries that know everything there is to know about them, and are very skilled indeed, may eventually, for whatever reason -- stop.
take them all with a grain of salt. learn everything there is to know about exactly what it is you want to accomplish, and don't rely on other people's solutions. the truth is, as these libraries grow, they tend to try and do everything for everyone, at the cost of being bulky, over-burdened, over-complicated, and over-reaching -- all the while, potentially not doing exactly what you had in mind.
even as a 10+ year veteran of web development, i'm not immune -- i use libraries, plugins, and architectures -- they certainly make things easier. but i take pride in knowing exactly how they work and what's going on underneath the hood. i have also extended them based on inheritance, and made them my own. learn to do the same thing. the library you want not 100% what you want? port it, rewrite it, and give credit where credit is due. if anyone has followed the swfobject library, you will see the very same progress -- it changed from one person's hands to another -- and now it's an entirely different beast.
my advice: learn from the ground up. existing libraries are excellent platforms to learn from and use, but please don't use them until you understand them. if you do, know that you are being inherently limited by the design and coding choices of the developing author, and you are subject to their whims, desires, and ultimately their lack of attention in the long run. at least that's my take on it.
so, the next project you do: own it.