|
1) like what you're doing
2-7) whatever
SumoRunner
Sunday, February 11, 2007
Deleting... Approving...
Jumping ship regularly.
Sunday, February 11, 2007
Deleting... Approving...
2) Being able to turn the usual poorly stated requirements into a useful application that the client really needs through tenacity, communication, and judicious use of iterations.
James C Send private email
Sunday, February 11, 2007
Deleting... Approving...
post.pretension = true
1. Try to keep the eyes on the ball, always. Don't get distracted that easy, because programs don't magically happen, they need to be nurtured all the way to completion, and any distraction will delay it.
2. Don't worry about comparisons between programmers, as we are all unique and hard to compare. If you don't look sharp enough, whatever!
3. Be prepared because this is a marathon any way you slice and dice it. Sprints are the exception. Resistance will be required of you whether you work for Google or the latest startup. Get your Engineering degree if you want to be in it for the long run and are not sure of your skills.
4. Beware of adopting old technologies as if they were new. That is, chances are that the famous technologies are the old ones, so don't be surprised when other folks use crazy and new technologies, as they might have other needs than you. If you end up having to support old technologies, like in maintenance of legacy applications, it's probably a trap you might end up regretting later if you don't know it that well. It would have been better for someone acquainted with the old technology to maintain it. If you end up in such a trap, try to enjoy it. :-)
5. Don't be frozen with fear of unknown technologies, as they are pretty much unavoidable in IT which changes technologies every year. If you are afraid of something, you probably are at least right in that. The main reason to be afraid is that many projects fail, programming is hard when considering that it needs to ship and be used by real people out there, and there are updates and conversions to be made all the time, you might be required to dedicate a lot of time (even weekends), and might have poor working conditions... It's pretty much up to you to handle with such situations. Switch jobs, switch bosses... Try to avoid getting stuck. :-)
6. Don't pretend! Pretend! I mean by this that you need to be aware of as many things as possible, but you still need ambition, courage, illusion, optimism... And this is important whether you are a programmer or a manager, so you can't hide.
7. Everybody can learn things, but it's the creation, the practice, the end-product that matters. Try to get your financial stability from your creation skills as much as possible. It doesn't matter if you are 20, 25, or 30 years old, if you can help it, try to get a share out of the business success for you. If you want to be a manager, Bill Gates wants you! :-) Know that doing things your own way can be too hard, even though rewarding at times. Get compensated for it as much as possible. :-)
Lostacular
Sunday, February 11, 2007
Deleting... Approving...
3) Focus. The ability to prioritize tasks. The ability to see the forest for the trees. The ability to not go off on random tangents. The ability to realize that you don't write software, you provide working solutions to real problems. This all basically boils down to keeping your head in the game.
IHaveNothingBetterToDo Send private email
Sunday, February 11, 2007
Deleting... Approving...
+1 Lostacular on the old technologies. One thing to add is that the "new" techniques are often old ones recycled as today's panacea. The good habit to draw from this is the wisdom to choose the most appropriate of the technologies for the task at hand and to avoid being sucked in by the hype associated with the latest "silver bullet" and its resultant over-application.
James C Send private email
Sunday, February 11, 2007
Deleting... Approving...
4) Of a programer, hygienic source code, please: it's tough to maintain source code that's been copied-and-pasted everywhere, uses cryptic identifier names, uses pointers instead of references, declares variables long before they're initialized, doesn't encapsulate, and (please refer to _Code Complete_ for a more extensive list of 'coding horrors').
Christopher Wells Send private email
Sunday, February 11, 2007
Deleting... Approving...
Off the top of my head:
1. To do programming as a hobby if you weren't getting paid to do it.
2. To keep your code as simple and readable as possible.
3. To be able to learn quickly, and grok unclear specifications.
4. To be able to think laterally; to be able to think outside the box.
5. To accept and embrace the fact that you'll always be learning new things.
6. To know that experience is what teaches you best, rather than a degree or how many books you've read.
7. To be humble (insert Serenity Prayer here....)
Yoey Send private email
Sunday, February 11, 2007
Deleting... Approving...
smart and gets things done!
Monday, February 12, 2007
Deleting... Approving...
1. Use coding practices from Code Complete.
2. Do not blindly implement whatever is written in spec - try to understand the buisness case behind it.
3. Spend some time in reading books, articles, blogs (Joel's suggested reading list has really good list of books) and also writing some white papers (inside your organization / blogs).
4. Refactor code as and when required and apply OO design patterns appropriately (Refactoring - Martin Fowler, Design Patterns - GoF).
5. Participate in developer conferences
6. Interact with your users - I can;t stress enough how important it is to understand business cases.
7. Enjoy programming. |
|