East coast technology blog

Post navigation

This is probably old news to a lot of people, but it was new to me so I’m writing about it.

A year ago, the CEO of startup Expensify wrote a blog post unintentionally bashing professional .NET developers. The entire post was inflammatory and insulting to the .NET world, with gems such as the following quote littering the whole blog:

The right sort of person is so passionate about coding, they can’t be stopped from doing it. They typically started before high school — sometimes before middle school — and never looked back. They write everything from assembly to jQuery, on PCs to mobile phones, doing hard core computer graphics to high level social networking. They’ve tried everything.

Everything, that is, but .NET.

You can’t make this stuff up. He goes on to explain that he makes all people with .NET experience on their resume at ALL defend that position during phone screens. He doesn’t see .NET as a “real” platform and that .NET developers just sit in their “McDonalds kitchen” pressing buttons that spit out burgers. He claims that .NET devs can’t adapt to situations (although, he very notably doesn’t give any examples of things .NET devs can’t do, but rather stays in his metaphor or burgers).

Here’s a slightly out-of-context quote:

See, Microsoft very intentionally (and very successfully) created .NET to be as different as possible from everything else out there…

He goes on to make some valid points about Microsoft getting people entrenched in their platform and their tools – but the same argument can be levied against many other companies as well. But regardless, the above quote is a bit laughable when you remember that .NET was originally Microsoft’s answer to Java. And .NET is very similar to Java in many ways. It was intended to be their version of Java, not something “as different as possible”.

The CEO also describes his developers as in a fairly humorous and confusing way:

Instead, we look for a very different sort of person. The sort of person who grew up cooking squirrels over a campfire with sharpened sticks — squirrels they caught and skinned while scavenging in the deep forests for survival. We don’t want a short order chef, we want a Lord of the Flies, carried by wolves into civilization and raised in a French kitchen full of copper-bottomed pots and fresh-picked herbs. We need people who can not only cook burgers, but cook anything, from scratch.

Once again continuing the McDonald’s metaphor, apparently the devs this guy is looking for hunt and cook squirrels. .NET is push-button development but his guys can adapt to ANY situation, since they’re hunters and can cook their own stuff, right?

This drama comes to a close last month, when Expensify publicly began searching for a .NET developer. They definitely acknowledged the hilarity of them looking for a .NET guy after bashing .NET so thoroughly. However, some good questions were raised in the comments. If they need a .NET dev (in this case, for WP7 apps) why can’t their squirrel-hunting devs just get in that McDonald’s kitchen and press that burger button?

The sad part is that most of the professional .NET community was warned, via some high-profile blog postings, to stay away from these guys. That means the people applying will have a higher chance of being those “burger flipper” devs that he was insulting.

Shadow Explorer is a neat little tool I found while cruising around the web. In a nutshell, it is a frontend built for Vista’s Shadow Copy tool. Vista Home versions allegedly do not have a frontend at ALL for this service, while higher end Vista copies do, but it’s not that great.

To use Shadow Explorer you can simply download it from the linked site above. It’s very simple to use – just download, run, and run the resulting .exe as an administrator.

Once open, it looks pretty bare, like you’re missing something or something broke. It probably didn’t. There’s a long thin dropdown at the top that will list out all the dates that there are restore points on your machine for. Select a date, and then you should see a copy of your filesystem (or at least the “protected drives”).

From there you can find files and restore them by right-clicking and then exporting them back to your filesystem. Works like a charm. I just had a situation where I saw a neat little popup saying “Files deleted permanently” and sure enough, some files were gone. Not in the trash, not in any temp directories, nowhere. No explanation. Restored them easily with this tool.

Thanks to Microsoft for Shadow Copy and thanks to these guys for making a way to access it! Shadow Explorer is kind of like backing up your whole harddrive (obviously it’s not a replacement for doing so… but it’s like making a LOCAL backup of all your files).

Make sure before you use this that Shadow Copy is enabled, though. Usually it is but I’ve seen at least 3 people who didn’t due to some errors in their configuration. To check, go to Control Panel, System (in classic view), System Protection, and then in the middle of the screen you should eventually see all your protected drives and unprotected drive. Simply check the drives you want to copy and hit apply or ok. You can also manually create a restore point if you want.

In business, many people talk in terms of “best practices” and “worst practices”. To start with, I would like to say that this is a BS term cooked up so that people have a way to back out of doing things the right way. It’s a politically correct term that people hide behind. I hate it. Instead of saying “you did this the wrong way” or “you took a shortcut that cost us time and money” people say “you did not adhere to best practices” and that somehow makes it less of a bad thing.

So here I present my list of SEO worst practice, or, SEO mistakes, in no particular order. This is going to cover both SEO implementation and theory.

1. Overselling optimization

The first mistake many SEO specialists make is to oversell SEO. Whether it’s their services or just the concept in general, it is really easy to get worked up over how much of an impact SEO can have, and sometimes clients think that they’ll instantly get to #1 on Google for whatever keyword they want if they just reformat their page titles.

It doesn’t work like that.

It’s important for SEO professionals, or people bringing the concept to their companies, to make sure that their clients know that it’s a slow process that might not show enormous results for their keywords. If a small mom and pop burger joint wants to target the “hamburger” keyword, they will probably not do very well, due to the ENORMOUS competition. It’s important to make sure that expectations are realistic.

2. “If only I did this, I could trick Google and improve my rank!”

No. You can’t. Sorry.

The first thing a lot of people say when they are introduced to SEO (especially those with some sort of stake in the project, whether it’s a content person, or a designer, or a developer) is “if I did X I could have my cake and eat it too!”.

Sometimes people suggest various methods of cloaking, which is in layman’s terms hiding content from the search engine so you can target keywords that might not be relevant to the site. For example if you saw that the keyword “puppies” wasn’t competitive (yeah yeah, unrealistic, cut me some slack!) but your site was about the rise and fall of Enron, you obviously won’t rank for “puppies”. But! says the enterprising new SEO recuit. “If I create a fake page with puppy information and then automatically redirect to my Enron page, I can get lots of hits!”

Trust me: If you can think of an idea on how to trick Google, rest assured someone else has already thought of it, tried it, succeeded, gotten caught, and had the loophole closed. It’s not worth spending any time thinking about.

Cloaking and other black hat SEO techniques can (and will) get your site blacklisted from most notable search engines.

3. Concessions

Someone will always oppose SEO. People actively working on a project will all of course want SEO, because it’s not undesirable for most any site.

That said, one person will always oppose the practical implementation of SEO while praising the concept itself. This is, honestly, one of the hardest things to deal with. Whether it’s a content writer not wanting to retool their text, or a designer not wanting to sully their wonderful design with ugly formatting (bold etc), or a developer not wanting to rely on 301 redirects and external js/css files, someone will want concession after concession.

“Well, we’ll implement this aspect of SEO if we don’t do this other aspect of SEO to maintain balance” or something along those lines.

Ugh. What people need to understand is, plain and simple, these “rules” of SEO are not meant as punishment, it’s meant as a complementary system that feeds and grows on itself. One aspect of SEO is not enough, ever. All of them is ideal.

Make too many concessions, and despite tons of effort, you’ll see little to no gain.

4. Too much Javascript!

Kind of a minimalistic header, javascript can be a pain in the ass for SEO. It’s not bad on its own. Stick all your javascript in an external file, reference it in the head, and away you go, nice clean page.

But, sometimes, javascript can be a burden. For example, what happens if you have a javascript-driven popup link on your site? The search bot won’t follow that link because it can’t. You now have deadspace search engine-wise on your site.

It’s tempting to use javascript, but in moderation.

5. Keyword stuffing/forgetting keywords

Covering both ends of the spectrum, keyword stuffing is the act of putting as many instances of a keyword on a page, or having way too many keywords.

This ultimately hurts SEO because the engine knows what you are trying to do. Think of a search engine as a self-aware machine. It is Skynet but without the killing part (so far). It is much smarter than you think.

Stuffing keywords will get you blacklisted, but forgetting keywords will get you laughed at. If the content writers don’t want to rewrite the content for web copy, or you forget to update it, and there are no keywords, the search engine bots will get confused and you won’t rank highly for anything. How is it supposed to know what your site is about unless you tell it?

“Technology trends” is a pretty vague and generic term, but it’s still applicable to many peoples’ jobs. For example, a web developer should know about upcoming technology, even if their company isn’t using that tech yet. Keep up on trends also keeps developers or other technology fields aware of other techniques that might just make things easier for a company. Worst case scenario, it let’s you as an individual know what the rest of the world is doing in case you want to jump ship.

Here are some of the best ways to keep on top of technology in its ever-changing yet totally-interesting glory.

1) Read Digg, Slashdot, and other peer-submitted sites

Sites like digg and slashdot are (or used to be) somewhat unique, in that the content is user-generated. This let’s you know that the information is relevant to readers. Of course, this is only useful if you know the demographics of the readers, but come on. It’s digg and slashdot. You can probably make some fair assumptions here and be right on target.

Reading news stories submitted by your peers is a great way to track trends. You’ll see upcoming technology that’s interesting, and you’ll see criticisms of technology that doesn’t work. In fact you’ll see a lot of criticism, but that’s also very useful, so you’ll be aware of all the negatives of something before jumping into it.

EDIT: Thanks to xionon for pointing out that Reddit is one I forgot to mention, but it is actually much more developer oriented.

2) Check out traditional news sites

By traditional news I don’t necessarily mean CNN and BBC and Fox news and places like that. Although these can be useful tools to learn about technology, most of the time this would be useful only for existing or already on-its-way-out technology, or technology that would appeal to people on a larger scale. This is changing, of course, but that still does hold a bit of truth.

A more relevant technical “traditional news” site might be something more like engadget, or gizmodo. These are traditional because they aren’t peer-submitted, but have their own editorial process to screen content. As such you know that the content coming through is at the very least somewhat well-written, and has passed some sort of screening process related to content so you get what the site advertises.

Of course, it being April Fools Day, those sites are a bit of an exception right now, but usually that’s true!

3) Build a social network of developers and other technical people

Whether this is through AOL Instant Messenger, Gmail, Twitter/blogs, Facebook, Myspace, whatever, building a network of technically-minded friends will really help you keep on top of things. One of the most important – and most fun – aspects of technical work is swapping stories with people who can appreciate your horrible socially-crippling nerdiness and, god forbid, actually identify and respect your inner geek.

Social crutch aside, you can swap ideas, learn new techniques, and hear about technology solutions you’d never have encountered otherwise merely by having friends and talking to them once in a while.

4) Attend conferences

This might sound boring, but go to official conferences. You get free swag, you meet other professionals, and this is a great way to build your network.

Plus, free swag.

It can help you understand a new topic to listen to a speaker who is an expert on the topic, as well. To be fair, it can also confuse the hell out of you, so make sure you’re attending the RIGHT conferences!

5) Join usergroups

Joining a local usergroup (through meetups.com or whatever that site is, or just looking through Yahoo! groups, or Google groups for a tech group) can have many great effects. One of which is free pizza once a week. Another is that you get a group of people, usually wanting to focus on a specific, similar topic or goal. Think of it as a study group for adults.

That said, you might want to tell your girlfriend that you joined a bowling league. If she doesn’t like bowling, break up with her. It’s probably for the best.

One example is in my area, obviously the Boston area, there’s a usergroup that’s been meeting to go over .NET 2.0 and onwards training, in order to get Microsoft certification. Much easier to study when you have someone to ask questions, instead of reading a book, friendless and alone.

6) Ask coworkers

Kind of a lame one to end on, but asking coworkers is often forgotten by many tech people. Coworkers can often have nuggets of knowledge (if I ever write a book I am calling it Nuggets of Knowledge) buried in their brains much the same way a squirrel buries acorns for winter. Spring is here, and you want the acorns of their intelligence. Dig them up!

When Firefox first came out, I immediately jumped all over it. It was so much better than IE, it worked so well, had new features, and Internet Explorer had become stale, old, and, dare I say it, uncool, even for a browser.

Over time, though, I switched back to Internet Explorer. With IE7, everything I liked about Firefox was now in IE as well, and of course the convenience of IE being already installed on a system, and it’s quick speedy startup factored in a bit. The thing that really drove me away from Firefox, though, was the loading time in earlier versions of Firefox 2.

It took me forever to open the darn program. It just would not open, period. It took ridiculously long, and used a whole lot more memory than IE. These problems have since been fixed, but there has not been a compelling reason to switch back.

Wait, scratch that, the compelling reason to have it co-installed on my machine was Firebug. There is a sort of half-assed version of this on IE, which is nice for general inspecting of items and quick CSS edits, but I really like the Javascript editor and debugger. Really cool.

But, with Firefox 3 beta versions out now, I gave it a shot. It’s neat. It’s quick. It’s zippy, and it’s really snazzy. Finally, lots more new features that are nice looking, function well, and are unique to the browser. Exactly the reason I switched to Firefox in the first place!

It seems that Firefox is not becoming stale as IE once did. I do hope that IE8 will come out and wow us with something – a great new interface, new functionality, or ideally both, with compliance issues fixed – but it looks like once Firefox 3 is finalized I might switch!

I will not switch yet, though. Why? It’s buggy. Believe it or not, I managed, on a friends machine, to get two instances of the same version of Firefox (beta 3) running the same website to render it incorrectly. One window correctly passed the acid2 test. The other didn’t. Consistently. So somehow, in a browser, the same program interpretted the same page differently. For this reason, I will not be switching until the beta tests are over.

In the past few weeks I’ve had the luxury of being able to sit in on (and participate in) many technical interviews for various positions. I’ve learned that many people do and say things that are never acceptable in an interview, at least not if they business is worth the time and effort of interviewing at in the first place.

I’ve come to realize that maybe these things aren’t always obvious, but at the very least maybe someone’ll get a kick out of them. Names have been removed and I probably don’t remember them anyway, but these are all based on real experiences, details removed.

1) Never say you’ve worked for 8 years when you’ve actually worked for 1

Generally, it’s never a good idea to lie on a resume or at an interview. Many people do tell small white lies, or exaggerate, and that’s probably alright, at least sometimes. But never overestimate your abilities by this large of an amount. It will be blatantly obvious to everyone in the room.

If you say you have 8 years of Javascript experience, you’d better damned well know some “common uses of Javascript” and not just stare at me blankly. If you say you’re got 10 years of web development experience, you’d better know some various methods (any methods) of transferring data from one page to another. These are two sample questions and their accompanying responses.

Pure insanity. This isn’t just a “know your shit” lesson. It’s a “if you claim to be an expert, know the basics” lesson.

2) Know the terminology

Sort of tying in to the first point, if you claim to be a member of a group, say, a web developer, you’d better be familiar with web development terms. Sure you may not have worked with CSS for a variety of reasons, but any web developer who’s never HEARD of CSS is in for a surprise. If you don’t know what a form is, or what a web part is, then you probably haven’t actually worked for long as a web developer, and there will probably be a large amount of ramp up time for you. Then it’s a gamble, are you likeable enough for the company to want to spend the upfront time and money to invest in your education?

Probably not. Be familiar with your field. It seems like common sense, but you’d be surprised at the number of people who are clueless about simple aspects of their field.

3) Don’t assume the jobs “in the bag” because you’re female

Yes, we really want to hire female developers. This means that yes, female candidates can sometimes have an “edge”, intentionally or not. We’ve seen our share of female candidates come in and have a great personality and attitude, act like they’ve already been hired, then completely bomb on the technical portion. Not even close to any kind of technical expertise.

We’ve got 0 female developers at my workplace, and this is not due to any kind of prejudice. It’s because everytime we get a female candidate she seems to fit in great, but is clearly not a developer of any kind, despite (again, back to #1) a resume full of references and “experience”.

4) If you bomb the technical questions, don’t ask if the questions were for a higher position

We had a candidate use this line the other day. Finished the technical questions and he did poorly. Very poorly. Then he asked when we were going to start the technical interview, because all those questions were way too hard for midlevel and were clearly “architect level” questions. Most of the questions were our entry-level questions which were intended as a ramp up to the harder stuff.

This made the guy look like an idiot. Immediately out of the running. Way down the list. One of the aforementioned female candidates very classily failed the technical aspect of the interview, asking “I didn’t do very well, did I?” and then sending an apology followup, saying she was sorry she was so unprepared and thanks for humoring her.

Classy, but won’t win you a job, either.

5) Don’t bottle yourself up

This is a very common thing I’ve personally witnessed with technological positions, especially. Applicants show up and completely bottle themselves up. No joking. No personal information. No small talk. Many people forget that people who are hiring want people they can work with every day. If you get hired you will have to deal with these people for a very long time, maybe even the majority of your waking life for the next few months, or years. They don’t want someone who has no personal life, no interests, and is a complete bore.

Work is boring enough already, don’t add to it. One of my favorite questions to ask at an interview is “Do you have any hobbies?” The responses I’ve gotten are very interesting. One guy we asked seemed really glad that he could talk freely about things he was interested in, and he was obviously passionate about what he did. Music, sports, reading, doesn’t matter what your answer is. His was actually a combination of things, and guess what? We hired him. Not based on his hobbies, obviously, but that was definitely a factor.

If you care about things that you do outside of work, odds are you will care about what you do at work as well.

One candidate answered the hobby question with “Nothing. Well, I installed hardwood flooring in my apartment once. But I don’t really have hobbies”. We didn’t like this answer. We did not hire this person. It was not solely due to hobbies, obviously, because that’s never grounds for dismissal. However, it is a factor, and for good reason.

6) Remember to be yourself, but on your best behavior

Interviews are where interviewers and interviewees both see each other on their best behavior. Everyone knows this. So be yourself, just on your best behavior. If you’re a passionate person, let it show a little. Don’t ever make assumptions about what kind of person a company is looking for. If you assume that, since they are hiring for technology positions, they want a robot with no sense of humor, then you’re probably wrong. If you assume that they want a class clown who will make them laugh at every opportunity, you’re probably wrong again.

Being yourself will help everyone. You’re not pretending to be someone else, so you’re not hired or fired under false pretenses. The interviewer gets to see who you are as well, and it makes the decision-making process smoother.

Questions? Comments? Feel free to leave a comment, or email me, James Martin.

I had an issue today that was not clearly covered in blogs that I found on the subject, so I thought I would write a little post explaining what the problem is and what my solution was.

My issue was on a .NET 2.0 page. As simply put as possible: Using a Theme was causing my browser-specific css to get ignored.

My Masterpage was using a simple IE-conditional to include css written specifically for IE7 (and another for IE<7). We also had a generic basepage that every page inherits.

For some reason (and I’ll explain why in just a second) my ie7.css file was just not getting recognized by any of my pages. I quickly checked the source of the page and found that the order of css on the page went: ie7.css in the conditional, followed by all my Theme css files located in App_Themes/Themename/css.

Introduction to Themes

In case you are new to .NET 2.0 and Theming, the general idea behind it is that you have a special folder called App_Themes. Inside this folder, you can make subfolders. These folders should be the names of your theme, so if you want a blue theme, the file structure would generally look like ~/App_Themes/Blue, and then images and css directories under that.

Why is this useful? .NET 2.0 includes the ability to set a page directive called “Theme”. At the top of a page, there’s some junk thrown in there by .NET, like MaterPage, Title, etc. You can add to that: “Theme=’Blue'”.

What happens next is that all that css is imported automatically. Presumably as well that css should have a relative path to the images. You can have skin files and all kinds of things in the Theme. The magical part is, if you want, you can also set the Theme programmatically. If this is the case, you could have some kind of Session variable, in theory, that “knows” where on the site you are, if you have different areas, and then set the Theme to the appropriate area. For example a Green area that has article.aspx and news.aspx.

In the Green/Blue example, if you used the same css class names (or even the same css FILE, copied in two different directories) you can literally just swap the image colors and automatically have two completely different looking websites running off of the same exact aspx/cs files.

The best part of Theming this way is that all you have to do in a codebehind is say, literally: “Page.Theme=”Green”;” and you get the Green Theme.

So what was my issue?

The Issue

The Theme css is imported automatically. Anything inside the Theme folder gets grabbed and added to the page in a <link rel=…> tag. This is fine. It’s not what it’s doing, but where. These are added automatically at the END of the head tag, by default. Good by IE conditional statements.

The IE conditional statement is supposed to pull in a stylesheet with extra or different definitions that override the current css in the case of IE. However, with css, the last version of a definition is used by default. So it was like my IE files were not even there.

The Solution

StyleSheetTheme! This is a second kind of theme that differs from the “Page.Theme” version of .NET 2.0’s theme system. (Geez the word Theme is starting to lose all meaning to me at this point… sorry 😦 I didn’t name these things!) A StyleSheetTheme differs from the regular theme in two ways:

1) The way it is added to a page programmatically

2) Where it positions the css on the page

StyleSheetThemes are specifically designed so you can alter the css with other stylesheets. Instead of placing everything last, it places it FIRST. This is incredibly useful for things exactly like browser-specific css files, or small little inline things you may want.

The reason I think so many people ignore this theme type is because of how it is implemented. On an aspx page you can statically declare it similar to the other theme, in the @Page directive, just by saying StyleSheetTheme=”Green”.

Programmatically, though, things are different. There is no Page.StyleSheetTheme. Instead, you have to override a property. That code would look like this:

protected override string StyleSheetTheme

{

get { return “Green”; }

}

This can happen in the basepage, which makes the most sense, honestly. You might notice that this is also static. Using a variable won’t help much, either, since it’s not executing at preInit or onLoad, it’s a separate method. What you CAN use, though, is a Session variable, as long as it’s not null.

Conclusion

This simple solution saved me a LOT of hassle today. I recommend more people check out StyleSheetTheme instead of Theme, since Theme requires hacks in order to get it to work well with alternate css paths.