Saturday, December 17, 2011

SaaS that has ASPX in the URL? Run away.

This is not a Windows bashing post. I worked on Windows exclusively for about 10 years and it's what we run in our house. Developing for Windows is a great experience, with Visual Studio, C#, the .NET framework, Microsoft has made it so. That said...

Heard of SaaS? It's all the hotness after software vendors figured out that selling software for businesses to run on their own computers wasn't going to work anymore. Thanks to the fast-paced American business market and pointy-haired CIO types, we no longer have funds for local IT folks to deploy and operate machinery. So we'll pay 3x as much for a "hosted" solution. That's where SaaS comes in to rip us off offer a solution.

In any case, two of the most appalling SaaS products I've seen in the past year has been from vendors who based their stack all on Microsoft technology. For one of them, when you take a look at their product, it takes about 10 seconds to figure out this is a mishmash of ASP.NET 1.0, 1.1, 2.0 (and so on), components. Overall, It has the old and truly busted behavior of a Microsoft "web application" that uses Viewstate and iframes. God help you if you refresh or hit the back button. The other vendor didn't even support non-IE for the first 3 months of us being on their platform. How our people ever decided to use this, since we almost all work on Macs, I'll never know, but it's absolutely outrageous in 2011 if your website doesn't support Safari, Chrome and Firefox.

The problem with using extensive Microsoft libraries like this is that you are bound to what they implement. The web will improve. Compare the HTML and Javascript used in 2000 to that of a website today. When you're depending on Microsoft's "webforms" and such to generate that code, you are at their whims for your user's experience. Then when Microsoft decides to upgrade that experience, you'll need to upgrade, but oftentimes that legacy code won't be easy to upgrade. Consider the state of the art in .NET web tech from 2002 until now: porting all of that UX from Webforms 1.0 to ASP.MVC ... that's just not easy.

In general, I would run away from Microsoft tech for building a SaaS unless there are circumstances that require it. One is integration with other services on the Windows platform. Then it makes a lot of sense. Let's say your SaaS specifically helps people manage IIS instances for their own websites, and those customers want to use IIS. Fine, whatever.

On my last Windows project, I did the math on how much we'd save in software licenses by moving to Linux. It was only around $250K... not enough to justify the move. But having been removed from Windows for work for a year now, I'm fairly convinced that when you're building a service, you should go for Linux and FOSS, and it has nothing to do with up front cost. You just don't control your own destiny otherwise. Problem with MSVC? Bitch to Microsoft on their issue voting system and hope they fix it. Problem with GCC? Patch that shit. And being a customer of SaaS, I'm just not going to trust vendors that don't understand this.

Wednesday, November 23, 2011

No, you don't know C/C++ [Resume/Interview Rants, Part 2]


Probably more than 50% of the resumes I see -- maybe even 75% -- have a "languages" section. For those not familiar, a resume will look like this:

Joe Coder
1313 Mockingbird Lane, Sunnyvale, CA

Objective: To be a Great Programmer
Languages: C/C++, Java, PHP, HTML, XML, CSS, Javascript, ASP.NET, T-SQL
Prior Work Experience: PHP Web Company, Inc. 2009-Present

See what he did there? There's a "languages" line that just lists off a bunch of random stuff. Recruiters, and not to mention LinkedIn, will tell you that this is how you get your resume found online -- by putting in a lot of keywords that people are looking for. Some resumes I've seen are so chock full of keywords that a person 2 years out of school has a 3 page resume. I think my resume finally passed 1 page last year... that's, um, 17 years since I've started working full time and 25 years since my first job.

And oftentimes this works out. Consulting is one area where it does. People want to hire consultants with a particular skill that they don't have. So if I was looking for a C programmer and didn't know the first thing about it, I'd probably look at Joe's resume and be interested. When I interviewed him, he would probably be able to show enough savvy to make it through the interview, and I would hire him.

When he arrived to do the work, he would be cramming to make it through the day to do the work in C. Googling frantically, asking questions on StackOverflow, etc. But since the client really doesn't know how to write code himself, and Joe is a resourceful guy, chances are the project will go along fine. The project will be delivered, albeit in likely hacky code, and everyone is happy.

It absolutely does not work this way when you're looking for full time software engineering gigs.

And here are some pro tips on what I'm looking at. My hope here is that over time, everyone will save a lot of time by following these tips.


First thing's first: I'm suspicious because you put HTML, XML, CSS, and ASP.NET under "languages".

This is the first red flag. When you're interviewing for a software engineering gig, markup languages don't count. I expect to be able to hand any decent software engineer any crazy-ass markup language and have them understand it. I would say that a blanket classification for listing a language in this section is it has to be Turing Complete, but, unfortunately, HTML+CSS is Turing Complete. So I just have to say "markup languages don't count."

ASP.NET is not a language at all. It's a library. This is like saying that stdlib is a language I know. Yet ASP.NET is in these lists all the time, along with Spring, Hibernate, Struts, etc.

And damn you Ohloh for listing many of these under "languages". How is XML any more a language than a CSV file?


Don't list it if it's just a hobby language

Unless you've undertaken some serious hobby work, that is, and feel as prepared as you would with your work.

I had a candidate who was doing fairly well in the interview, telling me about his last job. At some point I noted he listed Ruby and Rails on his resume. I said, "Hey, what have you done in Ruby?" He said it was hobby work. I asked what it is that he's created, family website, something else? He admitted he had bought the book and never really read it.

Let's repeat that: He put on his resume a language for which he had bought a book and never read. O...M...G.

Don't be that guy. Please.


If you list it, be prepared to answer questions about it.

This is an extension of the first point in part 1. Red flag number two: you just spent 2-3 years at a PHP company, doing PHP work. Yet PHP is the third listed language on your resume? Shouldn't it be #1? Your best language should be what you're working with right now, right?

If you have "C/C++" on your resume's "languages" section first, to me that means that either that's your main interest or your main expertise. When I ask you questions, that's where I'm going to go. If you don't want questions about a subject, do not include it on your resume.

The other thing is, I do not properly introduce myself. I'll tell you my name, but not what I do. So you have no idea if I'm a PHB or a neckbeard (answer: 50% of each, well maybe 75% PHB these days... *cries*). This is a trap. If my introductory batting-practice questions lead you into making yourself out to be an expert in something, I may just drill you hard on that later.


Thing is, I won't ask you about stuff you say you don't know

If you come to me saying all you know is PHP, I'm not going to ask you about C++. If you know a language I don't know, and explain it well, I will take that all at face value.


Most importantly (and subject of post): if you put C/C++, it makes me sad

They're not the same! If you write C++ that looks like C, you're doing it wrong. If you write C that looks like C++, your coworkers will likely make fun of you. But if you lump them together as one language on your resume, I'll be sad. If you say that "C/C++" is a language, verbally, in the interview (this has happened), I'll just go ahead, take the blue pill and end it all now.

So the first thing I'm going to ask you is "which is it, C or C++? What's the difference anyway?" If you can't answer this, and you've led me to think you should know, then it's a hard spot to recover from. I don't even think of myself as a good C or C++ programmer given the genius co-workers I've had over the years, so if you've set yourself up as one and can't answer my easy questions... that's just a problem.

Bottom line: if you have to have a "languages" section on your resume, for whatever reason:

  1. List it in the order of languages you know best
  2. If you want to work in a particular language, you're taking a risk listing it first if you don't know it well. But, I don't blame you for trying.
  3. Don't list stuff you don't know.
  4. Don't list XML, HTML, CSS unless you're a designer, and call them skills or markup or something other than bulking them with C++ and Java, please.
  5. For the love of god, don't lump C and C++ together.

Full disclosure, my languages line from my very first resume coming from college (1994):

C, C++, Renderman Shading Language, perl, csh, sh.

And I'd say I totally overestimated my experience with Renderman Shading Language (shouldn't have listed it) and underestimated my experience with Perl (I didn't realize at the time I was more of an expert than I knew).


[Edit]

Heh. I've done the "C/C++" misnomer myself on this very blog. In my defense, I was mostly programming in C# in 2008, so my brain was fairly warped.

Sunday, July 24, 2011

Space: it's just not our thing

I saw a very nice and sentimental video of the Space Shuttle launches.




Really nice, nicely done.

Let me give you my perspective on the Space Shuttle. I love NASA and what they have done with the Shuttle and Apollo before it. However, the time for those has passed and we should not replace them with anything that takes humans into space. Ever.

Space is simply not a human thing. We are far too fragile to survive out there for any meaningful duration, and I think the space shuttle proved that fact. Over the last 30 years, we've accomplished launching a telescope, several satellites and some erector sets from the Shuttle. Furthermore, the Shuttle has enjoyed a 1 in 25 chance of death -- meaning you are 365,000x more likely to die on a Shuttle than a commercial flight.

I'm not trying to diminish the accomplishment, I think putting humans in space is hard. What I am trying to ridicule is the idea that we should keep doing it. It really is too expensive for where it gets us. We cannot do much with the limited opportunity we're given to be in space, and to give us more would be cost prohibitive and risk too many lives.

No, something else needs to take space from here. Either it will be artificial intelligence or some sort of engineered organism that can do it. We're the first species in the history of the world that can create a being that can explore for us. It's time we start focusing on that. Automata will get us to the next level, not more Shuttle-like stuff.

Monday, July 04, 2011

Apple is now Microsoft

You know why? Because I've become a Mac person. That would be impossible if they weren't now Microsoft.

The Mac is the path of least resistance. It comes with software that gets the job done (iPhoto, iMovie). It's rare to worry about drivers. You won't worry about support. Apple is ubiquitous. There's an Apple store near every major city. Your iPhone works with it. Your iPod works with it. It has iTunes. It connects to all of your Windows stuff. It's supported by everything you pretty much will care about except some games.

And, having just gone to Best Buy to look over the competition, Apple has the best hardware for the buck. I thought for sure we'd walk out with a PC for my mother-in-law. Instead we walked out planning to buy a Mac. PC laptop makers have completely lost the plot. They've gone from making reasonably priced good hardware to making crap that, while it appears cheap, is actually expensive for what it is. The most egregious problem is the crazily offset trackpad. Whoever thought that laptop users needed a number pad starting at 15" is an idiot. Protip for PC laptop makers: JUST COPY WHAT APPLE DOES. It's not that hard.

You won't find $300 wonders from Apple, but you also won't have computers that die after 6 months. I already learned that lesson by buying my in-laws a netbook. First the wi-fi driver was busted. Then wi-fi died. Then the whole thing died after 13 months. I'm now recommending they get a Macbook Pro 13", and will be ordering them one here shortly.

Maybe I've changed my tune on this because I don't work on software that targets the desktop anymore. I can't possibly fathom making a case for having a Windows laptop at work, where my actual work is on Linux. A Mac is a seriously imperfect solution because it's not Linux, but least with a Mac I can reasonably do my work and still have a desktop experience with commercial applications -- without virtualization.

Or maybe I've changed my tune because the desktop is just that irrelevant. But at the same time, I'm about ready to start recommending to normal people that the buy an iPhone instead of Android.

Or maybe it's just because I'd rather be a normal person, than jumping through hoops to get stuff to work just to save a couple hundred bucks.

Anyway, bottom line: Apple is now Microsoft. They control the consumer market. I think they're making inroads into the enterprise simply because most of the enterprise has started running on the web. I think Apple still has a problem with sunsetting OSes too quickly, but that will eventually change as they reach deeper into Microsoftdom.

Sunday, March 06, 2011

The new premature optimization: lines of code

In the last 10 years, the number of widely available programming languages has exploded and, thanks to client-agnostic technology such as the web browser, HTML and HTTP, the ability of engineers to choose their language has increased. As such, you can't find a thread about languages where lines of code aren't compared. Lines of code are compared in both number of lines required to do something and elegance/style. Because, after all, when we choose a language to use, we then have to stare at it all day. So it's worth seeing how good or bad it looks.

Take, for example, this tidbit on the front page of the Haskell website:

3.1 Quicksort in Haskell

qsort [] = [] qsort (x:xs) = qsort (filter (< x) xs) ++ [x] ++ qsort (filter (>= x) xs)

3.2 Quicksort in C

True quicksort in C sorts in-place:

// To sort array a[] of size n: qsort(a,0,n-1) void qsort(int a[], int lo, int hi) { int h, l, p, t; if (lo < l =" lo;" h =" hi;" p =" a[hi];" l =" l+1;"> l) && (a[h] >= p)) h = h-1; if (l < t =" a[l];">
My copy of their HTML is broken here, but the gist is this: Haskell allows you to do a quicksort in just 2 lines of code, and C is 28 lines. Conclusion: Haskell must be that much more fun and expressive to work in.

You'll find examples like this for every language that's out there except for C, C++ and Java, because those are considered the old and busted languages that require too much cumbersome code. The new hotness.... Ruby, Python, Erlang, Haskell, Scala... they'll all have examples like this.

Meanwhile, while we're comparing lines of code, performance is going to crap. I saw someone make the point today that Ruby 1.8.x provides just 2% .... TWO PERCENT .... of the performance of C. And it's true -- backed up by the language shootout.

Furthermore, many dynamic languages allow you to write elegant code like this, but it's also unchecked. It requires far more unit testing in a dynamic languages to get the same assurances that one can get from using a statically typed or type-inferred language. So, long term, you are putting the onus on yourself to do checking that would otherwise be done by a robust compiler. (Haskell doesn't have this problem, of course).

Could it be that the new form of "premature optimization" is in the form of lines of code? In the case of Ruby or Python, we're prematurely trading off compile time checking and performance to have what we consider more elegant code? This is not new, it's been going on for years -- a C programmer will tell you that C++ was similar, and a C++ programmer will tell you the same of Java.

And I know someone is going to tell me that if they hadn't written in Python or Ruby, they never would have shipped it quick enough. I don't know how this claim can be proven valid or invalid. There are lots of websites out there written in Java that are successful and timely.

Also, when challenged, sometimes the rebuttal to this concern is that "you can always extend your [Ruby/Python/Perl] using C." That's true, you can. But if the requirements of your project have some aspect of performance or using APIs or libraries that aren't supported by [some language here], then aren't we falling into the pit of premature optimization, just in terms of what we perceive as a better way to work? Why are we disregarding requirements just to fulfill the dream of reducing lines of code?

I'm not saying these languages are bad. I'm saying that requirements or realities of the project/world are being disregarded to use them. So let's call it what it is: premature optimization.