I wrote another article that attempting to answer the question whether or not college is overrated for developers, but there is a broader question; what should a developer learn? Whether or not college is attended, a developer has to learn certain things. New to the software development processing, a fledgling cannot be faulted for wanting to know what he should learn. I'll given my opinion as to what a developer needs to know.
First, all software developers need to be familiar with at least one language. What constitutes familiarity with a language? Syntax is first and foremost; your code needs to compile. Data types and basic libraries are essential as well; your code does need to be able to something. Once you're able to compile programs in a language that can do something, the basic requirements to develop software have been met.
Getting computer to do something is not sufficient; code that compiles, runs, and appears to do what it is supposed to do is far from optimal. A software developer needs to be familiar with how structure his code in some organized fashion. There are two fundamental ways to organize code: objects and structures; every developer should be familiar with both. Even objects use structured programming. Object-oriented and structured programming will guide you in accomplishing what you desire in an organized way. Organized code is much easy debug, update, and extend than unorganized code.
Writing code that is merely organized is not enough. Poorly organized code offers small benefits over garbled spaghetti code. Consequently, developers must, even in just cursory manner, must familiarize themselves with the principles of design. How cohesive and tightly coupled a given block is must be paid attention. Weak cohesion implies a broaden of focus; broad focus increases the likely that any given code change will touch a given code block. Tight coupling implies that given block relies heavily on other code blocks; that reliance also increases the likelihood of change. Any veteran developer will tell you that getting stuck in a maintenance nightmare is one of the worst development experiences. That nightmare can be avoided by paying head to coupling and cohesion. As a result, every developer should familiarize himself with those concepts.
I realize that these are broad tips and not specific technologies. Specific technologies come and go, but solid development foundation never leaves you. With a solid understanding of what I've described above, you will able to do any type of development that you choose.
Like all good developers, I'm constantly scouring the web and publications for new technology. When embarking on interesting and experimental projects, the effort to find new technology becomes that much more pressing. That search, impelled by desire to solve some rather pressing problems, led my to Apache's Thrift.
Thrift aims to solve communicating across machines and across languages. This is a classic problem for which there have been many solutions. What makes Thrift unique is its reliance on excepted technology. All Thrift communication is RPC, which is a tried and true methodology. RPC libraries are not uncommon. Thrift allows RPC calls to be made between processes written in different languages running on different machines. Data can be serialized on the way out and on the way in, so that's on particularly special either. Thrift, unlike a serialization library, allows languages to share data types across the RPC calls. Class A in Java is used as class A in C++. Thrift takes care of the details of abstracting how a Java class is morphed into a C++ class over an RPC call. When you add in the fact that Thrift supports a wide range of languages, it becomes quite an appealing technology.
An appealing technology is not necessarily a useful one. Why should anyone attempt to learn how to integrate Thrift into his software? Thrift's cross langauge capability allows a programmer to pick the language that is best suited for a particular task. An ASP.Net UI could be married to Java Servlets. Those Java Servlets could communicate with some really fast C++ code. Since all of those calls are RPC, they're going to be fast. The penalty of communicating across is not as high as may for some technology such as DotNet remoting. The speed and cross language capability of Thrift opens a whole new world of software design.
I'm going to play devil's advocate for a moment; Thrift is a cool piece of technology, but it does present some challenges. The data synchronization means that the data types, which are communicated across languages, have to be defined in a cross language way. For a large data model, this could be both time consuming and messy. Translating data types can be tedious. The process of debugging the communication between the exchange of data between languages is not exactly fun either. For those reasons, avoiding Thrift and using multiple languages may be prudent.
Still, experimenting with Thrift on a small scale, where the data model is not unwieldy, may be fruitful. If your experiments deliver a comfort in working with Thrift, then a larger project may be doable. The possibilities that such a technology offers for big time systems are wide. Consequently, Thrift is at least worth considering.
I've been working with ASP.Net MVC for a couple of weeks now. As a veteran web forms programmer, I am familiar with ASP.Net, so web development is old hat to me. Still, ASP.Net MVC is a sizable departure from the old web forms model.
Microsoft shortened up the page pipeline. View state has gone, which in itself saves a good amount of memory and processing resources. The old collection of controls such as textboxes and bottons, each with its own viewstate, have disappeared as well. The controls have been replaced by a tagbuilder class and the ability to extend the the HtmlHelper class that renders a tag to a page. Both changes make the process of generating a page must faster.
ASP.Net MVC is more than just an efficient web renderer. MVC separates duties of a web application into unique spheres. The presentation layer is handled by views. The data within the application is handled by models. The logic of the application is handled by controllers. A web application that used to a muddled mess of page markup, controls, and code-behinds is now a cleanly separated application.
The benefits of ASP.Net MVC are certainly performance but the performance benefits may not be the most beneficial. The separation of duties that ASP.Net MVC provides conforms very well to test driven development. In fact, test driven development was part of the motivation behind Microsoft's design. The benefit of such symbiosis is improved quality and better maintainability. While performant web applications are important, working one are even more so. As a result, the ability to eliminate bugs during testing as well as find them later on is significant benefit.
There are trials in writing an MVC application if you're used to the old web forms way. The manner in which you achieve some of the same goals will be different. Change, especially when that change is significant, is never easy. The pain of making that change is well worth it. I'm discovering that right now. Sometime in early September, I hope to share the fruits of my labor. Until then, give ASP.Net MVC a try.