Learn to adapt and adapt to learn


Adapt or perish, now as ever, is nature's inexorable imperative. -H G Wells

I have been away for a while: had a lot of coursework to complete and I am finally out of it unscathed. Hi everyone, welcome back. As usual, I will begin my rants with the disconnect between the job market and the definition of a software engineer.

Recently, I received a call from a company (which I do not recall applying to) asking me "In which technology are you a software engineer?"

It is the same as asking an automobile engineer, "In which type of vehicle engine are you an automobile engineer?" Specialization, you say? Not really. Although automobile engines do not evolve as fast as programming languages, an engineer must be ready for all. (S)he is the one who should make the decision regarding which is most suitable.

It basically undermines the factor of learnability within the engineer. Is it not possible that an engineer learn about a new technology and implement it? Hath not an engineer brains?
I got carried away by a bit of Shakespeare there.

However, the point I am trying to make is this: The technology is disposable. Especially in software development, where they get outdated really fast, we need people who not only have development skills  but at the same time, engineering and reengineering skills along with learnability of new technologies.

One common example of outdated technology is that of the Enterprise Java Beans or EJBs. It was (and still is) a server-side managed component architecture for enterprise applications (http://www.oracle.com/technetwork/java/javaee/ejb/index.html). Till about 2008, EJB was a highly demanded skill for "software engineers". However, it didn't take much time to die out and one would hardly see any new positions requiring knowledge of EJBs. Soon people realized that EJBs were not practical for real world applications and EJBs went out faster than lightning.

So, what happened to the knowledge gained by people who were experts in EJBs? Panic and rushing towards learning the next hot technology? If we learn by experience, we must note that adabtability and learnability should be focused on by companies.

A software engineer will provide that. One of the things that a software engineer does over a computer scientist is evaluate tools. There should be enough reasons to select a particular language and then develop in it. The focus should move away from coding and towards software development.

In fact, IEEE Computer Society's Certified Software Development Professional Certification Program (CSDP: http://www.computer.org/portal/web/certification/csdp) has the following elements:
  1. Business practices and engineering economics
  2. Requirements
  3. Design
  4. Construction
  5. Testing
  6. Maintenance
  7. Configuration Management
  8. Engineering Management
  9. Engineering Process
  10. Tools and Methods
  11. Quality
Out of 11 elements, just one element (Construction) deals with programming. Even there, it is elementary to select the appropriate language or technology before development.

Adaptability and Learnability are two important virtues of a true (software) engineer.

Cheers!

Comments

Post a Comment

Popular posts from this blog

Software Architecture Patterns: MVC

Image
Long since I have updated here, I went through a number of experiences to land up in developing within the Android platform. Being pushed out of my comfort zone of server-side and database development, it is a fresh adventure by itself in developing mobile applications. Away from my usual rants about software engineering, I would like to be a bit more specific about a topic. Software architecture can be defined in a number of ways. The software engineering institute has compiled the modern as well as the classical definitions of software architecture. http://www.sei.cmu.edu/architecture/start/glossary/moderndefs.cfm http://www.sei.cmu.edu/architecture/start/glossary/classicdefs.cfm To be concise, software architecture is a set of models which define the highest level of system abstraction. This may begin with understanding the qualities of the required system and the tactics that enable those qualities. The summed up architecture document will consist of static views such...
Read more

Scrum: The Art of Doing Twice the Work in Half the Time

Sutherland, Jeff, & Sutherland, J. J. (2014).  Scrum: The Art of Doing Twice the Work in Half the Time . New York, NY: Crown Publishing Group. https://www.scruminc.com/new-scrum-the-book/ Introduction  The author, Jeff Sutherland, along with Ken Schwaber conceived Scrum as a method of improving productivity in software development teams in the early 90s. Coming from the horse's mouth, one gets an insight into the history behind Scrum and how the author evolved the process with every project he worked on or consulted for. One also gets to view the process through Sutherland's eyes as he applies that to every project. He provides ample anecdotes to supplement his arguments towards using Scrum as the process of choice not just in software development but also in other engineering as well as non-engineering domains. That said, it also brings about a bit of a confirmation bias of Sutherland regarding the efficacy of Scrum. Through the reading of the book, one desire...
Read more