Software development is a very specialized area. It often enables the creation of strict specialities, where a programmer spends his whole time learning the intricacies of a particular language and computer environment and employing that knowledge to particular applications.
While it is true that most of us go to school and learn a common introductory computer language, it is very unlikely that jobs will be available for the exact language you learned during those years.

For example, Pascal was the language used to teach programmers for a long time. I was one of the students that had his first programming experience with Pascal. Despite this, as one of the consequence of the increasing specialization in software development, nowadays hardly anyone writes code in Pascal anymore. All the “real” programming is performed in languages that are reasonably good at exploring the existing computational environment and supported by major manufacturers of PCs, Macs, and mobile devices.

When we look at job descriptions, the specialization of the profession becomes even more impressive. Each job requires a different subset of skills that can only be acquired with years of job experience. All of this leads to a scenario where people feel compelled to spend a long time working with the same tools and libraries.

Specialization versus Exploration

One of the main consequence of high specialization in software engineering is that it is nowadays possible that you spend 99% of your working time writing code in a single language, for a single computer system.

While this may lead to an increase in productivity, in the long term it may also be harmful to your personal development as a engineer. It is not only useful, but also desirable that we have more varied experiences. The current trend in specialization may lead to more productivity in the near future, but it may also impair the development of equality important skills, such as an appreciation of system architectures in general, the a wide knowledge of different systems and a familiarity with alternative solutions that might just as well be useful to the problems you’re solving.

Boredom and burn out are frequently an adverse result of overspecialization. Under some circumstances it becomes increasingly hard to focus on a single aspect of the system. Good software engineers understand that this means they need to look at something different to improve their careers.

How to Embrace Diversity

There are no rules as to what you can do to break your common patterns. Just look for things that entice your imagination and jump at the opportunity of increasing your development possibilities. Here are a few suggestions that may help you, though.

• Learn a language that provides a different programming paradigm. For example, if you are good at object oriented programming, try to learn a functional language. This will help you see problems in a different way. Certain programming languages are adequate for a particular application domain, so making this change can also help you to understand these different problem domains as well.
• Investigate new programming environments. This is a good way to learn how things can be done differently from what you’re used to. For example, if you are used to graphical IDEs that can do everything with a mouse click, try to get your hand into a command line based environment. You will certainly feel you’re unproductive at the beginning, but the idea is to learn different tricks from command line environments that can be translated into your own programming workflow.
• Experiment with different application areas. Sometimes we’re so used to our particular domain that considering a different area may provide a lot of insights into the way we work. For example, if your area is web programing, try to create something that requires number crunching with floating-point libraries. It is certainly a nice challenge that may help you in learning new concepts. On the other hand, someone currently working with scientific computing could look into creating a basic GUI-based application, or even a simple game.

As you see, the possibilities are limitless. Spending a few hours in such an exercise will not transform you in a specialist in a new area of programming, but will give you a few insights on how programming works in other domains. Then, if one day you have a similar problem in your hands, the solution will be much easier to figure out based on the concepts that you grasped during the exploration period.

Conclusion

Software developers don’t need to spend their whole time solving a narrow class of problems. In fact, it is sometimes just as helpful to look into different directions, which can provide a renewed focus and fresh ideas to be applied at your main goal.

Using exploratory programming exercises can be a great tool to improve your programming skills, even if you’re only using these concepts for small time periods. The general ideas that you will absorb can be applied in many areas and benefit current projects as well as future work.

Image credit: commons.wikimedia.org

Similar Posts:

• Day 4: Learn a New Programming Language
• Day 18: Development Speed is Important
• What all programmers have in common
• Day 2: Write Shorter Methods
• Day 8: Take the Rest of the Day Off