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

Read Risks Digest

[Jah-Wren Ryel]

Read The Risks Digest -- it ought to be required reading for all software developers because it is fundamentally about how systems fail and if you don't have a good grasp of how the system you are building might fail, then you will probably build it in such a way that it will fail like a house of cards the first time a stiff breeze blows.

It is low volume with pretty high signal-to-noise ratio so it is not a burden to stay current, and when you have some dead time the back issues - going back for more than two decades now - make for great reading too.

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

[Almahtar]

I'm pretty much in agreement. The compiler can't check your comments: It's explicitly told to ignore them.

While it's a ridiculous example, someone could easily change

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

To

std::string mkdec(std::string x) // Do a little dance, make a little love, get down tonight

And everything would still compile just fine, but all of a sudden new devs on the project are left in the dark as to what mkdec() does without reading through its code. If someone named the function convert_hex_string_to_decimal_string something cryptic or incorrect it would appear in many places (everywhere the function was used) and be much more noticeable and likely get fixed sooner.
Another fun one I've seen in legacy codebases a lot is

//Only used in this place or that place, or for this or that purpose.
int some_func() { blah }

... and that comment was written 5 years ago and is completely wrong. People used doxygen or intellisense or whatever and saw that this function exists and takes the input/output they want but never saw that comment so they used it in 1000 other places.
Or another fun one.

/* function foo()
does this, that, and another thing.
... big long description of inputs, outputs, constants that affect it, whatever ...
*/
void foo() {blah }

... and the description is horribly out of date because it's been changed a million times.

I'll say it again: the compiler can't check your comments, and it's just too easy to change some code that will make a comment wrong and not realize it. So comments have their place but their use should be judicious.

"Self documenting code" (good variable and function names, etc) that the compiler can verify for you are preferable.