Advice To New Programmers

So you are starting in this business?

First of all, ask yourself why!

What future do you think programmers have? Why do you want that future for yourself?

This is not intended to dissuade you, but to remind you that you are the most important consideration in making such a choice. Make sure that you go in with your eyes open, knowingly and don't just drift into programming because of a current interest, fad as they say.

ProgrammingProfession lists some alleged down-sides of the profession. At least be familiar with them to prepare your mind and future.

If you decide programming is for you, also ask yourself - can you take advice?

If the answer is yes' then here are some suggestions from some who are already programmers, and from others interested in the subject.

Listen to other programmers, including older ones, and try to learn from them. Experience is not spending 25 years repeating the same mistake despite what some starting programmers seem to think.... Competent programmers are like wine: they get better with age.
- I don't know that I could match features-per-hour of my younger years, my eyes and fingers are not as nimble, but my code is better organized, more flexible to changes, and easier to maintain overall.
There is a magic word called being organized. Spending time on designing a system of organization is always time well spent.
Get the big picture. Don't let the details clutter your memory. Commit the details on paper or on index cards.
- A PersonalWiki to keep track of details can also work very well.
  - As can a PlainTextFile?
Remember than there is a life outside programming. See CategoryLifeStrategies
For the technically inclined, the most difficult part about programming is understanding people (clients) wishes. Being open and human is a very important asset. Programming is about solving people's problems and not technical difficulties.
Just as plumbers and electricians need tools, programmers also need tools to work with. Here is one way to build your own set of tools: everytime you learn something new, write it down on an IndexCard (preferably a 3x5 or a 5x8); classify all the cards according to subject-matter or to programming languages and keep those cards handy. You can use different colours also, a color for every subject. These cards will be your set of tools. You'll be surprised to see in 5, 6, 10 years that you have forgotten how to program such and such function; when that happens take a quick look at a card and you will have the answer right there waiting for you. These cards will save you time (and money), effort and aggravation.
Show enthusiasm for your profession. Without this fire, you'll find long days behind a keyboard a royal bore and people around you will feel the same.
- To the contrary, I would suggest that you be professional in your approach. A workmanlike attitude, a professional attitude will see you through the times your enthusiasm is suffering a decline.
Success in programming as in every other profession is based on hard work. Here also like Thomas Edison said: "Genius is 1% inspiration and 99% perspiration". There is no magic recipe: there is work and work and work.
Design your functions slowly, carefully, using diagrams on paper if need be. Avoid SpaghettiCode at all costs. It is the programmer's worst enemy.
- The first part of this runs contrary to ExtremeProgramming. Is it being offered by an experienced programmer?
  - I am not involved with the advice, but I would suggest for new starters, it is best to follow the slower approach. ExtremeProgramming comes to be useful after one gets familiar with the rule book. It takes experience to develop the taste for simplicity, and skills to know how to achieve it.
The first part is a restatement of ExtremeProgramming. You write a test, considering what exactly you need to do, using index cards to model the interactions (or anything else) as required.
Gather and organize your set of tools (lint, wiki, DoxyGen, GraphViz, vi, tc, whatever) and keep an archive of your reusable code.
Practice estimating how long projects will take (not just IdealHours?, but also what real day it will be finished). Sure, you can finish school assignments in a couple of days -- but that is because the teachers specifically design these assignments to be finish-able in a short amount of time. Don't let that trick you into thinking that all programs are finish-able in a couple of days. Sometimes it will take a week, other times it will take months -- being able to tell the difference is a useful skill. TimeManagement.
- Concur. Some teachers of low-level CS classes pass out time sheets to aid students in tracking the time spent on homework. The basis of estimation is self-knowledge, after all.
Read code. First, brush up on your CodeReading skills. You'll need a couple of tools to help you grasp anything but the simplest script, pick ones that work for you. Now dig into the guts of the code of a well-written system. There are examples of good and bad available in open source form. Analyse and understand it in a way analagous to how your English lit teacher would have you study a play or short story. What are the key concepts in the domain and how are they expressed? What data structures does it use, and why? How are the modules or class hierarchies defined? What are the idiomatic code structures and how does the system use patterns? A programmer will spend 80% of the job looking at and trying to understand existing code, and the non-code documentation will never be sufficient for comprehension. Extending or fixing an existing system is most of the job. Learning what makes for ProgramComprehension makes it possible to write better code.
Keep in mind OnceAndOnlyOnce, but don't get carried away too early. The EightyTwentyRule will bite you hard if you over-abstract and over-factor. Experience will teach you balance and when-and-where.
Embraced optional (defaulting) "named parameters" (KeywordParameterPassing). They can improve the flexibility of code.
Know one strong-typed language and one "scriptish" language fairly well. They each have their place and value and both teach you things. And you are better prepared if you have to leave your job and start somewhere else.
WorkBackwardFromPseudoCode. Focus on representing the problem-space first, and then jump into the technical issues of syntax, languages, etc.
Be skeptical of new buzzwords and alleged GoldenHammers. It's good to have enthusiasm about new tools and techniques, but do it with healthy dose skepticism.
Learn about RDBMS, SQL, A.C.I.D., and schema design. Schema design skills help you factor concepts and plan even if you don't actually use a database much in your domain.
Don't get too attached to your tools. Change them often.
- Heresy to Emacs fans.

CategoryEmployment