Dummies Guide to Software Engineering

I am not going to beat around the bush for this topic, its going to be straight forward and as blunt as possible. Its almost a year since I entered this industry, I did finally manage to be a part of a product release . You may not find most of the things that I have mentioned here in any Software Engineering book. If you can learn everything from reading books, then work experience has little value. To start of, the whole information technology(IT) industry in India is based on one word "Out Sourcing". Some people might feel this word applies only Service based IT firms and not Product based ones. American firms that are present here rarely if at all allow you to take ownership of Products in India. If at all they allow, its because the Product has reached its end of life, you will end up taking ownership for the Product in the name of sustainance. If you're part of brand new product development, consider yourself very lucky. The optimism of youth is often is greatly under estimated, I loved writing code in college. Being software engineer you would be expected to code , its one of the basic things your associated with. After entering this industry, at least in India I found out there more jobs here on which you can make a living without ever bothering to write a single line of code. Unfortunately the job titles companies give have engineering associated with them, which makes mockery of what a Computer Science Engineering is.!!! I would like call this jobs as Glorified Customer Support (GCS) or So called Engineering jobs. Now, how do you make out if you ended up in this jobs?? If somebody who doesn't have anything in relation to Computer Science , who hasn't bothered to master the essentials of programming, can do your job after the initial training as well as you can, then YES, your job is a GCS. Now here are a few myths and facts which I observed

1. As a fresher if you dream about writing code from scratch for a product, it will stay a dream for most of the time. There is already enough legacy code out there ,the odds of you doing this are next to nothing, you ll be mostly going through and making changes to some one's code.
2. If you're eager to learn new stuff and want to design,build your own product, then start ups are the place to be. Often with Large corporations, they have definitive roles with defined responsibilities, its like a being trapped in a box. You need to stay inside that box whether you like it or not. Going to work for a large company is like getting on a train - Are you going sixty miles an hour or is the train going sixty miles an hour and you're just sitting still???
3. No matter how much you howl or crib about, your American counterpart will be better paid than you, even if you end up doing more work than a average American does or more talented than him unless and otherwise you happen to work in America.
4. Acid test to see if people you employee for programming can code, Cut off access to Google or preferably internet itself and ask them to code. I bet most people from non Computer Science (CS) wouldn't be even able to compile their code, if at all run a program. As far as CS goes they might be able to run and give something as output, though it may not be what it is required.
5. Some companies have a policy not differentiating people from non CS and CS. Now this is an important indicator, this are companies you shouldn't take a job in, otherwise you ll end up doing GCS. Whats more annoying for you , especially if your from CS, people who never even heard of java will be allowed to write java programs while a CS guy would be put in GCS job.
6. Here is a tip for all those managers who work in companies who take people from CS and non CS, getting the right people in right jobs is far more important than just allocating more people as mere resources to projects. Quality can never be compensated with quantity. Going by this rule a CS guy should have a higher probability landing in a programming job then a non CS job. If this is not the case, then your Resource allocation program in your company program is screwed big time.
7. In software development there are more people issues than there are issues with specifications or features or code. This is unfortunate but true. As a programmer I would clone myself ten times over and allow myself to write all the code , rather than allow 9 different people to write code. Too many cooks , Spoil the broth. But with Software engineering you would always have too many cooks, but you need to come up with a wonderful dish at the same time.
8. 'Quality Engineering' (QE), we had one big chapter on this in Roger D Pressman's S/w Engineering book. Mostly I used to find it a mundane topic , whenever it was taught in class. People with right aptitude for QE are as much important to success of a product as people Good Programmers are. At higher level we do need people from CS in QE , to ensure quality, but lower level it doesnt really make any difference. Ideally QE is right job for people from non CS but who are interested in IT.
9. This is for all QE Managers who take QE seriously. In theory, there is no difference between theory and practice. But, in practice, there is. Doing plain QE without knowing the code is like learning engineering with theory but no practicals.
10. Often managers in IT could get too much cobbled up, in deliverables. and metrics. The mantra here is not getting things done on time, but it should be getting things done right. Metrics are just another indicator, they are like a women's skirt, they hide more vital things than the reveal.It is easier to measure something than to understand what you have measured.
11. The perception of favoritism is can be as bad as inequality in the cohesiveness within a group. This ones again for mentors and managers. Its often easy for people to get cozy with a few people in a team whom they like then others, after all its human nature to pick favourites. But if that favouritism influences your decisions at work, then your laying the foundations of breaking up your team.
12. Combine a deadline for delivery date, with large numbers of bugs, add to it shortage of trained resources to solve those bugs. What will a manager do?? He ends up deferring bugs to meet the release date. Deferring bugs never fixes bugs. Its like your being an ostrich digging its head beneath the ground and pretending its not in danger, when its faced by a threat.
13. Slogging your work during weekends to meet a deadline under pressure, will lead to more slogging. Slogging will never ever be a replacement for having a proper Work Plan in Place. Remember, the very moment you start slogging, it means something in your work plan is under estimated.
14. I’m a programmer, and I want to change the world, but they just won’t give me the source code. This one of typical out cries you hear. Coding is just one aspect of programming. The even more important thing is coming up with ideas how to implement things. Your good old O(n) vs O(nlogn) vs O(n^2) stuff. Call it a downside of having chain of management , Getting people who program to listen to people with ideas is one thing, getting people who program to accept those ideas is a whole another thing.

This are just a few of the issues that most of "want to be CS engineers" will face at workplace. Atleast it will help in setting the aspirations for a fresher who comes into IT , for what to expect and what not to expect. Expectations after all are the basis of all disappointments in life.!!!!!!!!!

Tweet