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.
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!
Hey, I like the ? : construct. You leave it alone!!!
"16MB (fuck off, MiB fascists)" - The Mighty Buzzard
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.
Comment removed based on user account deletion
?: 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).
Colin Dean Go a year without DRM
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.
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.
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!
So far I like mr_mischief's reply best. Aside from that, here's what keeps me on track:
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
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.
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.
Unfortunately, test-driven design is not a silver bullet, unless you're lucky enough to have a finite problem space where you can achieve 100% test coverage, which almost no-one does, and you can consistently write perfect test code, which would be surprising if you're worried enough about your normal code to write all those tests in the first place.
In the absence of such unrealistic guarantees, TDD lies somewhere between a useful addition to your coding practices and snake oil, depending on the realism and honesty of the person advocating/implementing it. Either case, it is not a substitute for good documentation and commenting.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
I strongly agree. Self-describing code is much better than comments. Comments are only useful, IMHO, when you need to describe a complex situation. If it can be expressed in one sentence or less, it should probably be part of the code itself. I.e., instead of:
std::string mkdec(std::string x) // Converts x, a string representing a hexidecimal number, to a decimal string.
std::string convert_hex_string_to_decimal_string(std::string hex_string)
The latter says the exact same thing, but is far likelier to be maintained properly. Also, if you get in the habit of coding like that, you never have to worry about forgetting to comment. Furthermore, the "comment" is effectively replicated every time the function is used. Hence,
instead of:
hex = "0x" + number_str;
return mkdec(hex);
you see:
hex = "0x" + number_str;
return convert_hex_string_to_decimal_string(hex);
Now, if you had a function that implements a complex algorithm that can't be summed up in short order, then sure, use a comment. But in my experience, 95% of comments in code are like the above "mkdec" comment, and would be better expressed just by using a more descriptive function or variable name. I think a lot of coders are just lazy and don't want to have to type in longer, more descriptive variable and function names.
You don't exist. Go away.
Actually, I've been told that assembler code ought to be commented in just that way. In well written high-level code, individual lines should have a self-evident purpose, but often this is just not possible in very low-level code. Can you really tell at a glance what "djnz" means? And even if the answer is "yes", can you reasonably expect everyone else to have it memorized?
I don't have enough experience with assembly language to render an opinion myself on whether this is really necessary in a development context, but in school I spent a semester programming ASM and the line-by-line commenting seemed indispensable.
(Or did you mean that the comment was somehow inaccurate? Like I said, who can look at "djnz" and remember what it means? I can't.)
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!
I want to make one point. *any* code is unmanageable if you don't comment
I disagree strongly. I think the important thing is to make your code easy to understand. Comments should be a last resort.
As an analogy, consider your MP3 player. Suppose that every time they struggled with a UI decision, they just decided to put something in a manual or on a sticker on the back. It would be an abomination. The right approach is to make it so that as much as possible, instructions aren't necessary.
When I'm coding, I'll first try to put information in names, like variable and method names. Next I'll try to extract methods or objects, so as to minimize complexity. Then I'll worry about interface and object names. And I put a lot of information in readable unit tests, as that's a kind of documentation that the computer can verify still is valid. Documentation is always a last resort.
I have to deal with a lot of other people's code, and I'll always take beautifully polished code with no docs over mediocre code with lots of docs.
Find the most authoritative reference manual you can find for every tool, every language you come in contact with. The question is not "how do I make it do such-and-so?", the questions are "what is it made to do?" and "what can I make it do?".
Do the onion-skin trick: read -- almost skim -- once, for fast comprehension, don't try to remember everything, just remember the new words and where to find them. Read it again, to remember which parts talk about which other parts. Read it again, to start understanding why those parts talk about those others. Only then should you even start thinking about asking yourself "how do I make this do X?".
Don't trust *anything* in any other book until you can tell what part of the authoritative reference it's talking about. Using C++? Pay the $18 or whatever it is now and read the ISO standard. Every book about C++ you read, tie what it's saying back to a section of the standard, and be sure you understand what both are saying. Using vim? Read the help. All of it. Do it again. Using MS Word? Hit F1 and start reading. Read everything. Using Python? Get the reference manuals and read them. Using TCP/IP? Read the RFCs.
Read The Fucking Manuals. Obsessively. Reread them again a month later. Then again a few months later. The questions are always: What is this made to do? What can I make it do?
Get used to it. I used to tell people I read manuals for a living. Classes are excuses to spend that much time reading the manuals. If you read the manuals, you won't need the classes. There is an *astonishing* amount of crap out there in the help books, useless "simplifications" that obfuscate the point of what they're supposedly explaining.
What worked for me every time I had or could steal the necessary time was, roughly, to overengineer the hell out of it, then boil out all the crap. Antoine de Saint-Exupery's maxim is absolutely dead-on: Perfection is achieved, not when there is nothing left to add, but when there is nothing left to remove.
With a little practice, most of the overengineering and boiling-out parts can be done in your head.
Particularly while you're new, reread your old code, constantly. Go find things you worked on before and read them again.
As always, all IMO. Insert "I think" everywhere grammatically possible.
I agree that as developers we should strive to write good, self-describing code that doesn't need comments.
Yet I still tend to write a lot of comments.
Well-written code can convey most of the how of what you're doing, but it rarely can convey the why -- and that's important too.
Suppose I look at code someone else (or even myself) wrote two years ago. I see what I think is an error in how the logic applies one of the business rules.
Is it an error?
Or was it right, and the business rule has changed?
Or is it still right, and there's some reason for the way it is that I don't understand?
Did someone in management mandate a change that runs contrary to the last version of the design docs? Was a more obvious solution tried first, but found to fail under testing?
All of these things are useful to know, and as much as I'm in favor of self-describing code, it rarely can communicate them.