Posts tagged developers

Developers Are Adopting Java 8 In Droves

Warning: serious programming geekery ahead.

With the release of Java 8 back in March 2014, the developer community was primarily excited about two things. One was support for lambda expressions, also known as anonymous functions, which (in Cay Horstmann’s admirably simple definition) are blocks of code you can pass around in a program for later execution—or, if you prefer more formal terms, “a way to represent one method interface using an expression.” Second was Java 8’s embrace of the multicore world. 

See also: Java And Scala: Former Competitors May Be BFFs Before Long

Functional programmers viewed the new directions that Oracle was steering Java 8 as a strong validation of core principles in languages like Scala, Erlang and Haskell. Detractors suggested the new directions of Java 8 were potentially a threat to supplant those languages. (I covered the implications of Java 8 for other languages back in February).

Jonas Bonér

Six months after the release of Java 8, San Francisco-based Typesafe—the commercial backers of Scala, Play Framework, and Akka—has released a follow-up survey of Java developers. A hefty sample size of 3,000 Java developers not only updates our data on Java 8 adoption, it highlights other trends driving enterprise application development today.

For some context on the survey findings (you can download the full findings here), I spoke with Typesafe CTO and Akka creator Jonas Bonér.

ReadWrite: So tell us where Java developers are with Java 8 and what the survey data suggests.

Jonas Bonér: In our original Java 8 adoption survey six months ago, we found that two thirds of Java developers planned to upgrade within two years, which is really aggressive. So we were surprised to learn with this new survey that two-thirds now have actually already upgraded or plan to upgrade within a year—the adopters are six months ahead of what was already a fast pace. 

When you think about how much Java is running in production, you just don’t expect to see this much of the market move that quickly.

Of the excitement around Java 8 for those who have adopted it already, lambdas continue to be at the top of their list of things they’re enjoying. Eighty percent called “lambdas with expressions and virtual extension models” the feature they cared about the most. With Java 8’s support of lambda expressions, type inference, syntactic sugar for static methods, and new APIs like Stream and CompletableFuture, Oracle has basically taken 9 million Java developers back to the future with a renaissance around functional programming.

The Lambda Lies Down On Broadway

RW: Why the major interest in lambdas?

JB: Well, first it simplifies traditional callback-driven programming by adding syntactic sugar on top of anonymous classes. Lots of Java APIs are making use of this callback style and all of these libraries will be able to make direct use of lambdas, enabling its users to write more fluent and less verbose code.

This is great, but the biggest benefit in my opinion is that it enables a functional style of programming, which has a lot of advantages, but primarily delivers more succinct and expressive code that is easier to compose and reuse. But perhaps most importantly, code that allows you to work with state, safely, in a concurrent environment.

In the single-threaded world of the 80s and 90s, dealing with state in applications was a lot easier. But, as we all know, the multicore world of distributed computing today has opened up a Pandora’s box and made it much harder for Java developers to shoehorn all of this state into a perceived reality of running in a single core. 

Technically it is possible, through mutexes and other blocking primitives, but it just doesn’t scale. 

In Java the default is mutable state, but a functional approach to programming—which can be simplified as composition of functions operating on immutable state—can make the design of concurrent and asynchronous (event-driven) applications so much easier, allowing us to take full advantage of all the exciting new multicore hardware on the market. 

Examples of this include the JDK itself with its Stream and CompletableFuture libraries. Event-driven programming also opens up for a more loosely coupled architecture, with isolated components communicating in a non-blocking fashion, and forms the basis for the principles defined in the Reactive Manifesto.

RW: What about those that do not have plans to upgrade, what’s the holdup?

JB: Of Java 8 holdouts, 69% are running Java 7, and 26% are running Java 6. For the majority of the Java 8 holdouts, their decision has nothing to do with Java 8 and more to do with how their businesses operate. Among those shying away from Java 8, 37% said their non-adoption was related to “hurdles with legacy infrastructure” and 19% said “organizational obstacles/red tape.”

However, it would be a mistake to call organizations that don’t upgrade to the latest versions of software “laggards.” Sometimes I think that analysis of market adoption of new versions overlooks the legacy infrastructure and existing libraries that organizations have to upgrade—where the cost of upgrading may not make financial sense, and it has nothing to do with the merits of the new version itself. 

Java’s footprint in production is so massive, there are just a lot of moving parts at most enterprises when thinking about upgrading a language that touches so much of its infrastructure.

Apache Spark Is On The Move; Docker, Not So Much

RW: You polled those 3,000 Java developers on their use of other technologies. Given the large sample size, I’d be interested to hear about other surprise findings that came up.

JB: Amazon EC2 is used by more than half of respondents (57%), making it the most common cloud technology used by Java developers. Apache Hadoop ranked second in popularity at 30% and Big Data newcomer Apache Spark is being used in production by 17% of respondents. 

Given that Spark was only introduced to the market in June of 2013, we think that’s really an incredible production usage statistic, and a sign of just how much mindshare Spark is capturing in the Big Data world.

One of the head scratchers was around Linux containers, where the data didn’t really line up. While 60% of respondents claimed to be investigating Linux containers, and 23% said they use Docker, only 13% said they are actually using Linux containers in production.

There were really no surprises where application server adoption was concerned. The latest findings confirm that adoption of lightweight, open source Java Web servers like Tomcat and Jetty are far and away more popular than traditional heavyweight JEE application servers like WebLogic or WebSphere, which are nearly tied in popularity.

I was also surprised about the Internet of Things adoption: 21% claimed to be running networked devices/M2M/IoT in production, with 22% “planning for future deployments.” That’s way out ahead of the IoT adoption curve for the rest of the industry.

Lead photo courtesy of Shutterstock

View full post on ReadWrite

You’re Not Coddling Your Developers Enough

In a world being eaten alive by software, you need to hire more developers. A lot more.

Perhaps more importantly, according to former Netflix cloud chief and current Battery Ventures Technology fellow Adrian Cockroft, you need to help to make them productive. Which mostly means you need to get the heck out of their way.

Here’s how.

Why Developers Matter

Software increasingly sets the pace for competitive differentiation, and developers write that software. Cockroft, speaking at Monktoberfest 2014, suggests that organizations need to reorganize themselves around DevOps principles and practices to give developers the space they need to succeed. 

See also: Developers, Not VCs, Help Us See The Future Of Technology

Developers, after all, point to the future. While many make a fetish of revenue, Cockroft insists that developers, not revenue, are the best indication of where the market is moving:

If we were looking for billion-dollar revenue streams, after all, we would miss the widespread adoption of container technology like Docker, the embrace of NoSQL databases and Hadoop, the shift to cloud computing and more. None of these has yet generated the kind of revenue that yesterday’s license-based software models have, which is why companies like Oracle have been so lethargic about adopting them. 

But make no mistake: They are the future of computing, a future being written by developers, not IT.

Shut Up And Code

According to Cockroft, “speed wins in the market.” Therefore, enterprises that want to be competitive must find ways to unleash developer productivity. Often this simply means letting them work in the ways that they wish to, which can be discerned from an analysis of so-called Shadow IT. According to Gartner, 38% of corporate spending on servers, software and the like is no longer controlled by the IT department. That number that is projected to jump to 50% by 2017.

A significant percentage of that is being driven by developers and the lines of business they serve.

Motivated by the need to get things done quickly, developers have for years turned to open source and cloud technologies to unshackle themselves from bureaucratic software licensing and hardware provisioning policies. Even slow-moving governments have caught on, as Gartner analyst Lydia Leong highlights

Those companies that want to compete effectively, says Cockroft, must take this traditional development process:

Source: Adrian Cockroft

And squeeze out the inefficiencies. To wit (quoting Cockroft):

  • Hardware provisioning (“approval process and hardware purchase”) is undifferentiated heavy lifting—replace it with a cloud-based “infrastructure as a service” alternative;
  • Software provisioning (“deployment and testing”) is undifferentiated heavy lifting—replace it with a cloud-based “platform as a service” alternative; and
  • Building your own business apps (“software development”) is undifferentiated heavy lifting—use a cloud-based “software as a service” alternative.

This leaves organizations with a tight, iterative process whereby developers take business needs and rapidly prototype, build and deploy microservices (loosely coupled services that together comprise an application) in the cloud, with constant customer feedback to help tweak the application. The new process looks like this:

Source: Adrian Cockroft

Such a process is built on immutable microservice deployment, whereby a company keeps old code in service, unchanged, until traffic routing changes, at which point the new code/service group is rolled into production. According to Cockroft, this approach is faster and “scales with large teams and diverse platform components.” 

It also tends to make developers happy. Yes, even your developers. As Cockroft humorously pointed out, one Fortune 100 CTO told him that “Netflix has a superstar development team, we don’t!” To which Cockroft responded:

Netflix hired them from you, and got out of their way.

Making Developers Happy

Which is, of course, the key to enabling developer productivity. Yes, all those perks that Facebook, Google et al. provide their employees must be nice, as are the outsized salaries and equity grants that Leo Polovets captures in his analysis of AngelList data. 

See also: How To Code Like A Startup

But they’re not ultimately what a developer wants. Or, rather, they’re insufficient in themselves to help you hire and retain great engineering talent.

The best developers want to work on things that matter in a way that allows them to express their creativity. Developers want the speed, flexibility and convenience of the cloud. They also don’t want to be mired in silly software licensing discussions, which is why open source has boomed (and why your company needs to write more open-source software). 

They want to use modern programming languages like Go. (Cockroft noted that 75% of the interesting projects he sees are written in Go.) They want to use modern data infrastructure like Hadoop.

In short, they want you to get out of their way.

Lead image courtesy of Shutterstock

 

 

 

View full post on ReadWrite

Fitness-App Developers Are Growing Wary About HealthKit

ReadWriteBody is an ongoing series in which ReadWrite covers networked fitness and the quantified self.

For the second time in two weeks, Apple has jerked fitness- and health-app developers—and like-minded consumers—around.

Apple’s HealthKit, a set of tools for sharing health data between iPhone apps, was supposed to be a key feature of iOS 8, Apple’s latest operating system for its mobile devices. Many developers raced to include it in new versions of their apps in time for the release.

Instead, Apple yanked their HealthKit-enabled apps from its App Store on the morning of iOS 8’s release, and hastily informed that they had to remove HealthKit from their apps.

On Wednesday, Apple released its 8.0.1 update to iOS and announced it was ready for HealthKit apps again. The problem—8.0.1 itself wasn’t ready, and Apple pulled it amid reports that updated phones couldn’t make calls and had trouble with Apple’s TouchID fingerprint sign-in feature.

Apple has promised a new version, 8.0.2, will come out in a few days, and hence so will HealthKit—in theory.

Hurdles For HealthKit Apps

The problem is that Apple wasn’t even allowing HealthKit apps in the App Store until yesterday—which isn’t much time to rewrite an app, test it, submit it to Apple, and win approval. The pullback of 8.0.1 would have stalled anyone trying to do so anyway.

Given all the troubles Apple has seen with iOS 8, some developers are now taking a wait-and-see approach. (An Apple representative did not immediately respond to a request for comment on the issues with HealthKit’s rollout.)

“We are waiting for the update to iOS before we resubmit a version of FitStar Personal Trainer that integrates with HealthKit,” says Alexis McDowel, a spokesperson for FitStar, which had originally planned to release a HealthKit-ready version on September 17 along with the introduction of iOS 8.

Runtastic is waiting until “we are sure the bugs have been squashed” to rerelease its apps, says Josh Shaeffer, the company’s vice president of business development. 

RunKeeper opted not to join FitStar and others in launching alongside iOS 8. That saved them from the troubles others saw. “RunKeeper wasn’t affected because they haven’t integrated HealthKit yet,” says Dorothy Jean Chang, a spokesperson for the company. 

RunKeeper’s namesake app and Breeze, a newer fitness-tracker app, work on iOS 8, and the company’s optimizing them for the new operating system, with HealthKit coming later. “They’re doing this to make sure they’re thoughtfully optimizing the user experience, rather than blindly racing to the front of the line,” says Chang.

HealthKit’s Future

HealthKit’s botched introduction may not hurt Apple in the long run, if it’s able to fix its software problems. But in the short term, it’s cost the company significant goodwill with the bleeding-edge developers it needs to popularize the feature. 

It’s also annoyed consumers who were promised a brave new world of smarter fitness apps since this summer when Apple first revealed HealthKit. 

HealthKit remains an iPhone-only solution, which means Google has an opportunity with its Google Fit software on Android and potentially other operating systems as well. Google Fit’s architecture allows for cross-platform development in a way HealthKit doesn’t.

And, as I’ve argued before, there’s an opportunity for someone to come along with a better solution for connecting fitness apps together. HealthKit ultimately aims to consolidate your vital signs and workout stats on your phone. That makes sense for a company that makes vast profits selling hardware. But where that data really belongs is on a secure server in the cloud, where you can access it from any device and connect it to any app.

If anything, HealthKit’s delays give everyone who’s working on fitness apps a chance to catch their breath and ask what the right way to gather and store health data really is.

Photo by Shutterstock

View full post on ReadWrite

5 New iOS 8 Features Developers Need To Get Their Heads Around

The latest iteration of Apple’s operating system is finally here, just a few short days before the iPhone 6 itself—both versions—makes its actual appearance.

Developers have had access to iOS 8 since June so they could explore new features, test their apps, and see what’s changed. If you’re just catching up now, here are some of the biggest changes you’ll encounter as a developer when you start working with iOS 8.

Adaptive User Interface

It’s time to start thinking differently about user interfaces.

In iOS 7 and previous versions, developers needed to consider different ways users might encounter their apps—primarily the landscape (horizontal) and portrait (vertical) views. The introduction of Auto Layout, a tool to simplify the process of fitting apps to screens, in Apple’s developer suite Xcode minimized that particular headache.

See also: Hold Up! Here’s Why You Might Want To Postpone That iOS 8 Upgrade

Now, says Step Christopher, iOS team manager and instructor at Big Nerd Ranch, Apple wants to change the way developers think about designing apps completely. “Apple no longer wants us to be thinking of specific screen modes,he said during a demo. “Instead they want us to target general sizes and let them flow out to the different devices and orientation as appropriate.”

Christopher thinks this means that soon Auto Layout may be the only, or at least most way to design apps for Apple products. “If you’re not using Auto Layout it’s something you need to get up to speed on very quickly,” he said.

Context Sensitivity

Today’s Apple users increasingly want smarter devices. That includes day modes and night modes for apps that adjust their brightness according to the time.

Users may also notice that more apps want to access the phone’s location data. That’s already becoming a bigger thing, but as iOS 8 makes it an easier feature for developers to include, it’ll become even more popular.

iOS 8’s new capabilities allow for context sensitivity in regard to motion, too. Since the latest Apple devices have sensors to detect altitude and movement, those sensors are now fair game for app development. New apps, or apps converted for iOS 8 could potentially deliver different displays to users who are walking than to those who are driving.

Extended Functionality

Apple didn’t just release 4,000 new APIs for developers. In iOS 8, it also made it easier to add API functionality to apps in general.

See also: How To Download And Install Apple’s iOS 8 Beta

APIs allow developers to add new functionality to their apps without reinventing the wheel. However, testing the new apps has been challenging so far because developers are only able to see how they’ll look using the new software, not hardware.

Now that Apple has finally released new phones, testing how APIs work on the latest phones running iOS 8 will be a little less frustrating.

Outside The Box

The Notification Center is going to play a much larger role with apps in iOS 8. More developers may want to take advantage of the ability to display new kinds of notifications from different apps.

Some developers are even referring to one kind of new notification, which Apple calls “Today Extensions,” as “widgets” since they bring some of an app’s functionality outside the app proper.

Zach Waldowski, a software developer at Big Nerd Ranch, demonstrated that adding extensions to app functionality is as simple as opening up Xcode, clicking “Application Extension” and adding it to your app.

Swift

No discussion of iOS 8 is complete without a mention of Apple’s new in-house development language, Swift.

Introduced at the World Wide Developer’s Conference, the language is designed to be simpler to use than Objective-C, while still being compatible with Objective-C. Apple hopes an easy-to-use language will encourage more developers to build on iOS 8.

See also: Apple’s Swift Language Goes Pro, Reaches Version 1.0

Swift just got upgraded to version 1.0, which means it’s officially out of beta. Apps that include some—or more—Swift coding are now allowed in the app store. That gives more developers an incentive to try it out for new apps right as the new devices are coming out.

Photo by Global Panorama

View full post on ReadWrite

New Facebook Tools Let Developers See What Users Are Doing In Their Apps

Facebook has a new plan for helping application developers monitor the success—or failure—of their applications. And that’s true whether they’re developing apps specifically to work with Facebook or not.

On Tuesday, the company introduced two new functions in App Insights, a tool that lets developers monitor traffic and Facebook interactions for apps. The new capabilities give app developers more detailed information about user behavior and app performance.

App Insights requires the Facebook software development kit (SDK), but works for general mobile apps as well as desktop apps that are integrated with Facebook.

Developers can now categorize groups of people by using “label cohorts” that group individuals into specific categories based on actions they’ve taken in a particular app. This information enables simple A/B testing, in which developers introduce a change for a subset of users to see how they react.

For instance, mobile game developers can provide one group of people with a digital gift and then track that cohort to see if it leads them to eventually spend more in the game.

Facebook offers four preset cohort types. These include “action-based,” for groups of people who done something specific, like clicking a button or making a purchase, and “time-based,” for users who all downloaded an app at the same time. Developers can create their own unique cohort types as well.

The second update provides specific, time-based data on how frequently people use an application and what kind of action they take after downloading it. This data is available up to 14 weeks after the person installs the app, and can be found in Facebook’s new App Event retention charts.

These charts monitor different “events,” like installing the application or making an in-app purchase. Developers can use this data to find out how fast users get to a specific level in the game, or how soon after downloading an application a user makes a purchase. 

To start using the new tools, developers should install the Facebook SDK.

Photo courtesy of Facebook

View full post on ReadWrite

Why Even “Simple” Technology Can Be Hard For Developers

Convenience drives much of the world’s best technology, from Amazon Web Services to Web frameworks like AngularJS. But that “convenience”, which makes it easy to quickly become productive, often comes with a hidden price tag: to become truly productive, you’re going to have to sweat.

Great technology is often deceptively simple, allowing newbies to intuitively “learn” the system without much effort. The problem comes when people assume they have mastered the technology when all they’ve really done is the equivalent of coding a “hello world” app. Before you blame the tool, you often need to invest time in learning to use it correctly.

“Mixed Feelings” About AngularJS

Let’s take AngularJS as an example. Angular is a Web application framework—a collection of JavaScript code libraries, templates and other software intended to make it easier for developers to build dynamic Web pages or Web apps.

See also: Angular, Ember, And Backbone: Which JavaScript Framework Is Right For You?

The problem, as Anand Mani Sankar suggests, is that while it’s simple to start with AngularJS, that simplicity belies the power of the framework:

[AngularJS] also simplifies the application development process by abstracting a lot of the internal complexity and exposing only what the application developer needs to know.

While this sounds like a great thing, it can also lead newbies to think that they’ve mastered the system upon completing their first “hello world” app:

The AngularJS journey can evoke mixed feelings. The learning curve is very different from other JS frameworks. The initial barrier to get started is very low. But once you start diving deep the learning curve suddenly becomes steep.

Sankar then points to Ben Nadel’s humorous depiction of an AngularJS journey:

Some people, of course, get stuck in the troughs. George Butiri, for example, gets a lot of Google search love with his “The reason Angular JS will fail” post. Butiri argues that AngularJS is actually quite difficult, without giving much in the way of specific examples of why this is so, at least beyond “because I like jQuery more.”

It’s So Easy To Fail 

Much of the best technology is like this. It’s deceptively simple to get started, but if you want to truly master it, you’re going to have to make a big investment of your time. Some people start strong, discover the complexity, and then complain that technology doesn’t remain mind-blowingly easy forever and ever.

Sorry, real technology doesn’t work that way. It always requires effort and will fail if not applied in the right way.

Take NoSQL databases, the world in which I spend most of my time.

See also: When NoSQL Databases Are—Yes—Good For You

Newbies to NoSQL, whether MongoDB, HBase or Cassandra, like to tout its schema-less nature. The old world of relational databases required a rigid schema but HURRAY! In this new world of NoSQL, gone are schemas that define your data’s structure, gone are DBAs, GONE ARE RULES! So easy!!

Which, of course, is complete nonsense. As my colleague Asya Kamsky likes to say, “NoSQL != NoDBA.” (That is, NoSQL is not the same as “no database administrator.”) 

NoSQL does not mean “no DBA”. If anyone tries to convince you otherwise, they probably have something to sell you.This does not mean that you have a team or even a person who has the title “DBA”—however, if you have a database, whether it’s relational, or non-relational, then someone has the role of “DBA”—and if they don’t know that they do, then a whole bunch of things aren’t being done or thought about before problems happen.

Go through the hater posts about NoSQL databases or AngularJS or most any technology you prefer and I guarantee many, if not most, of them are written by people who feel cheated that the technology didn’t fit how the user wanted it to work, often with minimal to no real investment. Sure, sometimes technology fails. At times, spectacularly.

But far too often we complain when technology doesn’t magically remove our need to work.

Fewer Levers, More Happiness?

One way to get the best of both worlds is through managed services like Amazon Web Services’ Redshift. Redshift is a fully-managed data warehouse that runs in the cloud. “Fully managed” means that it’s easier to use, but it also means that users lose some of the knobs and levers they might have in Teradata or another enterprise data warehouse.

That, however, is precisely the point.

As Matt Wood, general manager of data science at AWS, told me recently, Redshift and other AWS services aim to improve ease-of-use for users by removing complexity. Giving users fewer “levers” means that AWS also gives them fewer ways to fail. The trick, of course, is finding the balance between product simplicity and user control.

Airbnb, for example, was elated by how easy Redshift was to begin with, but then required some trade-offs (and investments):

The first challenge we had was schema migration. Even though Redshift is based on Postgres 8.0, the “subtle” differences are big enough, forcing you into the Redshift way of doing things. We tried to automate the schema migration, but the problem was bigger than we originally expected and we decided it was beyond the scope of our experiment. Indexes, timestamp type, and arrays are not supported in Redshift, thus you need to either get rid of them in your schema or find a workaround.

Having put in the effort, however, Airbnb saw a minimum of 5x performance improvements over other systems and dramatic cost savings. Easy to get started, but also worth continuing to invest.

And so it is with a lot of great software that is deceptively simple to use. To get beyond newbie status with any great technology, you’re going to have to use it as intended, and you’re going to have to spend the time and effort to master it. 

There may be free software, but there’s no free lunch.

Lead image courtesy of Shutterstock; AngularJS graph by Ben Nadel

View full post on ReadWrite

Google Allows Developers Integrate With Search Within Site Feature

Google announced a few changes to the search box you find within the Google search results. Often, when you search for a brand name, Google will add a search box within the search snippet result for that site. That box allows you to search within that specific site only. The results are similar to…



Please visit Search Engine Land for the full article.

View full post on Search Engine Land: News & Info About SEO, PPC, SEM, Search Engines & Search Marketing

The Secret To Hiring Great Developers Is Hiding In Plain Sight

Everyone wants to hire more engineers, including you, driving software salaries through the roof. Unfortunately, it’s very likely that you don’t have the slightest clue how to recruit well.

Take heart. While your ability to spot real talent in an interview may be weak, open source makes it relatively easy to see who can actually code, and who simply knows how to answer useless, abstruse questions. 

Engineering Success

Finding great technical talent is important. In fact, in a world increasingly run by developers, I’d argue that it’s the most important thing any company does, whether it’s a technology vendor or a manufacturer of cars or clothes. The better the engineering, the better the product, and the better the product, the less reliant your company needs to be on sales and marketing, at least, early on. 

Or, as venture capitalist Fred Wilson puts it, “Marketing is for companies who have sucky products.”

The problem, of course, is that everyone is scouring the planet for the same engineers. Which, in turn, has driven the cost of developer salaries way up:

Chart by CNBC

There are all sorts of gimmicks to finding great engineers. Google, for example, used to impose complex brainteasers on job applicants—only to discover they were utterly useless, as Laszlo Bock, senior vice president of people operations at Google, said:

We found that brainteasers are a complete waste of time. They don’t predict anything. They serve primarily to make the interviewer feel smart.

Brainteasers, then, are out.

But, as Bock went on to highlight, so are brand-name schools, test scores and grades. “Worthless,” he declares. In fact, the whole hiring process is a “complete random mess.”

So how can you fix this?

Changing The Interview Process

One way is to change the way you interview. As Laurie Voss, the CTO of NPM, recently argued, “You are bad at giving technical interviews…. You’re looking for the wrong skills, hiring the wrong people, and actively screwing yourself and your company.”

Sadly, she’s probably right. And not just about you. We’re all pretty bad at technical interviews (or interviews, generally, for that matter). 

The gist of her post is that too often we “over-valu[e] present skills and under-valu[e] future growth,” hiring people based on what they’ve done (or went to school) rather than what they can do. Or, as she summarizes:

1) Many interview techniques test skills that are at best irrelevant to real working life; 2) you want somebody who knows enough to do the job right now; 3) or somebody smart and motivated enough that they can learn the job quickly; 4) you want somebody who keeps getting better at what they do; 5) your interview should be a collaborative conversation, not a combative interrogation; 6) you also want somebody who you will enjoy working with; 7) it’s important to separate “enjoy working with” from “enjoy hanging out with;” 8) don’t hire [jerks], no matter how good they are; 9) if your team isn’t diverse, your team is worse than it needed to be; and 10) accept that hiring takes a really long time and is really, really hard.

Bock echoes this, indicating that Google’s experience has been that behavioral interviews work best. Rather than asking a candidate to remember some obscure computer science fact, Google now starts with a question like:

“Give me an example of a time when you solved an analytically difficult problem.” The interesting thing about the behavioral interview is that when you ask somebody to speak to their own experience, and you drill into that, you get two kinds of information. One is you get to see how they actually interacted in a real-world situation, and the valuable “meta” information you get about the candidate is a sense of what they consider to be difficult.

This is a great approach, but there’s a way to take it one step further.

Open Source Your Interview

The best place to see how engineers solve problems in the real world is in the open-source projects to which they contribute. Open-source communities offer a clear view into an engineer’s interactions with others, the quality of her code and a history of how she tackles hard problems, both individually and in groups.

No guesswork. No leap of faith. Her work history is all there on GitHub and message boards.

But open source offers other benefits, too. As Netflix’s former head of cloud operations, Adrian Cockroft, once detailed, open source helps to position Netflix as a technology leader and to “hire, retain and engage top engineers.” How? Well, the best engineers often want to work on open source. Providing that “perk” is essential to hiring great technical talent. 

Interviews are important to ascertain cultural fit, among other things, but they shouldn’t be a substitute for the more informative work of analyzing a developer’s open source work. 

And if they have none, well, that tells you something, too. A colleague at a former company told me that the best engineers were all on GitHub, not LinkedIn. While perhaps an overstatement, there’s a fair amount of truth to it, too. 

In sum, you should be able to get to know your next engineering hire through open-source development far better than through any interview process, no matter how detailed. 

Photo via Shutterstock

View full post on ReadWrite

StackOverflow Readers Are Not Your Average Web Developers

We knew StackOverflow was different. Turns out it’s, well, really different.

The technical Q&A site looks like your standard Web developer hangout. But according to new data from IEEE Spectrum, its community has some unusual technical tastes. For instance, its readers evince a serious interest in the niche-y area of embedded hardware development—that is, programmable systems that typically live inside other gadgets and don’t expose a user interface to the average person.

On the other hand, this data doesn’t necessarily mean researchers have uncovered unexpected pockets of embedded or enterprise popularity, Maybe StackOverflow’s community preferences is simply telling us how poorly documented these technologies are—and how the right online forum can self-organize to meet the needs of developers who have to work with them.

Correlating Online Technical Communities

In response to IEEE Spectrum’s new programming language popularity analysis tool, Redmonk analyst Donnie Berkholz set out to try to uncover “commonalities and communities across all of [different] sources” so as to glean “insight into what technologies developers care about and use, and which provide mainly reinforcement of others.”

So, when comparing the popularity of programming languages as measured by jobs vs. which ones get discussed on social media and open-source code hubs, the top-10 programming languages look like this:

Source: IEEE Spectrum

Some correlations he found make intuitive sense.

For example, there is an exceptionally strong correlation between Twitter conversation and Google trends. As he puts it, “people talking about programming languages in real-time chat tend to also search for what they’re talking about.”

Berkholz also uncovered very strong correlations (above 0.85) between Google Trends and search; programming language interest across different job sites like Dice and CareerBuilder; Reddit and Google Trends (developers look for information about current topics on different sites); and GitHub created and StackOverflow questions (a correlation of open-source usage and broader conversation among forward-leaning communities). 

Others correlate more weakly between sources—like HackerNews with most everything else.

But StackOverflow stands out.

StackOverflow Developers: A Breed Apart?

In fact, StackOverflow developers stand alone. Completely alone, it would seem from Berkholz’s analysis. As he notes:

The weakest correlations were between StackOverflow views and almost everything else. It’s shocking how different the visitors to StackOverflow seem from every other data source.

Here are the top-10 programming languages on StackOverflow in terms of what readers actually read:

Source: IEEE Spectrum

These results differ markedly from all other sources. As Berkholz highlights:

Three of the top 5 are hardware (Arduino, VHDL, Verilog), supporting a strong audience of embedded developers. Outside of StackOverflow views, these languages are nonexistent in the top 10 with only two exceptions: Arduino is #7 on Reddit and VHDL is #8 in IEEE Xplor. That paints a very clear contrast between this group and everyone else, and perhaps a unique source of data about trends in embedded development. Enterprise stalwarts are also commonplace, such as Visual Basic, Cobol, Apex (Salesforce.com’s language), and ABAP (SAP’s language).

This could suggest that StackOverflow is a leading indicator of hot new technologies. For example, the hardware bent to its audience might point to rising interest in the Internet of Things, which is going to be built on top of a whole lot of, well, embedded hardware systems.

Or, frankly, it could just mean that StackOverflow does a particularly good job of providing a home to smaller communities of embedded and enterprise developers that can’t get good documentation from Salesforce.com. 

I mean, really, who wants to hang out in IBM’s Cobol Café?

But Who Are These People?

While we don’t have data from 2013 or 2014, in December 2011 someone took a survey of 2,532 StackOverflow users. A significant chunk of StackOverflow users come from the U.S., with the largest percentage (12%) in California and the second largest (8.4%) in New York, with a majority (53%) aged 25-34 and 68% having at least 6 years of IT/programming experience.

Not particularly surprising.

What is surprising, given the IEEE Spectrum data, is that a whopping 40% describe themselves as web application developers while only 4.3% are embedded application developers. Most are building enterprise applications (32%) or web platforms (33%), but the languages they indicate they know differ from the languages they view on StackOverflow:

Source: StackOverflow Annual Survey, 2011.

This jibes with the enterprise developer finding in the IEEE Spectrum data. It’s still hard to see the embedded hardware developer in these numbers—though not so hard to uncover the enterprise developer.

This becomes more pronounced if we only look at StackOverflow users who answer questions (and not necessarily those that read the answers):

Source: IEEE Spectrum

In short, there’s a difference between those that answer questions and those that merely lurk. For example, the top 20 most active StackOverflow participants have little to do with embedded engineering, as this data visualization shows. (Click through to see what each works on.)

StackOverflow Is Unique

So while StackOverflow has its share of mainstream Java and JavaScript folks answering questions, what many people really find useful are its sub-communities for embedded programming and enterprise development that aren’t really replicated anywhere else, as Berkholz posits. 

Such technologies don’t have great documentation within their home communities (e.g., Salesforce.com’s Apex language), but StackOverflow has become the go-to home-away-from-home community for these embedded and enterprise technologies.

There are far more questions tagged “Java” (625,000+), for example, than for Arduino (12,000+), but according to the IEEE Spectrum data there’s way more reader interest in the latter than the former. The IEEE Spectrum approach measures both the number of questions posted mentioning each language in 2013 and the amount of attention paid to those questions. In StackOverflow’s world, people pay far more interest to embedded and enterprise than general Web development, even though its user base has historically skewed web developer.

A different breed, indeed. Or, quite possibly, an indication of mainstream enterprise and web developers looking beyond “mainstream” to tap into the Internet of Things applications or other modern applications?

Lead image by Flickr user Alexandre Dulaunoy, CC 2.0

View full post on ReadWrite

Maybe Asia-Pacific Developers Will Deliver The Internet Of Things

Demand, meet supply. The world is in dire need of millions of Internet of Things developers within the next few years. The good news? According to a new Evans Data survey, 17% the world’s software developers are already working on IoT applications; those in the Asia-Pacific region are particularly active.

See also: The Internet Of Things Will Need Millions Of Developers By 2020

The bad news? This developer population doesn’t have a strong history of software and cloud services innovation.

Asia-Pacific: A Hotbed Of Activity

To reprise: Evans Data’s recent global survey of over 1,400 software developers found that 17% are working on applications for connected devices for IoT, while an additional 23% expect to begin work on them in the next 6 months. Given that so much of the world’s electronics are produced in Asia-Pacific, it’s perhaps not surprising that it’s the region with the most aggressive IoT developers. 

In fact, nearly 23% of APAC developers are currently developing software for Internet of Things. Only 20% of APAC developers say that they have no such plans, compared to 36% in North America and 49% in EMEA. 

But the real question for APAC developers is whether they’ll repeat their errors of the past few decades: building great hardware and neglecting to connect that hardware with software and services. Sensors, it turns out, are somewhat pointless.

More Devices, More Connected

The number of ‘things’—30 billion devices connected to the Internet by 2020, according to Gartner, compared to 7.3 billion personal devices—is impressive but not the real story. Soon enough, as Gartner suggests, these devices “will … be able to procure services such as maintenance, cleaning, repair, and even replacement on their own.” They will be able to interact without human intervention, creating all sorts of possibilities, not to mention security vulnerabilities.

Developers are making this happen, developers that believe in and are helping to shape a connected future:

Due to the convergence of cloud, embedded systems, real-time event processing and even cognitive computing, developers are blessed with a perfect storm of low-cost devices and the ability to intelligently connect them. That in turn will yield revenue-generating services, which is where the real IoT money is.

Opening Up The Internet Of Things In APAC

While 31% of developers associate the Internet of Things with cloud computing, according to the Evans Data survey, the connections that bring device data to the cloud are much more important. As Intel Internet of Things business leader Ton Steenman complains, companies currently spend 90% of their IoT budgets “stitching things together,” when that number should be closer to 10%.

APAC hasn’t traditionally been good at such “stitching.”

That stitching is hard both because developers haven’t trusted third-party networks to carry their device data, but also because connectivity hasn’t been built into devices and sensors at the pace needed, as data from Berg Insight suggests:

• Wireless connectivity has been incorporated into just 1/3 of point-of-sales terminals sold in 2013

• 27% of ATMs in North America are connected to cellular networks while only 5% to 10% are connected in Europe

• The number of “oil and gas” devices with cellular connectivity hovered at 93,000 in 2013 but will jump to 263,000 new units by 2018

There are signs that this is changing, particularly in APAC, which was an early pioneer in mobile communications. Just looking at the prevalence of connected smart electricity meters, APAC has the lead, despite lagging considerably in 2011.

Companies in APAC have struggled to build compelling software (e.g., Sony smartphone interfaces) or cloud services (e.g., Samsung cloud sync and back-up services). While this is changing, it’s an open question whether APAC will be able to take the lead in developing connected experiences across devices.

One place to start is by opening up APIs.

As Rob Wyatt argues, “It is the open, local API that is missing from the Internet of Things.” To make the it work anywhere, and particularly in Asia-Pacific, it’s not enough for “vendors … to provide dumb ‘smart’ devices with a select handful of ‘strategic’ integrations within their pay-walled garden.”

For Internet of Things applications to work, device vendors need to provide open APIs so that other developers can hack services around and into them. 

If APAC developers do this, they’ll win the war. Again, the battle won’t be won by building nice devices. It will be won by creating compelling developer cloud-services experiences that span a wide array of devices—all of which can start with open APIs on those devices so that developers, both within APAC and outside it, can hack the future.

Lead image by Flickr user Ed Coyle, CC 2.0

View full post on ReadWrite

Go to Top
Copyright © 1992-2014, DC2NET All rights reserved