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

[jd]

On the other hand, there are some universal rules:

• Plan/Design everything
• Document everything
• Version control everything
• Test everything
• Deny everything

Re:Go with the flow

[Anonymous Coward]

For the complete list see how to write unmaintainable code at:

http://mindprod.com/jgloss/unmain.html

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:Always think about maintenance

[enkidu]

Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?
- Brian Kernighan, "The Elements of Programming Style", 2nd edition, chapter 2

Get out now

[Anonymous Coward]

Get out, now, for the love of God, while you still can.

Document your code

[TheSpoom]

Tab out everything in a code block. This should be obvious, but you'd be surprised how bad some stuff is out there. And try not to put in too many one-line ifs without brackets delimiting the code block... you can easily make the mistake of thinking something should be in the if's scope but isn't becuase there are no delimiters.

Comment. Comments are incredibly, incredibly important. They kinda go along with an overarching "don't be a douche" rule; while you may know what's going on in your own code, if it's at all complicated, tell the reader what it's doing. If you don't, someone is going to be very pissed at you later. If you want to go above and beyond, do Javadoc (or other style appropriate to your language) comments where appropriate; a lot of IDEs actually hook into them so you can highlight a method and see what it's doing.

And try looking at / working on some open source stuff as well. The big apps usually have a coding style they follow throughout and aren't that bad for a reference.

Re:Goto is good

[bigstrat2003]

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

Stay away from the vending machine!

[Anonymous Coward]

Eat healthy and exercise. Pack your lunch or buy real food instead of the overpriced over-caffeinated junk in the vending machine. You'll save money and feel better.

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

A few tips

[mr_mischief]

I'm far from a master programmer myself, but this much I know.

• Don't get attached to your code. Your code sucks as a newbie. Your code will suck a little less with experience. Even the master coders sometimes write a section of code that sucks. Much of the difference between a newbie and a master coder is that the master coder recognizes his own mistakes when he comes back to them and rips his old code apart to be replaced by new code. The quality of the application as a whole is where to take pride if you're going to be proud of something. Being overly proud of a line, a function, a class, or a library will often get in the way of the quality of the application. Your users don't care about the code you write or how clever/inspired/tight/beautiful/special it is. If rewriting part of the code improves the application, then that's what matters.
• Bugs happen. Fix them without blaming or arguing. Don't place blame on the people who wrote them. If blame must be placed, place it only on the code in which they were found. Your job is to make the code work, not to piss people off by pointing fingers. You'll write bugs into code, too, anyway, and you don't want every one of them thrown back in your face.
• Make a habit of promising less and delivering more. It's much better than the other way around.
• If you're doubting how to design or code a section of a program, ask two people whose programming styles differ. Take as much of the advice of both as will fit into one solution. Try to change which two people you ask from one task to another, even if some of them are not the absolute best programmers on the team. You'll learn more this way than attaching yourself to one mentor unless your mentor happens to be a world-class wizard. You'll also keep allegations of cronyism and team splitting down.
• Use source control of some sort. Even if your team doesn't use it overall, use it for your portions. Even if it's something really basic like tarring up your project directory at the end of every work day and keeping the tar files, do it. Try to subtly hint at its benefits for the whole group if they're not already using it.
• Learn a programming language completely different from what you use at work in your spare time. The perspective it gives you can be very helpful. Lisp, Scheme, Haskell, Erlang, and Forth are good candidates for most people to pick up. If you're not exposed to one of Python, Perl, or Ruby at work, pick one and study it at home, too. Any one of those will do, although my personal preference is Perl (after all, it's just a personal preference). JavaScript's object model is interesting, so that wouldn't be a bad choice either.
• Don't read /. and other sites too much when you need to be coding. It's great to take a break and come back to a problem, but don't overdo the break part when a deadline looms. Cramming and hurrying when coding isn't as easy as hurrying up many other kinds of work.
• Get plenty of sleep and drink plenty of fluids. I know it's old advice and it sounds corny. All those tales of lone hackers coding all week on coffee, Jolt cola, cold pizza, pot stickers, and hot and sour soup are romantic and inspiring. They're stories about great people getting stuff done against the odds, though. You need to think clearly to code well. If you can think clearly on 3 hours sleep and cold pizza night after night, then good for you. If not, take care of your body so you can concentrate.
• Set reasonable short-term goals on projects and cross them off one after the other. You don't have to knock the whole project out as one commit two days into the schedule. If you can schedule kind of conservatively and get ahead of schedule, then use that time to improve your code or save it for troubleshooting later in the project. Don't get cocky when one module gets implemented smoothly and tell your boss to shorten the whole schedule. It'll just come back to bite you in the ass if you do.

Re:Goto is good

[TheRealMindChild]

http://imgs.xkcd.com/comics/goto.png

Moral of the story: Even when you think a goto is OK, you will still get eaten by a dinosaur.

Learn by example

[Repton]

1. Read The Daily WTF. 2. Don't do that.

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.

Some tips

[sukotto]

Here are a few tips off the top of my head.

* Learn how to use your company's version control system.. and *use* it

* Comment your code and be smart about it.
That is... Keep the signal/noise ratio of your commenting as high as possible.
Comment the big picture and a description of what tricky bits of code are supposed to be doing (and why). Not commenting trivial things.

* Avoid putting tricky bits in your code :-)

* Never assume that some code you write is temporary. Lots of mission-critical systems started off as a "temporary" project.

* Always try to write the best code you can, even if it's just a little one-off (see above point)

So, that means making sure your function names, variables, etc all have intelligent names. Each block of code does one thing. Each block of code is small (try to keep it on a single printed page, including all whitespace and comments)

Avoid using global variables, gotos, tightly coupled code, code that messes with the internals of objects/data-structures, etc.

* Set up a little svn server on your workstation for all those little snippets of test code you write. You never know when you're going to want to go back and look at that stuff again.

* Read other people's code. Try to figure out if it does what it's supposed to do.

* Get a good IDE and learn how to use it really well. Use the same one as the majority of your dev team (unless it really sucks).

* Make yourself as FAST as possible. If you're really fast/efficient then you have more time to think and solve problems:
- Learn how to type. seriously. get a typing tutor program and do 30 minutes a day until you can touch type as fast as you can speak.

- Learn the hot-key combos for your programming environment. You won't believe how much faster you'll be.

- Stop using your mouse for common tasks.

- Use code templates everywhere you can get away with it. Every time you start a new file, every time you write a new function

- Learn the idioms of whatever language they have you using. You should never have to stop and think about common constructs in your code

* Keep a spellbook. If you learn anything cool, interesting, or elegant. WRITE IT DOWN. By HAND I know it sounds stupid, but it really helps

* Learn how to accurately estimate your time. For everything you're asked to do. Write down how long you think it will take (in hours). At the end of the task, or the end of the workday, track how much time you've currently put in, and how much more you think you'll need. (Never modify your original estimate). Then, when people start asking you to estimate how long a project will take you'll have some historical data to help you come up with a realistic number.

Pro tip... when you're starting out. Multiply all your estimates by 3. Newbies are usually way too optimistic

* Read. lots
Read books on the language your company expects you to learn. Try to also read general books on programming, design, project management, etc. Try to understand the big picture of your project as well as the nitty-gritty of the part you're working on.

Some good books to get you started
- Code Complete
- Pragmatic Programmer: from journeyman to Master
- Programming Pearls
- Joel on Software book
- Mythical man month
- Getting Things Done

* At the end of each project, keep a log of what the project was called, what it was for, who it was for, and what you did to contribute. You can also jot down what language you used, what gotchas sprung on you, your estimate accuracy ratio, etc.