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.
Seriously, you can look it up yourself.
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
... http://stackoverflow.com/
Learn design patters. They will make the world make sense.
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.
Sometimes I wonder if the editors eyer bother checking the firehose tags for "tvpo" or "tvpoinsummarv".
Resist the temptation to reinvent the wheel.
My mother never saw the irony in calling me a son-of-a-bitch.
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.
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!
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.
Spend your day looking for opportunities to make the first port on slashdot.
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
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.
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?
Don't read Slashdot at work. :)
Comment removed based on user account deletion
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.
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.
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.
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.
"When life gives you lemons, don't make lemonade. Make life take the lemons back!" -- Cave Johnson
Lets hope you have some well hidden coder aptitudes
I'm far from a master programmer myself, but this much I know.
Find and watch episodes of and old cop show called "Columbo".
Whenever you are unsure of anything, act like Peter Falk's character (Columbo). Whenever you are very sure of something, try even harder to act like that. If things don't make sense to you, ask questions, do experiments, use google, use your brain until they do make sense. And if you have a theory (or a plan, or a piece of code) that you are sure is right, put it to the test.
Don't be a know-it-all, don't blindly assume that you know anything. People sometimes get annoyed at developers who take nothing for granted, but that sort of attitude gets results, so they put up with it a lot longer than they put up with developers that assume they already know everything and project that assurance right up to the point where the project goes down in smoldering ruin.
--MarkusQ
10 print "think about doing this\n" 20 GOTO 10
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.
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
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.
Introduction To Algorithms -- Cormen
Unix Internals : The New Frontiers -- Uresh Vahalia
Programming Pearls: John Bentley
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!
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!
Maybe, if you are still programming in FORTRAN-77. For modern languages, the use of exceptions is recommended.
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
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/
My Daily photo website.
"What To Do Right As a New Programmer? "
Donate everything to the GPL.
Be fired because no real work was done.
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.
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.
John McAfee 'It was like that time I hired that Bangkok prostitute; to do my taxes, while I fucked my accountant'
1. Read The Daily WTF. 2. Don't do that.
Repton.
They say that only an experienced wizard can do the tengu shuffle.
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.
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.
#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.
Remember, Slashdot does not have a -1 disagree moderation, and no, troll, flamebait, and overrated are not substitutes.
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.
EvilCON - Made Famous by
Comment removed based on user account deletion
1) Encourage employer to go open source
2) Start sourceforge project to entice free labor
3) ?
4) Profit.
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.
this comprehensive guide: http://freeworld.thc.org/root/phun/unmaintain.html.
Please read "Design Patterns" by the gang of four. (http://en.wikipedia.org/wiki/Design_Patterns)
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.
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.
Don't waste your work time reading slashdot ...
No offense to Mr. App Dey, but what company takes helpdesk people and sticks them in engineering? We need to know what products to avoid...
They're fun, but can cause you trouble later.
What the fuck are you talking about developing "a flow"? Jesus fucking Christ just listen to whatever music you want to and don't listen to elitest music whores like the parent here. Listen to country, listen to Wierd Al, listen to Michael Bolton, whatever the fuck helps you. Just don't listen to people like the parent poster that religiously reads pitchforkmedia.com every fucking day and jerks off all over the newest "indie" record.
1. Always blame the latest bugs, and bad code on the last developer that left the team.
2. Document as little as possible, as it takes away from your time coding.
3. Leave a lot of crumbs from chips, and snacks around your keyboard and mouse. It will prevent people from using your computer.
4. Don't use deodorant as it will prevent people from bugging you or asking questions unless they truly are urgent.
5. Feel free to sit down and chat with the senior developers when they look busy.
6. Don't worry about the readability of your code since nobody will really look at it again.
go get a degree in CS before you get anywhere near a compiler. That should give you your best practices and keep you from doing anything stupid.
One specific I picked up, put your constants on the left hand side of your comparison to avoid accidentally typing '=' instead of '=='. For example:
handle = new MyClass(); ...
if(NULL == handle) {
If you screw up and type '=' you will generate a compiler error.
Quite often (more often than I would care to admit), I reach a roadblock on how to do something the right way. I can't quite wrap my brain around what the best method or algorhythm should be, or what the interface should look like, the workflow, etc.
Sometimes I'll spend WAY too long racking my brain for a solution.
What I've learned is that if I just distract myself for a short period of time, by doing something else like taking a lunch break, when I return to the problem the solution will come to me almost right away.
-David
Even if nobody else has to deal with it ever you will forget how stuff works years from now.
Learn who likes helping people and who doesn't. Then, don't overuse the helpful people and piss them off. If you need to bug the unhelpful people do so by email. Corollary: always be willing to help, but don't be afraid to say: "this has to wait."
It's one thing to write code that follows a sequence of steps and generates correct output. It's quite another thing to write robust code that handles problems gracefully.
In the real world, problems are inevitable. For example:
As you design and write your code, try to anticipate the problems you'll have to deal with, and the things that could go wrong. Be religious about error checking and handling -- sure, it's tedious, but it makes your software dependable and easier to support once it hits production. Unless you like 3AM wakeup calls from the guys in network.
You may not be able to recover or work around all problems, but your code should at least handle them gracefully--even if that simply means cleaning up, logging an error, and alerting the operator for further troubleshooting.
Outsource it to India.
I once inherited a Win 3.x device driver that was written entirely in asm. Several hundred k of raw code.
At a first glance it looked good and well commented, in fact virtually every line was commented.
However on closer inspection i found lines like
djnz ax loop: ;; Decrement the register ax and jumpt to loop: if not zero
First and last x86 project i ever touched
Think before you code. What are you doing? Why are you doing it? What rules are likely to change? What data structures best represent what whatever you're coding is/does?
Get familiar with data structures. What is a pointer? What is the difference between pass-by-value and pass-by-reference? What is a dictionary/map/associative array/indexed table? What's the difference between is-a and has-a? What is big-O notation?
Learn to map your assignments to data structures and algorithms, independent of your programming language. Then translate that into the language; if it doesn't translate cleanly, figure out why it doesn't translate, and try a different structure/algorithm. Being familiar with your language will help here, as it will be easier to see immediately what maps to the language well, or even when a somewhat suboptimal design (say, XML) may allow massively simpler code due to standard library support. Being somewhat familiar with other (completely different, say Ocaml vs. C) languages will help you see more alternatives that you can choose from.
If your application uses SQL to talk to a database (as opposed to being forced thru some abstraction layer), learn SQL beyond the minimum required. Pushing certain logic into the queries (with proper indexes) can be a massive speedup, pushing the wrong logic will cause problems. This is on the same order as choosing the right algorithm based on it's big-O speed, rather than silly little things like loop unrolling and hand-coding replacements for too-slow library functions.
Master unit testing. It will keep you from screwing up the system.
Don't code anything until you've confirmed your in-house libraries and open source libraries don't already have the solution. There is very little that hasn't already been done. You'll score more points by saving time that being a code master. Most of the time nobody reads the code, but they certainly read the time sheets and the budgets.
Solve your problems on paper or a whiteboard before you code (or search those libraries). You've got to know where you're heading.
Break large problems into small solvable units. If you have a block of code that is more than you can view at once on screen, you haven't broken the problem out into enough granularity.
Prototype and refactor. Repeat.
Don't ask about programming advice on Slashdot! Over the years I never read more moronic "advice" on what constitutes good programming than the idiotic majority of Slashdot. Especially the "toy" language lovers, the Java/Perl/Ruby/Phyton/VB/C# crowd. The script kiddie whannabes that think the crap they churn out is real code. The same dweebs that think all programming is like on their beloved PC/MAC/Linux box. The ones that think real-time means really, really fast. The ones think fault tolerant means if your code has a bug, it should crash, and deservedly so! They believe recursion is a cool toy--use it everywhere! There is so much memory on ALL computer now that malloc can never fell (no need to check those return values!!). That real languages like C and C++ are too hard for them to understand (which is the languages fault). They're still trying to figure out what a pointer is. Oh, and all machines are ASCII, bytes are always 8-bits, int is always 32-bits, Unicode is 16-bits, and endian, why that is just a ghost story meant to frighten children. And Java is portable.
Some stuff I've learned over the years:
;)
1. Learn to use Google and techie-based forums effectively for the language(s) you are using - 99 times out of 100 someone else has had the same problem you are facing and has solved it, and posted the solution
2. Get in good with your network admin - this is a must if you need network stuff done in a hurry!
3. Know when to code fast and ugly, and when to code elegant - whats the point in spending 2 hours to code the elegant solution when you KNOW your code is only going to be run once, and the 10 minute ugly version with hardcoded everything will work just as well?
4. When writing classes/methods/etc, think about the programmer who comes after you in 3/6/12/18 weeks/months/years time and has to modify what you've done. In most cases, it will be you and then you have to re-figure out what you did and why you did it that way. Make method names and variable names consistent and easy to understand, use the datatype of the variable in the name, etc...simple stuff like that helps enormously. The coding books can teach that stuff.
5. Linked to point 4....Comment, Comment, Comment! But do it wisely - dont comment each and every line but comment a "block" of codelines. Describe what the block is doing, and if its relevant, WHY you chose to code that way - there may be a certain reason to do with the database maybe, or with the network setup. It explains to the reader why the code reads the way it does. It keeps down the "WTF/min" count!
6. Dont refactor just 'cos you can - quite often you will come back to a piece of your code to fix a bug, and you'll find that since you wrote it, you've learned more stuff that you know will make this piece of code fly, but it involves major rework to the code. Resist the temptation (and the temptation will be there, believe me) to do the major rework! Your boss is expecting you to fix the bug, not re-invent the entire method, and if you post a fix time of 3 hours to a job that should have taken your 15 minutes...you wont win yourself friends with your boss. Plus you are introducing a new set of code to the system that requires testing, and all the stuff that goes along with that...
7. Bide your time - the way to get onto the big, interesting projects is to do the drudgey hack work in the beginning. Do the hack work well - keep your code efficent, relatively bug free, get it done ontime and the interesting stuff will come to you.
8. Bugs happen - just like life: make a mistake, learn from it, and try not to let it happen again. It is very rare that you will have a program run bug-free first time...and the more lines of code you have, the higher the chance it wont run first-time.
I'm sure there's more stuff, but you can figure it out yourself
Peter Norvig has a thoughtful list of suggestions.
Same could go for software development.
Couldn't stand the weather
1) go buy code complete. read it a chapter a week. when you are done, reread it. if your understanding of the book has not changed completely, you need to go find a new career.
2) learn discipline now. code complete has some excellent examples (e.g. declaring variables only as you need them and initialize them immediately, put constants on the left hand sides of logical tests, etc.) and your coding standards should provide other guidance.
3) take dijkstra's words to heart: "The competent programmer is fully aware of the strictly limited size of his own skull; therefore he approaches the programming task in full humility, and among other things he avoids clever tricks like the plague." corollary: "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." (kernigan)
4) get in the habit of maintaining engineering notebooks. over time you'll figure out how to keep useful notes and those notebooks will be worth their weight (or more!) in gold.
5) go find a senior dev that you have a solid personal relationship with and see if you can establish an informal mentor/mentee relationship.
6) ask questions. lots of them. keep on asking until you're satisfied with the answer.
7) understand that any task that requires more than 2 minutes worth of programming merits at least 10 minutes worth of putting a plan together / drawing pictures / planning and at least 30 minutes worth of testing (ideally by adding to an existing automated test suite, hint hint...)
Always have a backup!
make sure that is you screw up, you can go back to a working previous version.
If you work with databases, backup the databases too.
By practising this mantra you'll soon be spotting the gaps in other people's thoughts and specifications, which in turn will make you into one of those awkward people who can simultaneously (a)hold up the slip-shod enthusiasts and (b)find a better, more elegant, solution AFTER THINKING ABOUT it.
A good programmer has to be a mental athlete. Develop your powers of concentration and insist on a working environment where you can think in peace and are not expected to work flat-out for hours on end without a recovery period.
When coding, look for patterns in the code - at the smallest level, anytime you find yourself copying and pasting code without modification, you've identified a pattern and will be better served by extracting that out into a reusable function/method.
You'll find that there are identifiable patterns in all aspects of programming. In the broadest sense, learning how to first identify them, then use them, then predict them is what differentiates a code monkey from a great programmer.
Finally: listen to what your users "mean" and not just what they say. When they try to explain a problem to you, avoid the "works fine for me" syndrome -- remember that they wouldn't be talking to you if /something/ wasn't broken. (Even if 'broken' only means they don't understand how it should work: that could be a sign that how it works is flawed...)
Please, please, please, no matter how late it is, no matter how much of a rush you're in, don't copy and paste blocks of code when you know deep down you should be generalizing and rewriting that block as a method or function somewhere for re-use. I can't even begin to count how many hours my team has wasted tracking down and fixing the same bugs that were pasted all over the place in legacy code.
like ? leave_alone : ;
There, fixed it for you.
HA! I just wasted some of your bandwidth with a frivolous sig!
Pick a well knwon, good quality open source project. Read documentation, experiment with the product and then read the code. Pick a minor bug from the bugtracker and try to fix it. Ask for help if you can't. You will find out that those who try to contribute get help. Repeat and rinse. You will get better. Nothing helps more than writing peer reviewed code.
1. Document everything. The consolutants where I work produced some sloppy code, but did a fair job documenting what most functions did. When it came time to port it to a new architecture and do some general cleanup, this head start was invaluable.
2. Don't fall for fads. If you're in web development, remember that 80% of the market uses IE. Don't overcomplicate online applications with garbage like CSS and AJAX. If you have to contantly reload or need CSS to be usable, your design is broken.
3. Write code that can stand alone. One thing I curse the consultants for is the use of global variables, which allowed them to setup processes that were all or nothing in a very specific order. Much of our cleanup has been decoupling these functions to recover from failures.
4. For the love of God, implement some sort of error handling. I pass in a list object to every function, so I can follow what happened and only have to figure out the root cause.
If you write it right the first time, it takes less time to debug later. Measure twice, cut once. It takes much more time to find a bug then to write the code.
Be a real programmer. http://www.sorehands.com/humor/real1.htm
Fight Spammers!
The key to being a good programmer is a careful balance of laziness, hubris and impatience.
IMAGE VERIFICATION IS EVIL!
No, he is not wasting away his life, he is trying to join dreamers who are trying to change Second Law of Thermodynamics. When he understood that unfortunately, that was just a dream, -sorry R.E.M. was on the radio :)- it will be long past the point of no return....
"My code isn't the reason it crashed! It was the Windows!"
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!
Look buddy, I got nothing against the ? : ternary, but the line ends with 0; which looks at best like someone with a droopy eye lookingh surprised and at worst someone bawling their eyes out. If you read code like that all day, you will get very upset. It's bad enough that so many lines of code end in );
Seriously, the one important piece of advice I have for anyone who is gouing to write code in one of these langauges with brackets and semi colons all over the place is this: the language is designed to briong you down, you gotta work hard to make it happy. That is why a good for loop goes like this:
The trick is to remember that someone will have to maintain the code after you. It is your duty to make reading the code a happy experience.
I don't therefore I'm not.
...but also know where your code came from. There are tons of code snippets, modules, libraries, etc available for reuse. Reusing code is good - as long as you know what you're getting. No, you probably don't need to code your own sort routines - but you should know how the sort routine you're using works, its limitations and its advantages.
Don't status everything at "80% Complete" - your manager knows better, and you are going to end up right back on the support desk (or out on your ass) if the team can't trust you. Raising your hand and saying you need help is better than missing your milestone and leaving the rest of the team high & dry.
Always remember that your beautiful code is NOT why the company is in business. The application is being built to *do* something - to help execute a business process, or control a machine or simply entertain someone - but it has some purpose. Even if you work for a commercial software vendor and your code is the product being sold - it is still being built to do something for the customers. Don't lose sight of that purpose - having working code that is reliable & maintainable really is more important than using the latest nightly build of the ubergeek framework.
Finally, communicate with your teammates. Don't barricade yourself inside your cubicle for months writing your code masterpiece only to find out that the requirements changed 3 weeks ago, or that the guy in the cubicle next to you already has a function that does exactly what you need in the project he finished last month. The team CAN accomplish more than the sum of the individuals - if the team really acts as a team.
1. Learn how to use polymorphism properly, it can be a very powerful tool when used correctly, but can make a huge mess of your program architecture when used incorrectly. What is the difference between an 'is-a' and a 'has-a' relationship? When do you use one or the other?
2. Learn proper functional decomposition. Breaking your problem down into small pieces is important for solving the problem one bit at a time (however, they have to work together well when you put it all together!). The computer science mantra is 'divide and conquer' for a reason.
3. Learn how to do threading/locks/synchronization correctly. You will make mistakes, and they will be hard to fix. Threading bugs are hard to prove they exist, they are hard to diagnose, they are hard to fix, and they are hard to prove that they are fixed. Threading/sychronization isn't as simple as wrapping a mutex around parts of your code, especially if you have threads doing work that is depended on by other threads.
4. Regular expressions make quick work of string processing, in a concise, easy to maintain form. Take the time to learn them.
5. Security is hard. Very hard. I suggest you first learn how hard it is, so that you can understand /why/ you need to be very careful. Then you can learn about /how/ to do it correctly. My favorite example of this is "RSA blinding" - if you can watch the power consumption of a cpu as it runs a cheap implementation of RSA, you can see it spike power draw when doing parts of the algorithm. You can then use the length of those spikes to get an idea of the approximate value of the inputs to that algorithm, where the inputs are chunks of the key. Now, you can reduce your brute-search attack because you know that some keys are unlikely.
Let me know who you work for so I can avoid a company that is now promoting its help desk employees to programmers... (cheaper than outsourcing I guess?)
My best advice would be to never listen to the Support Desk people, they know absolutely nothing.
No matter what more politically-correct people like to think, all people are not born equal. The best software developers are born with a certain affinity for the mindset required. Education can build on it, but if you don't have it to start with you won't ever be good or as happy working as a software developer as whatever you're really cut out to be.
You need to make an analytical and honest decision with yourself as to whether this is a direction you want to be going in with your life and career. Unless you're absolutely sure you're the right person to be a software developer, then don't do it. The fact that you've apparently already been happy to do tech support rather than write software might itself be an indicator that this is not a good move for you.
OK now you've decided to go ahead anyway, the next stage is that you need to know what you are doing.
Contrary what most other posters here are suggesting, you're jnever going to be fully effective if you just try and learn on the job or learn from other software developers around you. There is a lot more to being a good software developer than being able to write a program that runs OK.
By limiting yourself to learmning on the job, at best you will only develop a tiny subset of very specific skills you need for your particular company/product/langauge/toolchain, and will not get a deeper understanding of some very important concepts. Also that approach will almost certainly start you off with some very bad programming habits (i.e. your colleagues).
Ask your company to allow you as much time as you can get to attend some Cumputer Science and Software Engineering courses at your local college or university.
If you need justification, tell them that your company will save way more than the time/money it costs them in terms of your increased knowledge, usefullness and code quality meaning much less rework required.
If they still say no, then make every effort yourself to at least do some evening courses and build points towards a Computer Science or other similar software related degree.
Assuming you don't want to work for the same company for ever, you need to understand that no matter how good you think you are, these days a Computer Science or other relevant degree is a basic requirement for many if not most software developer positions. You learn a lot of really useful fundamental concepts on a CS degree course that will be highly relevant, used and needed throughout your whole career. Ususally the only people who dont agree with the value of a CS degree for software engineers are those who don't have one, so don't know what they don't know.
Besides the things previously mentioned... Plan (or think about) what the finished product is going to look like before you start...... When planning, sometimes a pencil and paper is much more efficient than a keyboard...... Commenting is everything. You would be amazed to find out later, you don't remember your own code....... Be consistent with your styling. Try to follow a standard in convention....... Be a researcher, don't reinvent the wheel. (someone has done it before, and usually better)....... Unless you have a cause, a single stretch of code should not run for pages/screens....... Don't go overboard on breaking up code. That is just as bad........ It is easier do document as you go. The little (but important) things are easy to forget....... Don't assume that input data will always be good data. Consider the results when (and it will) that occurs...... Don't assume any training or intelligence on the part of the end-user. (see previous)
Your co-workers know a lot less than you think they do, but sometimes know a lot more than you think they do
Your boss knows less about programming than you could ever believe possible, it's not his job
Take chances, the standards you think your code will be held to are far lower than you've been led to believe
The standards of correct, well-designed, well-documented, and easily maintainable code are not the standards your customers and your competition hold your product to - software is more than code.
Hold your own code to higher standards than your boss does, but get it done within the business constraints he sets.
Be nice to the guy who is maintaining your code.
Seeking the perfect design is a recipe for disaster.
Interfaces should be inherited, implementations should be aggregated. Do it the other way around and you're digging a hole you'll never dig out of. Nor will that guy who is maintaining your code.
Objects do not represent real-world objects, no matter what the books say. Objects either manage state or behavior, not both.
Code flexibly those aspects likely to change, code rigidly those aspects unlikely to change. Novice programmers get that wrong more often than any other principle.
Never write code that "you're gonna need someday". That day is likely never come, and when it does, nobody, including you, will remember what you already coded for it. And even if you or they do, it won't be the right approach.
No principle, including all the ones here, is always true. Never violate them, except when you should.
Insightful and funny are really the same thing, except one has a punch line.
Ideally, one should have a formal education before writing software professionally--there is a lot of theory that has been figured out that is useful to know in practice. However, given that that is not going to happen, then my advice is to avoid reinventing the wheel, or, worse, inventing a bumpy thing that the car rides on but is slow and inefficient and uncomfortable and breaks from time to time. Collect references where you can look up algorithms and theory--apply what other people have done instead of writing new algorithms. Most programmers' jobs are tailoring known algorithms to current situations, not writing new algorithms.
If you want to grow up to be a great prolific coder, follow these two rules --
1) do anything that makes you want to write code
2) don't do anything that discourages you from writing code
Coders cease to be coders because they fail to follow these two rules, and many find themselves in marketing or customer support. Some even wind up in sales.
There have been quite a few good comments here.
Like:
-Don't take criticism personally.
-You aren't your code.
These are all very good comments. I would also like to point out that you are embarking on a long journey. Your not going to become a great programmer in a year. Not even in 2, 3, or 5 years. But you can improve and progress over time. To do that you should invest time outside of work on improving. I would first concentrate on your first language. After that I would start working on theory and some books like code complete, beautiful code, etc as well as reading programming blogs. There is a lot of crappy stuff out there but in time you'll learn how to sort through it which is a very necessary skill you'll need in general.
For theory books you should start earlier then later reading a data structures book. Move on to an algorithms book and eventually check out compilers a bit too. Throw a good design patterns book in there. I've found that the head first design patterns book is really accessible. More so then the gang of four. You probably don't know what that means yet. But if are software engineer for long you'll at least hear that name a few times.
This may seem a bit overwhelming and it is. But all of these things are useful tools. You'll probably never have to write a compiler. But you may need to write something that parses simple code and generates other code.
Simple data structure knowledge is invaluable. You should know the big O notation for all of your basic data structure operations. It is very helpful to be able to recall it like your ABCs.
You should also learn other languages outside of your scope. It'll help you to understand your main language more and probably give you new ideas as well as cement some common programming themes.
Learn how to use more then one operating system. Learn the strengths of weaknesses of each so you can make the right decision when developing and chose the right platform. You can use tools on one to help with the short comings on others. (Insert blurb about basic 'nix command line tools here.)
Next learn some operating system theory. It actually is helpful to learn how operating systems work when you are trying to trouble shoot weird problems.
Like I was saying before this is going to be a long journey. Your working on becoming a professional/craftsman. This will not happen over night or even over the course of a few years. Enjoy your journey.
Some people may scoff at this last suggestion. However, I would suggest going to a real college if you think you like programming. Get a computer science or computer engineering degree. Don't mess with a technical college. They really don't dig as far as they should into theory and won't help you get your foot in the door.
Plus college was a really great experience for me. It opened my eyes to a lot of things in engineering and outside of engineering. Plus I made some great friendships.
Good luck
1. Don't let your ego get in the way of learning from your coworkers and from yourself. You're all on the same team, right?
2. Use version control. I don't want to start a war about the best system to use, but if your version control system isn't at least as good as Subversion, use Subversion. There's really no excuse. Subversion is free, it runs on anything you're likely to encounter, and you can create a repository on your local machine if your team can't be bothered to run a server. If you use Windows, TortoiseSVN is a great shell-integrated subversion client.
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!
It's been a long time sense they almost got the 'Young Ones' and they are hungry and bored.
John McAfee 'It was like that time I hired that Bangkok prostitute; to do my taxes, while I fucked my accountant'
ALL programs share one requirement: security.
Learn about it (http://www.owasp.org), practice it, and do it well.
Application security is also a very lucrative career path right at the moment.
Andrew van der Stock
habits I should/shouldn't develop, etc as I take on my new craft.
Stop wasting time hanging out on /.! You should be working!
In my 20 years of development experience, I think nothing is so valuable as writing discrete pieces of functionality wholly separate, hiding the implementation details from the interface. Always write code as if you'll have to completely replace it (you probably will at some point), with an eye to making that as painless as possible (IOW, you won't have to change other code just because you changed this chunk).
I'd also recommend checking out the Test-Driven Development paradigm, which ensures you have complete test coverage for every line of code you write. It's not a panacea, but it really provides confidence that your code is correct, and makes it easy to ensure past mistakes are not repeated. I'm an extremely careful coder, and it still does wonders for my code quality, and often also my productivity/efficiency.
Having worked for a "cowboy coder" (someone who wasn't trained in programming) in the past, I recommend you take some programming classes at your local university. There are subjects covered there that won't be in your company-sponsored classes. You need to understand the implications of large sorts, relational databases, writing modular and reusable code, etc.
Nitewing '98
Everything works...in theory.
What's a FTOOMSH?
Number one tip for all programmers anywhere. Have an opinion, don't be afraid to voice it, but don't be a jerk.
Don't tell people that such and such is crap and they should feel bad for writing it, tell them you've got a better way and it can be improved.
Don't ever be fooled into thinking you're better than someone else and that there's no chance that they can tell you anything of value.
Always keep in mind that your job is to reduce and manage complexity - not to increase complexity or let it run wild.
Seek out ways to make your code simple and elegant.
A large part of complexity management is making sure that your code can be read easily, and that it's function is obvious from a quick scan.
Find good code (this may be difficult), and read it. You'll notice things including:
- short functions / methods
- each function / method does one thing, and it's name clearly tells you what it does.
- simplicity and understandibility is favored of 'trickiness'.
- in the words of the "Pragmatic Programmer" folks, the "Don't Repeat Yourself" (DRY) rule is followed.
One more thing - don't fall into the bad habit of "I'll do it this crappy / complex way now, and refactor it / comment it later". In practice, "later" rarely happens.
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.
"The question of whether machines can think is no more interesting than [] whether submarines can swim" - Dijkstra
Did Robert Frost need a course to become a poet? Albert Einstein to be a scientist?
I have nothing against courses. They are quite useful. But if a course is all you need to become a programmer than I can tell you that you will be part of a problem, not part of a solution. A programming course should answer the questions which you already have.
You sleep a programmer, think as a programmer, born and die as a programmer. Programming is a philosophy to make the world much better place. It is about being a part of a technical revolution.
The Russians have won. They have made the world a cesspool of distrust, greed, fear and hate.
1. Get good at reading code. Two reasons for this:
a) you will pick up good design techniques by osmosis the more code you look at, and
b) pragmatically, this is what you'll be doing most of the time as a team programmer.
Get good at seeing overall patterns in the code, and learning how to quickly narrow in on the part that's important to the job at hand, while ignoring all the rest--otherwise, there's just too much to keep in your head at once.
2. Always write code to be readable by humans. Logically structuring code so that others will be able to easily understand and modify it (and your code will *ALWAYS* be modified), is much harder than simply writing a sequence which will execute correctly in the computer. It is also crucial, given the scale and complexity of modern software engineering. Communicating with people is more important than communication with computers.
3. Realize that your code will live longer than you think it will. Anything that's meant as a quick hack which isn't immediately replaced with something better will become entrenched, forgotten, and will be used without a second thought for years afterward. People will want to re-use it as a template for other code, or re-organize it into a form you never anticipated. Therefore, make sure it's always understandable, as easily modifiable as possible, and never check in code unless you are prepared to see it copied and pasted into future projects for years to come.
The software business is a mess. Sure there are some pockets of brilliance, but in general things are chaotic.
If you are working with an established product (i.e. one that has been around 10 years or more) it probably doesn't follow any established principles and it will be frustrating to constantly be compromising what you know is right because of poor design. I believe that most large companies are mired in bureaucracy, incompetancy and so called process. That is why most "big" applications ultimately "suck"
Let me just sum up what everyone above has said, and what everyone else will say: Write code other people can read. This means commenting often, using consistent naming schemes, remembering that white space is your friend, etc. Above all, do not try to prove your programming chops. We'll assume you know how to code by default, don't try to impress us by condensing a dozen lines of code into two.
Be absolutely sure to remove all the useful 'notes to self' in your source code, just in case they confuse the people who have to maintain your code after you have jumped the boundary fence and gone on to the greener pastures elsewhere.
It's essential that you express your ego by punctuating, frequently, any remaining comments or programmer documentation with vulgar 4 letter naughty words and the occasional ".". Commas, colons, semi-colons etc? They are only for 18th. and 19th century authors of true literature.
Use the most hi-falutin' prose you can dream up in the user documentation. It will enhance your standing in the company. You know, use "utilize" instead of "use" and similar ad nauseam.
Make sure you split infinitives and put adverbs before verbs, such as "To boldly go".
In spite of the fact that all compilers allow for long strings as variable names, your excellent memory for details allows you to use identifiers such as slb2docm when those mere mortals with poor memories would have wasted time and energy with something like: sales_ledger_balance_to_date_of_current_month.
Never ever even dream about your program handling error cases, because it's a total waste of time and intellectual effort. Equipment never fails, and people are perfect. After a while you will get complaints about this. Your thought is that your users are careless and need a good prod to wake them up. So you send an error message something like: "Er Um?\nYou're a clot!!\n?". Make sure to handle every error condition identically. Never, ever, anything more informative, because it will reduce the force of the aforementioned prod.
You know you made in the precise image and likeness or your $DEITY and never ever make mistakes, so with absolute certainty, you know that you simply never ever need put ASSERTs in your code. That's for weens. :-) but many a true word is in jest.
Master `vi`
`vi` users disrespect casual Emacs users and merely tolerate the few hardcore Emacs users.
All other editors are for complete `tards and it shows in their code.
Indent with 3, no less, no more spaces. Don't use tabs. Tabs in code is for 'tards.
And braces need to line up like so:
if ((/* some sort of condition */)
&& (/* some other conditions */)
&& (/* some ever better conditions */))
{
}
People who tell you otherwise, or that style is a matter of taste...
you got it! Tards.
Stay the hell away from Windows programming. You know why.
Don't be tempted to think that it's someone else's responsibility to handle backups and versioning. Always keep your own when possible, even if you're using some kind of enterprise source code mgt. This sounds paranoid and overkill, but you'll be amazed at how many things it can help you fix in a pinch.
Please don't use "umm" or "err" or "erm".
Never, ever under any circumstances should you comment your code. If other people can understand your code then you are easily replaced.
string s1 = obf;
string s2 = ever;
string s3 = uscate;
string [] s4 = new string[] { "ything", "ly", "can", "possib" };
string result = s1 + s3 + " " + s2 + s4[0] + " as much as you " s4[3] + s4[1] + " " + s4[2]
-- Sex is the antonym of pringles. Once you pop it's time to stop.
I'm just curious, did you have any qualifications besides 3 years of working at the support desk? Do you at least write code in your free time?
Most of the people in our support department would be terrible programmers. Some might be able to hack it, but they'd probably stick to ifs and for loops and make everything look like a huge main block.
Then again, there is one guy in development who does write everything like a huge main block.
If your only qualification is 3 years of working at the support desk, then you are lucky they hired you rather than someone with at least a B.S. in Computer Science. The best advice I can give you is start writing code in your free time immediately. Follow tutorials on common data structures, like stacks, heaps, pointers, etc. Once you have that down, start practicing OOP.
25 years ago I read a book called Software Tools in Pascal. This had a huge, beneficial impact on me.
The most important single thing I learned from that book is something they called "left-corner design". It goes like this:
Find some small part of your project, preferably something at the lowest design layer. Then code it up and implement it. Make it so brain-dead simple that you can spot all the bugs, and fix them. Now, consider some simple way to make it do something more, something else needed for the final product. Then make it do that, and fix it until the new feature is also working perfectly. Iterate.
As a real-life example, I once made an advanced audio DSP (digital signal processing) engine. It started out as a program that could open a wave audio file, read all the samples, and write them to another file. Then I added a function that could do some simple processing before writing the audio. And then I added some more stuff, and some more, and so on.
As much as possible, make early prototypes that actually do some useful subset of the problem you are trying to solve. If your program will have users, give them early prototypes and see what they say. The Software Tools book had an aphorism that 80% of the problem solved now is usually better than 100% solved later.
You may also find that, as the users try out your prototypes, they may discover surprising things. Perhaps what they originally asked for isn't what they really wanted, and you need to drastically redesign. Perhaps once they start using your prototype, they may invent new features that they really want more than some of the other stuff they asked for.
And perhaps you may get a surprise: "Yeah, we told you you could have 8 months to develop it, but now you only get 4." And three of those months are already used up. The left-corner design hopefully means you will deliver something. And it might just be enough.
The opposite school of design would be to think everything through and plan everything. Hold long rounds of meetings, draw diagrams, that sort of thing. That may actually be appropriate in some industries; if that's how they do things where you work, study it and try to figure out if they have a good reason for it. But even if so, you may need to knock out some sort of handy utility for your own convenience, and left-corner design is the way to do that.
steveha
lf(1): it's like ls(1) but sorts filenames by extension, tersely
The best thing to do, in all seriousness, is be slow and methodical. Make sure you understand everything every step of the way. This means that you're going to be an idiot for at least 6 months, but after that you'll have a solid basis. A lot of people try to avoid looking dumb at first, so they act like they understand everything, but in the long run that's a mistake.
Be lazy, really lazy, as lazy as possible.
Don't write any code you don't absolutely have to.
The less code you write, the less code you have to debug, test, etc.
Code like the person maintaining your code is an axe murdering psycho that knows where you live.
Write code like your too lazy to write any documentation and then write useful documentation(this goes back to the being lazy bit), only write documentation if it's going to be useful. useless obvious documentation just increase the chance that the mass of documentation will never be updated and the person who has to read it will curse you to hell.
- Jesse McNelis
...and that is all I have to say about that.
http://jessta.id.au
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.
Be ruthless about eliminating complexity whenever possible.
In the end, that's really the job of a programmer -- managing complexity. When there's less of it, your job is easier.
We get this question on the Head First C# forum every now and then from people who read the book, finish it, and want to know what to do next to get a programming career. Here's the post I usually send people to. One thing I think new developers should think about is working on a team -- that's a skill that takes practice, and doesn't always come easy to developers. The better you are at it, the more successful you'll be in your career. (I've got a few tips in that post for getting that kind of experience. Contributing to an open source project is definitely a good start. Karl Fogel's excellent book, Producing Open Source Software, is a great way to learn about how to do that effectively.)
Building Better Software
Then you have no business maintaining said piece of code. RTFM, before you start maintaining. Some ops, in some machines, have side affects that aren't obvious from a single one-liner comment on the side.
As Scott Meyers says, use 'const' whenever possible.
So I prefer:
const unsigned num_days = leap_year ? 366 : 365;
to:
unsigned num_days = 0;
if (leap_year)
num_days = 366;
else
num_days = 365;
So, yes, leave the ? : ; ternary operator is our friend.
On the technical side, read a lot of code. Write a lot of code. Learn about data structures and algorithms. Read books and blogs about software development. Don't wait for permission to learn a new skill, just show up one day and start doing it. Experience counts, so does enthusiasm. All the really stupid mistakes have already been made, there isn't any reason to repeat them. Have fun. If you aren't, find a different job.
On the non-technical side, be smart, and get things done. Be reliable. If you say you are going to do something, do it. Find out what your manager wants to get accomplished and accomplish it.
Those are the main things...
don't forget there are people recognize what a bat product theirs are, too.
Don't be afraid to ask questions! No matter how silly they may seem to you - if getting them answered will get your work done faster you will benefit in the long run. And learn.
My 2c: The best way to answer some tougher programming questions is to prototype specific tasks. Part of this process requires that you have an always-ready environment that allows you to do so. Your own prototyping tools would in this case simply be a ready environment which would permit you to just jump into code without worrying about prerequisites. Something as simple as a prepared template would do, or a tool like this one: http://www.youtube.com/watch?v=Yfxrt2pc3pg
When you merge you 3 months work back to the main branch, you will not check every change in every file.
There is now code in your app that no human has ever seen Your change + My change may be just peachy, or may be broken.
If you have unit tests, then you have a higher confidence level that Your change + My change play nice together.
When you fix a bug, add a few unit tests to cover it.
http://davesboat.blogspot.com/
Most important for a programmer is to know how to test your code.... AND DO IT!
Any monkey can make code. Making code that works is the mark of a good coder.
This doesn't come with time or experience. Even the most experienced coder makes coding errors (and lots of them), but what distinguishes the good coders from the bad is that the good ones FIND their mistakes before releasing their code!
So, test continuously, test often, test everything, test every single module/function in isolation, test the modules/functions working together, then test everything again!
Make automatic test programs that you can run at a moments notice (or even better have a test machine checking out your code frequently and run them). Run them at least once a day (no, I'm not kidding). Remember, the sooner you catch an error, the less 'cost' it carries.
Use a code coverage tool to ensure you've tested all your code. Test methodically, not haphazardly 'poking' the code and calling that 'testing'.
I've been coding professionally for 15 years now. It still amazes me to see how many 'old' coders think they're coding gods just because they know every in and out of a dozen languages, and yet their code still fails frequently because they don't bother to test it (they don't need to, "because they know their shit" *roll*).
Learn to test your code well, and you're well on the way even if you don't know the language you're coding in as well as others.
Asking that question disqualifies you as a developer
You may joke but sadly there are many open source projects where a core 'elite' of programmers seem to want to do just that. Many people believe that if their code is going to be read by lots of people then it should look 'clever' (read: incomprehensible). NO NO NO NO NO!!!!!
Readable well commented code is better than 'clever' code that is nearly impossible to understand 100% of the time, and one comment at the top of a 15,000 line source file saying something along the lines of "this file is responsible for managing data" doesn't count as commenting in my opinion.
Posted anonymously so that I don't get an angry horde of open source developers coming to kill me.
I recommend brushing up on (or learning from the beginning) algorithm design techniques. These are formal ways to diagram how the code works before actually starting to write the program itself.
Avoid the primitive one-dimensional flow chart technique and learn instead the two-dimensional Warnier-Orr style of algorithm design. Google for tutorials.
Then, (as our programming teacher at Portland Community
College used to tell us) get a big sheet of paper, a little pencil, and a really big eraser. Start with really simple programs and learn how to draw loops, branches, and linear instruction sequences. Get good with free-hand drawing of brackets. Draw lightly with the little pencil so that you can erase whole blocks of bracket drawings. When you master simple programs, learn to draw linked lists, binary trees, and recursive loops like the QuickSort and the Tower of Hanoi.
Learn how to walk through the Warnier-Orr drawing and try every thing that you can think of to make your walk-through crash. When it does, erase that section of the drawing and re-draw all the brackets and symbols for that procedure. Every hour spent successfully crashing the algorithm is many hours saved debugging actual code.
Do all this at home. You have a new job and your employers will question their decision to promote you to the programming crew if they see you drawing big brackets and symbols on a sheet of paper. Especially if you tell them that this is formal academic programmer training.
It actually is, but they won't believe you.
Good luck.
I started reading books on software design and best practice from day one when I was struggling to get my first program to compile. I am glad that I did as something always sticks and I never felt overwealmed by new challenges as I always wanted to apply some new techniques. Learning more than one language is a very good idea. So if you are writing serverside webapplications, say, then its a good idea to learn advanced javascript for the browser. Else if you are writing divice drivers in C then it is a good idea to learn advanced shell scripting for the OS. If your learning Java then learn Groovy. Its a good idea to learn a 'complimentary language' (e.g. an agile one that helps you out in your day job) in such a manner to learn to see more than one approach to any problem. The best advice I can give any programmer though is to take a touch typing course at a secretarial college and learn to type. Most programmers type with one finger and thats a bit of a bad industry joke really. Once you can type at full speed you can write really descriptive comments, method names and variable names. You will also be more productive. Sure you can get a typing game to train you to touch type but no-one ever completes those so I lugged my behind down to a secretarial college and forced myself to complete the course. My final advice is that once you get the hang of programming try to spend at least a helf day a month experimenting with fun looking opensource software in your favourite language. Your learn a lot from that that will help you in your day job and will also have fun.
Never trust any input from anywhere. A large number of existing security vulnerabilities are because programmers couldn't be stuffed validating input. If you should be getting an integer, then make sure it is one and throw an exception (and log if appropriate) if you didn't get one. If you should be getting a string, make sure the string content fits with what you are trying to achieve, and isn't too short, and isn't longer than it should be. The above is especially true if you are passing on input from one area (say a customer) and passing it on to another (say an application server that will end up putting that input into a database). Never trust that other people's code is validating your input either if you are passing input to their code!
Catapultam habeo. Nisi pecuniam omnem mihi dabis, ad caput tuum saxum immane mittam.
A few things I learned from my colorful career as a programmer:
1. Attention to detail is a life or death skill.
2. If you ever get stuck figuring something out, once you do fix it, write yourself a small blog entry about it.
3. Regardless of how weird the error looks, it happened to somebody else before you. Google it, I can assure you plenty of people before you wrote about it.
4. Don't rush. You are s new programmer, it is expected that you will need a little more time to get things done. Play that to your advantage.
5. Every successful programmer I know has very solid fundamentals. The fundamentals are critical, one of the most prized skills of a really good senior programmer is the ability to pick up new languages with not too much effort. Over the years I have noticed that every single shitty programmer I have run across had weak fundamentals and was instead focused in knowing just one language/platform/whatever.
6. Learn the code macro capabilities of your platform's most common IDE or editor. Almost every major IDE, and all of the legendary "programmer" text editors, have this functionality. BBEdit allows you to write very powerful scriptlets in many scripting languages, VS.net has a feature called code snippets that is a fantastic time saver. EMACS has so much stuff that many see it as almost an operating system.
7. Learn regular expressions now, it is a skill that pays off immediately.
8. Learn proper ANSI SQL, it will make it much easier to switch between major RDBMS platforms.
9. Don't worry if your "lead" apparently knows less about programming than you do. Sometimes your lead knows more but is drowning on non-programming work, some other times it's going to be a programmer that wasn't good enough as a programmer but it is somewhat usable as a first line supervisor. Or somebody's cousin.
10. People love to pin problems on the programmer. Learn the politics of the game, there are subtle ways to protect yourself and deflect that kind of thing.
11. Embrace Goddess Caffeine.
12. Try to understand your customer. Mot all customers are dumbasses, and once they like you, they keep asking for you which is nice. When the customer is at ease with the programmer, the project manager can relax a little bit.
13. Every time you are about to say "it can't be done," give it another minute, see if you can turn that around into "that won't work, but there's a way around it ..."
Pedro
----
The Insomniac Coder
"I love my job, but I hate talking to people like you" (Freddie Mercury)
Perhaps your first task should be ask for a spell-checker. :P
Your best hope is that there's a real programmer there to mentor you. The programmers that arrive at my shop, 1 in 3 can be mentored, and the rest are a waste of a seat. 1 in 10 can actually write usable code out of the chute.
Wouldn't have been the Millennium would it? :-)
A few minutes spent testing while you are writing your code can save you hours later when someone finds that the system isn't doing it right...
You will not remember or recognize the code you wrote 6 months ago. You will not remember how that neat little hack worked or why you put in that odd little exception. Learn to comment the unobvious (and when commenting the obvious why you did it is more useful than what the code is doing).
Find an editor that does auto-formatting for your language (and use it!), it makes the code easyer to read and more pragmatically when the formatting goes wrong it means you have missed out a bracket of a ; or something and can spot/fix it without having to execute the program.
Always code as if the person maintaining your code is a physco who knows were you live.
If you are on a team, you most probably have more experienced people all around you. Leech off of them for as much as you can. That's where you will learn most of your worst/best practices.
And yes, read some specifications on the environment you'll be using. Language, servers and other technologies. You don't need to know these documents off by heart (they are on paper for later reference) but skim through them at the least. Ok printing the iso specification for c++ is by choice :) It was mine heh.
Also drill yourself on 'finishing' your work. Cleaning up source files before submitting is never such a bad thing.
Simple answer, 3 parts:
1. Document more than is necessary. B/c your estimates of what's necessary will always obsolesce over enough time.
2. Test cases. Tests that make sure the code runs, tests that you can run later to see what broke what.
3. Don't be a savage. Use real identifier names (i,j,k are only ok in very specific cases), well indented code, version control, etc. Code Complete was suggested above, it's a good place to start. If your shop doesn't do version control, that's no excuse for you not to.
Care about electronic freedom? Consider donating to the EFF!
First, in order to become a good programmer, you should expect to read about one hundred times more code than you write (in terms of finished code). Read both your colleagues' work and code from elsewhere (open source stuff, stuff in books, etc.).
When you are reading a program, try to decide if it is good code or bad code. If it's bad code, decide why. As you start to move beyond "well, it's not done the way I would do it", then you will be in a place where you can learn new ideas and techniques just from reading somebody else's code. When you see code you think is bad or even just hard to read, decide why and figure out how to avoid doing that yourself.
There are a lot of second-rate programmers in the world. They get that way by avoiding the chance to learn from other people, and through not learning from their own mistakes. Try to set your work up so that you do learn from your own mistakes. For example, eventually one of your colleagues will find a bug in code you wrote. If at all possible, fix it yourself. Then go look for similar cases in the rest of your code. If they don't want to give your he bug to fix, ask them to explain what you did wrong and how you can avoid doing it again. Once of the best experiences in my programming life was doing this for a couple of years while working on a life-critical system. I learned a lot about how to write better code, and how to write programs so that the compiler catches the bugs for me.
You should read some books that will give you ideas about how to think about program designs, approaches and how to approach the nuts and bolts of the field. However, the best reading list depends quite a bit on your chosen language. Here's a rough list (slanted towards C and Java, so if that's not your bag other books may be better choices):
These are also good but are more narrowly focussed:
I would also suggest that you make a to-do list of things to learn or find out about. A big item on there should be to expose yourself to a small number of programming languages that differ quite a lot from the language you mainly use at work. An example of such a diverse set of languages might be: Visual Basic, Java, C, a scripting language (e.g. Python or Perl), LISP, and a functional language (e.g. Haskell or ML). The idea here is to squish your brain into a configuration where you can think about your existing problems in terms of a selection of programming paradigms.
If you are lucky your employer will recognise the need for everybody to get better at their job and help pay for these books. My earlier employer didn't, but I made a habit of buying a good book every month or so and reading it. I'm a better programmer for it. My current employer pays for books, but I find I buy different kinds of books for home and work (e.g. at work I bought "Python in a Nutshell" and at home I recently bought a stack of compiler books).
As far as possible, code for open standards and avoid using (unimplementable) proprietary extensions unless you are forced to use them. This will ensure that the usefulness of your code won't be in control of a single vendor.
The largest prime factor of my UID is 263267.
I agree with the "comments first" approach; but better yet is the "tests first" approach. Build all of your non-ui code using jUnit or testNG with mock objects. Then you effectively document the expected behaviour of your code with sample code (the tests) that show all of the expected inputs and outputs for the scenarios you thought of, the bug fixes you made, and the enhancements you put in.
Writing unit test code before you write your application code will force you to think about "what it does" before you think about "how it does it" which is the starting point of any design. Coding the test cases first guides you naturally into creating modular code compiled to interfaces. IoC frameworks such as spring, picocontainer or hivemind are a big help when working this way. Maven the build tool supports the tests first approach and can publish a website of reports based on the tests run to show what code is covered by the tests. (The examples above are java but there are similar frameworks in other languages, it is the approach that is important not the particular tools to support the approach).
The pay off to the effort in setting things up to work "tests first" is that you get less defects and more modular code that you can refactor with confidence. You know your code is working after you change it when you see all of your old tests passing. Rather like the 'tortoise and the hare' you seem to start off making slower progress but you finish the race ahead of anyone else when you have code that you can keep on adapting and changing in response to the inevitable late in the day changes, fixes and enhancements.
If you can't see both ends of a loop or condition, then what's inside is too damn long. The minute you have to start scrolling or trying to match braces across multiple pages of code, you lose track of what loop / condition you are inside of.
Never be afraid of using something like GOTO HandleAnError;
If you are making a set of say 20 tests, and need at any point to abort the remaining ones if one fails, then having 20 levels of nested conditions is NOT the way to go.
Likewise if your indenting is such that you have to horizontally scroll your editor to even see the start of a nested nested nested statement, then it is again far too nested already.
Simply make a test - did it fail ? If yes, then GOTO the error handler - otherwise continue with the next test etc.
It's clean, unamibiguous, and saves scroll work with your mouse and a lot of time in mentally unwrapping all the nested levels.
Oh, and finally, don't EVER believe your boss when he tells you it needs to do "X AND Y, but never Z" ... because chances are three weeks later he will come back and say "make it do Z also".
Code defensively, as if you know you will have to come back and modify it later ... don't ever assume a project is finished, because in my experience, it NEVER is !
Oh, and good luck.
Dude... You been slashdotted before you even wrote your first code... what do you worry about?
Write functions that do what their names claim they do and NOTHING else. Then comment on non obvious things, pre conditions for algorithms etc but do not put comments in instead of better function names, decomposition etc! Yes, your could should be readable without comments. Oh and yes, pick up many different languages and perhaps most importantly - have fun!
The best advice and the least followed: K.I.S.S. - Keep It Stupidly SImple. Resist the urge to delve fist-deep in complicated frameworks.
One thing I've seen people fall into is the whole "Im leaving exactly at 5" thing. Now when you've got something that really needs to get done, do not be afraid to sink a little more time to get things to a natural break point before you leave the office. Makes it easier, for you, to walk in the next morning and start in a clean way. It also sends a message to the boss object and the new coworker *pool that you actually give a fsck about what you do.
Reply to That ||
You'll be a better developer if you work under good developers, challenge them, and seek to understand why they do the things they do.
In addition, look at major open-source projects in the language you'll be using if they exist. For example, as a Java developer, I often looked at Apache Jakarta projects as a reference for the "right" way to setup a project (with continuous integration, tests, documentation for new developers, etc.)
One thing I wish that I would have done is to blog everything I learned in a major free hosted blog server (hosted by a large company that would hopefully not go away anytime soon). If you do this though, you might just want to keep records as text files while you are working and then blog them later. But don't blog anything with company specific data in it! If your company has an internal wiki server, you could use that for private documentation usually, or worst case store it in text files only, and then be sure to periodically make a local copy of it and all of your code that you write to have a personal copy, if you can. Early as a developer you'll need to provide source to places you apply for work, and it is good to have your work for your own purposes as well.
He gets to code for a day and see the number of bugs that can be introduced.
1- Master OOP 2- Learn about Patterns but don't be patter happy! 3- User Version Control 4- Unit Test 5- Write readable code. 6- Automize repetitive work as much as possible.
Here are some things that I consider to be inviolable rules for programming...
1. Never EVER design a user-interface around what you already know how to program. Design how the UI is supposed to work, and then learn whatever programming you need to learn to make it work that way. This is an inviolable rule as far as I'm concerned. Getting this wrong is how you end up with nightmarishly bad interfaces, like unresizeable dialog boxes too small to contain the information you put in them. Don't do stuff like that. Ever.
2. Don't hardcode numbers, unless they are physically incapable of being changed (e.g., pi).
3. If the application is going to be distributed outside the company, you probably don't want to hardcode strings (that the user will see), either. Some strings are for internal use by the application itself (e.g., part of a file format), or for communicating with other software (e.g., part of a protocol); those you can probably hardcode. Also, the "can't find configuration file" error message string will have to be hardcoded.
4. Error messages should start with an oversimplified end-user-oriented headline, consisting of 2-4 non-technical words, and the headline should be *unique* to that specific error message, because it's the only thing the user is going to remember and report when there's a problem. Including some technical detail may also be appropriate, depending on the situation, but you can't count on users to report the technical details back to you in bug reports, so make sure the friendly headline uniquely identifies the specific error.
5. It is *theoretically* possible to write too many sanity checks and send too much information to the log file, but as a beginning programmer, you are certainly going to err in the other direction, guaranteed. For now, it's best to assume that more sanity checks and more logfile entries are automatically better. When you reach the point where you have to start rethinking that and cutting back, it will be a milestone in your programming career.
6. Comments should tell *why* the code does a certain thing. Don't comment on what it does. That's redundant. Any competent programmer can tell *what* the code does, just by reading it. But the reasoning behind it may not be apparent even to you, when you look back at your old code in a few months, let alone to someone else. Explain _why_ in the comments.
7. Don't hardcode filenames or paths, ever. Even the config file location should be possible to override in some fashion (e.g., via command line argument or environment variable).
8. It is *theoretically* possible to make an application too configurable, but I am not aware of a single documented case of this actually happening in the entire history of computing. If you aren't sure whether anyone will want to change a certain thing, it's best to assume that someone will want to change it for some reason.
9. Options are for advanced users; default settings are for end users. Don't let end users tell you what should or shouldn't be configurable, and on the other hand don't let more advanced users tell you what the default settings should be. If the advanced users want something different from the default behavior, they'll be competent enough to change the settings. Design the defaults around end users, so they don't *have* to change any settings. Also note that you may want to create a UI for some of the simplest options, but it's okay to let more advanced users edit the config file for the more esoteric stuff, especially if the config file has comments explaining what the options do.
10. Don't get caught up in theoretical purisms. Sometimes the object-oriented approach is best, but sometimes a more functional approach works better. A good programmer chooses the approach that fits the problem at hand.
Cut that out, or I will ship you to Norilsk in a box.
As a new programmer, I guess the first thing is to learn how to program.
One of the biggest issues I see from any software (OS's on down to utilities) is that the coder doesn't have any idea who the user is or how they expect to interface with the program. I have seen common words re-defined by programs (MS is the worst at this) and common conventions ignored. Try and get a few basic business courses such as marketing, management & accounting so you can somewhat speak the language. Also I would try and get someone in the department(s) you are coding for to be intimately involved in the project from design to final acceptance testing so any issues can be caught early. Good luck and remember that you aren't really coding for your boss but for the user. (That would be me in a lot of cases)
If you are going to design and implement software components that have any UI in them, please FOR THE LOVE OF DOG do not assume yourself to be a competent GUI designer and expert, just because you know how to spell out language logic into your IDE or WYSIWYG editor. Even if it has a GUI editor, leave it alone and abstract your non-GUI logic so that you can connect it to a GUI later when someone competent in the area finishes one for you.
Awful GUIs as a result of mismanaging priorities and areas of competence are all around us, and I am sure you yourself pondered over few bad examples. Now is your chance to understand the issue and not make the same mistake again.
I presume of course that your are a software programmer, not both (which few people are). You are not your target audience, so if you think an OK button should be to the left, it does not make you an authority in the matter.
When it comes to the rest, most is already said. Observe, be careful in the beginning, design as much but not more than you can in advance, minimize the code writing phase (it will spare you your arms and brain). Do not overcomplicate neither the software, nor the tools you will use to create the product, tools like IDE, compiler, UML editor if any, etc. Do not overuse the abundance of choice you as a software developer have. The most useful software is very simple in the sense that it achieves its goal exactly, no less, no more. You will be thanked for that more than you will know. Read books, as much technical as wisdom-and-guidance sort. But reserve an opinion, it is what makes you an unique programmer, not just a typewriter monkey. Be skeptical meeting the type of programmers that try to convince you about some definite programming practices they sincerely think are best. Heed to their wisdom of experience, but reserve an opinion. Value practical code over theoretical approach, because it is the real products we use, not theories. But do not reinvent the wheel, most theories have been implemented in practice, and it is what makes your life easier.
Remember, the most probable goal of your company is to make money, so that you can get your salary and your boss may buy himself a new wristwatch for 2 grand and pay ails to his ex-wife. Combined with the fact that most folks that comprise the bulk of an IT company would not know half of what you will know about IT internals, they will ignorantly still push their own ignorant agenda when it comes to the style of product. It is your job to provide them with the necessary insight so that product is quality, not just a seller. Adobe Photoshop may sell well, but it is in absolute sense a mediocre product.
Thanks for reaching this far.
I was firmly in camp 1, until a more experienced developer "showed me the light". I think my code has improved 10-fold since then, but who knows, as I gather experience & tools change I might go back to the first camp (though I doubt it right now!). Whichever camp you start off / end up in the following always apply:
Even after 5 years of coding I write code that I think WTF was I thinking when wrote it after a couple of weeks away from it.
"How to be a Programmer: A Short, Comprehensive, and Personal Summary" by Robert L. Read is an excellent and wide ranging paper that the author released with a GNU FDL licence. Here's the pdf http://samizdat.mines.edu/howto/HowToBeAProgrammer.pdf
Agreed wholeheartedly. I really only ever write two types of comments. The first type is the sort of comment that gets fed into javadoc, doxygen, etc: API documentation. Even then, you generally don't need to say too much if you've designed your library well. The second is comments admitting that something sucks and explaining why it sucks.
Sometimes, though ideally not very often, something prevents you from doing it the way you would have liked to do it: lack of time, design flaw in a library, deployment constraints, bugs in other components, etc. That's the sort of thing I like to see in comments. Tell me why it's not done the "obvious" way, otherwise I'm liable to waste time trying to change it to the obvious way.
Generally this latter sort of comment will start with something like FIXME:, HACK: or TEMP:. At a previous employer we had a tool that would grep the entire codebase for this sort of comment and produce a report of all of the craziness so that it'd stay on our radar and eventually be fixed one way or another. Even though I don't have that tool at my current employer, I still make a point of writing the comments in this way so that in theory such a tool can be used.
Don't go Overkill,
But if you have to copy/paste a section of code > about 6 lines, it should be put into a Function/Procedure that is globally accessible.
There's nothing worse than finding a bug in a section of code & realise it's in 10+ different places.
Name Functions/Procedures something suitable, readable code will help you & others. (same for variables, unless its obvious).
Rest is pretty much depending on what language ur coding for. I assume its OOP (of some sort).
Another pair of eyes (programmer) is sometimes good as well, another person may think of another approach etc.
And always if in doubt, use google... :)
Well, as someone who has been programming for the last 22 years I could write an entire book on this subject. But from the top of my head I have three things you should definitely bear in mind, whatever programming area you are about to move in to.
1) Plan. If a project goes wrong and it's the programmers fault, in most cases it's due to the lack of planning. If you don't know how to plan a software project or a software programm: Learn it and apply it whereever you go. There is an entire subsection of our profession dedicated to this particular issue. Quite a bit of it is academic masturbation, but there is a reason this field of expertise exists.
2) Cover the entire pipeline of software production. If you don't know how to automate the tasks you need to do 10 times a day, how do you expect to be able to automate other peoples tasks with your software? Learn about your tools, toolkits and appstacks at every level and learn to cover the entire pipeline of software production with what you do. That includes versioning, building/compiling (if you're using compiled stuff), sync & deploy (if you're doing web-stuff), deployment, testing and debugging. Read my comment on the web-admins stack here to get a picture of how deep you should be able to dive in your field of expertise.
3) *START* with learning OOP. If you haven't programmed yet, you have an advantage. You can start learning the OOP way right away and won't have to deal with academics and crappy literature that can't explain OOP to people who are used to the procedural way of doing things. OOP isn't hard and it's also not the holy grail it's presented as, but it's a good approach and methodology and the only way to do software in certain fields (such as business logic). As a sidenote: It's a myth that people not used to OOP are spoiled for their life. It is true however, that there are very few people out there that can properly explain OOP to old-school programmers. You avoid that shortage by learnign OOP right away. Look into procedural stuff later on. Also because the people doing that are helpfull and usually don't have their head up their ass as much as the former. :-) ... I actually recommend that you look into starting your programming with Java - however bizar that may sound. It probably will help you in the long run.
Good luck.
We suffer more in our imagination than in reality. - Seneca
It worked even for COBOL. If you don't know where you are going, it doesn't matter how you get there.
You'll have to upgrade your wardrobe if you're moving from tech support to programming. For example, your tennis shoes need to be thoroughly cleaned. Toss out the ripped AE jeans and get Levis. A little facial hair wouldn't hurt, just make sure it's a little shaggy around the edges. And don't forget to start wearing your hair longer. You'll also need a trademark, like suspenders or orange sneakers, or maybe chewing tobacco and always walking around with a cup in your hand. Use one drawer of your desk for late-night snacks. Toss out all the trail mix and stock up on twinkies (Hostess - not the generic ones). Ho-hos are okay on Fridays, but generally stick with the Twinkies. On a more serious note, don't try to reinvent the wheel. Find some similar code that someone else on the team has written and use that as a starting point. Never start from scratch.
While there are realistically about 50... the main 3... the ones that best identify if you are a good programmer... or "that guy"...
4) Understand the coding tags you are using. Not just that they "work". This is the biggest source of problems when upgrades happen. Just because it "does it" doesn't mean it should be used for it.
3) Use standard code writing utilities. There's nothing worse than opening a file to see that 10,000 lines of code is actually 1 single line. We had a russian developer who used this crazy tool. It didn't format to any standard... and yeah... it was ugly.
2) Indention indention indention. People who don't indent make me sad. Their code is unreadable and typically it's to hide their inept abilities and security holes.
3) COMMENT YOUR CODE! Not just for others to follow your logic but for YOU to follow your OWN logic when you come back to it in a year and go "WTF was I doing here!?!".
If you do the above... chances are you'll end up being a very good developer. Other people have posted a LOT of great books and resources for coding. After you've mastered the above, if you are doing web applications you should look into the following
SQL Injection Attacks (Learn how to prevent them)
Relational Database Design
Frameworks (Tomcat, MachII etc) a lot of time these frameworks will save you days of work. Steep learning curve though.
SVN's
"It works on my machine" from your lexicon. It only makes you seem like a jackass to everyone else.
So many injustices..so little time..
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
All bow to his Noodliness!! His Noodle Appendage has touched me!
So, what was it today? White widow? Kush? Blueberry?
Keep on Slashbongin.....
music lover since 1969
Learn C (need to understand the computer memory model), and that's it. All the rest is bullsh... and fashionable stuff.
The first three rules of programming I adhere to are as follows:
1. The end user is dumb
2. The end user is dumb
3. The end user is dumb
I use those rules to remind myself that if it can be broken the user WILL find a way to break it. THINK about it before you write it. Make it "user proof". Something that I personally find useful is purposefully trying to break it. Not just writing it so it works and saying that I am done. No, do everything and anything to it. Even the most off the wall, could never happen scenario. Then study why it broke.
Also, there is no problem with re-using code. Everyone I have every encountered encouraged it. That leads you right into making code as generic as possible. This way you can re-use segments over and over. If you know you need to make 25 or 500 of something then write a generic builder.
Finally, do not re-event the wheel. Study the API. Chances are what you are trying to do is already written in some form.
At least that is what I do.
Happy Coding
I'll try anything once. Twice if it tastes good
I'm not going to read through all 355 comments, so this might be duplicated, but I'm typing it in anyway.
I'm in a similar position right now. I haven't been given a title or anything, but I'm essentially writing pipeline tools and as the only programmer in the studio anything code-related falls to me.
One thing I've found is that it's always a good idea to, within the limits of your time and ability, code with the intent of making things easier and more intuitive to the end user. This usually means writing code that's harder / takes longer for you. For me, for example, I'm about to code up a UI front-end to some tools in our 3D software. The easy way to go would be to make a few buttons and have users hold to a workflow. Instead, I'm going to take the time to make a more intuitive UI based on a library of functions I've been developing. If I'm successful, then people won't have to worry about workflow because everything they need will be visible to them in nicely-named boxes and radio check buttons.
Oh, and there's no such thing as too many comments.
The note on explaining it in English first is a good one (or whatever your native language happens to be) -- I find that coding is less a science, and more the art of language translation.
Learn enough about security risks in code... by enough, I mean enough to know that it's -as important- to write secure code, as it is to produce software that does what it's supposed to in the first place.
Remember "Profanity is the one language all programmers understand".
Get a copy of Code Complete - read it, and take it to heart
The big one - READ - study GOOD code, and understand WHY "clean code" is (There is another book for you "Clean Code")
Understand that you are NOT only programming for the computer, but that you are programming for the future programmer who comes in and looks at the code. (BTW there is a real good chance that the programmer who will be looking at that code in 6 months, or 5 years will be YOU) Code comments should not explain what, but why.
Find a few good blogs by experienced programmers - read them - particularly if they are the experts in the Business matters that you are working on.
-- 73 de KG2V For the Children - RKBA! "You are what you do when it counts" - the Masso
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.
----- Open Source = More Secure (mmmmkay)
Listen to your elders... or, at least, those who have been in the business longer than you have. :)
GC
Gregory Casamento
## Chief Maintainer for GNUstep
... 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.
[signature]
A developer will separate the "UI" from the application. The developer can write a UI -- if that's what the boss wants deployed... blame the boss, NOT the developer.
I've had people tell me "the UI must look EXACTLY a certain way", for no particular reason. Can't tell them its a bad UI; they pay the bills.
Just another "Cubible(sic) Joe" 2 17 3061
The technical part is easy - that just tells you how to get the job done. The hard part is getting the correct requirements.
Doesn't matter if you're writing for your co-workers or for paying clients - Listen to what they are trying to do.
When something isn't clear, don't be afraid to ask questions.
When it still isn't clear, ask who really does the work (but don't put it that way). 90% of the business intelligence in this country is sitting on Excel spreadsheets handled by administrative assistants. Find them, befriend them. They are your only conduit to getting things done.
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
Do some programming for fun. Invent a side project for yourself, something you want to do for its own sake. Have fun. Play.
Do you like games? Write a simple game. Do you like math? Write a program that models some mathematical principles.
-kgj
If you write an object, method, function, or subroutine that has a scope outside your own code -- it can be linked to or called from anywhere else -- you can't ever change its parameter requirements or return results in such a way that previous versions will fail.
You can get around this with overloading, you can get around it with version numbers on your newer declarations (yuck), or other such hacks.
Don't write your code such that people who depend on it can't upgrade to the newer libraries simply because you've changed all the calls they have to make.
F'ing Microsoft does this and it is painful as hell.
if your original method was:
int doSomething(int var1, int var2, int var3)
and you need a fourth variable in a newer version, keep the old version around and either overload it (just create the new method with teh same name and the other variable) or give your new method a new name. Where possible, move the code from the old method to the new one, and just call the new method as the only code in the old one -- supplying the missing data.
Yeah, I know it makes for a lot more code and more methods in your libraries -- but it makes version upgrades happen a million times more smoothly.
The problem with quotes on the internet, is that nobody bothers to check their veracity. -- Abraham Lincoln
That is to say, don't be adverse to doing it the way a more experienced programmer has asked you to do it. Its ok to except the wisdom of another programmer, you don't have to reinvent everything.
Conversely, if you have the instincts of a good programmer (if not, you should be doing something else) and something strikes you as not ideal, don't be afraid to test it and see. And if you're right, don't be afraid to tell your superior what you've come up with. But do it with tact and respect.
That, really, I think covers the biggest issues. Because anybody who's not willing to learn from others and anyone who's not able to test things and improve them where it makes sense to do so, all while maintaining good communication skills, is not someone who should be programming.
-- Senior Software Engineer, Attorney appearance services, locallawyerapp.com.
A very useful book is
"Practices of an Agile Developer" by Venkat Subramaniam and Andy Hunt
The Pragmatic Bookshelf
http://pragprog.com/titles/pad/practices-of-an-agile-developer.
Code Complete (recommended above) is also very good
* Version control everything
Pay attention to your choice here. I've used Bazaar and Mercurial for some personal projects, and will be migrating to Git at work. (Notice a common theme? DVCS! (Distributed Version Control System))
Version control has a profound impact on how you work. On small/personal projects, I recommend DVCS simply because it's easier to setup, and quicker to work with. Why waste time building a Subversion server, or signing up for one on Google Code? And if it's on Google Code, do you enjoy not being able to work when your Internet is out? Never mind the difference between commits happening instantly, and taking several minutes.
On larger projects, DVCS is helpful simply because merging is easier. It's gotten to the point where I avoid branching in Subversion for anything that'll take less than a day, because it could easily take 20 minutes or more to merge those changes back in, assuming no one else is touching trunk in the meantime -- and I'll have to resolve a few dozen conflicts. With Git, merging is much quicker and easier, so I branch whenever I feel like it.
* Test everything
Hard to say whether the parent menant human or automated testing. You need both.
In particular, read up on test-driven development, and behavior-driven development.
Once you understand that, unless your company has a profound need for speed, use the language which most cleanly allows you to specify intent, not mechanism. (If working with a larger project, this may not be up to you, but there's always the occasional script.)
Oh, and chances are, your company does not have a profound need for speed. Premature optimization is the root of all evil. Optimize after you have a performance issue, not before. (Given the choice between two equally pretty ways of doing something, you might choose the faster -- but if the faster-executing way is going to take 20 times more code, don't do it until you need it.)
Don't thank God, thank a doctor!
The technical aspects of being a developer within a company are only half of it... you also need to learn how to deal with upper management who has no clue about what you do or what IT does in general. I wish every manager who deals with IT would be forced to read The Mythical Man-Month. Most don't understand that software development is a mental job, not a physical one, and everyone's mind works differently. For example I work best coding for two hours then taking a 10-15 minute break, but my boss looks at this as wasted time. I can't tell you how many times I've stared at a problem for hours, stepped away for 10 minutes for a soda break, and come back to figure it out in seconds. NOt taking the break actually wastes time! Also deadlines are important, so be firm on when you can finish a project. If you think it'll take X amount of time and no less, make sure they know it... and if you get into the project and find that you need more time, let them know quickly as opposed to the day before the deadline. I've worked many a late hour because I wasn't up front about a deadline or didn't voice my objections to unreasonable dates. But every company is different. Some have younger management who understands what IT does, but most aren't. And it makes matters worse when you don't have an IT manager or programming lead who doesn't stand up for the folks under them. So sometimes it literally becomes dog-eat-dog... when that happens i suggest finding another gig. Hope this helps --
I've been working on very well-known projects for many years, and the best advice I can give is to avoid shared mutable state.
Based on my experience, here's what you should become proficient in:
- Updating monolithic systems with functionality they were never meant for.
- Having lots of meetings. Lots and lots of meetings.
- Looking busy without actually being busy.
- Adding dots, commas, buzzwords and excessively overengineered language to technical documents.
- Taking really long lunches without anybody noticing.
- Getting told that you can't certain technologies because they're too new, and instead using even newer technologies because they were paid for.
That's about all I got. No, what? Of course I love my job. Why do you say that?
You know, the poor sucker who will be using it or the other one who has to try to get some information out of it.
Your boss didn't and is relying on specifications assembled and eviscerated by a PHB.
It's amazing how many IT applications were written to satisfy the Pres or VP and don't work because nobody ever consulted the actual user.
Even before you learn how to code, you need to learn how to test software. One of the most brilliant programmers I ever worked with was a lousy tester. He didn't know the first thing about bounds checking and what could happen when people fed him bad data. His programs always worked when he got good data, but tended to blow up when you sent him unexpected data.
That's the first thing you should learn.
"Politicians always tell the truth, when they're calling each other liars."
only one thing to add to all recommendations:
"THE USER IS STUPID"
never asume that the user can think like you, or reason like you, that's a common error because it leaves a lot of things out for the final product that cause a real pain later.
- Approach the job the right way. The goal is not to solve the problem in whatever way possible, but rather to solve it in the cleanest and most easily maintainable/modifiable way. You're not coding to solve today's problem but rather to create code than can be easiliy maintained and modified for the next 10 years.
- Minimalism / clean design. Most often the best design is the one that results in the least amount of code. If you can redesign or recode to result in less code (without reducing the functionality or maintainability) then that is a good thing. You'll quickly learn to regognize clean design/code from that with unnecessary cruft/complexity.
- Push yourself to tackle projects that are at the edge of your capability. You won't learn much doing stuff that is too easy! If work doesn't offer enough challenges (or even if it does), do stuff that stretches you in your spare time.
- Learn new techniques whenever you can. Programming talent is like sharks - it needs to move to stay alive! Whatever language/domain you are working in, try to identity the state of the art tools that others are using, and use them yourself. If you are using C++, learn to use the STL right away (hardly cutting edge, but you'd be surprised how many don't use it).
- Ask questions from more experienced developers whenever they arise, or whenever you suspect there's an easier/better way do to something. You'll advance faster by leveraging the experience of others than by having to repeat all their learning errors yourself!
Always remember, Code Reuse != Cut and Paste. Code Reuse should be done thru the use of public shared libraries. If the functionality you need exist somewhere else, but is not part of a common shared library set, look into making it so. Also, before doing this, or cutting and pasting into your code, make sure you understand what it is doing, and does it correctly. I can't tell you the amount of crap code I run into that is obvious cut and paste.
Whatever you do, don't listen to anyone on Slashdot.
But seriously, whatever you end up doing, there are a few things that are of value on most any project:
1. Always try to make your code readable and easy to understand for someone that's not inside your head.
2. Naming things well is critical. No amount of documentation or inline comments will make code with bad naming easy to work on, and when your code is well-organized with useful names, documentation and comments become much less important. Hint: if you have a hard time naming something, it's usually (but not always) an indication that it's not as well organized as it could be.
3. Always try to spend a certain amount of time reworking your code to make it easier to understand. 5, 10, 30%---as long as it's something. This will help with #1.
4. Always try to think about how you can test what you wrote. It will help your designs, it will reduce your bugs, it will help you relate to your QA, and it will help with #1.
5. Learn to let go. While you can take pride in your coding skills, don't get attached to your code.
6. Software development is a social skill. Become very good at these: working collaboratively, understanding other people's frustrations, finding ways of working with/around people effectively when you depend on them, articulating your ideas in an e-mail, and explaining to other people what you're doing and why you're doing it. Someone that is a decent programmer and has all those skills is a thousand times more valuable on any software team I've been on than someone that knows everything there is to know about software but doesn't have those skills.
7. Always try to find a way to make things less painful for your team, or at least yourself. Software development always has certain pain points, and there are usually things that you can do to reduce some of it. RCS/SCM, continuous integration, automated deployment, automated functional testing, a wiki for documentation, an IRC/campfire server for collaboration with people not in your office... all of these are things that can (but won't necessarily) reduce pain on your project. While you might have to pick your battles, never resign yourself completely to the status quo of your software development process.
8. Everything else is in the details, really. If you continue to learn (new languages, new frameworks, new app servers, new operating systems, new software development methodologies, new tools, etc.), and you keep to these basic guidelines, nothing else is particularly important, whether you're coding Java, C++, PHP, Ruby, Basic. If you're not learning anything new on your project, then try to work with your managers/clients/etc. to change that. Whether you put Java code in your JSPs, whether you prefer underscores or camel-case, whether you put SQL inside strings or use an ORM, whether you write your unit tests first, or last, or not at all, whether you like to put an 'I' in front of your interface names, or a str as a prefix for your String variables, or never use curly braces for one-line 'if' clauses, or swallow your exceptions---these things don't really matter in the long run. You'll probably change your mind on some of your most strongly held positions, and more importantly you need to be able to work effectively with people that hold very strongly to the opposite position.
And don't program on/for/with .NET ;D
angel'o'sphere
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
1. Use revision control, e.g. Subversion.
2. Use a formal bug-tracking system. At the very least, numbered text files full of issue descriptions.
3. Start spending some time in the relevant Usenet groups for the languages and technologies you'll be using. This will expose you to the gamut of good and bad practices, let you hear multiple sides to every argument, and put you in a position to make up your own mind about what conventions you care to follow.
No seriously, my advice is: Don't follow the "recipes", don't cut & paste code. Always have the REFERENCE docs open and get a real sense of APIs you will be using and their potential. That'll make you a better programmer.
Check out my cross-platform apps
I won't waste your time pretending to be a programming professional, however I do have to tell you something critical which you no doubt already know. COMMENT, like a madman! Six months from now your own code will be as foreign as a strangers to you. You need to remember why you did what you did, but you won't. COMMENT within the source.
Depending on which kind of coder you want to be, you can also get inspired for an attitude at http://www.catb.org/~esr/faqs/hacker-howto.html?PHPSESSID=22f7378d0d1ea654962a22bf13166a5a#attitude
My one golden rule for any scripting or coding is to ask myself the following question.
"Can anyone else look at this code and understand what it is doing and how?"
If the answer is no then it's not good coding, even if it does what you want. Remember that it might be you that has to return to it in a year or more and you don't what to have to spend hours just working out what you did.
(Sorry, don't have time to create a login right now)
You are wasting your life away. Go into something exciting, fun, and PROGRAMMING is not any of that. Especially if you are an idiot, like most so-called programmers are today.
Well , i guess it depends on the job i guess. In my job i have plenty of programming , but there's also a good part research and design ,and that's exciting enough.
Slipping shoelaces ?
Drug use and excessive caffeine consumption. The best skill to add to your repertoire is probably surreptitious web browsing.
I've worked on code with blocks that size that were not documented as you describe. Finding the corresponding start or end of a block was a big pain in the ass. And you know what? It was a trivial pain in the ass next to the problem of tracing through those garguantuan loops. I document ends of classes and namespaces (} // class Foo) just for convenience, but if you need to document if, for, and while blocks that way, then the code needs to be rewritten. If you have a hundred big loops, then it's better use of time to rewrite one of them than to document all of them.
"But it's what you _asked_ for."
If you do what you always did, you get what you always got.
Take factual courses, not process courses. Avoid anything called "software engineering" or "development" anything or "testing" anything. Be doubtful of the usefulness of "proof" of correctness, unless you are working on mission-critical systems. Interesting classes are likely to be assembly language, programming paradigms, data structures and algorithms.
All those facts you would get in college also exist in books, and generally on Wikipedia, which is why the education isn't necessary.
Everyone has their own personal cult; no one is right for everyone all the time. Many of them are better than 90% of what is actually done in the field.
Read books, including all the ones listed here. Also, Implementation Patterns, by Kent Beck. Later, or really, the first time you don't know how to structure something, buy Design Patterns, by Erich Gamma et al. Put it on your shelf, then buy Head First Design Patterns and read it instead.
Don't be afraid of "Head First" or other intro books; often they will provide the framework to understand the lists of available tools later.
Learn what tools your group uses, and then learn other tools as they become useful. Profilers, unit test frameworks, IDEs and debuggers will all cut down on the knowledge you need to remember at any given time in order to be effective.
Most of all, try things out. Don't be afraid to make mistakes, just make them big so they are found. If you don't understand something, try to use it. If you don't know how to proceed try the doing that really stupid thing that couldn't possibly work; either it will or you'll learn enough about the problem to find a different way. Don't get bogged down in either the high-level stuff, or the low level stuff. Eventually you'll realize they aren't that far apart, but in the meantime swap often.
It's not your code, it belongs to the organization that pays you to code.
In other words, drop the ego and protection about it.
Don't be afraid to release. This is the number one thing I see new programmers do. Work on something, not share and then be afraid to release it into the wild.
Show experience coders what you are doing, schedule code reviews with the experienced coders.
Remember code reviews aren't about beating you up, they are about explains different ways of doing things.
Learn to talk to your 'customers'. ask questions so you can find out what they want and what they are trying to accomplish. This may not be what the ask for. Use common sense.
The Kruger Dunning explains most post on
In general,
like all corporate jobs do as your managers tell you. It matters not if you are wrong or right, it matters not if they are wrong or right, it matters not if you are both wrong, it matters not if you are both right. It matters that they directly control how much you earn and how happy you will be in your role and there is not a damn thing you can do except resign to change things.
Do not publicly dis-agree with your management
Try and make your managers look good
Understand the business you are working in, not just the tech e.g. what is AP/AR/GL
Whatever language you are told to use is OK they all do pretty much the same things using different words. Learn concepts not implementations.
Make efforts to meet your users they are your clients and be respectful to them
The only book you need to pick up is from the pragmatic programmers 'The Pragmatic Programmer: From Journeyman to Master' remember although this book details how to do software dev your management overrides this unless you can convince them otherwise.
There are many other books to pick up but in general pick up classic books not how-tos e.g. pick up Mythical Man Month not Dummies guide to HTML, pick up OOA/OOD/OOP rather than the latest O'Reilly, pick up HTDP/SICP rather than Javascript in 24hrs.
If you wish to transcend the mediocre be prepared to understand that most dev shops are truly mediocre. The current status quo in development is in reality piss poor performance.
I am stoner, hear me RooR ;]
For heaven's sake, try to be humble. For some reason, this industry just breeds arrogance. You'll run into many colleagues that think they are experts at everything.
Few are, and the real experts are usually the humble ones you don't know about until you actually work with them.
Find those people. Emulate them, befriend them.
Be open minded, not just OSS minded...
One mistake I see a lot of new programmers make is to follow an belief system, and refuse or be reluctant to expand into other areas outside their belief system.
Even if you don't have an immediate use for a technology or programming model/language, don't run from it. There are a lot of things to learn from tools that you may never use in production.
This goes from OSS classics to even .NET and WPF/XAML concepts that are new programming paradigms.
Absorb as much as you can, and AS A PROGRAMMER, accept all things as viable options and 'part of your profession'.
The second words of advise, don't limit yourself to programming. With the current markets many employers expect employees to not only be programming geniuses that can do everything themselves, but also manage the servers (web development for example) and be security gurus. The more of these roles you 'understand' the better you are, even if you don't get stuck in these roles, as you will know when the people in the roles are screwing up the operations or making your job harder for no reason.
When commenting, write the INTENT of the class/function/method. So when a different programmer looks at it, they know what it is suppose to be doing.
Always remember, in 6 months, you'll be a different programmer.
The Kruger Dunning explains most post on
All replies on this site are nice and they have a point. Don't worry. Be happy. Read books and learn as much as you can. However, there is one more point: Know when to get out.
Let's face it, not everybody is cut for software development. If you succeed then great. If you feel like you're not enjoying yourself at work then it is time to go. Many people do not know how to do it and as a result we have a large number of dissatisfied IT workers who basically drag everybody else down. Don't be one of them.
Document first, then code. Then when you get overwhelmed by the long hours and unrealistic deadlines and confused by feature creep, you will be able to remember what you are actually supposed to be doing. And later, you will be able to do maintenance because you will have the documents specifying intent. If you try to document AFTER coding, you won't.
Document like you will be gone tomorrow. My business partner died and left me thousands of lines of code with no documentation. It took a year to find out that the subtle bug wasn't in the software but actually in the design of the hardware. And if you leave a project, and come back later, you might actually be gone. You will be a different person by then, and won't understand what you had in mind unless you remind yourself.
Unless you are using a braindead language that cares about it, use lots of white space to make your code clear.
And keep in mind that the coding is the easy part. Designing a clean approach, careful error checking and handling, fail safe, fail soft, and fail over, great human interface and the like is where a good program comes from. The actual coding can be assigned to a student if the design and documentation are good.
This might sound mean... but always look at what you are doing with the question "what can the end user do to mess this up?" For years I have watched programmers bang their heads against unexpected responses from users. Often accompanied by exclamations of "not even an idiot would do/type/click/think/attempt that!" So the summary watch phrase would be "expect the unexpected".
Your comments are written to answer questions that the people reading your code cannot readily answer for themselves.
Your procedure is:
Needless words are a complete and utter waste of time. If you're stuck in some PHB-driven environment that insists your comments provide unneeded answers, find some way of marking what matters. Right-justify the real comments, whatever works.
Whitespace is a language. Find the arbitrary parts in whatever style you're matching and make your use of them mean something that helps readers. Indent variable definitions differently, to subtly highlight them. One blank line or two?
Make it mean something. Don't document that meaning, because (a) if you have to document it, it's raising questions not answering them and (b) you're not perfect and the poor you will always have with you.
re the verbiage rule: the rest of Strunk & White is gospel also. Likewise Orwell's "Politics and the English Language".
As always, all IMO. Insert "I think" everywhere grammatically possible.
"training", "mentoring" just don't cut it. this is exactly why the state of the art is so bad. Software development is about designing and building things. Too many here and elsewhere wouldn't think of hiring a self-taught engineer or other professional but somehow think their mission critical applications can be assembled by someone with some help desk experience and no design/engineering education.
If you do this someone will hunt you down and kill you in your sleep.
I had to maintain code for a state machine for a disk platter verifier (old style 9" platter IBM monster fixed format) written in C and the moron programmer used 'i' as the state variable. The code was 35,000 lines just for the state machine.
Try finding every place 'i' gets changed by grepping for 'i'.
Oh and just for grins and giggles the code only ran on a modified 80186 SBC in a multi-bus embedded computer and the compiler was MS C 3.0 and the development system was across the street from the class 100 clean room that the only machine capable of running the code existed in.
Why bother
So why did I go to school for 4 years in CS and take Cal 3 where I had to hand graph 3D models when I could have just gotten "trained" by my company?!
Learn your tools, all of them, even those you don't know you have.Among these are: ... ).
* Compiler, learn as many options as you can.
* Debugger, no need to say more.
* Leak tester, along with other memory problems
* Profiler, not only for efficiency but to debug with too.
* Version control, if you company doesn't use any then get one of the free ones and use it yourself, religously.
* Any tools that come with your OS ( grep, diff
Use some common sense. I wish I could strangle every programmer that used a diff or "made changes" for revision comments. Don't reduce the effectiveness with your own stupidity.
Don't hope for good training from the company. A company will send a C programmer to a week long C++ course and expect them back as experts, at a university you will spend a year learning C++ ( even when it is a second or third programming language ). You're better off buying a book.
Well, you can as easily list all classes within a package as classes within another class.
You know, it started off with one or two commands. Then it grew, er, slightly. Yes, I might want to refactor and put the classes in a separate package as top level classes. Fortunately these are my runtime functional debug classes, and the class implementations themselves are deliberately sparse.
Things like this are hardly significant issues, until you spend an hour or two wondering why your code change does not do anything at all, without any warning :(
Read thedailywft everyday. Don't do any of that.
And don't waste all day reading slashdot.
Coder's Stone: The programming language quick ref for iPad
Create clear code, and everything that's still not clear: document it. In code comments (doc++/JavaDoc) is easier to maintain than other documents, so try and keep to that. Use an IDE with automatic code completion and background compiles (Eclipse for Java, Visual Studio is playing catch up for C#/C++), because this is the 21st century.
Once you are through with the basic basics, see if you can install a static code analysis package. With Java, I really like the combination Eclipse + Checkstyle. I think Lint is the one best known for C/C++. Ask a local Guru to setup a nice configuration for you that reflects the company style in use.
A static code analyzer works by looking for semantic (what code *does*) rather than syntax errors. It will also look for abuses or possible problems with your coding style. You can catch hints that even an expert would think of (at least not all the time).
Also learn about Unit frameworks for testing your classes. Personally I think you should use a code coverage tool with that so see how much code you are actually testing. Creating reliable code is about programming defensively and about using the correct tools to go with that. You test human interfaces by giving the code to your local sales dept, there's no way you can come up with Unit tests for that kind of behavior.
All these hints are pretty useless if you don't have a good support structure within the company though. Contacting the right people will probably be the best way to start. But they will be busy, so have clear questions ready or you will be put off.
Change management.
Unless your team's change control processes are highly automated and difficult to circumvent, almost all bad code that makes it into production is caused by either:
a) a very simple, last minute change that "doesn't need to be version controled (or tested or code reviewed), I know it's right."
b) compiling/packaging the wrong version of a file, either one that is missing a required change or one that contains incomplete changes.
Actual mistakes in coding usually trail these two issues, since most coding errors are usually caught during testing or during the design and code review process. Most organizations due better at testing and code/design reviews than they do at version control and SCM.
We are the 198 proof..
Personally, I really like Peter Norvig's eassy, "How To Teach Yourself Programming in Ten Years"
Write a block of code and then bask in its glory.
Then attempt to re-write it but shorter and better.
Loop :P
Thank you all for your response, I've got a good list of books to read, and a wealth of suggestions and pointers. Now off to go grab copies of them and read up.
..just because you can, doens't mean you should...
Always write your code as if someone else is going to be editing it. This includes tabbing everything neatly and writing as many comments as possible! And don't just write lazy comments either, write clear and descriptive comments as if someone else can understand what your code is doing, without having to reverse-engineer it.
Buy a large bookshelf.
is that you?
Yes, I'll second that. For example, a well written and generic sort routine will be called "sort", and will handle just about anything that is thrown at it. You write a call to sort, and it is redundant to have a comment that says "sort container X". But it makes a lot of sense to say why X is being sorted, or why at this point in the code, or how it fits into the bigger context.
The comments act to describe the bigger picture; like paragraph breaks in code to describe the semantics of a group of lines. Or abstracts summarizing a whole class, so that there is no need to read the entire code just to understand roughly how it works.
The primary reason we don't have the compiler checking our comments is not because we don't want to, but because we don't know how to. A little bit of English can convey a lot more meaning than a whole swathe of code, though less precisely. You can live and breathe code, and still not be aware of the programmer's intention without a little hint from the comments.
Every generation seems to make this assumption that code can be 'self-documenting'. Code can be a wonderfully precise way of describing some concepts, almost mathematical. But that doesn't mean that all concepts can be contained in a self-documenting piece of code.
You work on programs of hundreds of thousands of lines of code, and uncommented code really does become unmanageable. It isn't that hard; another 20% extra effort as the code is written...
Yarr, if you wish to be a true master coder, you must become a pirate. Review as much code as you can and pirate the parts you like. If there is something you see which you don't understand, take the time to research it!
When starting you'll make things harder then they need to be. That's ok, it's just the learning process. If you realize that there is a better way of doing something, stop what you are doing and do it the right way (even if it means a bit of a rewrite).
You'll find many coders which have been coding for longer then two years, will tell you how their code is the bomb and how you should code like them. Be wary of their advice, but listen to what they say and if it makes sense to you, try it.
Don't get cocky after two years and think your code is the bomb. Always try new things and keep learning. If you do something one way and you see someone else do it a different way, always sit down and ask your self why one way is better then another.
I personally love to code and find creative ways of solving complex problems. On the other hand, I've had a couple friends that tried coding for a while and eventually realized that they didn't really like it. Try it out and see if it's a good fit for you.
It sounds like you have little training in computer science, since you're coming into programming via the Help Desk. So I'd urge you to learn about data structures and algorithms. Learn which data structures are good at doing which things. Then choose accordingly when writing your apps. After that, you can back-fill with classes. Try to talk your company into paying for a CS degree.
Write your code as if you were a maintenance programmer that got paged at 3am because the critical batch update crashed. IOW, write it clearly and document concisely so the poor dumb schmuck who get's called to debug it has a hope of figuring it out
Do not believe in finites, infinites, right or wrong. In regards to your business logic... If someone says this will always happen this way, be ready for it not to happen that way. If someone says says this will never happen, be ready for it to happen. Plan for bad data. Plan for a connection to another system, database, etc. to fail. Handle it gracefully. Nothing you do in application development is right or wrong so long as it accomplishes the business objectives. There may be better, more efficient ways to do things. But give 10 programmers one business problem and they will solve it 10 different ways. Programming is an art not a science. I would avoid anybody else that tells you otherwise. Do not get attached to a programming language or any code you've written. Don't get pissed off if you burn away a week of your life code some amazing code and then find out it was all for not because of a requirements change. It can be frustrating. But it is just 1s and 0s and in the big scheme of life it is just unimportant. Schedule your life first, then schedule your coding around it. Doing it the other way is just unhealthy. Physically and mentally. When you do code do it with extreme passion. Don't do anything halfass. Always strive to learn something every single day. Be the go to guy at work. Patrick http://stopdoingnothing.com/
"Action is the thing that escapes most people. Great ideas are a dime a dozen. Great actions are few and far in between.
You can still write good code without having a CS background. Sure, if you designing an operating system, designing a compiler, or delving into some low-level code, more engineering know-how is required. However, I've found my Math/CS background only to be mildly useful when writing database apps...
Here are some things you can do to become a better programmer...
Mentorship
Find someone (preferable a group of people) you can talk shop with. Nobody loves solving someone elses problems, but most programmers like to discuss best practices. Pick apart other people's code. It could be an open source project or maybe just the source code to some guy's game you found online. Maintaining code allows you to see other people's mistakes. Writing good code is hard, writing maintainable code is even harder. You can learn a lot about design by being on the other end of the development process (i.e. maintanance). Sometimes mentorship is just reading good code.
Read, read, read...
All the coding in the world will get you only so far. You need to consult the wisdom of experts. Some other good books are:
Object-Oriented Software Engineering: Practical Software Development using UML and Java by Timothy Lethbridge and Robert Laganiere
2nd edition
website for book
They even have a DVD with an entire semester's worth of lectures (based on the book) available for $50 online.
Applying UML and Patterns
by Craig Larman
3rd edition
sample chapters here
There's a series of videos (about 3 hours in length) that describe many of the details in the book.
Anything by Martin Fowler
Martin Fowler's website
You may wish to also check out:
A seminar on the Object Oriented Design with a focus on the Unified Process (or something close to it)
Methodology, methodology, methodology
The above books will introduce you to many of the existing methodologies in software engineering. It's not so important what methodology you choose; what is important is how you implement it. While many people may disagree with me on this. Engineering methods can be taught, problem solving skills can be acquired, and math skills can be learned. You might not be the next Edsger Dijkstra, but you can learn to write very good code on schedule and under budget. It may be hard to write code at home when you've been writing code at work all day, but try working through a project from beginning to end with perfect documentation (yes, make use cases...) utilizing all the right tools (i.e. version control, bug tracking, make tools). Doing this will make you a better programmer. Learn to take a few minutes each day and write out what your going to do. I often start writing code for the day by opening up notepad and figuring out what I'm going to do in psuedo-code. After, I just flesh out the notes and spend the rest of my time testing. Some guys like to do this on paper. Many professional organizations start out a days worth of coding drawing UML (or some close approximation to it) on a white board. The key is to plan before you code. Don't just jump in front of your IDE.
What do you mean my sig is repetitive? What do you mean my sig is repetitive? What do you mean....
*Opens .vimrc, checks options*
:set backup
Kids these days.
The best advice I can give is: PLEASE, PLEASE, seek SIMPLE solutions to everything.
Look for patterns in the problem domain that map elegantly to capabilities in the solution domain. e.g. "this looks like a grid" database table/spreadsheet/array. Try to look for solutions that involve the least code, and will cope best with change.
Don't do overarching "this will solve everything" framework solutions. Avoid the "inner platform effect" (see thedailywtf.com)
A bunch of other things:
If you find yourself saying "this is just a quick hack, we'll fix it later", then that's a bad sign. Find a better solution.
Ask questions. Ask lots of them. Don't worry about being annoying. This will help you in not repeating peers' mistakes, and in not duplicating code. Work closely with more experienced staff members. Learn from them.
Leave your pride/ego at the door. Don't get attached to your code. Accept criticism. You still need to stand up for what you believe to be right - more senior people can still make crappy solutions. But, remember the politics and pick your battles.
Stir things up... but just a little. People get set in their ways, and this stifles innovation and improvement. As the new guy, you have a unique perspective, and your fresh ideas can help. In this game, there is no "one way" to do things, but established teams and experienced engineers often fall into the trap of thinking there is.
Whenever you find a solution, look for another one. Your first thought isn't always the best solution.
Learn from the team culture, norms, "this is how we do it around here". Fitting in is often (not always!) more important than doing things right (e.g. a solution cohesive with the rest of the codebase can be better than an otherwise superior solution). But, be sure to make a distinction between what you think is right, and what your team norms are - this is important, because both will influence how you solve problems now, and in the future.
Remember, not everything is best solved by writing code. Integrating existing components, or using existing components can save a lot of time.
Also, remember that there are thousands upon thousands of dumbshit hacks in the software engineering world. Beware of them and please do not become one of them. Focus on your skills and continually train yourself.
Always remember that just because it passes all the unit tests and gets through QA, it doesn't mean that it is good code. The first level of acceptability is "Does it work?". Make a concious effort to make your code maintainable and extensible.
The logic in the spec isn't 'like it (then) use it', and it makes no mention of leaving it alone in the case of not liking it, so your syntax is incorrect. Please re-read the spec.
Also, camel case is often favored by VB programmers. While it would be an assumption to call you a VB programmer, I will risk that rather than suffer a VB programmer to live. Please report to the nearest self-immolation center for immediate incineration. Thanks for your co-operation, and have nice day.
HA! I just wasted some of your bandwidth with a frivolous sig!