- The Great Reversal in the Demand for Skill and Cognitive Tasks (PDF) — The only difference with more conventional models of skill-biased technological change is our modelling of the fruits of cognitive employment as creating a stock instead of a pure flow. This slight change causes technological change to generate a boom and bust cycle, as is common in most investment models. We also incorporated into this model a standard selection process whereby individuals sort into occupations based on their comparative advantage. The selection process is the key mechanism that explains why a reduction in the demand for cognitive tasks, which are predominantly filled by higher educated workers, can result in a loss of employment concentrated among lower educated workers. While we do not claim that our model is the only structure that can explain the observations we present, we believe it gives a very simple and intuitive explanation to the changes pre- and post-2000.
- provinces — state and province lists for (some) countries.
- Cultural Analytics — the use of computational and visualization methods for the analysis of massive cultural data sets and flows. Interesting visualisations as well as automated understandings.
- The Code is Just the Symptom — The engineering culture was a three-layer cake of dysfunction, where everyone down the chain had to execute what they knew to be an impossible task, at impossible speeds, perfectly. It was like the games of Simon Says and Telephone combined to bad effect. Most engineers will have flashbacks at these descriptions. Trigger warning: candid descriptions of real immature software organisations.
Tim O’Reilly’s Solid Conference keynote highlights the capabilities that will let us shape the physical world.
O’Reilly’s keynote address at the Solid Conference in 2014 explored the human-IoT link. The talk expanded the scope of the IoT, making it clear this isn’t just about individual devices and software — we’re creating “networks of intelligence” that will shape how people work and live.
The talk has become an essential resource for us as we’ve investigated the blurring of the physical and virtual worlds. That’s why we decided to put together a text-friendly version of the presentation that’s easy to scan and reference. And since we think it’s so useful, we’ve made the text version publicly available.
You can download your free copy of “Software Above the Level of a Single Device: The Implications” here. Read more…
A closer look at the forces causing demand
Buzzwords in the software industry arise and then die off with startling frequency. Ambiguous terms such as “growth hacker”, “sales engineer” and “rockstar developer” trip a developer’s spidey sense that the person saying them is just handwaving. However, occasionally a new term is created to articulate a programming skill set based on demand due to changes in the software development industry.
In 2013 the search term “full stack developer” took off on Google Trends and began appearing in numerous tech startup job postings. In this term’s case there are several real trends driving developers to invest in learning and identifying as full stack developers.
The usage of the full stack developer term is driven by several larger trends in software development. Read more…
Software and hardware are moving together, and the combined result is a new medium.
An updated version of this essay was published in December 2014.
The result is an entirely new medium that’s just beginning to emerge. We can see it in Ars Electronica Futurelab’s Spaxels, which use drones to render a three-dimensional pixel field; in Baxter, which layers emotive software onto an industrial robot so that anyone can operate it safely and efficiently; in OpenXC, which gives even hobbyist-level programmers access to the software in their cars; in SmartThings, which ties Web services to light switches.
The new medium is something broader than terms like “Internet of Things,” “Industrial Internet,” or “connected devices” suggest. It’s an entirely new discipline that’s being built by software developers, roboticists, manufacturers, hardware engineers, artists, and designers. Read more…
Business analytics projects: Using decisions as a basis to prioritize and identify requirements
Most normal people don’t look at data sets just for fun. They study views of the data to make decisions about what to do, be it a decision to take some specific action or a decision to do nothing at all. The main purpose of business analytics projects is to develop systems that turn large and often highly complex data sets into meaningful information from which decisions can be made.
The decisions that people make using business analytics systems can be strategic, operational, or tactical. For example, an executive might look at his sales team’s global performance dashboard to decide who to promote (tactical), which products need different marketing strategies (operational), or which products to target by markets (strategic). Generally speaking, all software systems that include an analytics component should enable users to make decisions that improve organizational performance in some dimension.
The App Store model has increased the uncertainty of the software release process
The recent unavailability of the Apple Developer’s Portal just underscores how increasingly dependent developers have become on third parties during the software lifecycle. For those who are not following the fun and games, the developer.apple.com sites, which include much of the functionality needed to develop Mac and iOS applications, has been unavailable for more than a week as of this writing. Although iTunes Connect, the portal used to actually deploy apps to the App Stores, has remained available, the remainder of the site territory has been off-limits. This is all thanks to a security intrusion (evidently by an over-zealous researcher.)
The App Store model has fundamentally changed how software is distributed, mostly for the better (IMHO), but it has also removed some of the control of the release process from the hands of the developers and companies they work for. As I have spelled out previously in my book on iOS enterprise development, the fact that Apple has the final say on if and when software goes into the store has required more conservative release timelines. If you want to release on the first of September, you need to count back at least two weeks for “gold master”, because you need to upload the app, potentially go through a round of rejection from Apple, and then upload a fixed version.
Android apps don’t suffer from this lag, because most of the Android stores don’t do any significant checking of the applications uploaded to them. The Devil’s Deal that Apple developers have made with Apple is that in return for the longer wait time to get apps in the store (and having to follow Apple’s rules), they get a de facto seal of approval from Apple. In other words, it is assumed that apps in the iTunes store are more stringently policed and less likely to crash or do harm (deliberately or else-wise.)
The current downtime has brought that deal into question, however. Suddenly, developers who need new provisioning certificates, passbook certificates, or push notification certificates find themselves with nowhere to go. Even if iTunes Connect is available, it doesn’t do you any good if you can’t get a distribution certificate to sign your app for the store. I’m sure that there are developers at this moment who have had their finely tuned release strategies thrown into disarray by the in-availability of the developer portal.
Being essentially at the mercy of Apple’s whims (or Google’s, for that matter) can’t be a pleasant sensation for a company or individual trying to get a new piece of software out the door. The question that the developer community will have to answer is if the benefits of the App Store model make it worth the hassles, in the long run.
Passion isn't just for romance novels.
Graduates, parents, guests, members of the faculty of
<%= college.collegeName %>. I am honored today to have the opportunity to speak with you, as you move out of the cloistered environment of higher education, and into “the real world.” Except for those of you moving on to postgraduate degrees, of course. You will get to enjoy a life uncluttered by 401Ks and team building exercises for a few more blessed years.
But, for the rest of you, today marks your first step into a journey that will last the rest of your life, unless you’re able to cash in on your equity in some startup, in which case I’m sure you’ll be hearing from the
<%= college.collegeName %> alumni office before the check settles from your brokerage.
In my 35 years of experience in the software field, I’ve met a lot of developers, young and old. And the one thing that separated the truly successful ones from the crowd is passion. Now passion is an overused and abused term these days. Too often people take it to mean a passion for being successful, for achieving a personal goal in their life. When I talk about passion, I mean love. I’ve been in love with computers since I was 14 years old, and I’d be playing with them even if I didn’t get paid for it. If software engineering is merely a means to an end, you’re not going to be happy in the long term working in this field, because much of it is God-awful boring unless you have a passion for it.
Being passionate about software is critical to being successful, because the field is a constantly moving target. What will net you $130K today will be done by junior programmers in five years, and unless you’re constantly adding new tools to your belt, you’re going to find yourself priced out of the market. Many of the best projects I’ve ever worked on came to me because I had already gained the skill-set on my own. Play around with new technologies, contribute to open source projects, and you may find yourself with an opportunity to apply those skills on the job, and get them into your resume. You are rarely going to get an opportunity to have your current employer pay for you to learn things, so learn them on your own and be in a position to leverage the skills when a new project comes along. But if you have a passion for technology, you’ll already be doing it, and enjoying it without needing me to tell you to. That’s why passionate people have a leg up.
People in their 20s tend to jump into small, fledgeling companies, and that’s one of the best things you can do. A junior developer at Fidelity or Akamai is going to work on one thing for long periods of time, while at a start-up you’ll get a chance to jump all over the place, learning many different aspects of the field. But don’t fall into the trap of trading long hours and happiness for the gold ring of equity. You are never going to be in better shape, less constrained by responsibilities, or have more energy than you will right now. Burning 80-hour weeks grinding code is a terrible waste of that gift. Most companies crash and burn, and that equity they gave you will be just toilet paper. It won’t pay for the time you sacrificed eating take-out pizza in front of a glowing tube rather than enjoying the best years of your life.
If you’re passionate, you’ll do the job you’re required to do, and more, but don’t let your employer abuse your enthusiasm. One of my tenets of life has always been that “a lack of planning on your part does not constitute an emergency on my part.” There will be times in your life when you have to step in and fix genuine, unforeseen emergencies, and burn the midnight oil. But if you’re being asked to do it regularly, just because your company didn’t allocate enough resources to see the job through, you’re being played for a patsy.
Consider the benefits of loyalty to your employer. More than just about any other industry, software suffers from a nomadic workforce, where spending five years at a single company is rare. Remember that in a good work environment, you make friends as well as money, and as much as you may say you will, you never keep in touch with them when you move on. But don’t be afraid to jump ship if you are truly unhappy where you are, either.
Software is adding more and more value to machines. Could it completely commoditize them?
I’m a sucker for a good plant tour, and I had a really good one last week when Jim Stogdill and I visited K. Venkatesh Prasad at Ford Motor in Dearborn, Mich. I gave a seminar and we talked at length about Ford’s OpenXC program and its approach to building software platforms.
The highlight of the visit was seeing the scale of Ford’s operation, and particularly the scale of its research and development organization. Prasad’s building is a half-mile into Ford’s vast research and engineering campus. It’s an endless grid of wet labs like you’d see at a university: test tubes and robots all over the place; separate labs for adhesives, textiles, vibration dampening; machines for evaluating what’s in reach for different-sized people.
Prasad explained that much of the R&D that goes into a car is conducted at suppliers–Ford might ask its steel supplier to come up with a lighter, stronger alloy, for instance–but Ford is responsible for integrative research: figuring out how to, say, bond its foam insulation onto that new alloy.
In our more fevered moments, we on the software side of things tend to foresee every problem being reduced to a generic software problem, solvable with brute-force computing and standard machinery. In that interpretation, a theoretical Google car operating system–one that would drive the car and provide Web-based services to passengers–could commoditize the mechanical aspects of the automobile. Read more…