Many individuals are looking to break into a video game designing career, and it's no surprise. A $9 billion industry, the video game designing business has appeal to gamers and non-gamers alike. High salaries and high rates of job satisfaction are typical in the field.

In order to design video games, however, you need a certain skill set. Computer programming is first on the list. While games are made using almost all languages, the most popular programming language for video games is C++, because of its object-oriented nature and because it compiles to binary. The next most popular languages for games are C and Java, but others such as C# and assembly language are also used. A strong background in math is usually required to learn these languages. Individuals wishing to design games should also have an extensive knowledge of both PCs and Macs.

There are many colleges and universities that offer classes not only in programming but also classes specifically on game design. Some of these schools have alliances with game developing companies, leading to jobs for students upon graduation. Programming video games can be lucrative. The average game designer's salary is $62,500, with $55,000 at the low end and $85,000 at the high end.

Programmers are not the only individuals needed to make a video game, however. There are multiple career paths within the gaming industry, including specialists in audio, design, production, visual arts and business.

Designing a video game can be an long, expensive process. The average budget for a modern multiplatform video game is $18-$28 million, with some high-profile games costing as much as $40 million. Making the game, from conception to sale, can take several months to several years. Some games have taken a notoriously long time to make; for example, 3D Realms' Duke Nukem Forever was announced in April 1997 and did not make it to shelves until July 2011.

Video game programmers have a high level of job satisfaction. In a March 2013 survey conducted by Game Developer magazine, 29 percent of game programmers were very satisfied with their jobs, and 39 percent were somewhat satisfied.

If you're interested in a game development career, now's the time to get moving. Take advantage of the many online resources available regarding these careers and start learning right away.

Let’s face it, fad or not, companies are starting to ask themselves how they could possibly use machine learning and AI technologies in their organization. Many are being lured by the promise of profits by discovering winning patterns with algorithms that will enable solid predictions… The reality is that most technology and business professionals do not have sufficient understanding of how machine learning works and where it can be applied.  For a lot of firms, the focus still tends to be on small-scale changes instead of focusing on what really matters…tackling their approach to machine learning.

In the recent Wall Street Journal article, Machine Learning at Scale Remains Elusive for Many Firms, Steven Norton captures interesting comments from the industry’s data science experts. In the article, he quotes panelists from the MIT Digital Economy Conference in NYC, on businesses current practices with AI and machine learning. All agree on the fact that, for all the talk of Machine Learning and AI’s potential in the enterprise, many firms aren’t yet equipped to take advantage of it fully.

Panelist,  Michael Chui, partner at McKinsey Global Institute states that “If a company just mechanically says OK, I’ll automate this little activity here and this little activity there, rather than re-thinking the entire process and how it can be enabled by technology, they usually get very little value out of it. “Few companies have deployed these technologies in a core business process or at scale.”

Panelist, Hilary Mason, general manager at Cloudera Inc., had this to say, “With very few exceptions, every company we work with wants to start with a cost-savings application of automation.” “Most organizations are not set up to do this well.”

It is said that spoken languages shape thoughts by their inclusion and exclusion of concepts, and by structuring them in different ways. Similarly, programming languages shape solutions by making some tasks easier and others less aesthetic. Using F# instead of C# reshapes software projects in ways that prefer certain development styles and outcomes, changing what is possible and how it is achieved.

F# is a functional language from Microsoft's research division. While once relegated to the land of impractical academia, the principles espoused by functional programming are beginning to garner mainstream appeal.

As its name implies, functions are first-class citizens in functional programming. Blocks of code can be stored in variables, passed to other functions, and infinitely composed into higher-order functions, encouraging cleaner abstractions and easier testing. While it has long been possible to store and pass code, F#'s clean syntax for higher-order functions encourages them as a solution to any problem seeking an abstraction.

F# also encourages immutability. Instead of maintaining state in variables, functional programming with F# models programs as a series of functions converting inputs to outputs. While this introduces complications for those used to imperative styles, the benefits of immutability mesh well with many current developments best practices.

For instance, if functions are pure, handling only immutable data and exhibiting no side effects, then testing is vastly simplified. It is very easy to test that a specific block of code always returns the same value given the same inputs, and by modeling code as a series of immutable functions, it becomes possible to gain a deep and highly precise set of guarantees that software will behave exactly as written.

Further, if execution flow is exclusively a matter of routing function inputs to outputs, then concurrency is vastly simplified. By shifting away from mutable state to immutable functions, the need for locks and semaphores is vastly reduced if not entirely eliminated, and multi-processor development is almost effortless in many cases.

Type inference is another powerful feature of many functional languages. It is often unnecessary to specify argument and return types, since any modern compiler can infer them automatically. F# brings this feature to most areas of the language, making F# feel less like a statically-typed language and more like Ruby or Python. F# also eliminates noise like braces, explicit returns, and other bits of ceremony that make languages feel cumbersome.

Functional programming with F# makes it possible to write concise, easily testable code that is simpler to parallelize and reason about. However, strict functional styles often require imperative developers to learn new ways of thinking that are not as intuitive. Fortunately, F# makes it possible to incrementally change habits over time. Thanks to its hybrid object-oriented and functional nature, and its clean interoperability with the .net platform, F# developers can gradually shift to a more functional mindset while still using the algorithms and libraries with which they are most familiar.

Related F# Resources:

F# Programming Essentials Training

Millions of people experienced the frustration and failures of the Obamacare website when it first launched. Because the code for the back end is not open source, the exact technicalities of the initial failings are tricky to determine. Many curious programmers and web designers have had time to examine the open source coding on the front end, however, leading to reasonable conclusions about the nature of the overall difficulties.

Lack of End to End Collaboration
The website was developed with multiple contractors for the front-end and back-end functions. The site also needed to be integrated with insurance companies, IRS servers, Homeland Security servers, and the Department of Veterans Affairs, all of whom had their own legacy systems. The large number of parties involved and the complex nature of the various components naturally complicated the testing and integration of each portion of the project.

The errors displayed, and occasionally the lack thereof, indicated an absence of coordination between the parties developing the separate components. A failed sign up attempt, for instance, often resulted in a page that displayed the header but had no content or failure message. A look at end user requests revealed that the database was unavailable. Clearly, the coding for the front end did not include errors for failures on the back end.

Bloat and the Abundance of Minor Issues
Obviously, numerous bugs were also an issue. The system required users to create passwords that included numbers, for example, but failed to disclose that on the form and in subsequent failure messages, leaving users baffled. In another issue, one of the pages intended to ask users to please wait or call instead, but the message and the phone information were accidentally commented out in the code.

While the front-end design has been cleared of blame for the most serious failures, bloat in the code did contribute to the early difficulties users experienced. The site design was heavy with Javascript and CSS files, and it was peppered with small coding errors that became particularly troublesome when users faced bottlenecks in traffic. Frequent typos throughout the code proved to be an additional embarrassment and were another indication of a troubled development process.

NoSQL Database
The NoSQL database is intended to allow for scalability and flexibility in the architecture of projects that will use it. This made NoSQL a logical choice for the health insurance exchange website. The newness of the technology, however, means personnel with expertise can be elusive. Database-related missteps were more likely the result of a lack of experienced administrators than with the technology itself. The choice of the NoSQL database was thus another complication in the development, but did not itself cause the failures.

Another factor of consequence is that the website was built with both agile and waterfall methodology elements. With agile methods for the front end and the waterfall methodology for the back end, streamlining was naturally going to suffer further difficulties. The disparate contractors, varied methods of software development, and an unrealistically short project time line all contributed to the coding failures of the website.