|
 New
developers, fresh out of college and training, are sometimes shocked
when on their very first jobs they are expected to swim alone. In
college they have their peers, classmates or instructors to help
them debug and solve problems. MOHAN BABU writes that new developers
must learn how to solve problems independently
I had an interesting discussion with some
peers in the IT industry a few weeks ago. They were project managers
and architects with years in the industry and are managing projects
that have a blend of talent from experienced programmers to rookies
just out of college. The projects they are managing range in complexity
from a few months with less than ten people to those spanning a
year or more with dozens of people. There was a common thread that
emerged during the conversation: the rookies, and even programmers
with a few years in the industry had got accustomed to the ‘easy
way’ of solving problems and were losing touch with the art
of finding answers and independently researching and solving problems.
What I mean by the remark that the new
generation of techies are losing out on the basic skills is that
given the ease of programming in languages like Visual Basic or
Java, and with the widespread usage of Integrated Development Environments
(IDEs) like Visual Studio or JBuilder which handle most of the grunt
work “programming” is starting to become an art of mapping
of the problem—set to the classes/objects in a drag-and-drop
mode. This is different from the development paradigm, which, even
a few years ago involved coding in C, Cobol or Assembler where programmers
would need to do an enormous amount of setup and groundwork in the
environment before a program could be successfully compiled and
run. For those developers, hitting a compile error, memory overflow
or “unhandled exception” was a day-to-day challenge.
What peeved some of my peers was the fact
that some of the new programmers had got used to a lot of spoon-feeding.
For them, a simple “page cannot be displayed” on the browser
is a “showstopper.” The fact that an enormous amount of
plumbing goes on behind the scenes in J2EE or .Net, making their
jobs easier, eludes them. Of course, ignorance is bliss as long
as things work fine. It is only when something doesn’t work
that alarm bells start ringing. The issue here is not that developers
experience problems during build or coding. The issue is that they
sometimes forget that they are paid to analyse and solve those problems
in the process of developing technical solutions and building applications.
At the risk of oversimplifying things,
we can look at most application development projects from two angles:
technical and functional. Technical challenges involve setting up
the development environment, libraries, plug-ins, data sources,
message queues and everything else that goes on behind the scenes.
Functional aspects include the business logic, the actual business
functionality, and problem or issue that the project is intended
to solve. Both these aspects of a development project are equally
significant. Unless business problems are solved, business leaders
who sponsored the IT project are not going to be happy. At the same
time, unless the IT tools and techniques are optimally utilised
to solve the aforementioned business problems, the project is going
to be unsuccessful.
The new developers, fresh out of college
and training, come brimming with idealism and ideas of the software
life cycles, algorithms and other theories. However, they sometimes
tend to get overwhelmed by the nexus of business and technology.
In a collegiate atmosphere they have their peers, classmates or
instructors to help them debug and solve problems. It then comes
as a shock to them when on their very first jobs they are expected
to swim alone. Of course, if they are fortunate to work for software
services companies like Wipro, Infosys, TCS et al, they get to work
in offshore teams with peers who are in the same boat as themselves.
The “seniors”, that is techies with a couple of years
in the industry, instinctively guide the juniors and rattle off
the answers to questions if they can, or in turn ask their seniors
if they can’t. This is the easy part. What if the senior’s
senior too hasn’t seen the specific problem in question before?
Then there is a breakdown in the problem solving paradigm. The seniors
don’t want to loose “face” and try to call their
colleagues and peers in the company or externally. This process
of track-a-peer continues till some poor sucker comes up with the
answer and the problem gets solved.
The question here is: where has the old-school
of solving problems, that is reading technical manuals, blue/red
books or even “googling” or searching online gone? And
this is exactly the issue that my peers and I were debating. I am
not going to give solutions to this problem in this column, but
needless to say there are many ways to tackle this issue which is
going to depend on the organisational culture, the availability
of peers and mentors, the learnability of the juniors. However,
the bottomline is clear: as India becomes a global powerhouse of
IT development, our software developers need to be taught the ‘art’
of independent problem solving.
Mohan Babu is a US based software consultant
trying to find the ‘sweet spot’ where IT meets business. E-mail:
mohan@garamchai.com
|
