Becoming a developer - the industry experience

[Mahesh Mohan]

Hi,

Many of you might be in BE and hopefully you have jobs to look forward to.

I have seen a lot of people in the industry who are either confused about the

wrong things or are fighting on the wrong fronts to make ends meet.

The standard level of quality that the industry expects is something beyond

our college education. Lets get one thing straight - the industry doesn't hire us

because they think we're awesome programmers, they hire us hoping that

we wouldn't turn out to be bird-brained morons who write bad code. So lets 

try and live up to that expectation first before we start our crusade to rule

the world.

Most of the development work that gets handed out these days is bug fixing or

addition of some new feature to an already existing monstrous software product.

First and foremost I'd like to clarify one thing straight off - debugging is not easy.

And its not bad work. Don't believe me ? Ok, then check out what the giants 

have to say about debugging :

“ Debugging is twice as hard as writing the code in the first place. Therefore, if 

you write the code as cleverly as possible, you are, by definition, not smart 

enough to debug it. ”     - Brian Kernighan

“ If debugging is the process of removing software bugs, then programming 

must be the process of putting them in. ”      - Edsger Dijkstra

Whether this is the case or not, you will be dealing with problems. There will be

a problem put forth and you will have to face it. 

There are some basic rules that you can follow to make sure that you're not looked

down upon. These rules help you write good code and create good software. Whether

you write code for a new software, a proof of concept, a legacy system or a cutting

edge product does not matter. You have to be good at what you do.

These are some points I'm re-posting from an answer that I recently

wrote on Quora :

1. Speculation is for sissies. Real men find the root cause.
Understand one thing and understand it well. When you're asked to fix a bug, 

assume that the fix is expected to be perfect. It can never be perfect unless you 

know for sure that you've fixed the right issue. Meaning, you need to be so sure 

about the root cause of the problem that you can argue about it with even a guy 

who is 10 years experienced and make sense. Know the entire stack of functions 

being called, all the factors causing the problem. Don't second guess something or 

code in a fix because it "feels right". Be absolutely sure.

2. Look at the bigger picture.
What you write as a bug fix might end up being a part of enterprise software or 

even end user consumer stuff which might be used by millions of people. Remember 

that they're gonna be mighty pissed off if your fix does not work. We give no quarters. 

What you do affects society. Never be the guy who makes weak fixes. Because 

you're promoting a culture here. A very bad culture.

3. Quality is not an option.
Refer point 2. There is another reason why quality is not an option. Because you 

take pride in a fix that you make. Its a personal embarrassment when you post a 

piece of code for review and someone tells you that the way you write code is just 

plain bad. Or when someone suggests an improvement. Or when someone points 

out that there are no comments in your horribly written code.

4. Understand that your fix is going to be part of a software.
What you write is not going to be standalone. Never will be. It will be part of a larger 

software. So there can be other factors which get affected by your fix. It will take 

some time for you to grasp the components of the software well enough to make 

sure that you don't make a boo boo, but try your best.

5. Use tools.
Tools save time. Period. You can speculate over a lot of things before you arrive at 

the correct function where you need to print some values into the log so that you find 

out the problem, but guess what, the tool could've revealed it much faster for you.

6. Test diligently.
Be absolutely sure that your fix is correct in all regards. Test it out well. If you hit issues, 

maybe the problem runs deeper than you thought it does. Fix that. Even before making 

the fix, I'd say its great to develop a habit of finding how to hit the problem in the first place. 

Be as innovative as you can in writing test programs or snippets which could hit the code 

path that you suspect to be problematic.

7. Use your common sense.
This is as important as anything else. I have seen code written to handle jobs in a 

multi-threaded fashion. It involved the interaction of two threads. The thread posting 

requests was single threaded. The thread handling requests was multi-threaded. The 

whole "we are multi-threaded" claim was a sham! Now it doesn't need more than 

common sense to understand what the problem here is.

8. Drop prejudice. 
You're looking at code. People who wrote it were perhaps more experienced than 

you. But that doesn't mean it can't be shitty. Look at code without being intimidated 

by it. Don't be over confident either. Code is just code. Find the problem, make the fix. 

Thats what they hired you for.

9. Know your shit.
Keep oiling yourself, studying the things that you already know. More often than not, you 

will require knowledge beyond just common sense. It isn't going to reveal itself to you. 

You shall have to chase it. So run !

10. Build a model.
Develop a sense of creating a model out of your field of work. List and understand the 

different components that exist in everything, and understand how they interact. Whether 

you do this for a software product, for an OS, for a computer or for the entire world itself, it 

will help you. This is how you become faster and smarter. There are no shortcuts to this. 

Once you see how the components interact and why they exist, you will get to the root cause 

much faster.

Regards,

Mahesh

[Ganesh Patil]

Hi Mahesh,

              Thanks Mahesh for sharing true fact about development. 

It is useful for both students as well as to the developers currently working in Industry.

Thank you,

Ganesh.

--
You received this message because you are subscribed to the Google Groups "(FG*)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fgstar+un...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
Regards,
Ganesh Patil.