One piece of advice

Question

If you could go back and give yourself one piece of advice at the start of your programming life/career to help you on your way what would it be ?

Answer 1

Start using a trackball earlier. I do so now but still live in mortal fear of RSI.

Answer 2

Always write your unit tests first! If you tell yourself "oh, I'll just write them later", it will never happen.

Answer 3

Always layer your applications alone logical lines don't stick everything together in a big soup, and use the debugger more.

Answer 4

Learn to use a Debugger ASAP rather than using print()/exit() statements for debugging...

Answer 5

Start earlier!

I didn't even know how to use a computer until High School, where I taught myself BASIC. If I could do anything different, it would have been to start earlier in life. I had the mental capacity, but it was wasted on simple math. (I don't meant to say that Math is easier than Computer Science. I'm just saying that 5th grade math was some pretty easy stuff.)

Answer 6

You don't really know as much as you think you do (and 'select' Isn't Broken!)

Answer 7

Ergonomics matter! 14 hours straight same seat staring at screens. not natural.

Answer 8

"That year you really tried to learn Assembler? Don't bother, go outside."

Answer 9

If I'm talking to bpapa in college - do more development outside of your regular coursework. Get with a professor on a research project. When you graduate in the burst-bubble world it'll help you get a job instead of doing video game QA for 2 years.

If I'm talking to bpapa starting his professional career - you CAN afford to be picky when you are trying to decide which job to take. If an opportunity smells bad from afar, it's going to REALLY stink when you are actually working there.

Answer 10

I think the most important thing to teach to a young programmer is how to step away from the computer.

Computers are awesome, but I kinda wish I had more discipline, and a social life.

Answer 11

Code doesn't exist unless it's checked into a version control system.

Answer 12

Just jump right in and have a go. It's not as hard as people make it out to be and the learning curve is a steep as you want it to be taking baby steps is just as valid a way of learning a new skill as taking giant leaps and it helps you to take stock of what the next step is.

To sum up, do it, do it at your own pace, evaluate your progress and goals frequently.

Answer 13

Oh. skim the books, but the best sites are... sites like these :)

/mp

Answer 14

Don't spend so much time learning the quirks of the syntax. Learn the concepts, and the rest will come.

Answer 15

Make sure you meet a chick (and marry her) in college cause you won't meet anymore once you get into your (predominately male) workplace :)

Answer 16

My advice is similar to (but more general than) everyone else: just do more! In college you may feel too busy but you should certainly push yourself even further: get a good grip on Linux or Windows (certainly both helps too), go learn some language or framework that they didn't teach you at school, and so forth. Everything you pick up then will come in handy at some arbitrary point in the future.

If you don't like your current situation (maybe your job sucks), you can still do the same and pick up skills to get yourself a better job. It's never too late!

Answer 17

Register stackoverflow.com

and register crackoverflow.com

Answer 18

Simple. Learn Assembler. When you young and can spend 20+ hours a day looking at a screen filled with bits.

I'd almost say the same thing about C. But with modern C you spend most of you time learning the framework you picked (.Net, Cocoa - whatever). learning Assembler you learn logic. And how things actually work.

Finally, get laid. Now, before you get plumped and bald. ;)

Answer 19

Two digits will not be enough come the year 2000.

Answer 20

Knowing how to use a version control system tops my list as well as using unit testing. Getting this two things done pat as SOP will save lot of time in terms of lost source codes or having gazillion copies all over the place.

Answer 21

My biggest hurdle was/is stop thinking that I was stupid compared to other programmers. When you read great code or watch a great coder do his thing, realize he didn't get that way by some sort of magic, or that he was just born with this great ability.

He worked at it. He has made the mistakes you have made and he learned from them. Just know that the only difference between you and him is time and experience. Not some unseen, unobtainable knowledge.

Learn different languages, and when and why to use them. Learn an editor, learn everything you can about it. Learn as many tools as you can. You won't use them all but you will be able to chose the best and know why you chose them.

Answer 22

Practice, practice, practice.

I used to think that reading books and attending lectures would somehow magically transform me into a great coder. While these things are still important, there is nothing at all that can replace writing your own code, and a lot of it.

Also, read other people's code, whether they are more advanced than you or not. There is rarely one single correct way to implement something, and a lot can be learned from seeing how others think.

Answer 23

Learn to type.

Answer 24

The goal is to make programs that others like and use...no matter how good a program is, if no one uses it it's worthless.

Answer 25

Find people doing worthwhile things, and work/play/hang with them. There are many comments about a finding a social life, but if you keep hanging out with people doing clever and interesting things, it'll be a more interesting social life than if you just fall into any group. Also, work hard to expand what you find interesting: many fields apply to what you are doing, and you just don't know unless you look.

Answer 26

Believe in yourself. Stick with it. Make it good enough, and people will love it.

Answer 27

Keep learning! Strive to learn at least one new language, technique, methodology, or concept every year.

Answer 28

write code, write code, write code, read some, write code, write code, read some.

bad code is code - any code is programming.

more code = get better at coding. AKA this site =>

Learn about all aspects of computers while reading some.

And a must

*Title – Code: The Hidden Language of Computer Hardware and Software * Author – Charles Petzold ISBN 0735611319

Answer 29

Get an internship with at least 2 different employers. Ideally, one of the employers would do software as a business, and one of the employers would have software (part of an "IT division") be a supporting component of the business.

Doing this helps you know what type of company works for you, what type of development work you get satisfaction out of, what kind of teams you like working with, what type of environment/architecture/language really interest you, and so on. All that info can be helpful in shaping your goals and the methods you use to achieve them.

Answer 30

Keep up the good work.

Answer 31

You know all those crazy ideas you have? Implement them! NOW! In ten years, you'll be an overnight success!

Answer 32

Buy yourself the biggest, brightest monitor you can possibly afford (e.g. 30" Dell or Apple).

You'll be staring at it for a long time.

Answer 33

Spec your ideas before you code them.

Answer 34

Don't be affraid to put your code out there. Do it often and Do it well.

Answer 35

Get a job with an organization that considers software and programmers to be valuable and important to the organization's success. Stay away from employers who don't: the software will suck, your co-workers will not care, and there will be nothing you can do about it.

Answer 36

The debugger is your best friend. Learn it, use it, love it.

Answer 37

Pascal won't last long. Plan to keep learning new languages throughout your career, or you won't last long either.

Answer 38

Get a computer science degree, and learn math, so you won't be stuck building 3 page forms for peanuts.

Answer 39

Avoid jobs with companies who have no other IT support besides yourself.

Answer 40

Get a real job in the the industry while you're still in school so you can get real experience when you graduate.

Answer 41

There is no such thing as a universal best practice. They all break down somewhere. Learn where your favorite techniques and patterns break and why.

Answer 42

Never rewrite anything that works from scratch. Do refactoring instead.

Answer 43

Learn about the tools you use and how they work.

Answer 44

A few things:

1: When you pick your firsts real jobs, pick something you really love. Don't waste your time doing something you don't like just because it will give you experience, or even just because it pays well. Take advantage of the fact that early on your career you have way less to lose. Later (once you are married, or have kids, or are in dept, or all of the above) life will be harder, and you will have to make bigger compromises.

2: Get involved in every project you can think of during college. Contribute to a locally organized conference, work on a school software project, work on a codeplex|sourceforge|googlecode project. Party.

3: Have fun while doing all of the above.

Answer 45

Programming is a very sedentary and often stressful job. It sucks you in and makes you eat cold pizza and drink soda at all hours of the night. Look around at your co-workers. Many software engineers are pretty heavy and unhealthy. I wish I were thinner and healthier.

My advice: Exercise daily. Eat right. Don't ever get soft in the middle.

Answer 46

Learn to use the keyboard keyboard shortcuts in your IDE and other commonly used programs. The more time your fingers are on the keyboard the better.

Plus it makes you look like a pro to other people! lol

Answer 47

Understanding that to be a good programmer you HAVE to work with people. Being a geek introvert may seem like the perfect programmer profile but if you can't communicate with people they wont understand how to use what you've written.

Answer 48

bpapa is right. While you're young and relatively inexperienced, be picky about the jobs you select... they will become your experience.

Answer 49

Read books

I have developed .NET for about 3 years now, but I started reading programming books just about one year ago. I thought I am fine if I read some blogs, but infact you learn very much if you read books.

Answer 50

If somebody asks you to change something that you've worked on for a while & you feel really angry/frustrated about this - This is a problem with you. Learn to take criticism better.

Answer 51

The best way to learn any language/framework/whatever is to start producing stuff using it. You can read all the blogs/books/theory you like - you don't truly know something until you've used it for a while.

Answer 52

First: What Patrick said... you need source control

Second: Take a creative writing class and a public speaking class. Being able to effectively communicate your ideas to co-workers, your boss, or people at a conference is just as important as having the idea in the first place.

Answer 53

I would tell myself to learn C and continue to learn C++. My first language was C++, but I don't feel I'm that good in it as when I went to university, I was pretty much forced into Java. So I would just encourage myself to learn as much as I can in C and C++ before going to university.

Answer 54

Learn Smalltalk. The earlier you really appreciate and understanded object-oriented design the better!

Answer 55

1. Ask questions! Don't completely understand something? Ask questions until you do. Ask your teacher, co-workers, friends and on online communities like this one. The only dumb question is the one that was never asked.

2. Having a 'it just works' attitude can get you down a very scare path if you ever have to maintain it. If you are afraid on maintaining your code then it's either overly complicated or you don't have the necessary deep understanding of how it's implemented.

Answer 56

Test First - It forces you to define the minimal set of criteria you need to solve your problem. You'll build better interfaces (api), and you'll write less code by developing "just enough" code to pass the test. The tests also serve as "documentation" to other developers on how the system is supposed to behave and allows them to add behavior without fear they are breaking functionality.

I was surprised how effective this technique is and how it increased my productivity.

Answer 57

Don't get your life advice on the internet.

Answer 58

Keep up with the latest technologies, but don't overspecialize. Everything becomes obsolete or loses popularity eventually.

Answer 59

Write or help write something other people use and you have to support - you'll soon see where your weaknesses are when other people get their grubby mitts on your hard work!

Answer 60

Don't do prototypes!

(Actually a serious answer: As a quick demonstration for a major client side module of a large project I wrote some VB code (VB4 in the mid 90's). Rather than re-writing the code is 'c' as should have been done at the time, this code was used as production code, and built on. When speed, installation and DLL Hell issues became a really serious problem, it was too late to turn back. Given the time again, I would do some mock up screen shots as a demo, and only code seriously once the project was green lighted).

Answer 61

Actually finish some of your pet projects.

Answer 62

Read Code Complete and understand that the most important thing is that people can understand your program easily ( even you, 6 months later )

Answer 63

Your wheel is not better!

Suck it up.

Answer 64

Learn another programming language. The perspective you gain is worth it, even if you never use the language professionally.

Answer 65

Step through every new line of code in a debugger. It is the easiest way to find new bugs.

Answer 66

Never, ever stop learning new things. If you don't have the opportunity to try out new stuff at work, buy books and learn on your own.

Learn by both breadth and depth - learn a tiny bit about everything, and pick two or three things to really focus on and learn inside and out.

Answer 67

Don't sleep in till midday every day when at uni studying comp sci, it won't end well for you that way.

Answer 68

Try to always work with people that are smarter than you. Life is too short to be surrounded by morons and trying to fix problems that everybody are aware of but nobody really cares to fix.

Answer 69

If you don't know how to do something, give the problem a good name.

Answer 70

Maintain an interest other than programming and IT. Make sure you stay (or get) "socially healthy".

Also, find yourself a mentor or three to learn from - it's far easier and more interesting to learn from people than from books.

Answer 71

Any code you write, either

1. You will come back to it at some time after being away from it for 6+ or more months OR
2. Another programmer will have to look at it without you being there

So, make it readable, consistent, commented, and documented.

I've spent so much time and effort trying to figure out what code does that I'VE WRITTEN that it's ridiculous.

Answer 72

Write more code. The only way to get better at writing code is by doing it.

Answer 73

I'd advise myself to not be so frightened that I'm dumb, this stuff is really hard. I'd advise myself that nobody knows even anything close to everything so the hallmark of a good programmer is to always question everything and to remain curious. I'd also point myself at Jeff's article on Strong Opinions Weakly Held (well it didn't exist back then, I'd take a copy with me ;-), because that article has completely changed my attitude to life as well as code.

Answer 74

Your work is about interactions with others. With people, with problems, with systems, with office politics, with the customers, with your boss. You never work in a vacuum, even if you are the only programmer on the project. Learn to play well with others and you will be years ahead.

Good ways to do this include, but are not limited to:

• Source control
• Documentation
• Learning to read code
• Just listening
• Realizing that not all process is evil

Answer 75

Read about your practice... Keep up with one job related blog/site... Always keep learning...

Answer 76

Learn the difference between the things you can control and the things you can't control. That way, you can spend your time and energy (both very finite) worrying about and working to improve the things you can control (skills/knowledge, attitude, work ethic, assertiveness, adaptability, punctuality, etc.) instead of the things you can't control (your boss, others' opinions of you, etc).

Answer 77

Set aside some time every day for learning. It doesn't need to be much, 30 minutes first thing in the morning before you start reading your emails will do.

Answer 78

"Debugging is twice as hard as writing the code in the first place. Therefore, if you write code as cleverly as possible, you are, by definition, not smart enough to debug it." - attributed to Brian Kernighan.

... the blood, the sweat, the tears that I have caused myself!

Answer 79

Sometimes you just have to do whatever it is you think really needs to be done. It is easier to beg forgiveness than to ask permission.

At the same time, make sure you know how to do what needs to be done :)

Answer 80

Screw this job! I never wanted to be a coder... I always wanted to be...

...A LUMBER JACK!

Leaping from tree to tree, as they float down the mighty rivers of British Columbia.

The Giant Redwood.

The Larch.

The Fir!

The mighty Scots Pine!

The lofty flowering Cherry!

The plucky little Apsen!

The limping Roo tree of Nigeria.

The towering Wattle of Aldershot!

The Maidenhead Weeping Water Plant!

The naughty Leicestershire Flashing Oak!

The flatulent Elm of West Ruislip!

The Quercus Maximus Bamber Gascoigni!

The Epigillus!

The Barter Hughius Greenus!

With my best buddy by my side, we'd sing! Sing! Sing!

Answer 81

People are very superficial, get a smart suit (and keep it smart), iron your shirts well etc., and you will get on faster.

Answer 82

Contribute to open source.

From there, you'll learn the basic software development stuff that most schools don't teach like version control and issue tracker.

Surprisingly (though I'm not surprised anymore), a lot of programmers are still in the dark about these things.

Answer 83

When you realize that your job sucks, LEAVE. You're not under any obligation to stick with a failing company/project/team/... There are better things out there.

Answer 84

Never work for a company that doesn't score at least a ten on the [Joel Test] (http://www.joelonsoftware.com/articles/fog0000000043.html "Joel Test")

Answer 85

Buy Google stock!

Answer 86

Just build things and don't wait for someone to hand you a cool gig. Start your own businesses / websites. Be comfortable with failing. Just get in the habit of getting things done. Confidence is built on experience which is built upon learning from failure.

Answer 87

Go to college!! Especially before you get married and have 3 kids to feed!!!

Answer 88

There's no such thing as "Real Programmers", and nothing Turing complete is "Just a Scripting Language". You don't have to be a hard core into ASM and low level C to get respect (though it can feel bad-ass). And don't ever use something just because it's an industry standard.

There is nothing wrong with loving python, javascript, hypercard, multimedia fusion, the starcraft map editor, or whatever your guilty pleasure "not a real man's language" is. Programming should be fun!

Also, Don't wait for academics to teach you computer science. Start learning now!

David: "Learn to Type"

Oddly enough, that's the one thing I went in strongly believing. I even taught myself dvorak =]. Now I don't have a shred of carpal tunnel, but I am getting back problems. Maybe I should have invested in a quality chair.

Answer 89

Learn how to program in a group environment.

When you first start out, it appears that programming is a solitary exercise, just you together with the machine. To do anything real, though, you need to learn how to work with

1. One other person (either a programmer or marketer)
2. A small team (divide up a program into modules so that work can proceed in parallel)
3. A large team (you are a cog in the wheel of a huge project...)
4. Open-source community at large

None is this is clear when you start out.

Answer 90

I agree about the source control..very important.

Continue to learn other languages. Don't rely only on the language you program in at work. You never know when Microsoft is going to stop supporting it...

Answer 91

Learning how to do stuff in practice can be even more fun then learning to do stuff in theory. Start with coding horror, read proggit (ok, so that wasn't available till I graduated college). Find blogs that interest you. Its scary at first but you'll understand it all soon. Who knows, one day I might even figure out what Steve Yegge is talking about.

Answer 92

Drink more beer

Answer 93

Decide what your core competency is and adjust your career to exploit that competency.

“You can’t get a gold nugget from a horse turd no mater how hard you polish it.”

Answer 94

Based solely on the extremely limited experience that I've had, it would be: "You don't know half as much as you think you do." (Apply repeatedly.)

If I had a second it would be that "sometimes removing semi-colons is more useful than adding them."

Answer 95

• Don't printf debug
• Don't release code you wouldn't like to maintain. You'll probably will.

Answer 96

when coding, always disconnect your Internet connection.

Answer 97

Know what you want the code to do (framed in the form of a test, which needn't be automated). And the code isn't done till it's passed that test.

Answer 98

Do the risky items first.

In other words, work out what the greatest risk is to your project. The first task should be to do whatever it takes to drive out that risk, or kill the project early. Repeat until your funding source is willing to wear the remaining risks.

This piece of advice subsumes "Specify first", "Write a disposable prototype first", "Write unit tests first", "Write the user stories first", "Write the project plan first", "Learn your tools first". They are all just special cases, for some projects, of the general rule.

Answer 99

You learn to write good code the same way you learn to write good prose: practice and constructive criticism. If your organization doesn't do code reviews already, get them to do so. You'll be amazed at how much you learn by reviewing others' code and having others review your code.

Answer 100

Beware the myth of the perfect code... it doesn't exist and never shall exist.

I'd also add that design patterns are something I should have picked up sooner than I did.

JB

Answer 101

640k is not enough for everyone...

Oh,

and impersonating Bill Gates is not cool. I wish I knew that a sentence ago.

Answer 102

Assume NOTHING!

Answer 103

1) Read (good) code to get ideas

2) If you're writing anything that will take you longer than 3 hours to complete, more of your time will be better spent designing it (off the keyboard, on paper or a whiteboard) than you think. Don't just jump into writing code!

3) Learn about design patterns and good code practices -- you don't want to be that guy (gal) with everything in one giant class and try to debug your 3 page long function.

Answer 104

That cobol you are learning might just come in useful after all, Not every programming job will require you to know the ins and outs of inheritance....

Answer 105

Write Unit Tests

You know that test code that you write in your main methods as you go along, to make sure the code does what you think it should, then delete and replace when you move on to the next item?

Don't delete it. Find a way to keep it all and build it into an effective unit test/regression suite. Oh - and find out what those are at the same time. They are much easier to do than you might think.

You'll thank yourself in the long term.

Oh yes, and don't forget to coin the term Test Driven Development for it. Then it'll be your name that everyone remembers!

Answer 106

Practise your communication skills as much as possible, especially with non-technical people. They're most likely to be your customers.

Answer 107

Keep in touch with the good programmers/technicians/managers you work with; one day you'll want to hire them.

Answer 108

Don't try to finish solving a problem just because you start working on it. Instead, maintain a list of your most important projects and make sure you work a little on all of them on a regular basis (weekly, at least). This will enable you to deliver more than most of your peers, and sometimes with higher quality of the solutions.

Answer 109

Your life is about happiness, balance study and work with social skills and be active. Living healthy is way more important than knowing how code better than your peers.

Also, social skills is way harder to learn than programming anyway... there's no set syntax or mathematics in life, so spend as much time with your friends/partner(s) as you can!

Answer 110

Be prepared to throw the first one away.

Answer 111

Always write code with the assumption that the person who'll maintain it is a schizophrenic killer who knows where you live.

Answer 112

Get some sleep. Your brain needs it, and it will pay off double: No time spent on writing psychedelic, sleep depraved code, and no time spent on correcting your psychedelic, sleep depraved code from last night.

Answer 113

Get the higher degrees before you get a job. It won't happen because of time and expenses otherwise.

Answer 114

Start contributing to an open source project earlier (it took me nearly 10 years to get around to it) and check into a version control system much more regularly :)

Answer 115

1. learn about business and marketing before going out on your own
2. always have (at least) two clients, in case one disappears
3. if you want to get rich, you have to work for free (otherwise you don't own it)
4. sell products, not just your time; time is finite

Answer 116

You're a software engineer, so think like an engineer. Understand the reasons for things. Leave religion out of it.

Answer 117

Remember Hofstadter's Law: double that estimate.

Answer 118

Backup database then run sql command

Answer 119

Don't watch too much star trek, it's good to have something to talk about to people other than other coders :)

Answer 120

It's easier for your backup strategy if you have in mind

Code doesn't exist unless it's checked into a version control system - Patrick McElhaney

Answer 121

Learn to embrace outsourcing.

Answer 122

If you are behind on a deadline, talk to your boss politely before doing free overtime. Quite often your boss will extend the deadline, reduce the requirements, give some of the work to someone else or give you paid overtime instead. If he doesn’t it is a good sign that you need to find a new boss.

Answer 123

Time is your most valuable asset. So only do things you're truly passionate about. Spend your free time searching for a passion if you don't have one. You'll know you've found something you're passionate about when you can't find enough time in the day to pursue it.

Answer 124

Using other people's code is like wearing someone else's underwear. Get used to it - it feels funny at first, but it is ultimately a time-saver. As a corollary, learning to write in other people's style is a benefit for keeping the feel of their code. Also, don't bitch too much about other people's code. You have to work with other people. He/she may be the idiot today, but it will be you tomorrow.

Answer 125

Never, ever forget: You were looking for a job when you found the one you have now. You can always do that again.

-R

Answer 126

If you can't use the new technology you want to use at work, either get a job where you can, or create a side project to get experience with it.

Answer 127

Find a mentor and don't be afraid to ask questions.

Answer 128

Buy Microsoft stock.

Answer 129

Find a Mentor in your early career, i realized many of my assumptions where not correct.

if i had channelized my energy in my initial career, it would have been better.

and also Mentor some one you know who is in need.

Answer 130

Understand to better key Google Search Keywords and Google Features Boz you are going to use google a LOT

Answer 131

Patience, Perseverance, and Practice - These three things will help you survive the hours of debugging

Answer 132

Pursue your own interest first, work as much as necessary to pay the bills, and pursue the technologies you are passionate about. If you can't find a work related projects in those technologies to get experience in, create your own project.

Answer 133

If I could give one piece of advice to the 13-year-old me toying around with Turbo Pascal back in the day - it would be this:

Whenever you find yourself writing code and it's starting to feel really exciting and challenging.... That's when you're doing it wrong. Go back, re-read the API, grab a coke, relax - you're doing it wrong.

In my experience, great code is hardly ever what I call 'challenging'. Don't get me wrong; writing great code can be a thrill when you're in the zone, and it can be hair-pullingly frustrating when you're not, sure -- but the code itself is rarely 'interesting'. It's not full of cool hacks to make some parameter pseudo-overloaded in some special case; it's not riddled with exotic heuristic functions or nested ifs or magic GOTOs or completely obfuscated bit juggling. Even the most amazingly optimized algorithms follow sound, simple, elegant principles to accomplish what they do.

So the very instant you feel a tingle in that heavy-duty problem-solving part of your brain -- STOP! Because you're doing it wrong.

I am not the best coder in the world, and I don't work on the hardest problems known to man, so if I'm finding nifty solutions to hard problems, it's usually because I've created those problems for myself. With a little bit of refactoring, the problem goes away, and the code turns out far more readable.

Either that, or it's simply that I didn't check the API well enough, and the framework (or the language!!) provides a function just for that purpose, and one that was written by a much better coder than me. I can't even begin to tell you how many 'nifty' classes and algorithms I've built and then scrapped because I discovered there was an optimized language construct for exactly that purpose, sometimes even with the same method name!

Anyway, for better or worse - that would be my advice. Most of the time, great code is elegant, readable, uses practical, sound design patterns and best practices anywhere it can. And once you start to get it, that kind will tingle too.

Answer 134

Configure your e-mail client to only check for new mail once ever 60 minutes or so and inform everyone at your company that you will only answer questions sent by mail.

Answer 135

Comment your code where necessary

Answer 136

Take care of yourself. Programming is great fun, but your physical, emotional, and spiritual health are still important.

Answer 137

This is not meant to sound as philosophical as it does, and I post it in the context of programming.

Don't succumb to analysis paralysis. Even if you can't do it perfectly on the first attempt, just do it. Get a prototype version working then work to refine, enhance, and perfect the final product.

Answer 138

You're not as smart as you think you are.

Shut up, listen and learn. I pissed away a great many learning opportunities because I was too busy trying to be too clever by far.

Having mentored/managed a number of young developers since then, let me say, I was by no means unique.

Answer 139

Avoid jobs that deviate from your intended career goal of being a real programmer.

I've seen too many good coders get sucked into Help Desk / IT roles (which eventually became their careers) b/c they didn't look around and just settled with the first company to make an offer.

Answer 140

Work hard to reach your dreams while you're young!

Find a way to couple all those abstract concepts together into an integrated solution.

Answer 141

Take the time to make (even a rough) design first - it saves you lots of time later on. Even just putting down a few words to make sure that you have an indication of the direction you want to go in.

Answer 142

Optimize, optimize, optimize! Try to optimize everything that you do，no matter you do it once in your life or do it every day.

Answer 143

Be patient until you have completed your code and keep on improving it till u are statisfied with it

Answer 144

Learn the code templates and similar tricks first before diving into coding.

Answer 145

Learn to learn. It is, after all, your primary skill.

Answer 146

No matter how well you think you wrote something, in a year you will come to know how much it sucked! Focus more on making software that works and less on software perfection!

Answer 147

• Expect and demand the proper tools to do your job.
• Write out your specs.

Add-ons:

• Work on your departure to a better employer from day one. That is, document everything, leave nothing "for later" without notes, and so.
• If you want to do web pages, specialise in that, don't half-ass it. Get to learn the various browsers out there (keep an eye out for one called Firefox, believe the hype, forget its roots leading to Netscape).
• Browsers don't do large tables well, look towards Ajax or some custom XMLHttpRequest to fetch a portion at a time.
• The bottleneck is not the database, nor the software using it, it's in between, it's getting your data from the database to the software. A.K.A. small datasets are key.
• SQLite is not a database server. It's a friendly fread().
• Writing clear code helps.
• Look up "Dijkstra" on Google. Believe that he's watching you code, and he's not happy.

Further add-ons:

• A 32 bit float is precise enough most of the time.

Answer 148

Project managers don't.

Answer 149

Always check your ego at the door

Answer 150

Don't forget Google

Answer 151

The design of the program is as important if not more than the choice of the programming language.

Answer 152

Focus on understating the problem and simplicity of solution ALWAYS.

Answer 153

Always code as if the person who will maintain your code is a maniac serial killer that knows where you live

Answer 154

Don't be so close minded. There are other interesting thing's beside programming. :)

Answer 155

Make your code simple, and easy to understand for other developers, and don't worry about the performance implications this may cause. Most of the time, the ability for others to easily see through your code, will far outweight the (most probably irrelevant) performance costs.