Slashdot Mirror
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."
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.
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.)
If I have nothing to hide, don't search me
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.
Game! - Where the stick is mightier than the sword!
Get out, now, for the love of God, while you still can.
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.
It's better to vote for what you want and not get it than to vote for what you don't want and get it.
- E. Debs
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.
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.
US Democracy:The best person for the job (among These pre-selected choices...)
- 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.
Developers: We can use your help.
Don't read Slashdot at work. :)
Comment removed based on user account deletion
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
circleForVehicleToMoveBetterThanDraggingWouldNormallyAllow
Well.. maybe. Or Maybe not. But Definitely not sort of.
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.
When information is power, privacy is freedom.
I'm far from a master programmer myself, but this much I know.
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.
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.
Previewing comments are for sissies!
1. Read The Daily WTF. 2. Don't do that.
Repton.
They say that only an experienced wizard can do the tengu shuffle.
Use a slow machine with little free memory to test your code. It teaches you to be efficient. That is why 1GB of ram is not enough for an office anymore.
Fight Spammers!
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.
Come play free flash games on Kongregate!
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
The problem with quotes on the internet, is that nobody bothers to check their veracity. -- Abraham Lincoln