I've been wanting to write about this for some time. About 8 months ago I not only left my software engineering position at Microsoft but I pivoted technology stacks all together and plunged into an entirely new and different technology ecosphere. This was not a calculated move to abandon the Microsoft platforms (windows, .net, powershell, visual studio, etc, etc...) nor was it a reactionary vote of no confidence in the Microsoft based developer community. Over the past few years I have developed a growing passion and involvement in automation tooling. Over time this involvement consumed my "after hours" time and while it certainly occupied a fair amount of my work at Microsoft, I was presented with a super compelling opportunity at CenturyLink Cloud where I could cultivate this passion all day long (not JUST nights and weekends). Like many companies that are not Microsoft, it so happens that we use tools, infrastructure and development stacks that are not entirely Microsoft based.
Much of our back end runs on linux, there is no hyper-v here, and our automation leverages Chef and is therefore saturated with ruby based tools. As a result, I have not written a line of C# or SQL in the last six months and I have opened visual studio no more than a handful of times. I read and write ruby everyday and have been contributing much of my spare time to ruby based open source projects like Vagrant, Test-Kitchen, and the ruby WinRM gem, my primary IDE is a text editor (sublime text 3), and my work funded laptop natively runs an Ubuntu 14.04 desktop. Let me tell you - this is a very different world and this post will attempt to describe some of the ways in which it is different from my experiences in the Microsoft world.
Again, I want to make it clear that I do not see this "pivot" as a conversion or even evolution to something better. While I do absolutely feel that some of the technologies I am working with are "better," there is alot that I miss and other areas that are just plain "grey." For example, I love just opening a text editor and writing code in a much simpler and snappier environment but there are moments that I yearn for some of the debugging and refactoring effeciencies that visual studio (and its plugins like resharper) provided. I'll probably dedicate a separate post to C# vs ruby but I still think C# is one kick ass language and while there are areas of ruby I have learned to love (and I am appreciating it more over time) I'd prefer a statically typed compiler aided language for not all but certainly my larger projects.
Differences are more cultural than technical
As I review the nuances that strike me as most profoundly different between the cross-platform world (this may not be the best term to use here but I'm sticking with it) and the MS-centric world, these tend to gravitate more strongly toward cultural differences than technical differences. Sure there are some fundamental distinctions to be found in the underlying architecture of linux and windows. If I were writing this just 5 years ago I'd be more tempted to give these differences more discussion but Microsoft has filled in some significant gaps and while its still "different," its really the culture that captures my attention.
What do I mean by culture? Well its just not interesting to compare and contrast these tools in terms of differing feature sets (but I will). Rather, there is a distinct and unique ethos in how these tools are composed and how their users value this composition and how they expect to interact with the tooling ecosystem that I find fascinating. Why is linux better than windows, why is C# better than GO, how do ruby gems differ from nuget packages? There is definitely some juice in all of these discussions but they will all eventually lead any observer of these debates to notice key character differences between these communities and what they value in the technology they build and consume.
So I am going to point out some of the characteristics of the cross platform community that I have found personally most notable. Look, this is a broad group and it is impossible to justifiably lump them into a cohesive community like I am doing here. More so today than ever there is growing "cross over" between this "cross-platform" community and the Microsoft stack developer communities. However, anyone who has spent any significant amount of time interacting with both camps will likely agree that the experience of interacting with one compared to the other evokes similar comparisons to groups that share different political or religious affiliations.
Open Source is normal
Yes...yes...I know Microsoft has recently made several announcements regarding the open sourcing of several significant formerly proprietary closed source technologies they own. What I think is key here is how in 2014, that is such a big deal. In so many pockets of the cross-platform world, its just how teams work. I personally share this value and I applaud those at Microsoft who have worked very hard to make this happen. But trust me, cultural wars have been raging inside the walls of Microsoft to push these projects to OSS and I assure you some of the coals are still quite hot.
Microsoft is in no way alone its struggle to open source its source code. Many, particularly larger, companies find themselves needing to wage internal campaigns to do the same. But my experience in the ruby community where I am most involved right now and its java, go and node cousins is that open sourcing and in many cases even your company's core IP is common place. Now I could go off on the virtues of why I think this is a wonderful thing and maybe, just maybe, unicorns and humans would peacefully coexist within the same halls if all code were open source, but instead I want to point out that differing attitudes of open source development reflect different mindsets and ways of viewing outside developers and development teams.
The open source adverse, may see OSS projects as the fruit of the "hobbyist" or "enthusiast" developer and not necessarily the product of highly skilled developer teams. This group may also see OSS as a threat either because it would expose "secret sauce" IP or sacrifice revenue opportunities because now the very thing you would charge for is freely available. I'm not "exposing" these views as unfounded at all. One has to walk carefully here but there are going to be distinct differences in the work habits and collaboration patterns of those who embrace open source and those that resist it or even just choose not to participate.
Personally my experience here has been largely positive. Even though someone else may be technically profiting from the contributions of my "work product," my contributions give me a voice in the direction of software that may not be "mine" but provides core services to my own product. It also gives full transparency into how a body of code works and exposes to myself and everyone else any key flaws that might exist in tools that I use and provide a way for me to either fix or work around problems.
Whether I pay for this software that I do not have time to write or not, the fact that I can read the source often proves itself to be invaluable to me in order to learn how to best use it or to solve blocking problems I might be facing as I use the software.
Now I will admit that there have been times of utter frustration where I just want the software to work as advertised and I'm pissed that I have to spend hours deep diving through someone else's code to figure out why I'm getting an UnspecifiedParameterException. But you know, I'd rather do that and learn some things in the process than spend the same amount of time on phone calls and emails with customer support. It also feels good to look at the code and see my github icon on the contributor list knowing that my fix is helping others perhaps in the same bind.
More granular projects and plugins over monoliths
This is reflective all over in the *Nix universe. You tend to see lots of tools that can be composed alongside of one another and each has a bounded scope of responsibility. Overall this is definitely a software design principle I appreciate. Historically, larger software vendors may try to sell a "one tool does everything" sort of tool chain. Sure its nice to just have to buy one thing and deal with one vendor but this often also means "settling" for inferior functionality on some part if not all of the tool.
Not just at my current gig but in several other projects I have found that its usually more efficient in the end to get the best tool for the job even if that means having to license several tools.
The Chef ecosystem is a great example here. There are literally hundreds of different pieces one can compose to build an infrastructure automation strategy. You are not hand fed a single tool to orchestrate provisioning, installations, security, testing and reporting that includes compatibility with all hypervisors, clouds, containers and bare metal.
The result can be quite mixed. At first one is overwhelmed by choice. You spend alot of time understanding the benefits of different workflows and tool chains. However in the end, you gain a deeper understanding into how the tools fit together.
What I have also found here is that this granularity can make the individual pieces much easier to understand and troubleshoot. It means I may just need to grok a few dozen files to fully understand how the core testing infrastructure works without having to worry that some Digital Ocean based provisioner is coupled to this infrastructure in such a way that is gonna mess with my VMWare driven scenario.
Finding the right abstraction boundaries can be more art than science and can potentially clutter or over complicate an API but more often than not it guides towards better flexibility and composability. It also assumes that its consumers are more technically adept. A jr. engineer is not going to be able to wire everything up to take advantage of this flexibility. Again, this can be for better or for worse. I think it also explains cultural differences in the communities that consume these different kind of products.
Compare the consumer of a large chef or puppet based infrastructure to say a vmware vcac (or whatever they are calling this at the time you are reading this) or a Microsoft system center solution. The same analogy might be drawn comparing web forms vs MVC consumers of ASP.NET. I am not saying that one is better because it has more flexibility and you should therefore NOT use the other. Especially if you do not need the flexibility, there is alot to be said for buying the "packaged" deal if it meets your needs so that you can focus your expertise elsewhere. I am stating that in large part, I have found that the cross-platform world tends to steer towards more smaller, composable parts that take some effort and know how to wire/script together than a monolithic "out of the box" solution.
Less IDE-centric programming platforms
I've already spent some time on this topic above. Certainly ruby, go and node lend themselves toward a text editor over a full blown IDE for ones primary development environment. Until recently, it was simply not practical to write C# outside of Visual Studio and it has been a long time since I wrote java but I remember having the same dependence on an IDE when I was a java developer.
Like everything else this has its upsides and downsides. You get lighter weight tools that provide 90% of the features you may actually use in an IDE. Many may find they do just fine without that extra 10%. Personally I find that there are certain times especially when debugging that I wish I had a richer debugging toolset. Actually these toolsets (like RubyMine) are available and may augment a text editor but can be tough to get used to them if you don't use them day in/day out. An IDE and "real" Intellisense can also be a real boon in discovering APIs without reading alot of source code. Then again, there is something to be said for reading source code. I have a better understanding for the API. Also, BONUS: as a new ruby developer, this is an excellent way to learn the idioms of a new language.
The command line is king
Historically products sold by Microsoft tend to be GUI heavy and in fact, its consumer base expect this. Often you get a v1 product with a GUI and need to wait for future versions for an API. The cross-platform world is filled with tools that have no GUI and will never have a GUI. Again, the consumer base expects this and values the command line.
Now I am the slowest typist I know and I say that, sadly, sans hyperbole. However I discovered years ago that I was more efficient with git on the commandline than using a GUI. For one thing I use source control all day, every day. I eventually found that using commandline tools even in the Microsoft world had a ton of value. Lots of Microsoft stack developers find this to be the case. However, I would not say this was nearly as prevalent among Microsoft stack developers largely because tooling simply did not lend itself to this. Just like it takes descent designers to write good GUIs, good command line tools also require a special skill.
Once you spend a certain amount of time immersed in the cross platform ecosystem, you learn some common patterns shared in most CLIs that allow you to navigate most others fairly quickly. The descent CLIs either have really good command line help or point to good READMEs on github or a product website. Note that there are some that are absolutely horrible. Oddly one of the most popular, git, does not rank highly in this regard. Others will scoff, but I think powershell is excellent in providing a discoverable command line interface with quality help. Its just too easy to get by in windows without ever opening a powershell window so many never learn it or use it consistently enough to pick it up.
More mature automation tooling
One thing that I and many of my colleagues note is that everything is harder and wrought with more friction when it comes to automating windows vs. linux. This has gotten much better since powershell and is getting rapidly better but this is still very much true today on the latest windows server OS (2012 R2 at the time of this post).
On linux, SSH is "just there" and their are no odd list of exceptions when it comes to running commands locally vs. remotely. Sure you can manage anything remotely on a windows machine but may have to jump through rings of fire to do so. However have you actually ever jumped through rings of fire? Neither have I but I have watched other do so and when they do they tend to stand tall afterwards with their arms up in the air and look extremely proud. So there is that...
Package management and configuration management have long been part of the linux lexicon but are novelties to windows. At least they are now novelties and not nonexistent. There are a rich set of automation tools in the linux world. Many, if not most of these are advertised to work with windows. However, there are often tears involved. I am confident Windows is going to catch up here and that the leaders behind Windows server want to do the right thing and understand the space.
I wrote an article for InfoQ a few months back describing the state of this tooling in the Windows world today. I'm really excited about where things are heading and have been an active participant in this space.
The gap is closing but there will always be a gap
I've hinted at this several times, but in areas where I think there are solid technical shortcomings, windows is catching up. I do think there will be a day for instance where the automation story will be at least very nearly as good as it is for linux. That said, I do think there will always be a cultural gap between these two platforms and their communities.
This is not necessarily a bad thing and I suppose that depends largely on your own developer ideologies and personal style. Even regardless of those, there will always be large pockets on either side that share very different values. personally, I enjoy both platforms for different reasons and I have good friends that develop for both stacks. Besides, what fun would the world be if windows and mac/linux users didn't argue? And in this world, how would you be able to identify the hipsters?
