Tag Archives: thoughts

Not Sure I Buy Into Science and Engineering Jobs “Losing Ground”

Posted on by
Reply

I read an article today that was published in yesterday’s San Jose Mercury News Business Section written by columnist Chris O’Brien entitled, “Key Job Sector Losing Ground,” describing how growth in science and engineering jobs over the past decade has remained flat relative to previous decades, and kind of being a doomsayer in that that flatness may have an effect on innovation. He does quote a researcher that said that perhaps that flat growth means a lack of demand for science and engineering jobs. Being in software engineering, I would tend to agree with that assessment. But I disagree that that flatness may lead to the possible constriction of innovation.

I think that the flatness is actually a correction of the excesses of the dot-bomb era. Even in 2007, there was a minor uptick in the technology sector, and several companies, including my former company, SuccessFactors, added LOTS of engineers in a very short period of time. Unfortunately, during a boom period, especially in technology, the focus tends to be on putting “butts in seats” quickly as opposed to getting the right butts in the right seats. I saw that at SuccessFactors, where we added lots of really mediocre engineers to our software development team. Most of these “engineers” were the typical, “code-first-think-later” code-monkey types. As a result, in 2008 when the economy soured, the company had to shed that excess and frankly, unneeded baggage.

I’m probably sounding a bit crass and elitist, but honestly, I truly believe that what’s happening with the technology job growth, especially here in Silicon Valley has more to do with companies being careful about choosing the right people to fill their employment needs, and choosing only those whom they feel will take them to the next level.

People talk about jobs being shifted off-shore. To me, it’s natural that they’d go there. Think about the jobs being shifted off-shore. I don’t think I’d be too far off the mark in saying that those are jobs that tend to be more maintenance and production-level types of jobs. The real innovation stays here. Even with my previous company SuccessFactors, despite senior management constantly saying that our engineering group was “global,” and always tried to blur the lines between domestic and offshore development, in reality, all the innovative work took place here in the States; and even new product development offshore followed the models and innovation established domestically. Plus their designs were always subject to approval from the US-based team. So in consideration of that, to me, this “flatness” is not really flatness. I believe it’s shedding the production and maintenance workers, and distilling down to a workforce of innovators here in Silicon Valley.

Call me insensitive, but as opposed to Mr. O’Brien, I’m in the industry, and have experienced the growth and decline of job number from behind the lines. Yes, I realize that I’m opining, but it’s not uneducated and not without experience in the sector.

Wednesday JavaScript Meanderings

Posted on by
1

On JavaScript Parasitic Inheritance

Hmmm…. Not sure that I really buy into all the craze in Parasitic Inheritance the last couple of years. Perhaps I’d buy into it if I heard a really great technical explanation, but thus far, all I’ve heard and read about the virtues of Parasitic Inheritance center around not having to use “this” and “new.” My reaction to that line of reasoning is “So what?” “this” and “new” are artifacts of the JavaScript language. Deal with it. Another line of reasoning used to justify the use of Parasitic Inheritance is the concept of the durable object, which is defined as “A durable object contains no visible data members, and its methods use neither this nor that. Again we return to the non-use of “this.” And again, “So what?” You can achieve something similar this using while defining a custom object in the traditional way:

function myObj() {}

myObj.prototype = (function() {
    function myPrivFunction(myArg) {
       return ...do something with myArg...
    }
    return {
        myMethod : function(param) {
            return myPrivFunction(param);
        }
    };
})();

You can have a whole set of private functions defined above the return that will not be changeable to the outside world. Furthermore, one of my biggest problems with Parasitic Inheritance is that you lose instanceof. Yes, there are ways to deal with it, but most of the examples I’ve seen deal with overriding Object and Function prototypes, or creating some intermediary “helper” function to enable instanceof with Parasitic Inheritance. My thought about this is if you have to make changes to the core of the language, then the “solution” you’re providing is simply an interesting engineering exercise.

On MVC: Put the DOM in Its Place, Dammit!

One of the things I see quite a bit of when working with JavaScript developers who are relatively new to using MVC frameworks such as Backbone.js is that their thinking is very DOM-focused. And while MVC in JavaScript does mean interaction with the DOM through the View, most developers focus their thinking around the View. As a result, their programming is all about direct references. But MVC is about separation of concerns, and each part of the MVC has an important role to play. As such, one of things that I do my best to help “teach” is having developers divorce themselves from DOM-based thinking, and start thinking at a much higher level; specifically, the system or application; breaking the application or system into constituent MVC parts.

Admittedly, it’s difficult for many to make the conceptual leap into MVC thinking because what we as UI Engineers produce ultimately shows up on the DOM. But the DOM is a by-product of MVC interaction. Once you get that concept down, then thinking with a perspective of MVC becomes quite easy.

It doesn’t help matters much when you have examples that are very DOM-focused, as many developers that move over to MVC are expert in jQuery or YUI or prototype.js, what have you. As a result, these developers provide examples that lean heavily on that previous experience. It’s a bit of vicious cycle.