It looks like none of my children will become programmers. Instead of letting
my fatherly advice to my new programmer son or daughter go to waste, I am going
to inflict it on you. If you are newly embarking on the journey that is becoming
a programmer, here is advice your father would tell you if he were a programmer.
These are things I had to learn the hard way.
Keep Learning: Read. Go to conferences. Subscribe to journals. Take
classes. Whatever it takes for you to keep learning, make it a priority. Learn
about every language you can find. Take time to learn about any new frameworks,
algorithms, techniques, models, paradigms, you can. Each gives you one more
tool in your tool chest. Each will help you more easily tackle your next
programming problem. Find a mentor, someone much better than you, and learn all
they can teach you. Never stop learning.
Learn To Communicate: I often joke that the most important skill you
can learn as a programmer is how to draw a rectangle on a white-board.
Communication is critical to the job of a programmer. Communicating with
customers, clients, users, co-workers, bosses, vice presidents, CEO's,
board-members, VC capitalists, all will become important at some point in your
career. Learn how to speak in public. Learn how to write in English. Learn to
effectively communicate in person. Learn how to persuade without shouting,
getting angry, or getting flustered. Learn how to speak without jargon. Help
people understand what you are doing. Learn to break things into simple,
understandable pieces. Learn to communicate by analogy and symbolism. Learn to
communicate.
Be Predictable: Learn how fast you can comfortably program. Wait to
predict how long it will take you to complete a task until you understand it.
Allow for the unexpected. Plan for vacations and time-off. Live with your
predictions. I don't believe I know a problem well enough to predict how long it
will take to complete until I can break that task down into sub-tasks that each
take no longer than 3 days (often less than one day). Live by this rule,
under-promise, over-deliver. It is better to deliver in 10 days what you
promised in 15 than to deliver in 10 days what you promised in 5. People depend,
schedule, and plan around your predictions. Make them the best you can and make
sure you can comfortably do them or you will be asked to live up to your
uncomfortable predictions. You will not be good at it at first; to compensate,
verify your predictions with someone more experienced. Learn to get better. Be
predictable; other depend on you.
Own Up To Your Mistakes: You will make mistakes. How you handle your
mistakes is how you will be judged. Learn how to say "I was wrong." If you
underestimated how long it will take you to do something, tell people as soon as
it is clear to you. If you broke the build, fix it. If you created a bug, fix
it. Don't deny the mistake, don't make excuses for the mistake, don't figure out
how to hide the mistake, don't blame others for the mistake, do something about
it. Take ownership of your mistake or you will repeat it.
Never Let Bad Code Off Your Desk: Your job as a programmer is to write
code that works, never let code off your desk you are not sure meets that
criteria. Not only does it reflect badly on you, it is much more expensive, and
much harder, to find a problem once it leaves your desk than before. Learn to
love unit tests. Learn to love code coverage. Learn to test your code better
than people who are paid to test it. Be embarrassed about bugs that are found
after you have checked-in. Be especially embarrassed when a customer finds the
bug. Don't rely on others to find your bugs for you, find them and fix them
yourself. Don't hope it will work. Test it. Don't assume it will work. Test it.
Don't whatever. Just test it. If you haven't tested it, it doesn't work; of this
you can be sure. But, even if you are diligent with testing, bugs will
get by you. You will make mistakes but try your best not to.
Programming is Fun But Shipping is Your Job: Programming is fun. It is
the joy of discovery. It is the joy of creation. It is the joy of accomplishment. It
is the joy of learning. It is fun to see your handiwork displaying on the
screen. It is fun to have your co-workers marvel at your code. It is fun to have
people use your work. It is fun have your product lauded in public, used by
neighbors, and discussed in the press. Programming should be fun and if it
isn't, figure out what is making it not fun and fix it. However, shipping isn't
fun. I often have said that shipping a product feels good, like when someone
stops hitting you. Your job is completing the product, fixing the bugs, and
shipping. If bugs need fixing, fix them. If documentation needs writing, write
it. If code needs testing, test it. All of this is part of shipping. You don't
get paid to program, you get paid to ship. Be good at your job.
That shipping part reminds me of a part from the book "I Sing The Body Electronic" :)
Amil | http://amilr.wordpress.com
09/22/2006 5:20 PM
I haven't even had time to think about settling down yet, passed the marriage age long time ago btw. So at least I don't have to be worried about my kids who won't listen to my advice.
"Own Up To Your Mistakes": Couldn't agree with you more as some developers tends to go round the circle with their Mumbo Jumbo to avoid admitting to their mistakes. They should work in Bush's administration really.
On the serious note, I wouldn't do anything else for fun and work other than coding and be involved in the world of I.T.
Here are my advice if I may to use this space to do so.
1: if you want to be in I.T. don't work as a programmer or at least do it for very short period of time. For the time and efforts you put in to learn all what you need the money is not worth it at all. If you are one of those lucky programmer who work 8 hours a day and gets a small fortune for it then you are in minority.
2: stay with a company as long as you can if you don't want to catch up with ever changing technology. If you work as a contractor then you are expected to know everything and to know most things you need to spend a lot of time learning them.
3: never work for a software house. This sort of company is only suitable for those geeks who want to work hard and learn fast.
4: never work for less than money that you deserve. Not only you won't do yourself a favour you also cut other developer's earning too.
5: never contribute your work for free when it could have business value to many. Remember tomorrow when you decided to get that mortgage or that sport car no one would donate a penny.
6: don't share your design openly to the people you hardly know. There are many smart people out there with cash that can turn around your design and make money out of it.
7: If you are going to make a presentation of your own product for someone or invited to do so always ask if they are doing the same thing or not. Many companies and people simply want to see what you have then steal your idea or get a lot of idea from it when they couldn't do it themselves. These days what it counts is who had the idea in the first place, any professioned programmer can do almost anything he sees but not many professioned programmers can be as creative as others.
8: don't make your work as your hubby. Listen to someone who is paying for this now.
9: if you don't like your work environment change it as soon as possible don't let this to ruin your appetite for success.
10: every job refusal is one step closer towards a better job offer. It sounds crazy but this is very true. So don't be affraid of trying.
Good Luck to you all...
Anon
09/25/2006 1:31 PM
This is a great post, I agree with all of it and what Anon contributed.
I will deliver the message to students that I teach ASP.NET 2.0 to at University as a volunteer though a Student Organization.
I've been telling them that for a while and this is all-in-one article, thank you. [Ofcourse you will be credited and linked]
finding a mentor has been the greatest struggle for me, I've come to find it on the web (blogs, open source projects, etc), but is not the same as actually working with someone everyday
Great article, I recognize a lot from what I did in the early years and still do.
At our school they always tell new students the following: Learning to program is one thing, Learning to engineer a program is the other.
And with engineering they mean, communicating with the customer about requirements and design desicions. Applying an engineering model to streamline the process of planning,designing, implementing ,testing and delivering software.
Chuck - thank you. I have printed this out and it now hangs on my wall. Although I have been programming for 16 years (OMG, has it really been that long?), your comments are just as applicable today as they would have been had I heard them when I was in college. Hmmm, maybe I should forward a link to the college (now a university) to include in future cirriculum... :-)
never underestimate the competence of your clients, only because they don't (fully) understand what you are doing. if they run a successfull business, then try to learn from them. they're not dumb because they don't understand anything about it, but you would be dumb, if you don't try to understand why they are successfull (and tailor your product to it).
i learned this when working for a jeweler. hey didn't know much about the internet, but he told me a lot about the way he deals with his customers, so his website (which i was working on) would benefit from his knowledge. it was a very valuable experience for me, because even though i was the experienced webdesigner, and the product was a webpage, he knew better how to approach his specific kind of customer interested in his jewelery, and that saved me from making a lot of grave mistakes.
stef | http://wehrlos.strain.at/
10/05/2006 9:39 AM
Under the heading of “Learn to Communicate”, make sure you learn how to listen, how to ask good questions and to take the time to truly understand others. I have had to deal with countless programmers who have preconceived notions of technical specifications and user needs that they simply don’t understand the ideas being discussed.
Communication is a two way street.
Dan
10/07/2006 7:28 AM
Hi,
great advise and I wholeheartedly agree. Also I would like to add some additional things (also usually learned the hard way):
1a. (addition to "Keep Learning"): Don't start or participate in "religious arguments". Java or .NET? Both have their respective advantages and shortcommings; Whether its pure OO or not is only of academic interest; Windows or Linux? Usually you're not the one to decide anyway. Bashing one and favouring the other will make you blind for the advantages of the other approach as well as for the shortcommings of your favoured system.
3a. (addition to "Be Predictable"): Learn to estimate. And don't forget that there's more than coding. Take meetings, design, testing, and documentation into account, perhaps add some time for the inevitable bugfixing afterwards.
7 (new point) Adhere to the requirements: 7a. Don't waste your time on addons, gimmiks, or presents, noone has asked for. If you've got a bright idea, propose it and have it made it a requirement. Only then you may do the actual development. 7b. Don't take the customers response personal. You just proposed one of your bright ideas and the customer rejected it? You pointed out a flaw in the requirements and the customer insists? If you think you know better, tell the customer and you have fullfilled your responsibility. But don't forget that it's the customer who decides and he may have to take things into account that you don't even know about. If he decides otherwise, live with it.
Alexander
Alexander | http://ajdotnet.wordpress.com/
10/09/2006 11:47 PM
Great post.
In Programming is fun but shipping is your job: "It is joy of discovery." should be it is "the joy." And "It fun to have your co-workers marvel at your code" should be "it is fun."
Thanks again. I wouldn't comment on this little stuff if it weren't good enough to deserve to have the typos fixed.
To the point, I recognize everything. I would have added one very important factor: * Define your task Myself I used to program a lot when knowing what I wanted to achieve but without first really knowing how I wanted to implement it, I just started to write code.
I'd like to add a few points about self-management.
No one mind, no matter how bright, can see let alone harvest all the good ideas which float around any given problem domain, so put your ideas on the table and watch them procreate with the others your team has. Hope for the best technical solution, not that you had the most ideas used. Let your brainstorms out-more ideas will replace them, never fear.
Cultivate an ear for that faint sound, off in the distance, of your wheels spinning, digging you into the mud. Knowing when to go home is a crucial talent and can save quite a bit of rework. Always backup regularly and do trial restores as well.
Don't get discouraged if a problem thwarts you. Just keep it in mind and the answer will arrive eventually. All of us veterans have tales of times when nothing worked, all our experts were baffled, and none of our usual tactics did a damned thing--But, if you keep at it, something is attracted by your imagination. Maybe an old friend's email, or a magazine article, or a datasheet from a mailing list you joined late in the second millennium. Something will work eventually.
You can accelerate this process by envisioning the day your solution shows up. As you drop off to sleep and just after you awaken, picture that day and how happy you'll be, how all your team will admire your design, anything else in the realm of positive emotions.
Most of us technical types are wary of the powers of our imagination, but try it out. It definitely works, and the more clearly you can picture your design, the more easily you can accomplish it. Watch out for negativity, since that also attracts. This is the real danger in complaining-not that you just see the "glass" as half empty, but that you actively attrack bad luck with that mindset.
Here is mine: 1.Acquire a PC. 2.Grab that programming books. 3.Use the internet as knowledgebase resource. 4.Teach yourself by doing it. 5.Follow your instinct. 6.Teach yourself how to follow coding conventions. 7.Learn when to use comments. 8.Patience is a virtue. 9.Avoid re-inventing the wheel. 10.Join and participate in the community.
See details of these tips at: Part 1: http://jacksbeanproject.org/wpblog/?p=11 Part 2: http://jacksbeanproject.org/wpblog/?p=12
Great list! For me the first would have read "Use your brother's Apple ][ when he is at work to pay for it.". Not much application today but it worked for me.
Very useful tips! My personal favorite one is: Never underestimate your customers, especially when you interact with them in a daily basis. Even if they don’t show it, they’ll notice any changes you make in your business and appreciate it of course if those changes are beneficial to them!
Good morning. He who labors diligently need never despair; for all things are accomplished by diligence and labor. Help me! It has to find sites on the: Turbo Tax. I found only this - <a href="http://turbo-tax.biz">turbo tax</a>. Alcohol treatment return on investment. Options on alcohol abuse and drug abuse treatment in new jersey. :eek: Thanks in advance. Geary from Kazakhstan.
Fatherly Advice To New Programmers
It looks like none of my children will become programmers. Instead of letting my fatherly advice to my new programmer son or daughter go to waste, I am going to inflict it on you. If you are newly embarking on the journey that is becoming a programmer, here is advice your father would tell you if he were a programmer. These are things I had to learn the hard way.
Keep Learning: Read. Go to conferences. Subscribe to journals. Take classes. Whatever it takes for you to keep learning, make it a priority. Learn about every language you can find. Take time to learn about any new frameworks, algorithms, techniques, models, paradigms, you can. Each gives you one more tool in your tool chest. Each will help you more easily tackle your next programming problem. Find a mentor, someone much better than you, and learn all they can teach you. Never stop learning.
Learn To Communicate: I often joke that the most important skill you can learn as a programmer is how to draw a rectangle on a white-board. Communication is critical to the job of a programmer. Communicating with customers, clients, users, co-workers, bosses, vice presidents, CEO's, board-members, VC capitalists, all will become important at some point in your career. Learn how to speak in public. Learn how to write in English. Learn to effectively communicate in person. Learn how to persuade without shouting, getting angry, or getting flustered. Learn how to speak without jargon. Help people understand what you are doing. Learn to break things into simple, understandable pieces. Learn to communicate by analogy and symbolism. Learn to communicate.
Be Predictable: Learn how fast you can comfortably program. Wait to predict how long it will take you to complete a task until you understand it. Allow for the unexpected. Plan for vacations and time-off. Live with your predictions. I don't believe I know a problem well enough to predict how long it will take to complete until I can break that task down into sub-tasks that each take no longer than 3 days (often less than one day). Live by this rule, under-promise, over-deliver. It is better to deliver in 10 days what you promised in 15 than to deliver in 10 days what you promised in 5. People depend, schedule, and plan around your predictions. Make them the best you can and make sure you can comfortably do them or you will be asked to live up to your uncomfortable predictions. You will not be good at it at first; to compensate, verify your predictions with someone more experienced. Learn to get better. Be predictable; other depend on you.
Own Up To Your Mistakes: You will make mistakes. How you handle your mistakes is how you will be judged. Learn how to say "I was wrong." If you underestimated how long it will take you to do something, tell people as soon as it is clear to you. If you broke the build, fix it. If you created a bug, fix it. Don't deny the mistake, don't make excuses for the mistake, don't figure out how to hide the mistake, don't blame others for the mistake, do something about it. Take ownership of your mistake or you will repeat it.
Never Let Bad Code Off Your Desk: Your job as a programmer is to write code that works, never let code off your desk you are not sure meets that criteria. Not only does it reflect badly on you, it is much more expensive, and much harder, to find a problem once it leaves your desk than before. Learn to love unit tests. Learn to love code coverage. Learn to test your code better than people who are paid to test it. Be embarrassed about bugs that are found after you have checked-in. Be especially embarrassed when a customer finds the bug. Don't rely on others to find your bugs for you, find them and fix them yourself. Don't hope it will work. Test it. Don't assume it will work. Test it. Don't whatever. Just test it. If you haven't tested it, it doesn't work; of this you can be sure. But, even if you are diligent with testing, bugs will get by you. You will make mistakes but try your best not to.
Programming is Fun But Shipping is Your Job: Programming is fun. It is the joy of discovery. It is the joy of creation. It is the joy of accomplishment. It is the joy of learning. It is fun to see your handiwork displaying on the screen. It is fun to have your co-workers marvel at your code. It is fun to have people use your work. It is fun have your product lauded in public, used by neighbors, and discussed in the press. Programming should be fun and if it isn't, figure out what is making it not fun and fix it. However, shipping isn't fun. I often have said that shipping a product feels good, like when someone stops hitting you. Your job is completing the product, fixing the bugs, and shipping. If bugs need fixing, fix them. If documentation needs writing, write it. If code needs testing, test it. All of this is part of shipping. You don't get paid to program, you get paid to ship. Be good at your job.
Remember these simple statements,
9:43 AM | Comments [33] | #Programming
09/19/2006 12:16 PM
In your bullet summary, there's a somewhat embarassing error: "Communicate is critical."Thanks for such a great article, though! This is one of very few things that make me say, "I wish I had wrtten that."
Jacob | http://jacobcarpenters.blogspot.com | jacobcarpenterAT NOSPAMgmail dot com
09/19/2006 6:51 PM
Ouch. Good catch. I corrected it. I guess I proved myself right for at least part of it...Chuck Jazdzewski | removingalldoubt.com | chuckjAT NOSPAMmicrosoft dot com
09/21/2006 5:42 AM
Good points.I'd add two more:
- Be ethical
- <your favorite search engine> is your friend
Rod. | http://openero.blogspot.com | rodolfo_fariaREMOVETHISAT NOSPAMig dot com dot br
09/22/2006 8:29 AM
That shipping part reminds me of a part from the book "I Sing The Body Electronic" :)Amil | http://amilr.wordpress.com
09/22/2006 5:20 PM
I haven't even had time to think about settling down yet, passed the marriage age long time ago btw. So at least I don't have to be worried about my kids who won't listen to my advice."Own Up To Your Mistakes": Couldn't agree with you more as some developers tends to go round the circle with their Mumbo Jumbo to avoid admitting to their mistakes. They should work in Bush's administration really.
On the serious note, I wouldn't do anything else for fun and work other than coding and be involved in the world of I.T.
Here are my advice if I may to use this space to do so.
1: if you want to be in I.T. don't work as a programmer or at least do it for very short period of time. For the time and efforts you put in to learn all what you need the money is not worth it at all. If you are one of those lucky programmer who work 8 hours a day and gets a small fortune for it then you are in minority.
2: stay with a company as long as you can if you don't want to catch up with ever changing technology. If you work as a contractor then you are expected to know everything and to know most things you need to spend a lot of time learning them.
3: never work for a software house. This sort of company is only suitable for those geeks who want to work hard and learn fast.
4: never work for less than money that you deserve. Not only you won't do yourself a favour you also cut other developer's earning too.
5: never contribute your work for free when it could have business value to many. Remember tomorrow when you decided to get that mortgage or that sport car no one would donate a penny.
6: don't share your design openly to the people you hardly know. There are many smart people out there with cash that can turn around your design and make money out of it.
7: If you are going to make a presentation of your own product for someone or invited to do so always ask if they are doing the same thing or not. Many companies and people simply want to see what you have then steal your idea or get a lot of idea from it when they couldn't do it themselves. These days what it counts is who had the idea in the first place, any professioned programmer can do almost anything he sees but not many professioned programmers can be as creative as others.
8: don't make your work as your hubby. Listen to someone who is paying for this now.
9: if you don't like your work environment change it as soon as possible don't let this to ruin your appetite for success.
10: every job refusal is one step closer towards a better job offer. It sounds crazy but this is very true. So don't be affraid of trying.
Good Luck to you all...
Anon
09/25/2006 1:31 PM
This is a great post, I agree with all of it and what Anon contributed.I will deliver the message to students that I teach ASP.NET 2.0 to at University as a volunteer though a Student Organization.
I've been telling them that for a while and this is all-in-one article, thank you. [Ofcourse you will be credited and linked]
Nikita Polyakov | http://www.campusKoder.net | campus_kodersAT NOSPAMhotmail dot com
09/26/2006 7:19 PM
great advicefinding a mentor has been the greatest struggle for me, I've come to find it on the web (blogs, open source projects, etc), but is not the same as actually working with someone everyday
Eber Irigoyen | http://ebersys.blogspot.com | ebersysAT NOSPAMgmail dot com
09/26/2006 10:10 PM
Great article.Wish I had written it :)
Anons contribution was pretty good too.
This is not only for new programmers but also for anyone who isnt already following any of the advice mentioned above.
nev
09/27/2006 10:51 AM
Great article, Chuck. Thanks for sharing.But wow, Anon in the comments above seems to be a very cynical and jaded guy. I hope I don't become someone like him when I grow up.
John Lam | http://www.iunknown.com | jlamAT NOSPAMiunknown dot com
09/29/2006 4:20 PM
Yes John, I can't wait you grow up one day soon :-)Anon
09/29/2006 11:43 PM
Maybe I should go back and add "play nice" just for you too ;-).Chuck Jazdzewski | www.removingalldoubt.com | chuckjAT NOSPAMmicrosoft dot com
10/02/2006 12:58 AM
Great article, I recognize a lot from what I did in the early years and still do.At our school they always tell new students the following:
Learning to program is one thing,
Learning to engineer a program is the other.
And with engineering they mean, communicating with the customer about requirements and design desicions. Applying an engineering model to streamline the process of planning,designing, implementing ,testing and delivering software.
Wilm | http://www.mein-design.nl/willem | willemAT NOSPAMmein-design dot nl
10/03/2006 9:21 AM
Chuck - thank you. I have printed this out and it now hangs on my wall. Although I have been programming for 16 years (OMG, has it really been that long?), your comments are just as applicable today as they would have been had I heard them when I was in college. Hmmm, maybe I should forward a link to the college (now a university) to include in future cirriculum... :-)Daniel | mailto:ddbraggAT NOSPAMshaw dot ca | ddbraggAT NOSPAMshaw dot ca
10/03/2006 7:47 PM
never underestimate the competence of your clients, only because they don't (fully) understand what you are doing. if they run a successfull business, then try to learn from them. they're not dumb because they don't understand anything about it, but you would be dumb, if you don't try to understand why they are successfull (and tailor your product to it).i learned this when working for a jeweler. hey didn't know much about the internet, but he told me a lot about the way he deals with his customers, so his website (which i was working on) would benefit from his knowledge. it was a very valuable experience for me, because even though i was the experienced webdesigner, and the product was a webpage, he knew better how to approach his specific kind of customer interested in his jewelery, and that saved me from making a lot of grave mistakes.
stef | http://wehrlos.strain.at/
10/05/2006 9:39 AM
Under the heading of “Learn to Communicate”, make sure you learn how to listen, how to ask good questions and to take the time to truly understand others. I have had to deal with countless programmers who have preconceived notions of technical specifications and user needs that they simply don’t understand the ideas being discussed.Communication is a two way street.
Dan
10/07/2006 7:28 AM
Hi,great advise and I wholeheartedly agree. Also I would like to add some additional things (also usually learned the hard way):
1a. (addition to "Keep Learning"): Don't start or participate in "religious arguments". Java or .NET? Both have their respective advantages and shortcommings; Whether its pure OO or not is only of academic interest; Windows or Linux? Usually you're not the one to decide anyway. Bashing one and favouring the other will make you blind for the advantages of the other approach as well as for the shortcommings of your favoured system.
3a. (addition to "Be Predictable"): Learn to estimate. And don't forget that there's more than coding. Take meetings, design, testing, and documentation into account, perhaps add some time for the inevitable bugfixing afterwards.
7 (new point) Adhere to the requirements:
7a. Don't waste your time on addons, gimmiks, or presents, noone has asked for. If you've got a bright idea, propose it and have it made it a requirement. Only then you may do the actual development.
7b. Don't take the customers response personal. You just proposed one of your bright ideas and the customer rejected it? You pointed out a flaw in the requirements and the customer insists? If you think you know better, tell the customer and you have fullfilled your responsibility. But don't forget that it's the customer who decides and he may have to take things into account that you don't even know about. If he decides otherwise, live with it.
Alexander
Alexander | http://ajdotnet.wordpress.com/
10/09/2006 11:47 PM
Great post.In Programming is fun but shipping is your job: "It is joy of discovery." should be it is "the joy." And "It fun to have your co-workers marvel at your code" should be "it is fun."
Thanks again. I wouldn't comment on this little stuff if it weren't good enough to deserve to have the typos fixed.
Charlie | http://blogs.msdn.com/charlie | charliecalvertAT NOSPAMmsn dot com
10/10/2006 4:27 PM
Thanks Charlie! I fixed the errors.Chuck Jazdzewski | www.removingalldoubt.com | chuckjAT NOSPAMhotmail dot com
10/23/2006 6:20 AM
Thanks for this Chuck. I hope you can use what you learned in the old days and mentor some executives in your current location.Good advice all around, thanks again.
Dave | mailto:dkeith2AT NOSPAMyahoo dot com | dkeith2AT NOSPAMyahoo dot com
10/26/2006 4:53 PM
Great post!Inoussa | http://inoussa12.googlepages.com | inoussa12AT NOSPAMgmail dot com
01/13/2007 5:46 AM
To the point, I recognize everything.I would have added one very important factor:
* Define your task
Myself I used to program a lot when knowing what I wanted to achieve but without first really knowing how I wanted to implement it, I just started to write code.
Ingvar Nilsen | http://www.ingvarius.com | blogcommentsNOSPAMAT NOSPAMingvarius dot com
01/16/2007 7:50 PM
That was amazing. I really, really enjoyed that.engtech | http://engtech.wordpress.com | engtechnologyAT NOSPAMgmail dot com
01/17/2007 9:08 AM
Great stuff! Thanks.Andrew R. | mailto:rachkovskyAT NOSPAMhotmail dot com | rachkovskyAT NOSPAMhotmail dot com
01/22/2007 10:42 AM
I'd like to add a few points about self-management.No one mind, no matter how bright, can see let alone harvest all the good ideas which float around any given problem domain, so put your ideas on the table and watch them procreate with the others your team has. Hope for the best technical solution, not that you had the most ideas used. Let your brainstorms out-more ideas will replace them, never fear.
Cultivate an ear for that faint sound, off in the distance, of your wheels spinning, digging you into the mud. Knowing when to go home is a crucial talent and can save quite a bit of rework. Always backup regularly and do trial restores as well.
Don't get discouraged if a problem thwarts you. Just keep it in mind and the answer will arrive eventually. All of us veterans have tales of times when nothing worked, all our experts were baffled, and none of our usual tactics did a damned thing--But, if you keep at it, something is attracted by your imagination. Maybe an old friend's email, or a magazine article, or a datasheet from a mailing list you joined late in the second millennium. Something will work eventually.
You can accelerate this process by envisioning the day your solution shows up. As you drop off to sleep and just after you awaken, picture that day and how happy you'll be, how all your team will admire your design, anything else in the realm of positive emotions.
Most of us technical types are wary of the powers of our imagination, but try it out. It definitely works, and the more clearly you can picture your design, the more easily you can accomplish it. Watch out for negativity, since that also attracts. This is the real danger in complaining-not that you just see the "glass" as half empty, but that you actively attrack bad luck with that mindset.
Kirk Halgren | mailto:khalgrenNOAT NOSPAMSPAMearthlink dot net | khalgrenNOAT NOSPAMSPAMearthlink dot net
01/29/2007 12:46 PM
hey, thanks for your comments, both chuck and anon!d ;-)
daniel | n/a | dan_c_marinescuAT NOSPAMyahoo dot com
01/29/2007 1:25 PM
Excellent article. Practical and down-to-earth. I am going to link this.Pradeep Chellappan | http://pradeepc.wordpress.com
03/11/2007 10:20 PM
profound stuff ' i'll be back'popa | nil | popaAT NOSPAMaapt dot net dot au
03/29/2007 1:34 AM
Great Advice for newbiew and experience programmer a like. Love your point form makes it easier to read..Well done
Ken Wee | http://honda-generator-parts.blogspot.com/ | kwlogAT NOSPAMblog dot com
05/09/2007 6:36 PM
Nice advises from the contributors.Thanks.
Here is mine:
1.Acquire a PC.
2.Grab that programming books.
3.Use the internet as knowledgebase resource.
4.Teach yourself by doing it.
5.Follow your instinct.
6.Teach yourself how to follow coding conventions.
7.Learn when to use comments.
8.Patience is a virtue.
9.Avoid re-inventing the wheel.
10.Join and participate in the community.
See details of these tips at:
Part 1: http://jacksbeanproject.org/wpblog/?p=11
Part 2: http://jacksbeanproject.org/wpblog/?p=12
Leo Veranga | http://jacksbeanproject.org/wpblog/ | leoverangaAT NOSPAMyahoo dot com
05/10/2007 10:49 AM
Great list! For me the first would have read "Use your brother's Apple ][ when he is at work to pay for it.". Not much application today but it worked for me.Chuck Jazdzewski | www.removingalldoubt.com | chuckjAT NOSPAMmicrosoft dot com
07/23/2007 5:39 AM
Very useful tips! My personal favorite one is: Never underestimate your customers, especially when you interact with them in a daily basis. Even if they don’t show it, they’ll notice any changes you make in your business and appreciate it of course if those changes are beneficial to them!Cash Advance | http://www.onlinecheck.com | CadvanceAT NOSPAMaol dot com
08/29/2007 6:53 AM
"Patience is a virtue." - we all know it, not all of us understand it. am i right or am i right?bedroom furniture | mailto:alin360AT NOSPAMgmail dot com | alin360AT NOSPAMgmail dot com
05/27/2009 9:49 PM
Good morning. He who labors diligently need never despair; for all things are accomplished by diligence and labor. Help me! It has to find sites on the: Turbo Tax. I found only this - <a href="http://turbo-tax.biz">turbo tax</a>. Alcohol treatment return on investment. Options on alcohol abuse and drug abuse treatment in new jersey. :eek: Thanks in advance. Geary from Kazakhstan.Geary | http://turbo-tax.biz | hanmamaxAT NOSPAMmasrawy dot com