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.

Columbo

[MarkusQ]

Find and watch episodes of and old cop show called "Columbo".

Whenever you are unsure of anything, act like Peter Falk's character (Columbo). Whenever you are very sure of something, try even harder to act like that. If things don't make sense to you, ask questions, do experiments, use google, use your brain until they do make sense. And if you have a theory (or a plan, or a piece of code) that you are sure is right, put it to the test.

Don't be a know-it-all, don't blindly assume that you know anything. People sometimes get annoyed at developers who take nothing for granted, but that sort of attitude gets results, so they put up with it a lot longer than they put up with developers that assume they already know everything and project that assurance right up to the point where the project goes down in smoldering ruin.

--MarkusQ

Left-corner design

[steveha]

25 years ago I read a book called Software Tools in Pascal. This had a huge, beneficial impact on me.

The most important single thing I learned from that book is something they called "left-corner design". It goes like this:

Find some small part of your project, preferably something at the lowest design layer. Then code it up and implement it. Make it so brain-dead simple that you can spot all the bugs, and fix them. Now, consider some simple way to make it do something more, something else needed for the final product. Then make it do that, and fix it until the new feature is also working perfectly. Iterate.

As a real-life example, I once made an advanced audio DSP (digital signal processing) engine. It started out as a program that could open a wave audio file, read all the samples, and write them to another file. Then I added a function that could do some simple processing before writing the audio. And then I added some more stuff, and some more, and so on.

As much as possible, make early prototypes that actually do some useful subset of the problem you are trying to solve. If your program will have users, give them early prototypes and see what they say. The Software Tools book had an aphorism that 80% of the problem solved now is usually better than 100% solved later.

You may also find that, as the users try out your prototypes, they may discover surprising things. Perhaps what they originally asked for isn't what they really wanted, and you need to drastically redesign. Perhaps once they start using your prototype, they may invent new features that they really want more than some of the other stuff they asked for.

And perhaps you may get a surprise: "Yeah, we told you you could have 8 months to develop it, but now you only get 4." And three of those months are already used up. The left-corner design hopefully means you will deliver something. And it might just be enough.

The opposite school of design would be to think everything through and plan everything. Hold long rounds of meetings, draw diagrams, that sort of thing. That may actually be appropriate in some industries; if that's how they do things where you work, study it and try to figure out if they have a good reason for it. But even if so, you may need to knock out some sort of handy utility for your own convenience, and left-corner design is the way to do that.

steveha

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.