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).

Re:Go with the flow

[digitig]

Then again, what books to read as programmers can be a whole other post,in fact I think it's come up.

Yes, but the general principle of "keep reading" is a good one. Read code. Read books (online or dead tree). Read articles. Read about new technologies, new approaches to old technologies, innovative solutions, successes, failures, pretty much anything. The person who stops doing background reading once they can do their job is a person who stalls and gets left behind. Do read critically, though, and remember Sturgeon's 2nd Law ("90% of everything is crap") -- there's nothing (well, not much) worse that someone who wants to overhaul the complete development process just because they read a magazine article about a new approach that promises to solve all the problems of everything that went before!

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.

Listen, think, and listen

[truthsearch]

- Listen to your end users. They're the reason you're writing the software. Even when they ask for something stupid, be sure to listen to their needs.

- Listen to other smart developers. Find the smartest experienced guy in your new team, or other similar teams, and pick up tips and feedback. There is a LOT that can easily be learned from other smart people's experiences. Ask questions, but don't be annoying. Following a few bloggers in your field can be helpful if you find the right ones, but an experienced person on your own team would be best.

- Read up on general best practices. Indent your code consistently, write comments, name variables and functions well, etc.

- Think about your code long term. Code is rarely used just once and never looked at again. Write it so it should last and be relatively easy for you to pick up a year later or for someone else to take over.

- Don't box yourself into one line of thinking. If you become religiously attached to one particular language, for example, you'll eventually stagnate. Learn the best traits of a variety of languages and systems. It'll make you a better all-around programmer.

Comment removed

[account_deleted]

Comment removed based on user account deletion

Work a year or two doing maintenance

[MikeRT]

There are a few advantages to starting with maintenance work:

1) The majority of the work is probably done for you.
2) You'll have a chance to force yourself to get used to working with someone else's code.
3) If you have good senior software engineers working with you, you'll have people who can show you how things ought to be done/have to be done.

I've been out of college for nearly three years, and most of my experience has been cleaning up the mess that others have made. Usually the projects have been ones written by cheap consultants who got the contract by bleeding themselves dry on their bidding. You'd be amazed at how obviously bad a lot of the work that these do, even though you're just getting out of college.

Write good descriptive comments...

[madhatter256]

Try to right program code comments as much as possible as long as memory permits it (if you do have a memory cap).

It makes your job down the road a lot easier, as well as other people's job easier, too.

Try to have it make sense, too. Overall, doing this helps you in retaining how the code works step by step so that you will almost know it like the back of your hand.

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.

Use a slow machine

[www.sorehands.com]

Use a slow machine with little free memory to test your code. It teaches you to be efficient. That is why 1GB of ram is not enough for an office anymore.