About a year ago I started a series of posts on becoming a software developer to coincide with the Code.Org "Hour of Code". This post is the fifth post in the series focusing on the skills, patterns and practices involved in being a developer. If you haven't yet, please go back and read through the preceding posts for better understanding of where this post is coming from.

I'm going to use this post to build on the third entry, focusing specifically on using the PluralSight training site to learn and improve your .NET Skills. Whether you are trying to up your game as a developer or break into writing software in the enterprise, if you HAVEN'T signed up for a PluralSight membership, you need to go and do that right now. Seriously. Take a couple of hours a week and improve your current skills or learn something new.

With your new membership, I'm going to lay out a suggested path for becoming an enterprise developer that I might be willing to hire.

Craftsmanship

First, you need to have instilled in you the proper methods for writing testable and maintainable code. The average enterprise application has a 7-10 year life span and while anyone can sling bits, only those that develop the skills to produce resilient, testable and maintainable software have a hope of longevity in the Enterprise and Consulting work force. I'm a firm believer in Robert C. Martin's SOLLID methodology as a starting point followed by a serious consideration of the accepted patterns and practices for enterprise development before charging off to chart new territory with any given application.

SOLID

Test Driven Design

I'm a solid believer in Test First Design and Development, but I don't believe that it's for everyone. That being said, even if you don't write your tests first, you still MUST WRITE TESTS. On my team, your code is not finished and ready for delivery unless it is accompanied by both unit tests as well as a test plan, both of at least a rudimentary level (not all code is unit tested, not all code is relevant to a test plan). I strongly believe that if you take the time to learn TDD it will force you to think about testability, and through that process, you will become a better programmer who produces more maintainable code. Even if you stop using TDD, your development and coding behaviors will be changed for the better for the exercise.

Web Basics

Before getting into the back end .NET server languages that drive the enterprise web, it's important to have a handle on how to develop in and understand the technologies that all of the web is built on. Even though the Microsoft Enterprise runs on .NET, it is served up using HTML, CSS and JavaScript. These technologies can get you pretty far these days without ever having to write a line of back-end code.

C#

By now you are a couple of days into your journey and you are wondering if there is actually any .NET content in this post, and I understand. I've attempted to lay out this discussion in a progressive manner, with incremental steps that build on each other. With that in mind, we will now step away from the web centric discussion to look at C# as a language

MVC 5

And now, back to the web. Everything you've learned so far has brought you to this point; the point of developing code driven, enterprise ready web based applications that are dynamic, well tested and built on the accepted patterns and practices that customers, clients and employers have come to expect.

TDD - MVC

As I mentioned, I would be remiss if I didn't show you how to test your MVC code.

Web Services

The web isn't just about HTML. Most enterprises also run on a heterogeneous environment of web-facing services that allow systems to reveal data to their users as well as other systems both internally and externally for raw consumption. These data-centric endpoints leave the UI behind and follow industry standard protocols for the publication and consumption of data.

Conclusion

So that's it. Or, I should say, "that's the start of it." If you have gone through these sections with any diligence you now have been exposed to the basics of what you need to know to be a web developer in the enterprise. Of course, now that you've been through all of this, there's still

• Logging
• Exception Handling
• Durability and Fault Tolerance (Queueing)
• Etc.

But we'll leave those for another discussion. Now, go out and write some code, get some experience and be a Software Craftsman.

In this Series