And let’s just skip right past Internet Explorer and its plethora of headaches, shall we? We all know it sucks. Here’s why else it sucks to be one of us:

1. Everyone Thinks It’s Your Fault

   So you’re QA. You’re testing a website and something is broken. It looks to you like the frontend, because that’s what you see. What may separate good QA from excellent QA is the ability to determine where the error lies, but sometimes that’s out of QA’s scope.

   Regardless of who the owner is, chances are the issue will go to you first. You must then determine if it’s even your issue, and either fix it, or pass it on. Bringing us to …

2. You Are Also a Project Manager

   The frontend is the very last thing to get done. That’s because the design needs to be finished way in advance so that assets can be delivered, and the backend has to be complete before you have access to data to use in your implementation.

   This means that you must act as Project Manager to keep everyone else on track, because otherwise you can’t ever get to work! And that’s why …

3. You Always Seem Late

   Since you’re the last one that gets to begin implementing, chances are you’ve got less time than everyone else. And sometimes you can’t even get started until after your deadline! And even when you do finally get your assets and can get to it, sometimes …

4. You Must Know Photoshop

   To be fair, I actually use The Gimp, which works fine. What I mean by this point is that you must learn to use a competent image manipulation program. Why? Because although you may have an excellent design person/team, chances are they’re not going to cater to you and your crazy CSS hacks.

   You know what I mean. Sometimes you’re wanting to sprite your images to get better page performance, or sometimes you need to pull off some crazy rounded corners hack to get the positioning cohesive across browsers. You could go back-and-forth with design all day, or you could say “screw it” and alter the image yourself. It sucks but that’s how it gets done. And that’s part of …

5. You Must be a Jack-of-All-Trades

   In addition to competency with a decent image manipulation application, you’re going to need at least a familiarity in many other areas. It’s very rare to find a frontend engineer who doesn’t ever need to modify at least some server-side code.

   For example, although I am official a frontend engineer, I probably spend 30-50% of my time in PHP. That’s because, before I can even render the markup I need to tweak, I’ve got to setup the data I receive from the backend.

   Not to mention the various other tasks that randomly pop up in the webdev stack, such as Apache rewrite rules or cronjobs. I’m sure the same could be said for most jobs, but it seems like frontend engineers’ skillsets must be broader than most.

But it’s not all bad. Especially right now in Silicon Valley, frontend engineers are quite valuable, so it’s a great time to know how to code for the browser. Either way, did I miss something? Let me know!
]]> http://scriptnode.com/article/5-things-that-suck-about-being-a-frontend-engineer/feed/ 1 http://scriptnode.com/article/software-development-meme/ http://scriptnode.com/article/software-development-meme/#comments Thu, 18 Sep 2008 23:50:21 +0000 Matt Hackett http://scriptnode.com/?p=171 I’ve been tagged by the insanely creative Jacob Seidelin, which means it’s my turn to fill out the Software Development Meme!

How old were you when you first started programming?

I was about 12 years old. That combined with my love of Nintendo really makes it sound like I never left the house, but I found time to play sports and get in trouble, really… …

How did you get started in programming?

A mysterious friend of mine (Jim MacDonald, who all but doesn’t exist online) and I used to play games all day, like Dragon Warrior and Shining Force. Then one day he wondered how games were made, and found…

What was your first language?

QBASIC! This has gotta be the easiest language to learn, and that says a lot in an age where PHP exists. I think more developers would benefit from starting with this fantastically simple language.

What was the first real program you wrote?

I wrote a program I simply called Dragon, which was a direct ripoff of Jim’s game Wizard or something. It used QBASIC’s DRAW commands to draw shapes and PLAY for sound effects. It was a single-battle, turn-based game pitting you (a knight) against a dragon. It was amazingly bad but pretty fun (for 12-year-olds anyway).

What languages have you used since you started programming?

Professionally: Only PHP and JavaScript

For fun and/or school: BASIC, C, C++, Perl, Python, QBASIC, Turbo Pascal, Visual BASIC

What was your first professional programming gig?

Working for Dav Glass at SchoolCenter. I was a PHP programmer making a measly $10/hour coding content management tools for K-12 schools. I was quickly promoted to lead designer (odd, right?), then when the company realized we needed engineers more than designers, put back into the development department. About a year after Dav moved to Yahoo!, I followed.

If you knew then what you know now, would you have started programming?

Oh hell yes. I’m always trying to learn as much as I can. Learning new languages is fascinating, and learning more about what you already are familiar with to me should be a daily exercise. If I had had the knowledge I have now when I was younger, I can’t imagine what I would have built by now. Interesting to think about!

If there is one thing you learned along the way that you would tell new developers, what would it be?

In a normal curriculum in school, students are taught to read well before they are taught to write. I’m not sure why this isn’t the case in programming. You’ve always got these wannabe developers that try to run before they can walk, and they end up tripping. There’s no shame in beginning modestly.

I recommend to anyone of any programming level: read other people’s code. The Internet is the ideal place to learn.

What’s the most fun you’ve ever had… programming?

Everytime I learn a new language, my first task is to build a game. I’ve been doing this for over a decade, in every single language I’ve dabbled in. But I think it was the most fun in QBASIC. I built an intentionally awful game called Seanbaby’s Magic Bus Ride Trip for you guessed it… Seanbaby. Working in Flash is really fun too, but nothing beats JavaScript.

Who’s next?

Let’s go with Isaac Schlueter, since he’s a great writer and always has interesting things to say!

]]> http://scriptnode.com/article/software-development-meme/feed/ 1 http://scriptnode.com/article/5-ways-qa-ruin-developers-lives/ http://scriptnode.com/article/5-ways-qa-ruin-developers-lives/#comments Sat, 06 Sep 2008 04:06:23 +0000 Matt Hackett http://scriptnode.com/?p=106
A Scholastic quality assurance employee

Quality Assurance people are important and valuable, to be sure, but they can also make developers’ lives much more difficult. This is particularly bad because (like many roles in an organization), their end goal is to help the developers make better software, not stress them out.

Here are some of the common ways QA workers ruin developer’s lives and how these behaviors can be avoided:

1. Misunderstanding the technology

   I’m often shocked by what somebody on the team didn’t know about. Understanding when software is working properly and when it isn’t can sometimes require a deep understanding of the technologies involved in making the software… And sometimes you just need to know enough.

   My favorite example of this is a bug I got about a year ago, in which the report was something along the lines of, “Page is dumping out plain markup, no CSS.” Sounds kind of like an RSS feed right? It was. This person had never heard of RSS.

   How to avoid this

   I hate to say it, but sometimes people just need to be qualified for their jobs. A unique perspective on a product is sometimes great, even sought after (for example, during usability tests). Other times, people need to do research and read up on the projects they’re working on. Most projects have awful documentation, but if they have it at all, it will probably mention in there what something like RSS is.

   On the other hand, nobody can know everything about everything. Technology moves quickly (especially when dealing with the Internet), so it’s understandable to be behind in a given area. A better way to handle this issue might be to suggest that perhaps the page could provide more information about what was misunderstood so that if others come across the same page, they’d understand too.

2. Assuming the software is buggy

   A friend told me about a bug he received recently. A QA person had tried three different features in the software that were supposed to display images. None of them worked, so three different bugs were filed. Thing is… those three areas of the software worked fine. It was the image that was broken. This person just assumed the software was buggy.

   How to avoid this

   When something is not behaving as expected, all reasonable checks should be made before branching out and getting others involved. Sometimes it’s as low-level as checking the Internet connection, and other times (as in the example above), it’s seeing if something works in other software. Pulling the image up in a browser or editor would have shown that the image was broken. Instead, everyone’s time was wasted.

3. Omitting necessary information

   I very recently received this email:

   Hi Matt there is Javascript errors on Devtool editor and preview pages. Do you want me to file a bug for them in one bug or are you already fixing (have fixed ) them?

   This email was next to useless. First off, I don’t know what environment these errors were found in. Typically at work we’ve got a handful of environments, sometimes up to five or six, and almost always I don’t know when they were last updated. All I know at any given time is about my development box, which I doubt people test on.

   Secondly, what browser and operating system were these errors found on? This is critical in a world where browsers behave so differently.

   Lastly, what were the actual errors and (probably more importantly) how did you produce these errors? Sometimes it’s very obvious. Load up a program or hit a webpage and the same error pops up for everyone on every operating system or every browser. Sometimes. But not usually.

   My all-time least favorite among the “not enough info” issues are the bugs that say something like, “looks funky” or “is broken”. I know what I think is funny. I don’t know what you think is funny. It’s ambiguous. If someone says, “it’s blue but it’s supposed to be red,” then I understand perfectly. Otherwise, there are blanks that need to be filled in, and a failure in communication has occurred.

   How to avoid this

   In short: I’m the developer. Need the info.

   All that really has to be done is to answer each of the questions above. I’d love to know about errors if there are any, but I must have the bare essentials of information about them, and usually the more information the better. Help me help you.

4. Not knowing the specifications

   Long ago, I lost track of how many bugs I’ve closed with a comment along the lines of, “This is by design.” Sure, sometimes nobody knows how the hell something is supposed to work, but if you’re doing it right there is documentation that answers these questions. It’s especially frustrating because the software is behaving exactly as intended and a bug is filed that (unknowingly to the creator) basically is saying, “Everything’s good, but I’m not aware of that.”

   How to avoid this

   Read the documentation. Know how it’s supposed to work. Don’t assume it’s broken. If all else fails, ask before filing a bug.

5. Over-filing bugs

   I’m primarily a front-end guy, so I get a lot of design tweak bugs. Sometimes a character is missing, sometimes a border is too thick, sometimes a font is one point too large… These tiny issues often take mere seconds to fix. What takes longer is managing each of the bugs created for these issues.

   A site I was working on a while back had a list that looked something like this:

   • Upgrade users
   • Truncate users
   • View users
   • Mass edit users
   • Import users

   For each bullet point in this list, I was assigned a bug whose summary was something like, “Add a period to the end of ‘Upgrade users’”. That’s five bugs for five really easy fixes. What a waste of everyone’s time!

   How to avoid this

   Bugs happen. Tickets for these bugs need to be filed. Usually they are unrelated and separate tickets are not just good, but necessary. However, knowing when to create fifteen bugs and when to create just one is very important to know in order to be efficient. Sometimes it’s best to think about the issues at hand and consider if they’re similar enough to be filed together.

   Another cause of over-filed bugs are duplicate bugs. This one’s easy, folks; just search for similar bugs before filing.

Note: I certainly hope this article hasn’t offended any kind QA folk. When they’re good at their job, they make my job way easier. Let’s hear it for QA!

(Special thanks to Isaac Schlueter.)

]]> http://scriptnode.com/article/5-ways-qa-ruin-developers-lives/feed/ 2 http://scriptnode.com/article/interview-questions-part-1-php/ http://scriptnode.com/article/interview-questions-part-1-php/#comments Sat, 12 Jul 2008 09:08:04 +0000 Matt Hackett http://scriptnode.com/?p=39 I interview a lot of people. Sometimes for a specific task, and sometimes just because we need more engineering power. In the latter case, it’s
usually enough to be a good, experienced engineer in almost any language. But usually we’re hiring for a job heavy on one language or another, and it’s my job
to find out if the candidate is fluent.

This is the first part of many articles I’m going to write about common interview questions in the vague and mysterious world of web development.
There are of course an almost infinite amount of questions one could be asked during an interview, but my questions are typically going to be
more about syntax and semantics than the probably more revealing questions on algorithms and problem-solving.

Without further ado, here are some common questions engineers get asked to see if they understand the basic syntax of PHP.

• What are the differences between single and double quotes?
• What are the differences between include() and require()?
• What does the === operator do?
• What does $$ signify?
• What are the various ways to append to an index array?
• How do you debug in PHP?
• Create a class and extend it.

Q: What are the differences between single and double quotes?

A:
The primary difference is that a string enclosed with double quotes is parsed. A string enclosed in single quotes is just a string literal.

<br /> var $foo = ‘bar’;</p> <p>echo ‘The value of foo is: $foo’; // The value of foo is: $foo<br /> echo “The value of foo is: $foo”; // The value of foo is: bar<br />

Q: What are the differences between include() and require()?

A:
The most prominent difference is that require() will throw an error if it fails to include the given file, and include() will not.

Q: What does the === operator do?

A:
Triple equals checks for both value and type:

<br /> $foo = ‘bar’;<br /> $pos = strpos($foo, ‘b’);</p> <p>if ($pos) {} // false: 0 is a falsy value<br /> if ($pos !== false) {} // true: 0 is not of the same type as false<br />

I like to ask if the engineer can think of an example (like the one above).
It’s almost guaranteed that a programmer that has been developing in PHP for an extended period needed === before.

Q: What does $$ signify?

A:
Double dollar sign signifies a variable variable:

<br /> $color = ‘red’;<br /> $red = ‘#ff0000′;</p> <p>echo $color; // red<br /> echo $$color; // #ff0000<br />

Q: What are the various ways to append to an index array?

A:
[see code]

<br /> $my_array = array(1, 2, 3);</p> <p>$my_array[] = 4;<br /> array_push($my_array, 5, 6);</p> <p>$my_array[count($my_array)] = 7; // This is possible but dumb<br />

I like this question because it’s easy on the surface, and engineers will almost always get the first two. When I say there’s one more way, an engineer’s
response is usually pretty revealing. Getting an answer like, “No there’s not,” shows (unearned) arrogance.
Candidates that figure it out on their own show thinking on their feet.

Q: How do you debug in PHP?

I think it’s probably most common for developers to use the quick-and-dirty echo statement. A better practice is to use error_log
or an external debugging library, because they won’t muck up the page and potentially cause other bugs.

Q: Create a class and extend it.

Not really a question, but still important.
I also ask about constructors and deconstructors, and make sure the candidate knows how to call the extended class’s constructor:

<br /> class Foo {<br /> function __construct() {}<br /> private function privateMethod() {}<br /> public function publicMethod() {}<br /> }</p> <p>class Bar extends Foo {<br /> function __construct() {<br /> parent::__construct();<br /> }<br /> }<br />

I also like to ask if public is required (it’s not because it’s the default state), and make sure that the engineer knows about protected
as well.
I like to have conversations about object-oriented programming rather than just asking syntax questions, because I’ve found it’s easier.

That’s it, really. These questions are just to see if an engineer is familiar with the surface of the language.
It could be argued that PHP is simple and quick to learn, and that these questions would shine a positive light on someone who spent a few hours reading about
PHP, and a negative light on experienced engineers who are fantastic but not very familiar with PHP.
It’s a valid argument, but again, this is just to test PHP knowledge.

If you know any questions similar to these, I’d love to hear about them in the comments.

]]> http://scriptnode.com/article/interview-questions-part-1-php/feed/ 0