Real World Advice for Fledgling Web Developers #
I originally posted this at isaacschlueter.com on September 7th, 2006. I’ve updated it slightly.
Today a fellow front-end engineer here at Yahoo! asked us for bits of real-world advice that we would give to up-and-coming front-end engineering students. He’s doing a talk at a school, and was curious about what we’ve learned. It struck me as a perfect idea for a blog post.
Any other front-end professionals out there? What would be your pieces of advice?
As front-end engineers, we can’t get away with being over-specialized. We are the ones who talk to everyone. We integrate with backend engineers. We get comps from designers. We tell product managers what can and can’t be done in today’s browsers. And, of course, our code is what the user actually gets.
It’s the most hostile arena (except perhaps mobile) in which to create software, but it can be deeply rewarding.
Most of the documentation out there is terrible. Get used to it. Chances are, the person who developed this-or-that thing was too busy to really explain how it works, or English is his second language, or he just never realized that someone else might find it useful. The newer the technology is, the more likely it is to be poorly documented. Learn how to search for your answers within the community, and test everything. Improve the quality of the knowledge base by adding to it. Complaining helps no one.
The specific tricks and languages that you learn in a typical computer science program are almost all useless in front-end engineering. This is a cutting-edge discipline, and no school could ever hope to keep up with it. Textbooks are usually written years ago, and every problem in them is already solved. This field is all about finding and solving new problems that no one has ever thought of. That sounds cool, but it’s also a ton of work. You need to be a little crazy to want this job. If you don’t love it, you’ll hate it.
Be nice to people. You never know when they’ll come in handy. Be strict in what you send, and accepting in what you receive, whether you’re talking about requests over a network or manners in a meeting. You don’t know what constraints someone had to deal with when they built something. The classic n00b mistake is to start out criticizing everyone, but that doesn’t help anyone. If you can do it better, do it; and then share it, discuss it, and document it. You don’t know the pressures that others are under, so be gentle when you tell them that something they want is impossible.
Be ready to compromise, with yourself and with others. The perfect system may take 10 days to create—you’ll probably have 3. Learn how to crunch and cut corners without sacrificing the quality of the end result. Build quality up front, and fill in the details as you go. Design your code in layers so that you’ll have something worthwhile, even if you don’t get to the end. Know how to cut out unnecessary features, and be ruthless with the red pen when necessary. Know how to say “No” to a request if it can’t be done in time, even if you’d really love to do it. But find out what’s really important, and make sure that it gets in there.
Hack! Play! Innovate!