Home Notes What I've learned

What I've learned E-mail
Saturday, 18 June 2011 11:10

Here are some things I've learned about the web design and development world in my short years in it so far:

Learning

The web development world is a maze (vs. a labyrinth), littered with innumerable equally-appealing choices.  For example:

  • JavaScript frameworks: jQuery, MooTools, Dojo, Prototype, ExtJS, ...
  • PHP frameworks: CodeIgniter, Zend, Symfony, CakePHP, Yii, ...
  • Popular web languages: Ruby, Python, PHP, C#, ...

If you're going to get anything done, you have to just step into the maze and start working.  The good news is that you can't really go wrong, even if you get lost for a while.  There are so many resources out there, and so many useful and cool things have already been done in pretty much any technology you decide to take on.

 

On the other hand, you can be like the myriad of people asking questions like:

Notice the number of [closed] questions that show up when searching for terms like best, better , and should I learn.  There's a good reason for that: questions like that are a waste of time, and are generally asked by people who are afraid and just stalling getting started.  I know because I've been there.  Pick one and don't look back, unless somehow you've managed to get yourself absolutely stuck at a dead-end.

  • It's not enough to read books.  (If it were that easy I would be a genius by now.)  You have to do the work and practice what you're reading.
  • When reading articles out there on the Web (including mine), check the date.  Technologies are getting updated so  quickly that some fix or trick that applied a few months ago may no longer work.  The publication date is the first thing I check before even reading an article.  If it's too old I'd rather spend the extra time to find a newer, more relevant piece.

Practice

If you're looking to get something done, chances are it's been done before.  Spend some time and look around the internet to see if someone's already solved the same or a similar problem.  It's worth it.  It's even worth it spending some money - you'll be rewarding someone else for their work while saving yourself time and your client money (which in turn could lead to more money in repeat business).

 

Good places to check are GitHub, CodePlex, StackOverflow, and Bing and Google.

When you eventually need help and post a question online somewhere, do it with others in mind: those who will be taking their own time to help you.

 

Ask the question first, then give the explanation.  If you've got a long-winded explanation behind your question, it's better to put it after the question.  That way the reader can scan the question, assess whether they're interested, know enough about the topic to help you, and if so, want to spend the time to read the story behind it.

 

Be respectful and courteous.  Someone else is using their valuable time to read your question and (hopefully) responding to it.  More often than not the first answer is less than helpful.  That's why there are multiple answers from multiple people with multiple backgrounds and areas of expertise.  You won't get very far with the community by being disrespectful to others.

  • Your work is automatically sandboxed to the virtual machine you're working in
  • You can experiment all you want
    • If you use VirtualBox you can take snapshots and easily revert if something breaks
    • If you run a Windows host, here is a short script to automatically take a snapshot before a virtual machine launches for use
  • Don't mess around with your host environment; only install what's absolutely necessary there

  • Make frequent backups.
    • Several times a day if you can afford to (in terms of space and computer power)
    • Here is what I do for backup
  • If and when you do experiment, record your experiments, observations, and results, and share them with others if you like
    • It's the best way to learn something for yourself, and it's also nice to share something you've spent hours on that could save another developer hours of time.  (Think about all the hours you've saved because of other's blog posts on problems you've struggled with.)

Computing

  • Get as much RAM as your system can take and/or you can afford
  • Source control is a wonderful thing, even if sometimes I wish it were easier to use
  • As much as I dislike to say it, the command line is the fastest way
    • I dislike to say it because the whole point of GUIs is so you don't have to remember many commands
    • Every developer has to strike his own balance between command line and visual interfaces

Client relations

There will be times when things won't work out with a client.  You won't agree with their demands, or they won't agree to your methods.  In these cases there is an incident I like to remember from college.  On returning a paper he graded back to us, the professor said something to the effect:

Before I return these papers I'd like to point out that this grade is not a judgment of your writing ability or your talent in any way.  It's simply an assessment of this particular paper.

 

The point is, just because things don't work out with one (or two, or three) clients doesn't mean you're not good at what you do.  Now if you're not good with three out of three clients, then it's a problem.  But if it's three out of fifteen or more clients, just take it as a matter of chance that things didn't work out.  Don't chastize yourself or doubt your ability, just move on.