What We Know Now: Dave Rodriguez

One of Hanson’s core values is “stay curious,” so we’ve been talking to fellow Hansonites about the words of wisdom they might today give to their past selves. Today we’re talking to Dave Rodriguez, Director of Front End Development.

One of Hanson’s core values is “stay curious,” so we’ve been talking to fellow Hansonites about the words of wisdom they might today give to their past selves. We’ve interviewed Video Production Specialist Ben Eddings, Account Director Sue Woten-Schultz, Connection Strategist Chris Kujawski, and Senior Account Manager Amy Shrewsbery. Today we’re talking to Dave Rodriguez, Director of Front End Development.

Sally: Dave, I understand your current discipline of front end development didn’t exist when you were in school, or even when you began working at Hanson. How did it come about?

Dave: Five or ten years ago, most of the people on my team would have told you that they were “web designers.” There was a period of time where you could really be a generalist in this field. One person might be doing the design comps (visual design mockups), the HTML, the scripting, the programming, and maybe even configuring the web server. There are still some people who do that, but I think that’s too many hats to wear. You certainly can’t do all of those things at a top level, so you specialize.

Up until about five years ago, my group were all considered “designers,” and we might have been asked to do visual designs, and then build them. We came to two realizations:

  1. Some people are really talented at graphic design and UI and motion design, and it’s better that they do the work than someone like me, who’s stronger on the programming / interactive end of things.
  2. Building web pages has become an increasingly technical skill.

It used to be enough to know HTML and CSS, but things have gotten far more complicated. We’re viewing the web on devices that barely existed five years ago, and we’re able to do things that we wouldn’t have dreamed of doing on a web site. We have 3D on the web, we have complex animations and web apps and all kinds of things that blur the line between “design” and “programming.”

The difference between a “front end developer” and a “back end developer,” also known as a programmer, or an engineer, is that the front end developer specializes in the parts of the site or app that you see and interact with, rather than the back end data and business rules and the other systems that you don’t see. So front end development is a role that wraps up layout and programming and everything else that you need to take a picture of a user interface (a design comp) and make it interactive.

Sally: Was there anything in particular that surprised you when you first got involved in web design?

Dave: The thing that continues to surprise me is how quickly the web moves and how much more capable it gets every year. Like I said, we’re doing things now that you would have never thought to do in a browser five or ten years ago. It’s almost a full-time job just to keep up on all the new things that are coming out. I spend a good part of my week reading various newsletters and Twitter feeds, looking for new technologies and new techniques that we can use on our clients’ sites.

The other difficult thing is that the web isn’t really one platform, it’s a gradient. Your users will always have a range of browsers and devices. Some are on the cutting edge, some are right in the middle, and some are way behind the times. The trick is finding the “sweet spot,” or that tipping point where a technology becomes well-supported enough that it’s responsible to use and it’s not going to cause too many side effects or require too many workarounds.

Sally: As director of the team here at Hanson, how have you seen our front end development process evolve?

Dave:  Our processes are becoming very technical these days. Building with HTML and CSS used to be very direct and simple. You write markup and styles, upload them to the server, and you’re done. Now we have all kinds of tools like Yeoman, to help us generate site skeletons, and preprocessors like LESS that make our stylesheets more powerful and more expressive.

So now there’s a step between the code we write and what actually gets deployed to the site. We’re using build systems like Grunt and Gulp to assemble all the pieces. That’s good because what we’re creating is better optimized, more modular, and more maintainable than it’s ever been.

Sally: What’s something you wish you had known about your field when you first started?

Dave:  The one thing they don’t teach you in school is how to work as part of a team. You learn how to program, or write HTML and CSS, maybe you learn some of the Adobe tools, and you can make your own stuff. But the number one thing I wish had known was how to be a contributor and a good team member. When I first started at Hanson many years ago, the hardest thing for me was to remember that what I was working on wasn’t just affecting me, it was affecting lots of other people.

For people who work on a team, good source control is important. We use tools like Git and Subversion to enforce check-in and check-out, and to keep versions of our files. But people have to know how to use those systems.

Everyone who’s just starting out in web development, either front end or back end, should learn version control and should get in the mindset of checking in everything you do as soon as it’s done. Even if it’s a personal project that no one else will ever touch, get some kind of repository and train yourself to use it. After a while you will come to rely on having all your revisions available, and not having that will feel like walking a tightrope without a safety net.

“Beyond the technology, you need to learn to be a good communicator and a collaborator.”

The other people on your team need to know what you’re doing, which means talking to them, whether it’s in person, or by email or instant messaging. Good collaborators seek agreement on an approach before, during, and after a project. The other thing to remember is that you don’t ever want to be the only person who knows about such-and-such a thing. If you get hit by a bus tomorrow, someone else needs to be able to pick up your project and keep moving. So document everything, leave good code comments, and put all your processes in writing. We have a wiki with pages for every project, and I’m always reminding people to document what they just did.

I love what I do, because every project is a new opportunity. It’s like sitting down at a table with a hundred things to eat. Sometimes it’s frustrating, because you really want to try some of this, and some of that, but you know that some of those things are kind of volatile, or not quite done. So sometimes you have to just try a little of something new, or you have to stick with what you know. That’s always a little disappointing, but things change so quickly that in a year’s time, the things that were exotic and new are now ready for primetime.

Sally: Thanks, Dave! Stay tuned for more career reflections from other members of our team.

0 Tweet
You May Also Like