Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

What To Do Right As a New Programmer?

timothy posted about 6 years ago | from the give-your-coworkers-good-nerf-guns dept.

Programming 662

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

cancel ×


Sorry! There are no comments related to the filter you selected.

Go with the flow (5, Insightful)

Anrego (830717) | about 6 years ago | (#25160397)

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 (1)

tekiegreg (674773) | about 6 years ago | (#25160469)

Oh certainly you're not going to forget the book "Code Complete" are you? Then again, what books to read as programmers can be a whole other post,in fact I think it's come up.

Re:Go with the flow (4, Funny)

Anonymous Coward | about 6 years ago | (#25160717)

Tip: Get together with your coworkers after work -- hit a bar on Thursday/Friday night, loosen up, relax, talk shit about your managers, etc. Find out what people do outside of work. Ask the girls if they shave their pussy, the guys if they shave their balls. If you're in the bathroom taking a piss together, compliment them on their cock. Little things like that make the work environment easier and the coding more fun.

Re:Go with the flow (0, Troll)

calmofthestorm (1344385) | about 6 years ago | (#25161009)

Or get you fired for sexual harassment.

Re:Go with the flow (5, Insightful)

martinw89 (1229324) | about 6 years ago | (#25160487)

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 (5, Informative)

jd (1658) | about 6 years ago | (#25161057)

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 (5, Insightful)

SQLGuru (980662) | about 6 years ago | (#25160941)

Great stuff. Find a mentor. Most technical classes focus on how to use the language, never how to use it 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.


Goto is good (4, Funny)

corsec67 (627446) | about 6 years ago | (#25160431)

Along with the ? : ternary opp.

Code that is hard to read means job security.

The IOCCC [] is a good place to learn style.

Sql Injection is a good thing. You don't need to escape user data before send it to the DB, users never do anything bad.

(Go ahead and mod me troll, I can take the hit. Note that this is actually a list of things NOT to do. Except goto is sometimes useful, for breaking out of a few layers of loops/blocks.)

Re:Goto is good (5, Insightful)

bigstrat2003 (1058574) | about 6 years ago | (#25160525)

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

Re:Goto is good (5, Insightful)

liquidpele (663430) | about 6 years ago | (#25160571)

I know you're kidding, but I want to make one point. *any* code is unmanageable if you don't comment - especially java if you use lots of objects and polymorphism. Please please please, leave comments so others can figure out what the fuck your logic was without diagramming logic on a whiteboard for 3 days...

Re:Goto is good (1)

Walpurgiss (723989) | about 6 years ago | (#25160635)

The only time I liked ? : was in school. It made my source look elite.

Of course, it didn't matter very much since half of the class didn't turn in working source code anyway, and couldn't figure out how to use scp or ssh, and coded their homework on windows before compiling in the lab with g++.

I consider it the school's fault that no one knew how to use even basic linux/unix commands, since for the first undergrad C++ class they used textpad + MiniGW port of g++ to code and compile.

Re:Goto is good (1)

Spy der Mann (805235) | about 6 years ago | (#25161217)

My rule is: Only use ? : for simple variable and string assignment. And in the very few cases that have operators in them, ALWAYS use parentheses.

Re:Goto is good (3, Insightful)

mudetroit (855132) | about 6 years ago | (#25160791)

This is one of the times when the saying "there is more than one way to skin a cat" comes to mind.

I work in a shop that has a solid rule of not commenting anything. It carries another hard rule along with it. We write very explicit method, field, parameter, and test names. If the code is in someway not understandable for you than stop and rewrite it so that it is clear.

Comments are a nice concept, but in practice they are rarely kept current. And amazingly enough are rarely correct immediately after they are written.

Sometimes there might be a better way to do things.

Re:Goto is good (1)

liquidpele (663430) | about 6 years ago | (#25161155)

Wow. So.. you guys don't write comments because you guys sucked at writing them and keeping them up to date. Is that a fair assessment? Comments are wonderful if used properly, but as you point out, too few use them effectively.

Re:Goto is good (3, Insightful)

Rinisari (521266) | about 6 years ago | (#25160595)

?: ternary is fantastic for short clauses, such as $foo = isset($_GET['id']) ? sanitize($_GET['id']) : 0;.

The logical sequence for this is a and b or c, or isset($_GET['id']) && sanitize($_GET['id']) || 0;, but ignore the PHP 'cause PHP won't handle it this way (it'll put a boolean in $foo).

Re:Goto is good (1)

TheSpoom (715771) | about 6 years ago | (#25160713)

I generally only use ternary when I'm outputting or concatenating something and it's a very simple test... otherwise, it's effectively an if (as in the example you posted), and can be more clearly expressed as such. Humans generally think "if x, than y, else z", not "var = (if x, than y, else z)".

Re:Goto is good (1)

Anonymous Brave Guy (457657) | about 6 years ago | (#25160809)

The main difference between the ternary ?: operator and an if block is that one creates a condition expression while the other creates a conditional statement. There are significant advantages to each in a typical programming language that provides both, but they are certainly not equivalent.

Re:Goto is good (0)

Anonymous Coward | about 6 years ago | (#25161125)

Having an expression and a statement is more for an academic point of view than real practical use. I guess it's like saying that one of the major fault of C is to have no procedure and only void functions. It doesn't change anything except for the purist.

Re:Goto is good (0)

SQLGuru (980662) | about 6 years ago | (#25160991)

Humans generally think "if x, than y, else z", not "var = (if x, than y, else z)".

Humans that have decent English skills usually think "if x, THEN y".....and I'll give you no slack because as a programmer, that should be drilled into you during your BASIC, PASCAL, PL/SQL, etc. days.


Re:Goto is good (0)

Anonymous Coward | about 6 years ago | (#25161197)

if (light_on_in_next_office)
assessment_of_boss = "Really driving the organization";
assessment_of_boss = "What a frickin' bozo!"

That's OK, but

assessment_of_boss = (light_on_in_next_office ?
"Really driving the organization" : "What a frickin' bozo!");

is more concise.

Re:Goto is good (-1, Troll)

Anonymous Coward | about 6 years ago | (#25160771)

Both the ternary op and goto have their uses. To say they are bad in every case shows your n00b status. Maybe spend a little more time studying your classes instead of playing video games.

Exceptions! (1)

mangu (126918) | about 6 years ago | (#25160879)

goto is sometimes useful, for breaking out of a few layers of loops/blocks.

Maybe, if you are still programming in FORTRAN-77. For modern languages, the use of exceptions is recommended.

Re:Exceptions! (1)

gamanimatron (1327245) | about 6 years ago | (#25160947)

Not so fast. There are exceptions to the use of exceptions.

It depends on what you're programming for. While this discussion seems to be BigCorp app-centric, there are other coding situations where exceptions are not available. Like, say, anything in a .DLL or .so that might be called by something other than C++.

Or when writing for next-gen game systems, where your code is running on three different architectures and the tech lead tells you that exceptions are going to be disabled for one of 'em.

Re:Exceptions! (1)

Count Fenring (669457) | about 6 years ago | (#25161211)

And on what you're programming in. In Perl, goto LABEL is a clearer, syntactically cleaner way to break out of loops than any of the various exception handling methods I've seen.

Re:Exceptions! (1)

TypoNAM (695420) | about 6 years ago | (#25161109)

C language doesn't do exceptions for example and another one is that in Linux kernel module development they suggest to use goto in their coding style for cases like when you have mutliple exit points in a function and need to do some cleaning before returning. Doing anything else would just add code bloat and then the compiler would have to waste time optimizing it all down to Esentially a goto / jump instruction.

- Coding Style Reference []

Re:Exceptions! (3, Insightful)

nog_lorp (896553) | about 6 years ago | (#25161177)

Lies. Exceptions are not meant for intentional flow control, they are for exceptions. Exceptions are (in almost all implementations) much slower and you would never want to use them in place of a goto in, say, a core loop where the goto case happens a significant portion of the time.

Re:Goto is good (0)

Z34107 (925136) | about 6 years ago | (#25161035)

Goto actually is good, for some cases.

We were given a lab assignment were we were practically forced to use it - a user can draw a picture, and you have to write the code to allow you to fill in a closed (or not so closed) shape. You know, the paint bucket tool in pbrush - you click in the region is filled with a solid color.

There's a nice recursive algorithm - something like fill(x, y). Return if (x,y) is filled or a boundary color, else do fill(x+1,y), fill (x, y+1), fill(x-1, y), fill(x, y-1). Or something like that, I'd have to look at my notes, or maybe think about it for a minute or so. But, the idea is that you recursively fill outwards from where the user clicked and fill every point.

Except, that such an algorithm would blow the stack. Even a tiny region on the screen has thousands of pixels - can your compiler handle thousands of layers of function calls? The solution was to code your own stack structure for saving the state of the function, and gotos were really handy for simulating "function calls."

Re:Goto is good (1)

Pulzar (81031) | about 6 years ago | (#25161167)

Except, that such an algorithm would blow the stack. Even a tiny region on the screen has thousands of pixels - can your compiler handle thousands of layers of function calls?

That's a troll, right?

Re:Goto is good (2, Funny)

actionbastard (1206160) | about 6 years ago | (#25161121)

Calculon: What? Have you got an extra 'GOTO 10" line? Look. I'm programmed to be very busy. If you can't heat water to 212 degress, I'm not interested!

Always think about maintenance (5, Insightful)

Mad Merlin (837387) | about 6 years ago | (#25160439)

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 (3, Informative)

corsec67 (627446) | about 6 years ago | (#25160503)

Yep, nothing worse than saying "Who the hell wrote this crap?", running svn blame, and then realizing that I did.

And, if you aren't using a versioning system, like SVN(preferably), CVS, git, that is a very bad thing. SVN and CVS also have the benefit of getting code to a remote computer when you check it in.

think about maintenance -- write crap !! (0)

Anonymous Coward | about 6 years ago | (#25160759)

considering an offshore group will probably be the ones to take your job, might as well go ahead and write crap now. So when you're unemployed, at least you'll get to laugh about the poor schmuck slogging through your recursive spaghetti nightmare.

Re:think about maintenance -- write crap !! (1)

SQLGuru (980662) | about 6 years ago | (#25161029)

You could always learn [insert foreign language here] so that when your job goes off-shore, you get to be the on-shore "manager". Usually a bump in pay, some extra travel, and a little more job security than your neighbor.


Dude he's a new coder. He'll be doing maint. (1)

HornWumpus (783565) | about 6 years ago | (#25161017)

Seriously new coders should ALWAYS be stuck on maintenance for few years.

Nothing will make you write cleaner code then maintaining a plumbers (coders) nightmare.

There is nothing worse the a brand spanking new 'super genius' coder for producing crap code. Not always but usually.

Re:Always think about maintenance (1)

moterizer (640201) | about 6 years ago | (#25161231)

And the most important aspect of maintaining your work is to remember this: six months after you've written your code, it might just as well have been written by someone else. So here's a way to get in a time machine and make your future self really happy: INCLUDE CLEAR COMMENTS EVERYWHERE. Even to things you think are obvious. If it takes you more than 10 minutes to figure out how to do something, make a note to remind yourself why you did it.

You'll be glad you did.

Get out now (5, Funny)

Anonymous Coward | about 6 years ago | (#25160441)

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

Learn how to just Google it (0)

Anonymous Coward | about 6 years ago | (#25160447)

Seriously, you can look it up yourself.

Document your code (5, Informative)

TheSpoom (715771) | about 6 years ago | (#25160451)

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:Document your code (1)

Anonymous Brave Guy (457657) | about 6 years ago | (#25160841)

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.

Better, don't repeat what it's doing (by definition, the code itself tells the reader that, and does so without any risk of becoming out of date) but add comments describing why it is doing it.

Perhaps have a look at StackOverflow (2, Informative)

debrain (29228) | about 6 years ago | (#25160455)

... []

Design Patterns (0)

Anonymous Coward | about 6 years ago | (#25160461)

Learn design patters. They will make the world make sense.

Commenting (0)

Anonymous Coward | about 6 years ago | (#25160467)

I know it's annoying and I know that it takes some extra time... but one of the BEST practices for any programmer is good commenting.

Er (2, Funny)

Anonymous Coward | about 6 years ago | (#25160493)

Sometimes I wonder if the editors eyer bother checking the firehose tags for "tvpo" or "tvpoinsummarv".

Re:Er (1)

Anonymous Brave Guy (457657) | about 6 years ago | (#25160859)

Sure, just not eyerv time.

Always.... (1)

ad0le (684017) | about 6 years ago | (#25160527)

Resist the temptation to reinvent the wheel.

Re:Always.... (4, Funny)

Bill, Shooter of Bul (629286) | about 6 years ago | (#25160599)

yeah, wheels suck. Instead create a circle that can be attached to a vehicle in such a manner that it allows the circle to roll while the vehicle moves in a straight line. And don't forget to give it descriptive name like


Stay away from the vending machine! (5, Informative)

Anonymous Coward | about 6 years ago | (#25160535)

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.

Re:Stay away from the vending machine! (0)

Anonymous Coward | about 6 years ago | (#25160933)

And you won't turn into a fat tub of shit by the time you're 35 years old, and wondering why no women want to touch you!

Code Complete is the #1 book I would recommend (1)

tatomaste (1329931) | about 6 years ago | (#25160543)

Timothy, Not meaning to disencourage you, but programming is not somethign you can learn to do properly in a short period of time. With that said, I would highly recommend you get your hands in a copy of "Code Complete." This books compiles a lot of good programming practices. If you are going to develop Object-Oriented applications, it will be also important you get some concepts down from the start. Larman's "Applying UML and Patterns" is a good introduction to object oriented programming. I have not read "Pragmatic Programmer" (recommented by the previous poster) but I hear it is pretty good. Depending on the language and the programming paradigm, the learning curve may vary. But good software engineering practices take long to master. Remember, learning the programming language does not mean you have learn how to program. The difference is as big as the difference of knowing english and knowing how to write scientific papers in english. So keep on reading, keep the intellectual curiosity always high, there is lots to learn and it is a lot of fun. Good luck and have fun!

Good tip... (0)

Anonymous Coward | about 6 years ago | (#25160545)

DON'T fall into the trap of spending all day on Slashdot when you should be working. Trust me, it happens.

Seriously though, ask questions. Lots of questions. Understand the process fully before you take on a full-time assignment. It's going to be essential to your success.

first post! (0)

Anonymous Coward | about 6 years ago | (#25160547)

Spend your day looking for opportunities to make the first port on slashdot.

help (0)

Anonymous Coward | about 6 years ago | (#25160551)

Biggest thing is document not just for the guy that will look at it later but for your self a couple months down the line and they want something to work a little different.
Modulize it makes it easier to debug and also to change things
Also think about what you want todo and how you want to do it before you start to type the first line of code
follow the preset methods your company programers write

Re:help (1)

SirSlud (67381) | about 6 years ago | (#25160975)

As a subset to this learn to anticipate design changes - if you think there is any chance they will ask for something different down the road, the time to build in the flexibility is NOW when writing new code. Code with future changes in mind - it often costs very little more to build in the futureproofing for changes in strategies.

Experiment and dabble in other languages (5, Insightful)

BrynM (217883) | about 6 years ago | (#25160557)

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.

Re:Experiment and dabble in other languages (1)

corsec67 (627446) | about 6 years ago | (#25160649)

Also, try to vary the kinds of languages you experiment in, like compiled, or interpreted and functional, or imperative.

(These are all imperative)
Compiled: Java, C/C++
Interpeted: ruby, perl

Functional [] : lisp, scheme, Erlang

Listen, think, and listen (4, Insightful)

truthsearch (249536) | about 6 years ago | (#25160563)

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

editing standards? (0)

Anonymous Coward | about 6 years ago | (#25160565)

My company just tagged me for full time App Dey

Maybe if submitters don't know how to spell, when the editors quote them, they could be like most editors and put "Dey[sic]" or something so we know it's not the editor's typo and that the editors can at least spell check?

Re:editing standards? (0)

Anonymous Coward | about 6 years ago | (#25160927)

They'd probably end up making it "Dey[sick]".

Re:editing standards? (1)

Hal_Porter (817932) | about 6 years ago | (#25161111)

hope dey get bettah.

Advice to increase productivity. (4, Funny)

radarsat1 (786772) | about 6 years ago | (#25160569)

Don't read Slashdot at work. :)

Re:Advice to increase productivity. (2, Informative)

middlemen (765373) | about 6 years ago | (#25161171)

Learn assembly programming. It will teach you inner workings of a computer and how higher level languages get down to the lowest levels. You will be able to appreciate computers a lot more than just by coding java.

code socially (1)

palinurus (111359) | about 6 years ago | (#25160579)

ask someone else to review your code. explain it to them; if it's hard to explain, maybe it needs work. read other people's code voraciously and critique it (maybe privately). let your ideas about style, techniques, practices become more fluid over time, not more rigid; this is the number one cause of death among programmers. be passionate and don't feel bad if other people don't care as much.

Help the suits (1)

rwade (131726) | about 6 years ago | (#25160585)

Ensuring that the business people and cost estimators are aware of hours you believes are required to complete can ensure that you're always in the work in a resource-constrained organization.

If you give the suits crap, you may put your project at risk of not being able to justify its existence.

Re:Help the suits (1)

SupplyMission (1005737) | about 6 years ago | (#25161159)

If you're in a resource-constrained organization, you have two options:

  1. Make yourself more valuable and less likely to get fired, or
  2. Find a job at a thriving organization where you can focus on doing good work, not worrying about staying in your job.

Your best bet is to work on the first, until an opportunity for the second arises.

The best thing you can do for your career (programming or other) and your own happiness is to learn how to work hard at tough jobs, and to recognize and act on opportunities to get into something better.

Read Risks Digest (4, Interesting)

Jah-Wren Ryel (80510) | about 6 years ago | (#25160601)

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.

Some advice I've learned (2, Insightful)

TheRealMindChild (743925) | about 6 years ago | (#25160655)

1) Your employer will never give you sufficient time to finish what you need to do. Bend over and take it. It comes with the job
2) Never blame someone else directly, even if it is obviously someone else's fault
3) Don't expect overtime pay. You'll never get it. If you ask for it, things will conveniently become a "this isn't working out" situation 4) The salesmen will sell things that you probably can't provide without working 24/7 for the next 6 months. They will also likely make 4x what you make, plus commission. Bend over and take it. 5) Do NOT EVER NEVER EVER bring in personal code to work... even if it suits the situation/project. Not only will you be expected to then provide some more goodies in your off-time, you pretty much lose the right to it of any legal ambiguity occurs. 6) Get every promise in writing. Whether it a bonus, "comp time" for late/extra hours worked, whatever.

Re:Some advice I've learned (3, Insightful)

mudetroit (855132) | about 6 years ago | (#25160917)

Or you could try working somewhere crazy where they actual value you and:

1.) Asks you how long you believe something will take and then actually listens to you, and more importantly won't punish you if you were wrong. (Though it is important to tell them as soon as you know were wrong.)

2.) Maybe people could actually just volunteer and say "I screwed up." when something comes to light? No need to blame period then.

3.) Overtime pay is completely dependent on what you agree to when you are hired. And if they agreed to it, and still won't pay you, then you don't want to work there.

4.) Or you work at a place where the salesman have a good relationship with the development team. And like above will talk to them about how long things will take and set priorities appropriately.

5.) Don't bring your own code in, but still keep coding in your off time. You learn from it.

6.) Any place you work should give you in writing what they ask to include. If they are out to stab you in the back you don't want to work there.

Not everyplace out there is a hellhole. It took me a while to learn this too, but there are legitimate good places to work. Find one.

Oh my... (0)

Anonymous Coward | about 6 years ago | (#25160673)

Lets hope you have some well hidden coder aptitudes

A few tips (5, Interesting)

mr_mischief (456295) | about 6 years ago | (#25160677)

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 (3, Interesting)

MarkusQ (450076) | about 6 years ago | (#25160729)

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.


Dont ever... (1)

ya really (1257084) | about 6 years ago | (#25160755)

10 print "think about doing this\n" 20 GOTO 10

Re:Dont ever... (1)

ya really (1257084) | about 6 years ago | (#25160783)

forget not to use a line break when you post something like the above in html

Re:Dont ever... (1)

base3 (539820) | about 6 years ago | (#25160843)

And don't forget that BASIC doesn't grok printf format specifiers :).

Work a year or two doing maintenance (4, Insightful)

MikeRT (947531) | about 6 years ago | (#25160787)

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.

standards (1)

wrench turner (725017) | about 6 years ago | (#25160799)


CM - revision control, continuous integration, CVS is fine, SVN is popular, CC is expensive

Use good naming conventions for symbols & files.

Make consistent use of whitespace/indenting.

Put a comment header at the top of each file (author,date,source repos,exec path,prerequisites,revision history).

Take your time designing/documenting/writing test plan, and less time coding/testing. Use good design over voluminous comments.

Don't make waves. Use the programming language you're supposed to. Write in the style (OO, procedural, structured, RPN) the successful members of the team do.

Learn from your mistakes. Be honest with yourself about your performance. Get good at estimating and delivering on time.

Treat people the way you like to be treated.

Find a mentor.

Three months later (1)

/dev/trash (182850) | about 6 years ago | (#25160943)

Be fired because no real work was done.

Re:standards (1)

Nicopa (87617) | about 6 years ago | (#25160951)

Wow! You shouldn't be making recommendations!

CVS fine? and SVN just the popular new kid?

Naming conventions? Do you really think that is one of the most important things to have?

Useless comment with revision history in the top of the file?

Find a mentor? What for?

Don't make waves??

All this sounds as a recipe to be a mediocre programmer... =)

Re:standards (1)

chromatic (9471) | about 6 years ago | (#25160995)

Naming conventions? Do you really think that is one of the most important things to have?

Only if you want to write and maintain screechingly obvious code.

Some things to do (1)

MarkKnopfler (472229) | about 6 years ago | (#25160831)

Introduction To Algorithms -- Cormen
Unix Internals : The New Frontiers -- Uresh Vahalia
Programming Pearls: John Bentley

Re:Some things to do (1)

Timedout (985565) | about 6 years ago | (#25161131)

Algorithms, eh? My job is to design them, but before I came to this job I never worried about it in a professional setting. (school was another thing, since CS is a lot of algorithm analysis as a degree) Seriously, you will find most sorts and searches are already programmed for you, and are optimized. And if you work in a larger framework there will probably be an optimized sort and search already implemented for you for that specific data set.

Write good descriptive comments... (4, Insightful)

madhatter256 (443326) | about 6 years ago | (#25160847)

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.

Know your strengths - your boss won't. (1)

eagee (1308589) | about 6 years ago | (#25160861)

Here are some tips that've helped me over the years:

1. Inheritance is very easy to misuse. Use it *very* sparingly!!! Figure out what Aggregation, Composition, and Delegation are (check out the strategy pattern, composite pattern, and facade patterns!)

2. Read an OOAD book. I liked the head start series - really fun, and easy to digest.

3. Never rewrite a project that's broken. Fix it first, then refactor.

4. Do all your planning *before* you write a line of code. It's much easier to erase a line between two objects than it is to refactor a class.

5. Figure out what you're best at / what you enjoy the most - implementation or design. Then you can play off the strengths of your team mates:

Implementationists are your low level guys who are great at math, know how everything works, and the kind of people you go to when you want a complex algorithm done.

Designers usually lean toward the visual side of things, are more concerned with how things are used than how they work, and are good with big-picture items like software architecture.

6. Don't stress, you don't become good at programming without making *lots* of mistakes! You'll learn how to avoid most of the pitfalls over time.

I hope some of that was at least a little helpful. Good luck!

Goals, motivation, and good music (3, Insightful)

Shazow (263582) | about 6 years ago | (#25160903)

So far I like mr_mischief's reply [] best. Aside from that, here's what keeps me on track:

  • Triangulate. A common mistake I see that produces bad code is people assuming that their code will be used for one thing and one thing always. That is almost never the case, unless you have the time, resources, and naivety to write code from scratch for every project. Try to see beyond the original assignment; set multiple scenarios and applications to your code, and try to fulfill as many of them as you can. Unification is good, and specialization is good--learn when to pick each end of the spectrum.
  • Take pride. It's easy to come up with a 15 if-statement hack, but you'll always save more time in the long run if you spend that extra 15-30 min doing research on how to solve your problem elegantly. If you can't spare the time, do your best to isolate the hacks (such as into their own helper methods) so that you can come back later and replace them with something more sensible. Avoid duplicating code, avoid creating deep chains of method calls, avoid complex undocumented code (if you must write complex code, document what it does so you can keep skimming). In general, try to write beautiful code--something you'd want to paste to your friend, so maybe he can learn a thing or two.
  • Music. When you reach a certain level of confidence that lets you build a flow, try immersing yourself in some good music. For me, listening to The Knife or Justice can significantly enhance my productivity and artistic spirit. Find what works for you.

But much more importantly, get enough sleep. I'm at least x2 more productive when I have 8.5 hours of sleep than when I have <7 hours of sleep. That's 1.5 hours that makes the difference of +4 hours of useful work. It's worth it, if you care about your work at all.

- shazow

Re:Goals, motivation, and good music (0)

Anonymous Coward | about 6 years ago | (#25161251)

+1 Justice

Avoid reading Slashdot (1)

vjl (40603) | about 6 years ago | (#25160915)

Actually, seriously, avoid distractions while programming, including reading this site. Set your e.mail to check once per hour, or simply turn it off to begin with. Don't burden yourself with making a certain "quota" of programming lines per day; some days you'll crank out a lot of code, other days will be more idea-focused and less code-focused

Listen to what your users want in a program; don't talk techno-babble to them, but instead watch how their workflow goes, and understand the problem your program is meant to solve. Listen to their feedback; though you may think your user interface is easy to grasp, if they don't, then it really isn't.

The single most important rule a good programmer needs to learn: Don't have an ego; be proud of your work, yes, but never get such a big head about being a programmer that you forget the people you are writing the programs for.

HTH, /vjl/

One GNU Way. (0)

Anonymous Coward | about 6 years ago | (#25160935)

"What To Do Right As a New Programmer? "

Donate everything to the GPL.

Business Experience (0)

Anonymous Coward | about 6 years ago | (#25161007)

the last 3 years of support desk gives me the business sense to know the environment I'll be coding for

That right there is the most important thing, imo. Assuming you're familiar with have done some coding before (with any language and any tools) then I can say you'll be able to learn the technical details and get up to speed a lot more quickly than someone with the technical skill that has to learn the business and all its particulars. Back in my first job when I ended up doing a lot of in house coding for a locally owned industrial distributor, probably the best thing I had going for me wasn't my fancy new IT degree but the years of experience I had working there part time both out back in the warehouse and later in the office.

Learn by example (5, Funny)

Repton (60818) | about 6 years ago | (#25161045)

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

App Dey? (1)

bsDaemon (87307) | about 6 years ago | (#25161049)

What the fuck is an App Dey?

Reminder: most languages are case sensitive. Likewise, pointers reference objects in the computer's memory, not your own -- so make sure you spell them right.

Re:App Dey? (1)

the-matt-mobile (621817) | about 6 years ago | (#25161185)

Funny that you mention case-sensitivity. Other than VB, T-SQL, and Pascal, I don't know of any common languages that are case-insensitive. Kind-of a shame really.

Personal stuff (0)

Anonymous Coward | about 6 years ago | (#25161105)

Don't whine, but do ask questions if you are stuck.
Don't be attached to your code.
Walk away from time to time; drinking water helps with this.

Orion Blastar's programming habbits (1)

Orion Blastar (457579) | about 6 years ago | (#25161115)

#1 For every start you put in an end, for every open bracket you put in a closed bracket, etc.

#2 For every object you use or open, you close it and free up the memory.

#3 Comments are your friends, use lots of them.

#4 Stick to the naming convention your company uses, like global variables begin with a "g" and integers begin with an "i" so a global counter variable is named as "gi_count" and a local counter is "i_count" or whatever your company says to use.

#5 Before you start to program, do research, analysis, and design, do psuedocode and flowcharts if you can they will help you out later, only then do you write code when all of that is done first.

#6 Work as a team, get a coworker to look over your code for mistakes and you do the same for him/her sometimes you cannot see mistakes in your own code, get help.

#7 Security should be built into coding, always check variables for buffer overflows and set and enforce limits in length of variables.

#8 Assume that users will type in characters in number only fields, and enter drive names that do not exist and error trap for that. Check any formula that uses division to see if the bottom is a zero and check for negative numbers before you do a square root and trap for those as well.

#9 Learn to think like a user, they won't know what you know. Think like someone who doesn't know how to program and then use your programs and see what happens. Then you can spot things a programmer would often miss or not see.

#10 The help desk is your friend, but get the correct error message and things the user did before the error happened to locate in your code where the problem is, if not, you'll have to play as Sherlock Holmes and figure out the mystery.

Don't Get Attached to Your Code (1)

Comatose51 (687974) | about 6 years ago | (#25161127)

Just because you wrote it, doesn't mean it's worth keeping. I don't know if your company does any sort of code review. If someone points out where your written code could be made better, don't get defensive about it. If they're right, they're right. The real gem is when someone points out how you can do the same or more by deleting some code. In any case, expect there to be drafts of code and rewrites. The hope is that once you've become more proficient and experience there would be less drafts and rewrites.

4 Steps (0)

Anonymous Coward | about 6 years ago | (#25161175)

1) Encourage employer to go open source

2) Start sourceforge project to entice free labor

3) ?

4) Profit.

Comment Code (0)

Anonymous Coward | about 6 years ago | (#25161207)

You may not know what that means now, but you definitely need to get into the habit of doing it now.

As long as you are able to code something, even if it has some bugs in it, but you document it, then it will make life much easier for you and everyone else down the road.

Too many people seem to think their code is bullet proof and they do not comment their code, which leads to many, many problems down the road.

Understand that it may not always be just YOUR code working in a system, so documentation helps everyone understand what's happening when it hits the fan.

Design Patterns (1)

asylumx (881307) | about 6 years ago | (#25161235)

Please read "Design Patterns" by the gang of four. (

Welcome to the Tower of Babel (1)

Louis Savain (65843) | about 6 years ago | (#25161241)

Good luck. You are about to come face to face with thousands of programming languages, operating systems, dev tools and conflicting advice from fellow programmers who are fanatical about one approach or another. Get ready for the Forth fanatics, the stateless functional programming lunatics, the autistic OOP multitude, the data flow slackers, the state machine mechanics, the immature script kiddies, the deranged hackers, the GOTO alarmists, the proper art of commenting freaks and the multithreading mutants from Mars. Did I mention atheists, vegetarians, punk rockers and libertarians? Abandon all hope of sanity as you take your first fateful steps into the mental asylum from hell.

Continuous Improvement (1)

speby (520912) | about 6 years ago | (#25161243)

Others here have commented that as a noob, your code will likely suck. Even a few months from you, you'll reflect back or encounter code you wrote and think about how much it sucks. The one tenant I can tell you is that code is never truly final. I mean 'final' in the sense that any product you're building (a web app or thick client or whatever) is never final because if people are using it, they'll always want new versions and updates that do things differently and better. This phenomenon gives you (and your product team) a chance to make things better, both in existing code/features and new things as well. Secondly, you should try to learn and focus on the art of testing. Just like when you were learning mathematics in high school algebra and calculus and later numerical analysis or number theory or whatever in college, your instructors always want you to 'check your work.' In the simplest case, that's taking your 'final answer' and plugging it back in for 'X' and solving to see if you actually got the equation right. Think of testing like this: a balance of both sides of an equals sign. Otherwise, be a sponge and read, listen, and absorb.
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?