Senior Java developer, one of the top stackoverflow users, fluent with Java and Java technology stacks - Spring, JPA, JavaEE. Founder and creator of http://computoser.com and http://welshare.com . Worked on Ericsson projects, Bulgarian e-government projects and large scale recruitment platforms. Member of the jury of the International Olympiad in Linguistics and the Program committee of the North American Computational Linguistics Olympiad. Bozhidar is a DZone MVB and is not an employee of DZone and has posted 74 posts at DZone. You can read more from them at their website. View Full User Profile

Do Web 2.0 Companies Really Have The Best Technical Talent?

10.02.2012
| 2466 views |
  • submit to reddit

There are a lot of cool companies with products on the web that millions of people are using. I’ll wondered whether I should label them “web 2.0″, “silicon valley”, “cool startups”, or something else, but I think it’s clear which ones I’m writing about.

The assumption is that these companies attract the best technical talent. And even despite my criticism of their interview process, I still used to think that indeed the best developers and software engineers go to these popular web companies. But due to a couple of observations, I’m no longer certain. These companies have been making junior-developer mistakes in many areas and I can’t imagine that a “top talent” could allow this to happen.

What raised my concerns is security. And it’s not computer-science heavy-cryptography-algorithm-design type of security. It’s the simple web security that every developer out there should actually know – how to store passwords. I was astonished to learn that Yahoo, LinkedIn, and recently Pandora were revealed not to be hashing and salting the passwords, which lead to password leaks. (Note: the case with Pandora is a bit less trivial as noted in the HN comments). It’s the bare minimum thing you should do, and any sane developer who sees that the company stores passwords in plaintext, or uses MD5 hashes, or doesn’t add salt, should just go and fix that (with management approval, yes). “Legacy” is not an issue here – you can hash&salt plaintext passwords, and you can add salt to a hash the next time a user logs in (by getting his actual password on login in order to generate a new hash). But many companies haven’t done that. I would be ashamed to work in a project that doesn’t follow these practices widely known for years, especially if it has millions of users.

But enough with the security. Let’s talk about API design. API design is hard, but it is manageable by top engineers. And yet, there are many instances of unstable, not well-designed APIs. Facebook, for example. They are improving it now, but it used to be horrible. The Android core APIs look (or used to look in the first versions) as if written by a freshman (just a simple example from my android experience: cursor.getInt(cursor.getColumnIndex(CallLog.Calls.TYPE));. Many methods with more than 5 arguments, etc.) Related to APIs – salesforce XSDs sometimes cannot be parsed, because they are invalid – we have been fixing their XSDs in order to communicate with them.

And these are the things that we see on the surface. I’ve heard “horror” stories like writing web projects in C++, and the other day I took a look at the code of reddit, which (even though I’m not a python developer) struck me with some really odd stuff (won’t go into details). I guess many people have heard or seen a lot of “wtf” moments, that a “best developer” just wouldn’t do.

So is it really the case that these silicon valley/web 2.0 companies have the best developers, or they are just regular companies that have average developers doing stupid things? There are certainly some great developers in these companies that do “magic” and “insane” stuff, but apart from the stars, are the rest of the developers also “the best”? I’m no longer sure this is the case.

Published at DZone with permission of Bozhidar Bozhanov, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)