What To Do Right As a New Programmer?

globeadue writes "My company just tagged me for full time App Dev — I've essentially never coded for money, but the last 3 years of support desk gives me the business sense to know the environment I'll be coding for. Now my company will be training me, so I think the technical side of things will be covered, what I'm looking for is best practices, habits I should/shouldn't develop, etc as I take on my new craft."

Comments

Go with the flow

[Anrego]

Well, I think you'll probably pick up those best practices as part of your "training".

Every shop does things differently.. from simple stuff like naming conventions right up to core design methodologies and team management.

My advice would be to just spend as much time as possible listening and observing. Read through existing code.. pay close attention in meetings to how the brainstorming and final solution tends to evolve.

Some companies take a "we are paying you for your intellegence.. part of your job is to argue your design and beliefs" attitude whilst others take more of a "we are paying you.. so shut up and do it the way we want" approach.

As a side note.. check out the book "Beautiful Code"... It's good mind food. "Pragmatic Progammer" is also good.

Re:Go with the flow

[martinw89]

I agree to an extent. As a new developer I think it's important to listen to more than one source. So listen in training but also be skeptical. Try to find other sources for claims.

And as for my book recommendation, I suggest "Code Complete"

Re:Go with the flow

[SQLGuru]

Great stuff. Find a mentor. Most technical classes focus on how to use the language, never how to use it right.....at least not until you get to the advanced classes, which as a new dev, you aren't ready for. The best place to learn these things quickly is to figure out who in the group knows what (and is friendly/helpful) and glom on to them. Become their friend (bribe them with caffeinated products) whatever it takes. And absorb everything you can from them. This will usually take more than one expert (best design guy, best coder, best db guy, best politics guy). Just don't be a pain about it....if they explain something once, write it down and don't ask them about it again except for further clarification.

I love taking people under my wing and helping them grow, but if they keep asking the same questions, I see that they aren't trying to learn anything and just trying to take advantage of my knowledge. I still help those people for the good of the team, but usually with "here's your answer, now go away" approach instead of the "here's your answer, oh, and here's a better way that will make you a better programmer" approach.

Layne

Re:Go with the flow

[Nefarious Wheel]

Remember at all times that "Listening" isn't the same as "waiting for your chance to speak". You'll get better mileage by laughing at the customer's jokes than telling your own.

Keep your reading up, and buy those books.

Keep a register of absolutely everything anyone asks you to do. Number and date each item. If you don't have access to a help desk-style problem registry then build your own. Make it quick to use. Notepad works. Spreadsheets a little better. BMC Remedy or HP/Mercury Interactive if you're spending someone else's money. Besides being good organisation, it's a serious cover-your-tail survival bonus.

Make your code clear. You want it to be so easy to read and understand that you can debug it over the phone in a new year's eve party if you have to. (Yes, I've had to.)

Comments first -- if you can't explain it in English, you probably don't have a handle on the problem yet. If you're chasing your tail and can't get that loop to work right, throw the code out and re-write it in English. Then try coding it again. Remember that English, your natal firmware, has been debugged over the course of your entire life and is still the highest bandwidth channel to your brain. (If you can write correct English, of course. If you don't, treat it like an essential coding discipline you have to learn.)

Be careful with your code libraries, and avoid bloat. If you're sorting a customer's web shopping basket, consider writing the sort yourself rather than including 200k worth of otherwise unused code. Even the lowly and properly-maligned bubble sort is better than that.

Conversely, never write your own little calendar applet if you can grab the code off the web. Plenty of work out there without requiring everything to be crafted with your own unique style.

Never, ever code when you're tired, you will break something. Caffiene is for the smiley boost during the work shift, doesn't cure the 10th hour stupids.

Disclaimer -- I've been a programmer for nearly 40 years, so I'm probably a stupid old person now. You're allowed to ignore the above (heh heh).

Always think about maintenance

[Mad Merlin]

Probably the most important thing you can keep in mind when writing new code is to think about the poor sap who has to maintain that code somewhere down the line. Especially because in a lot of cases, that poor sap will be you. Pretty much everything else follows naturally from there.

Re:Always think about maintenance

[try_anything]

There's a famous epigram (hopefully someone can provide it) to the effect that it's twice as hard to read code as to write it, so if you write your code as cleverly as possible, you will most certainly be unable to read it.

If you're proud of a clever solution and can't wait to show it off, then it's an unsatisfactory solution. The best solution to a difficult problem is the one that is so clear that after reading it, nobody can comprehend that the problem presented any difficulty in the first place. The sign of a really great programmer is that he never gets stuck with any difficult projects. Everything assigned to him turns out to have a simple, easy solution -- what luck!

Re:Goto is good

[bigstrat2003]

Hey, I like the ? : construct. You leave it alone!!!

Experiment and dabble in other languages

[BrynM]

Don't stick to just one language (the one they expect you to use). Learn how to do some basic things in several languages. This will help you understand "programming" rather than just knowing a language. Many of the same semantics apply in many languages with only the exact syntax changing. Learn the concepts not the implementations. This doesn't mean that you should try to code in many languages for your job, but as you are presented with problems do a general "how to do x" web search before you do a "how to do x using y language". The best coders I know see a particular language as a tool rather than a mandate. If you only stick to one language, you are imposing an artificial limit to your thought process and ability to problem solve.

Comment removed

[account_deleted]

Comment removed based on user account deletion

Re:Goto is good

[Rei]

I strongly agree. Self-describing code is much better than comments. Comments are only useful, IMHO, when you need to describe a complex situation. If it can be expressed in one sentence or less, it should probably be part of the code itself. I.e., instead of:

std::string mkdec(std::string x) // Converts x, a string representing a hexidecimal number, to a decimal string.

std::string convert_hex_string_to_decimal_string(std::string hex_string)

The latter says the exact same thing, but is far likelier to be maintained properly. Also, if you get in the habit of coding like that, you never have to worry about forgetting to comment. Furthermore, the "comment" is effectively replicated every time the function is used. Hence,

instead of:
hex = "0x" + number_str;
return mkdec(hex);

you see:
hex = "0x" + number_str;
return convert_hex_string_to_decimal_string(hex);

Now, if you had a function that implements a complex algorithm that can't be summed up in short order, then sure, use a comment. But in my experience, 95% of comments in code are like the above "mkdec" comment, and would be better expressed just by using a more descriptive function or variable name. I think a lot of coders are just lazy and don't want to have to type in longer, more descriptive variable and function names.