Traits of a good engineer talk to campus minds of 2008 l.jpg
Advertisement
This presentation is the property of its rightful owner.
1 / 15

Traits of a good engineer PowerPoint PPT Presentation

traits of a good engineer

Download Presentation

traits of a good engineer

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Traits of a good engineer talk to campus minds of 2008 l.jpg

Traits of a good engineerTalk to campus minds of 2008

N. Rajagopal, System Software Practice Head, RDS

Dec 17, 2008


Trait 1 l.jpg

Trait #1


Trait 1 curiosity how does it work l.jpg

Trait #1: Curiosity – How does it work?

  • Have curiosity of a small kid

  • Insatiable desire to know how things work

  • Have your own “feel” rather than going by other’s views

  • Enjoy playing around with controls, options, choices

  • You could be fixing a level 3 bug in a module. But that should not limit you to seeking beyond. You can ask following questions –

    • How does it get started?

    • Where are configuration files?

    • Which platforms does it work?

    • What tools are used? Why are those tools used and not something else?

    • What happens if I pull that card out

    • And so on..

  • Most of the time you have access to the source code, design documents, test plans, configuration files – take time to understand them

  • Use your project as a vehicle to understand the big picture of the project you are working on


What can go wrong with this code l.jpg

What can go wrong with this code?

void foo (char *bar)

{ char c[12];

strcpy(c, bar);

}

int main (int argc, char **argv)

{

foo(argv[1]);

}


What can go wrong with this code cont d l.jpg

What can go wrong with this code – cont’d

B. - "hello" is the first command line argument.

A - Before data is copied.

C. - "AAAAAAAAAAAAAAAAAAAA\x08\x35\xC0\x80" is the first command line argument.


Trait 2 how to break l.jpg

Trait #2: How to break?

  • Look for boundary conditions in design and code

    • What happens when you run out memory, file handles, records, and other resources?

    • What happens if I run x instances of same program in a server? Does it crash or just gets loaded?

    • Do you handle the situations gracefully?

  • “How can I break it??”

  • An engineer should always know the limits of her system and how to test it

  • Have an eye for details

  • Have a “hacking” mindset

  • Example of iPhone review

    • While there were so many raving reviews of iPhone, I found one review interesting – It pointed out different issues in iPhone: Inability to change batteries, draining of batteries when using BT and WLAN, inability do download apps, inability to use skype, cannot install 3rd party browser and so on

    • Bingo, the person was an engineer!


Trait 3 l.jpg

Trait #3


Trait 3 how to get going l.jpg

Trait #3: How to get going!

  • Very few projects are done in “grounds up development” mode now

  • You could be joining a project that has 2 million lines of code and 5 years into production. Your lead will ask you to fix a bug in a module.

  • How do you proceed in such situations?

    • Use code browsing tools

    • Build, trace and learn control path

  • Still not able to figure out? Then –

    • Check with fellow minds

    • Ask in communities, internal mailing lists, project space

    • Google, mailing lists

    • Search for Howtos, Wikis

    • “Figure Out”!

  • Be comfortable with the fact that you will work on big source code bases without fully understanding it. Don’t expect someone to train you on code

  • Key to success is not to get intimidated by size of project. Learn to zoom to right place, use right tools, ask right questions and get going! It is a maze and be learn to be comfortable with that!


What do you choose in these cases l.jpg

What do you choose in these cases?

  • You need to do code a mathematical function, say sine(x). There are two approaches –

    • You can create a lookup table with values for all the degrees and get value from table

    • You can write a function that calculates the value from first principles

  • You need to store lots of persistent data in your application. There are two approaches

    • You can compress the data and store it to save disk space

    • You will store the data as it is as you cannot afford the time involved in compression/decompression, but it needs much more storage


Trait 4 how to make tradeoffs l.jpg

Trait #4: How to make tradeoffs

  • Throughout your career, you will be pushed to look for tradeoffs in design, code and testing

  • All resources are finite; When it comes to design/code, you will get a budget and you need to manage within that

  • You need to understand contradictory requirements and come up with pragmatic tradeoffs

    • Caching: Size vs Performance

    • Object oriented development vs size/performance

    • Single thread vs multi thread; Cost vs benefit; Living with old architecture vs moving to new one and so on..

  • You can have religious beliefs, but be prepared to tradeoff if reasons are compelling

  • There will be pulls between budget, time, features and quality. This is a delicate balancing act, you will do throughout your career.

  • You need to define and adhere to acceptable levels in all these and get key stakeholders on board

  • Best engineered solutions are a beautiful pieces of tradeoff between contradictory factors

  • Making a right tradeoff is an art that you will learn over your career. It does not happen in one project. Learn by observing experienced people!


Trait 5 how to think long term l.jpg

Trait #5: How to think long term

  • You should not think that your code has short life span

  • Your work could survive many years and be used across multiple product lines

  • Cobol code written for IBM mainframes in 1970s were taking care of banking operations till 1980s

  • CMC designed CRIS system for railway reservation in early 1990s. It supported 100 terminals. Today, same core is still running but supports internet booking, credit card gateways, SMS and web frontends, IVR and scales to millions of transactions!

  • BSE stock trading system was designed by TCS for a small load in 1980s. Today, load has soared multiple times but same system runs on faster hardware

  • Don’t design/architect in such a way that you are forced to throw it away after sometime and do a fresh engineering. Avoid kludges unless absolutely required

  • Continuously refactor code

  • Remember each cycle of engineering takes time and money!

  • A good design/code is a piece of art, will survive years and is beautiful!


Trait 6 l.jpg

Trait #6


Trait 6 never stop learning l.jpg

Trait #6: Never stop learning

  • The world of technology keeps changing

  • Engineering development framework keeps changing

    • 1st generation: Mainframes, COBOL, batch processing

    • 2nd generation: Mini computers

    • 3rd generation: PCs, client server, network computing

    • 4th generation: web applications

    • 5th generation: Web 2.0, collaboration, co-creation, software as service and so on..

  • Each cycle of change has made engineers to learn new frameworks, languages, environments, paradigms and adjust to them!

  • If you don’t adjust to new realities, you will be come obsolete!

  • Learn “Programming” and not “Languages”

  • You can survive only if you embrace change and keep learning throughout your career!


Trait 7 pride l.jpg

Trait #7: Pride

  • An engineer should pride himself/herself of his/her work

  • Pride does not mean bragging or boasting

  • Pride means feeling good about what you have achieved

    • Met tight performance requirements

    • Managed a big change request without affecting existing design

    • Found an elegant workaround for this fix

    • Did a good tool in open source that helped to automate all my tests

  • Like your work and enjoy the challenges it provides

  • This acts as a tonic to you and makes you to face challenges!


N rajagopal info@mindtree com l.jpg

ImaginationActionJoy

N. Rajagopal

[email protected]

www.mindtree.com

© 2008 MindTree Limited


  • Login