README

Hello. My name is Aaron Westre. I’m a computer programmer. My primary medium of expression is software. I help organizations build software to meet their goals. I also help teams practice building better software together. I even create art using software and help other artists to do the same.

Programmers have a ritual in which they name the first piece of information that initiates a new project “README”. It usually explains the purpose of the project and describes how to get started. Consider this page a README for me. You’ll find information on working with me, collaborating with me, and how to decide whether doing those things would be benficial to you.

Should I hire Aaron to build software for me?

It depends. I know, I know, nobody likes that answer, but it’s true. The sections below describe some of the aspects that are important to evaluate when hiring any programmer. I’ve taken care to highlight both the potential benefits and costs of working with me, so you can make an informed decision.

What types of software does Aaron build?

I have built a wide variety of software, from web applications to virtual reality experiences. In recent years I have focused on building native, cross-platform, graphically intensive applications:

  • Native means software built to run directly on a device, as opposed to on the web. Think apps for your phone or laptop.
  • Cross-platform means software that runs on a variety of hardware. Think the same app running on iOS, Android, Windows, macOS, etc.
  • Graphically intensive means software that renders pictures to a screen. Think video games, drawing applications, or virtual reality.

You can see some of my work at: Artificial Natures

What development languages and platforms does Aaron use?

Over my career as a programmer, I’ve learned a lot of languages: HTML, CSS, JavaScript, Java, C, C++, Visual Basic, PHP, Python, Ruby, C#, and more. I’ve also used a variety of development platforms like Google Cloud Platform, Amazon Web Services, and Microsoft Azure for web apps; Unity, Unreal, and several open source OpenGL frameworks for graphics development; and a host of desktop and mobile UI frameworks like Cocoa (iOS), Android, WPF, UWP, and Xamarin.

Lately my focus has been on developing applications with the .NET (pronounced “dot net”) platform. .NET is an open source framework developed by Microsoft. At the moment, I primarily write code in the C# language. More and more of the applications I contribute to are built using the new .NET Core and Standard frameworks.

I have never met a programming language or framework I didn’t like. Some have endeared themselves more to me than others, but I am always open to new programming practices and paradigms. Building good software is far more dependent on the team behind it than on the technologies inside it.

Will Aaron be a good fit for my team?

Possibly. I have worked on teams that ranged in size, make-up and working procedures. Rarely have I found a team to be a perfect fit from the outset. On many teams, I have found a good fit after a period of collaborative experimentation. Some teams, however, simply don’t work in a way that is compatible with the way I work. That’s totally ok. Usually these teams are high performing, professional, and competent – we just can’t figure out a way to collaborate.

When the compatibility test fails, it is usually due to the fact that I am an idealist. This means that I operate more as an architect than as a hacker. While a hacker is laser-focused on getting things done, an architect is primarily concerned with finding the best possible solution to a problem. A hacker will typically get more done in a day than an architect will in a week. A team made up of only architects will never get software released. A team made up of only hackers will initially release very quickly, but slow down over time. When I join a team dominated by hackers (as is most often the case), I get overwhelmed by the disorder in their code. If we can’t find a balance between hacking and architecting, I can’t effectively contribute to the team.

The antidote to this dilemma is more intensive collaboration. Hackers like to go off on their own and get their work done. Architects like to get together and deliberate over all the options. When the hacker’s intensity is balanced with the architect’s collaborative approach, amazing things happen. The most successful teams I have worked on have roughly followed the practices of extreme programming, as described in Extreme Programming Explained by Kent Beck and Cynthia Andres. Extreme programming proposes a series of incredibly useful technical activities, but at its core it is all about intensive collaboration. A team of extreme programmers all work on the same task, at the same time, and in the same place. This yields a collective sense of ownership, shared responsibility, distributed knowledge, and ultimately a highly adaptable team that delivers quality software.

The practice of extreme programming isn’t for every team. There is a cost for any change in process and this is a big change for many teams. Many cannot afford the disruption, at least in the immediate future. None of the teams I’ve joined have practiced anything like extreme programming before I showed up. I have had success introducing these practices incrementally and I have been amazed at the results every time.

How do I hire Aaron?

For large corporate clients, I work on a corp-to-corp contract basis, typically facilitated through a recruiting agency. Direct contracts are always welcome, if we can identify well-scoped deliverables.

For small businesses, I bill on an hourly basis with terms defined in a flexible contract. I will work with you to find a budget and scope that fit your needs.

I do take full time employment as well. When I become an employee, it is almost always with a non-profit or educational organization. However, I may consider employment with a for-profit corporation if the team, product, and mission are compatible.

Does Aaron even know what he’s talking about?

Maybe. I’ve been building software for over 20 years and I’ve managed to learn some things. Some ways of building software are better than others. The more diverse the team is, the better the software will be. Managers, designers, testers, and customers make great software team members. Building software, like building anything new, will never be easy, but it can get a lot more fun. Software is an incredibly malleable medium for artistic expression. I’ve heard you can even make money with it.

I have a really cool idea. Will Aaron build the software for free?

Actually, that is a possibility. I set aside some of my time each month to work with artists and arts organizations on a pro bono basis. If you are working on a project that needs technological assistance, let me know.

Maybe you have other questions?

If you have read this far, I am very embarrassed. Despite all of my rambling, I seem to have failed to satisfy your curiosity. I apologize. Feel free to reach out at aaron@artificialnatures.com and let’s see if we can’t find some answers to your questions together.