Software engineer and author Jason Myers on changing roles in a changing market.
We often hear about how the tech job market is booming and has space for newcomers, but what does that mean for the developers already in the market? In December of 2014, Fortune.com predicted that 2015 would be an excellent year for developers to change jobs. Citing Dice.com, they note that jobs are popping up all over the country. In fact, Dice’s survey also reports 40% of hiring managers seeing voluntary departures, a higher number than was seen just six months earlier.
These are all large, general numbers. What does a job change, and the changing market, look like for individual developers? To get a better sense, I spoke with Jason Myers, who is working on our upcoming Essential SQLAlchemy, 2e title. Jason recently went from working for the email marketing service Emma, Inc., to working for networking giant Cisco. Here, he talks about how a change like that feels, and how the market looks to him.
How Scala will help you grow as a Java developer.
With Scala Days nearly upon us, the Fort Mason Center in San Francisco will be awash with developers excited to share ideas and explore the latest use-cases in this “best of both worlds” language. Scala has come a long way from its humble origins at the École Polytechnique Fédérale de Lausanne, but with the fusion of functional and object-oriented programming continuing to pick up steam across leading-edge enterprises and start-ups, there’s no better time than right now to stop dabbling with code snippets and begin mastering the basics. Here are three simple reasons why learning Scala will help you grow as a Java developer, as excerpted from Jason Swartz’s new book Learning Scala.
1. Your code will be better
You will be able to start using functional programming techniques to stabilize your applications and reduce issues that arise from unintended side effects. By switching from mutable data structures to immutable data structures and from regular methods to pure functions that have no effect on their environment, your code will be safer, more stable, and much easier to comprehend.
The tradeoffs of (accidentally) discarding continuous integration.
I’ve given a continuous delivery workshop a few times with ThoughtWorks Chief Scientist Martin Fowler, who tells an interesting story about continuous integration, from the first software project he ever saw. When Martin was a teenager, his father had a friend who was running a software project, and he gave Martin the nickel (or five pence) tour — a bunch of men, predominately on mainframe terminals, working in an old warehouse. Martin remarked that the thing that struck him the most was when the guide told him that all the developers were “currently integrating all their code.” They had finished coding six months prior, yet despite that they weren’t sure when they were going to be done “integrating.”
That revelation surprised Martin: in his mind, software development was a discreet, scientific, deterministic process, not at all represented by the vague comments of these developers. But the practice of as-late-as-possible integration was common back in an earlier era of software development. If you look at software engineering texts of the ’60s and ’70s, every project included an integration phase. This isn’t how we think of integration today, which happens at the granularity of services and applications. Rather, a common practice was to have developers code in isolation for weeks and months at a time, then integrate all their code together into a cohesive whole. And that phase was, not surprisingly, a painful part of most projects. Yet, that type of 60s and 70s workflow is still codified in some version control tools today, even though we have now determined that late integration is the opposite of how we should approach this problem.
Migrating to cloud-native application architectures leads to innovation.
Editor’s note: this is an advance excerpt from Chapter 1 of the forthcoming Migrating to Cloud-Native Application Architectures by Matt Stine. This report examines how the cloud enables innovation and the changes an enterprise must consider when adopting cloud-native application architectures.
Let’s examine the common motivations behind moving to cloud-native application architectures.
It’s become clear that speed wins in the marketplace. Businesses that are able to innovate, experiment, and deliver software-based solutions quickly are outcompeting those that follow more traditional delivery models.
In the enterprise, the time it takes to provision new application environments and deploy new versions of software is typically measured in days, weeks, or months. This lack of speed severely limits the risk that can be taken on by any one release, because the cost of making and fixing a mistake is also measured on that same timescale.
Internet companies are often cited for their practice of deploying hundreds of times per day. Why are frequent deployments important? If you can deploy hundreds of times per day, you can recover from mistakes almost instantly. If you can recover from mistakes almost instantly, you can take on more risk. If you can take on more risk, you can try wild experiments—the results might turn into your next competitive advantage.
The elasticity and self-service nature of cloud-based infrastructure naturally lends itself to this way of working. Provisioning a new application environment by making a call to a cloud service API is faster than a form-based manual process by several orders of magnitude. Deploying code to that new environment via another API call adds more speed. Adding self-service and hooks to teams’ continuous integration/build server environments adds even more speed. Eventually we can measure the answer to Lean guru Mary Poppendick’s question, “How long would it take your organization to deploy a change that involves just one single line of code?” in minutes or seconds.
Imagine what your team… what your business… could do if you were able to move that fast!
A brief introduction to Swift optionals.
Swift is becoming the language of choice for more and more developers on iOS and OS X. It’s fast, simple, clean, and has a number of features that simply aren’t available to Objective-C programmers.
While it isn’t a hard requirement to do so, several projects are being ported from Objective-C to Swift — especially those in their early stages — in order to take advantage of the speed, power, and safety of Swift. One of those projects isn’t actually a software project — it’s the upcoming Swift edition of iOS Games Programming Cookbook. When we began updating the book for Swift, the first thing that we had to do was to rewrite all of the book’s code in the new language. However, a straight re-write from one language into another isn’t enough. Swift behaves differently than Objective-C in very important ways, and that means that your ported Swift code needs to be aware of how Swift does things.