Monthly Archives: March 2012

Olympia Snowe Is My Kind of Republican

Posted on by
Reply

A friend at work often chides me in saying that despite the fact that I’m a Republican, how I speak about politics makes me a Democrat. I’m just as Republican now as when I first registered to vote when I was 18, and I still hold to the traditional Republican values of small government, individual freedom, and conservative – as in judicious, not political – financial responsibility. My friend teases me because I have a much more moderate position with respect to my politics, which focuses on the issues and not the ideology, so I suppose it must seem to him that since I don’t speak politics like 95% of the Republicans out there, I must be Democrat. He’d probably say the same thing about Maine Senator Olympia Snowe, who is one of the few moderate Republicans in Congress today, and who unfortunately is not running for re-election.

I read an article about her frustration with American politics today this morning, and despite the article’s title of “Frustrated Senator Olympia Snowe Give Obama an ‘F,'” the actual meat of the article focused on her general frustration with Congress. Here’s a quick excerpt:

“I think a lot of the frustration frankly in our party, in the Tea Party challenges or even Occupy Wall Street is really a reflection of our failure to solve the major problems in our country,” said Snowe. “It’s become all about the politics, and not the policy. It’s not about governing, it’s about the next election.”

So has this Congress failed the country on those critical questions?

“Absolutely,” Snowe asserted.  “You have to sit down and talk to people with whom you disagree,” said Snowe. ” And that is not what is transpiring at a time when we desperately need that type of leadership.”

What she said above mirrors EXACTLY what I’ve been talking about with others when discussing politics. Especially with my ultra-conservative friends, I’m often apt to say before going into a political discussion, “I’ll only engage in this discussion if we talk about the issue, not about the ideology. If you want to bitch about Obama did this or Obama didn’t do that, then let’s talk about how the Sharks are doing instead. Whether you like the guy or not, we have real problems in this country, and discussing political ideology is NOT going to solve them.” We usually end up talking about the Sharks…

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.

Want Your Team to Write Maintainable JavaScript? Start Making Them Think Alike…

Posted on by
Reply

A colleague at work today posted a couple of JavaScript/Front-End Development conferences that are coming up in the near future. One of them, the O’Reilly conference has a speaker talking about writing maintainable JavaScript. I did a bit of searching on him speaking about this topic, and the material that he presents is generally pretty good – at least from a coding standpoint. But I think that focusing only on coding won’t solve the problem. From personal experience, nothing can mess up maintainable code more than bad or non-existent design practices.

I know I don’t get too much traffic to this blog, but for those who have read my technology articles, they’ll know that I have a real design focus. Why? Simply because high-quality, easily maintainable software starts with good design, and I have LOTS of personal experience in this. I was able to get roughly 200 front-end engineers at a previous company to code the same way – in a maintainable fashion – by first teaching them good design practices. It all started out with using UML as the way to communicate our designs, then writing good technical design documents to describe and discuss the diagrams, then writing code that followed the designs. Of course, included in the process were both design and code reviews ensuring that the final product that was produced with lots of input and feedback.

Most would think that adding all this onto the development process would tack on more time to development. Admittedly, at first it does. That’s the “learning tax.” But once people are used to doing designs, and going through a few review processes to defend their designs and code, they become faster at development; much faster than they were before they started practicing “design first, code later.” While this also requires an overall organizational acceptance, it’s an easy sell because the overall code quality will shoot through the roof.

Plus, doing design then coding is the fundamental difference between software engineers and code monkeys. I’ve been around long enough in this industry to say that most software developers, though they like to think of themselves as engineers are code monkeys; albeit, with varying levels of experience. The more experienced developers will most likely be able to tackle a problem and get it right a lot of the time, but to me, when there’s not a design to accompany the development, there’s always a risk that problems that could’ve been mitigated and avoided with a design will trickle through. That’s not to say that a design will mitigate all bugs. That’s ridiculous. But you can avoid lots of problems simply by doing a design and following it; that is, implementing code according to what’s described in the design.

To crystallize the point further, let me say this: Code is PRODUCT; design is engineering. And when people are designing in the same way, they will tend to adopt coding practices and standards that are similar and maintainable throughout the organization.

So which do you want to be, engineer or code monkey? If you’re not already doing design, you know who you are…

A Real Pet-Peeve

Now that I’ve pontificated on the virtues of design, I’ll discuss code. The speaker on writing maintainable JavaScript, Nicholas Zakas, is quite an engineer, currently a principal at Yahoo. But in reading through his blog and reading through the conference highlights, plus reading this article that he wrote on the subject, he missed a VERY important point that is one of the very things that pisses me of more than anything else and that is lack of comments. I’m very good about commenting my code simply because once I’ve got it checked in, I want to be able to get a gist of the flow when I return to it weeks, months, or years from when I wrote it. I also do it so that others who may maintain my code after I’ve left know what I’m doing in my code.

I’ll just say it plainly: Commenting code is Programming I; not 101. You should be commenting your code from the get-go. Period. It’s such a key component to team coding and writing maintainable code, but it is often missed in talks and lectures because it’s assumed people do it. Nick, believe me, they don’t. 🙂

Here’s a Problem I Have with UI Developer Job Requirements

Posted on by
Reply

Here’s a job description I got in my inbox today.

LUCILE PACKARD OF STANFORD MEDICAL CENTER
Sr. UI/Front end Deveoper
Perm, Up to 115K
Top of the Line Benefits

Our client, Lucile Packard Foundation is looking for a permanent UI Developer to join their team immediately on a full-time basis. Please find the responsibilities below and let me know if you might have interest.

Skillset & Requirements:
•7+ years experience developing complex dynamic web applications
•Development and Collaboration w/ both small and large development teams
•Expert knowledge of HTML/XHTML
•Ability to write code without WYSIWYG editor
•Advanced Object Oriented JavaScript
•Experience with JavaScript libraries such as jQuery and DWR
•Practical knowledge of AJAX using JSON
•Proficient in the implementation of Cascading Style Sheets
•Skilled in the use of CSS Selectors
•Competent in Web Design and graphic creation
•Experience w/ WebSphere or WebLogic is a plus

Notice I bolded the “Advanced Object Oriented JavaScript” line. This is the problem that I have with this job requirements list: The very next line mentions jQuery. Every time I see requirements lists like this it almost invariably means that they’re really not doing OOP JavaScript. Oh, they use objects and such, but their actual implementation of OOP tends to be fairly limited. Another problem related to that line is that there is not associated line that requires object oriented analysis and design. Essentially, that shop is doing DOM-level stuff. The effects are cool, but I can tell that the position is pure coding, very little engineering.

Having gone through many interviews in the latter half of last year, when I’ve interviewed with companies who have these kinds of descriptions, invariably, when they post requirements like this, they’re only paying lip-service to actual object-oriented programming. And if they do indeed do OOP, they design by code, which raises a HUGE red flag for me. Only a couple of companies that I interviewed with (one of which I joined) did some level of design, or at least wanted to begin a process that included design. Now by design, I don’t mean visual design, but engineering design, which includes UML diagrams (or industry-standard diagramming), and technical design documents. The best company that I interviewed with up in San Francisco actually spent the better part of the interview grilling me on an object diagram they had me create based upon a set of animals within a fictitious animal kingdom. I had to create the object hierarchy, and also draw out simple sequence diagrams to illustrate the interactions between the animals and their “world.” Very cool stuff, and just about the best interview I had ever gone through.

Unfortunately, a lot of companies just don’t take the time to do real engineering design. Most internet-based companies engage in “agile” development. Gawd I hate that term, mainly because practicing it has been so bastardized. What many organizations just don’t realize is that Agile development requires so much more developer discipline than most engineers are willing to commit. This is exacerbated by pressure from sales and product management to constantly deliver features and the time allotted for delivery just doesn’t allow for taking the time to do design.

As for the last line in the previous paragraph, that’s actually horseshit. In my experience, with good developer discipline, you can actually deliver more in the same amount of time because you don’t waste time flailing around with code. If you discipline yourself to design what you’re going to build, then coding is simply connecting the dots. It may seem counter-intuitive, but I will posit that if you’re not spending at least 60-75% of your development time designing, you’re really not being very productive. Food for thought.