WHAT does it take for a fresh IT graduate,

strong in technology

but lacking in engineering experience, to become a mature, productive and professional software engineer? In wealthier countries, companies offer training to new college graduates. However, many firms in Bangladesh cannot afford this luxury.

In the following, I draw on my 20+ years of experience in software engineering in Silicon Valley - first as an engineer, then as a manager mentoring engineers -to discuss the skills that grow a novice engineer into a mature one. I assume that the novice engineer is - through their education, or being self-taught - already technically competent and knows how to quickly build working software using today's tools and technologies.

I started working in software after obtaining my Master's degree. With the necessary educational foundation, I began my journey to a mature software engineer. I did not know it then, but this journey would encompass learning these skills: a) direct application of academic knowledge, b) learning design, specially, differentiating "what" and "how", c) communication, d) value of testing, e) estimating tasks, f) leading a team and g) understanding customer value and selling it.

My first job had a "Software Engineer" title. I now realize it really emphasized the skill a) above. I had just completed a graduate thesis in Image Processing and my new employer manufactured an Image Processing System. Using my knowledge, I researched new ways of manipulating digital images. When research results were successful, we quickly incorporated these into our product. The distinction between the "what" and "how" was blurred because we often changed the product's definition based on the results of my research.

However, I started learning about engineering design at this job. By the time I started my second job, I had learned about the internal and external design of a product. This is a common but serious area of confusion for many. So I will elaborate using an example from architecture.

Last June, while visiting Italy with my family, we saw the Duomo of Florence. This cathedral with its beautiful, massive

dome has an instructive and compelling story behind it.

During the 13th century Florence emerged as a powerful citynation. So Florentines decided to build the Duomo to show off Florence's new wealth and status to her neighbors.

What captured my engineering imagination was this: the size and shape of the Duomo was decided in 1296. By the time Filippo Brunelleschi solved all the technical problems and built the cathedral, it was 1418!

In other words, the "what" of the problem was defined before Brunelleschi - who answered the "how" - was born.

The external design (also called the functional specifica-

tion) is the "what" of the product. The internal design (also called the engineering specification) is the "how". You must know what you are going to build before you figure out how to build it.

Ok, back to my second job which was to design and build software to drive a medical ultrasound imaging system. I worked very hard to write a complete external design, which described the was a doctor would use my software. Only when I was satisfied that it was complete did I attack the problem of building that software by writing the internal design. The resulting software proved robust and popular among customers.

During this time I had to explain and defend my ideas in front of peers, managers and customers. I was learning skill c), communication, which is critical because if one cannot explain one's ideas to others, the value of those ideas diminishes. The keys are: a) realize your audience may not know as much about your subject as you do, and b) speak in a language they understand.

At this time, a story about the software running medical diagnostic machines started circulating among engineers. Abug in the software, the story went, had exposed a patient to extremely powerful rays and done much harm. It was not clear if it was an X-ray, ultrasound or some other

type of scanner.

This - possibly apocryphal -story pushed me to learn skill d), the value of testing. I was worried that if there was a bug in my program, it might harm the patient. Lesson: the programmer and quality assurance engineers must be utterly ruthless in testing their own software as early as possible. By the time a customer encounters a bug it is often too late.

Sun Microsystems was a rapidly growing company when I came to work there as a software engineer in 1989. I faced a different type of challenge here because of a recent close call Sun had.

A year earlier, Sun had signed

a contract to deliver a new computer system to General Electric, one of the largest and most powerful companies in the US. Unfortunately Sun's project was behind schedule. Jack Welch, the CEO of GE, threatened to buy a fullpage ad in the Wall Street Journal exposing Sun's incompetence. Somehow a crisis was averted, but engineers at Sun became extremely particular about project estimates and project schedules.

This was the opportunity for me to learn skill e), estimation. The estimation of how long/how many people it will take to complete a software task is very difficult. Being able to do so accurately is an extremely valuable skill. One needs to cut up a task

into smaller, predictable pieces, and then add in some anticipated setbacks to arrive at a reasonable estimate. You need some experience before you can do this well.

Soon our work expanded and our group needed a leader. I stepped in, enabling me to learn skill f). As team leader I provided technical guidance to the team: for example, helping a more junior engineer choose which technology to use for his or her task, or reviewing code. But my most important role was to supply inspiration and confidence, so that the team believed "Yes, we can do it!" and overcame the various uncertainties usually associated with IT projects. I did

this by setting good examples, by being calm and logical during times of crisis and by setting and demanding high expectations from the team.

What about skill g), customer value? During my undergraduate days I had the good fortune to meet late Dr. F. R. Khan, the famous (Bangladeshi) structural engineer. Dr. Khan, like Brunelleschi, had solved hard technical problems required for building Chicago's Sears Tower, the world's tallest building at that time. I sought his advice on how to be a successful engineer. His advice surprised me. Instead of dwelling on technical prowess (which, I think, he assumed) he said, "Whatever kind of engineering you do, always think about its value to the customer and how to sell your work."

As an engineer, whenever I have followed this advice I have succeeded with the effort. Whenever I did not heed this advice -perhaps I became too absorbed or enchanted with the technology itself, or allowed myself to become distracted - my efforts succeeded less.

No doubt, learning and applying the above skills take hard work and patience. Moreover, IT is a tough field and success is never guaranteed. However, I hope that knowing about these skills will help budding engineers recognize and grab the opportunities for learning and excelling.

I finish today with the story of a successful software engineer. Jawed Karim, son of a Bangladeshi father and a German mother, is based in the US. He recently became famous as a co-founder of YouTube, a company which Google bought for USD 1.6 Billion. If you peruse his website, www.jawed.com, you can see how he has approached software engineering, blending technological know-how and innovation with brilliant design, discipline, and a keen eye for customer's interest.

I met Jawed in 2000, and immediately recognized the spark in him. I am encouraged that I have met several young Bangladeshis in the last year who also have a similar spark. What they need is the right guidance and support to create technological breakthroughs. It will not be easy, but I am confident that we have the talent and it can be done.

You can read Ihtisham Kabir's blog at backtobangladesh.blogspot.com