What To Do Right As a New Programmer? 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."
Document your code (Score:5, Informative)
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 [sun.com] (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.
Perhaps have a look at StackOverflow (Score:3, Informative)
... http://stackoverflow.com/ [stackoverflow.com]
Re:Always think about maintenance (Score:4, Informative)
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.
Stay away from the vending machine! (Score:5, Informative)
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:Go with the flow (Score:5, Informative)
Re:Advice to increase productivity. (Score:2, Informative)
Re:A few tips (Score:3, Informative)
This is all great advice. The parts about not being defensive about code you've written are spot-on. I would add the following to the list:
Some tips (Score:5, Informative)
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.
Re:Exceptions! (Score:2, Informative)
No.. you are a fucking idiot. Please never write software again.
Exceptions are designed for HANDLING EXCEPTIONS. Hence why in all modern languages like C#/VB.NET other .NET languages, Java etc do a complete stack walk every time you throw an exception (extremely expensive).
I'm all for avoiding premature optimization, but you don't have to be a fucking idiot. If your code "needs" exceptions to break out of deeply nested logic it's because your code is shit.
Learn to code.
Programming vs CompSci + Engineering (Score:3, Informative)
Your advice equates to "Broaden your background", so I support that thoroughly.
The most depressing thing about this whole thread for me is that nobody else (yet) has brought up computer science or software engineering. By implication, they're not relevant to a career in programming, and that's a disastrous indictment of the nature of this occupation currently.
The person in TFA will be getting some training in programming, probably focussed on gaining proficiency in one specific language, but will have no theoretical background whatsoever. And this is supposed to yield a good developer?
Computer programming is an engineering discipline, with a very extensive background and a deep theoretical foundation in CompSci. What that person will become, at best, is a hack mechanic, since he will have none of the foundation to become an engineer.
This is precisely why "bridges are falling down" all around us in software, daily.
Programming is currently in its deepest Dark Ages, and most practitioners don't even realize it. That person should at least read some simple background on algorithms.
Re:Always think about maintenance (Score:5, Informative)
- Brian Kernighan, "The Elements of Programming Style", 2nd edition, chapter 2
Re:Programming vs CompSci + Engineering (Score:3, Informative)
I was going to say, I was a bit surprised that they were promoting someone who presumeably wasn't in coding before into a development position, but the OP isn't quite clear on exactly what background he has.
While I agree that an education is important (enough that I am further pursuing mine), I also know that he could become a good hacker without it as well. Many people have done so, and have learned the foundation aspects through experience (and the community telling them so).
I'm still mostly working on PHP code, and I learned PHP on my own while I was still in high school. I am a much better coder today, and I do ascribe some of that to my schooling (both community college and university), but a lot of it, perhaps the majority, can be ascribed to personal experience outside of an academic environment. There's nothing like being thrown in to sink or swim.
Re:Go with the flow (Score:4, Informative)
Whenever you write code on future projects, you're often going to start by trying to re-use code from previous projects. So don't just treat the source-code you're writing now as something you know you're going to reuse in the future. Try to think of each useful chunk of code you write as being part of a "package" that includes not only the code itself, but also the associated documentation, the test cases, the performance metrics, use cases, the build files, etc.
You want to write the entire -package- so that it can be re-used on future projects, not just the code itself. Remember that as a developer only a fraction of your time is actually spent writing code: the bulk of your time is spent putting together all that associated "stuff." So make the "stuff" re-usable too.
Code to read (Score:4, Informative)
Your code is probably going to be read a bazillion times more than edited. So take some more time to write it clearly.
Performance is hardly an issue for most business apps - and you should solve most performance issues by choosing the correct algo/method, rather than optimizing code. 80/20 rules applies, 80% of the time is spent in 20% of the code. And the performance critical parts of the code are probably 5% (for most people).
The compiler is not buggy. Even though gcc might spit insane amounts of errors for a single mistake in STL, the compiler is not buggy. Even though you read your code a hundred times and you can't find a mistake, the compiler is not buggy. It's infinitely more likely that you have screwed up than it is to have a tool error (unless you're doing Verilog/VHDL :)
Learn to use a debugger. Any debugger will make you appreciate what the code does better.
Read Code Complete, Pragmatic Programmer.
10 Learn how to learn better.
20 Keep learning and practicing.
30 Goto 10
"Code For The Next Guy" (Score:1, Informative)
I have been a programmer for more years than I care to think about. My motto for the longest time has been "Code For The Next Guy". Invariably, the code that you write today will likely be maintained or enhanced by someone OTHER THAN YOU tomorrow. So, when coding, keep that in mind.
Some guidelines...
- Whitespace is your friend. So is proper indentation of your code. Make your code easy on "The Next Guy" to READ.
- There are 100+ ways to code a solution to a problem. The issue is that about 99 of those ways suck. Don't reinvent the wheel. Like a previous poster stated, read code from other developers, follow a programming standard and stick to it.
- Document code that needs documenting. If you are implementing an algorithm to solve a problem that might not be clearly evident to "The Next Guy", document that. Do NOT bother documenting the obvious, such as "Increment Counter" when you are incrementing a counter variable. If "The Next Guy" doesn't understand that, there will be issues.
- Make your variable names meaningful. You can get away with single character variables in a "for" loop, but that's about it. In the same vein, however, don't be ridiculously verbose with your variable names. A variable named "companyName" is much better than "coNm" and even better than "cn". A variable named "nameOfTheCompany" is overkill. Your variable should clearly denote the contents that are being stored.
I could go on an on, but you get the point...
"Code For The Next Guy"...not for yourself.
Re:Goto is good (Score:3, Informative)
From a programmer with over a decade of experience (Score:3, Informative)
... I'm still a new programmer. Stay adaptable, keep learning, never assume you know all you need to know. Learn from everyone including the new programmers who are just learning themselves. Take time at least once every few weeks to stop and ask:
Once a year I stop and spend some time thinking hard about:
So far this strategy has worked for me... of course it took most of the first decade to discover it. You are welcome to copy off of my notes. Asking Slashdot shows you are at least curious, that's good, take time to learn about and learn from leaders in your technology niche.
General Coding Advice from a 20 year programmer (Score:5, Informative)
Taking the question seriously for a minute -- something unusual for this venue --
Whatever rules you use, make sure they are the same as everyone else on the project. That includes the rules around comments, indenting, and bracket locations. I've seen huge arguments over placement of an enclosing bracket on the same line as a declaration or a new line.
Once you have a little comfort in a language, get on an open source team. They have to be very good about practices because they have hundreds of people working in different locations at different time zones around the world. You'll start with no real authority, being allowed to submit small changes specific to small branches of code. The owner of that small branch will be responsible for accepting your changes if they're good enough. Over time, you'll move up the chain. READ THEIR GUIDELINES. OSS teams have, of necessity, very rigid guidelines on code practices that allow hundreds of people to work on code together. They've had huge battles over those guidelines, and very smart people have said very smart things (you can find them hidden in the morass of garbage if you look hard enough) that have gone into those guidelines.
More Specifically:
If you're repeating the same code, put it in a sub or function (a method if you're using an object oriented language)
A subroutine or function should be as fine grained and generalized as you can possibly make it. It should accept as few parameters as it needs, and should return a single value (or perform a single action). Note: Some languages, like C, use the convention of returning a success/failure boolean as the return value, and the result of the function in a buffer passed as a parameter -- that's also a good strategy.
If your routine is longer than a single screen to read, give real thought to how you might break it out into distinct subroutines (or methods or functions)
Avoid overly complex rules for variable naming. I've seen insanely complex variable name rules that are painful to work with and attempt to encapsulate the the data type, scope, and purpose of each variable in its name. That's not necessary or helpful in modern language programming. Most programming environments let you mouse click a variable and instantly view its declaration and often even comments written by that declaration for explanation. If your variable name includes the type and scope, you'll have to refactor it if you change the type or scope (like from integer to long integer, or boolean to enumeration as is quite frequent)
Use an object oriented language where possible
REALLY learn how to use Overloading, Polymorphism, and inheritance in your object oriented language
Avoid global declarations and functions wherever possible. The smaller the scope of any variable or object, the less likely someone or something will step on it later.
draw out -- on paper -- your object model before you build it. Learn to start with an ER (Entity Relationship) diagram so you can understand the relationships between real world objects. Think in terms of "A" is always the parent of one or more instances of "B", "C", or "D", but may be either a parent or a child of "E". Figure that out using real world objects that your code object represents first, on paper. I personally do this on a whiteboard with colored pens first then transfer to software for mapping.
Trust nothing. Your methods, functions, and subroutines should stand on their own regardless of what crap someone else passes to them. In every method, sub, or function, VALIDATE all variable data, always. Check for overflows. Check to see if an object is instantiated (not null or nothing). Check to make sure values are within the expected ranges. These checks are very small in terms of system resources and program run time. Take the time.
Do your declarations, validity checking, and decision making outside your loops. Any loop you make should do as little as possible inside it. Everything you do in a loop ge
Code Reuse (Score:2, Informative)