WHAT'S NEW?
Loading...
download
How can I quickly become a good programmer?
1.Decide why you want to become a good programmer: Is it because you want a job, preferably in a high paying software firm? Great. Then you are set to reach NOWHERE. All good programmers I know are good because they loved what they did. Develop interest in programming. See, programming is the only branch in engineering where you can straightway apply what you learn. Your dad may have a car but he certainly wont allow you to tweak the V2 or swap it for a v6 just to see what happens. But with computers you can do whatever you want. You want to simulate a virus? Cool. Install a virtual OS and run it. Then, when you are done, remove the virtual hard disk. If you are good at what you do, you will get paid and surely get that dream job. Yes, even I want to work in a big software company. But thats not because of the fat paycheck. Its because of the work they do. Because of the exposure I will have. Have you ever bothered to find out what all these companies do and the enabling technologies behind their products or the kind of R&D they do? Jobs will come. Dont make yourself a sucker for one. Sachin is not a great cricketer today because he decided to play cricket to earn money and get dozens of endoresements.
  1. Programming languages:Internet Explorer. Being built on top of the Internet architecture does not necessarily require an active connection to the internet. It means that Web applications are built on top of standard web technologies such as:
    HTTP
    FTP
    POP3
    SMTP
    TCP
    IP protocols
    HTML
    XML
    Coldfusion
    ASP
    JSP
    PHP
    ASP.NET
    670px-38720-81
  2. Algorithms: Any good programmer has a good understanding of algorithms. Its not necessary that you know each algo by heart (in fact good programmers never learn things by rote) but you must understand when to use what. Algos will broaden your understanding and give you new ways to tackle problems. Another important thing is Data Structures. Its more important than algo. Once you have chosen (or developed) the correct data structure, the algorithm becomes self evident. For algo, read the book “Introduction to Algorithm” by Thomas H Cormen et al. You may also refer Andy Tanenbaum’s “Data Structures in C and C++”. Also if you have desires to participate in coding contests (the respectable ones), “The Art of Programming Vol I to V” by Donald E Knuth are mandatory. Also may be “Concrete Mathematics” by Donald Knuth. Again reading does not mean remembering everything. Just try and understand whats written.
programmer
  1. Coding contests: Coding contests are good for developing your algorithmic skills and they make you think fast. Its a good idea to participate in ACM ICPC or Page on topcoder.com. Then there are coding contests (like Sun’s Code for Freedom, Google’s Summer of Code, Microsoft’s Imagine Cup) where you develop a complete software. Such contests are spread over many months. Both require different sort of skills. You may be good in one and bad in another and yet you could be a good programmer. Contests like ICPC require lot of practice, fast thinking and you are expected to keep algos at the back of your mind. CFF, GSoC, on the other hand, requires creativity and focus spread over a long period of time. You dont have to come up with solutions too fast and you dont have to mug up algos. ICPC is like T10 while CFF,GSoc and Imagine Cup are like Test Matches. I would suggest you to participate in both types and then decide if you want to focus on either or both.
  • Design Patterns
  • Why? At its core, most programming problems belong to one of only a few general categories. These general problems have already been solved thousands of times – and are well-documented in a couple of “design patterns”. Step back from the problem in front of you. And you’ll be able to apply a proven best practice instead of reinventing the wheel.
    Keep in mind: Applying design patterns shouldn’t become a religion. Sometimes, all that’s really necessary are a few lines of simple code…
    Any art is learnt by emulating. And therefore, you must emulate the best. Design Patterns are tried and tested architectural (of the software kind) solutions to some commonly encountered software design issues. And therefore, a basic knowledge of some common design patters in needed if you are planning to develop something that is even moderately complex. I suggest “Head First Design Patterns” from Oreilly as the first step.
    1. Learning by emulation: Emulate the best. And this is possible by reading books written by the best and/or going through code from some of the best free software projects. I would urge anyone serious about programming to read the book “The Art of Unix Programming” by Eric S Raymond (dont forget to first slap yourself for not knowing who Eric Raymond is and then googling his name). You are not a programmer if you have not read that book. Period.
    Now let me address a few common grouses
    a. I dont find any interest in computers and want to do an MBA:Mainly a statement often repeated by Second Year(sophomore) students. Thats really your problem. I did not ask you to take Computers or even to join Engineering. You did not know, or bothered to find out, what you were getting into when you took up this branch of engineering and I am pretty sure you have NOT bothered to find out what awaits you in a MBA course either. I am also quite sure that 2 years after an MBA (if not earlier) you will also say pretty much the same thing about your job. Well what can I say. All the best
    b. I dont like reading the books (or any books for that matter) that you mentioned above: Well this is not yet the world of Matrix where I can just feed in programming skills to your brain. Dont force yourself to read them. You can’t . Do it only if you want to. And if you don’t, please forget about being a good programmer. May be its time for you to use the excuse mentioned above (point a).
    c. Give me one programming language that does all: There is none. Each has a different purpose. And thats how things are gonna remain buddy.
    d. I want to a ‘real’ project: Thats great. You can do two things:1. Start one of your own 2. Join a FOSS project. But most people are not happy with this. They expect me to ‘give’ them a project, one thats easy (read, should not involve anything other than C and the only files you need to include should be stdio.h, conio.h (yes people here still use Turbo C) and may be string.h and math.h) and I should tell them what to learn. When people say this,they expect to go on a Autopilot ride.
    e. I will learn X programming language by this sem/year/decade :There is no way you can sit with a book and learn a language. You need to do some real work with it, develop some real software and not just do those exercises in the book (that is necessary of course but not sufficient). Most of the languages I have learnt are because I was forced to do so as part of some project. Just pick up the basics in a day or two and then apply it to a real life project. Need ideas? Come to me.
    Finally as Larry Wall says in Programming Perl : “We will encourage you to develop the three great virtues of a programmer: laziness, impatience, and hubris.”
    Laziness:So that you go to great effort to reduce overall energy expenditure. It makes you write labor-saving programs that other people will find useful, and document what you wrote so you don’t have to answer so many questions about it. Hence, the first great virtue of a programmer
    Impatience: The anger you feel when the computer is being lazy. This makes you write programs that don’t just react to your needs, but actually anticipate them. Or at least pretend to. Hence, the second great virtue of a programmer
    Hubris: Excessive pride, the sort of thing Zeus zaps you for. Also the quality that makes you write (and maintain) programs that other people won’t want to say bad things about. Hence, the third great virtue of a programmer.
    tga2013-presentation-want-to-be-a-programmer-32-638
    1. Unit Testing
    Why? Every programmer has experienced something like this: you change a bit of code in one corner, and in a (seemingly) unrelated corner, something breaks! The bitter truth is: both new and changed code will inevitably contain bugs. Use automated tests that help you keep old code stable.
    Keep in mind: You can also go one step further and write tests before your actual code. This can give you a whole new perspective on how to approach problems!

    0 comments:

    Post a Comment