The programmers amongst us all share a common need; the need to learn something new, every day, every week. With everything you’ve learnt up to this point, what’s the single most important piece of wisdom you could pass on to a programmer just starting out?
Here are some ideas to get you started:
- Read The Mythical Man Month
- Read Code Complete
- Have the willpower to stick with Unit Tests and/or Test Driven development
- Comment/Document even the throw-away scripts that you think you don’t need to
What do you wish someone had told you, years ago?
know refactoring (which goes with the unit tests).
your first jobs will be fixing someone else's bugs, not making your own ( ;-) ). being able to read code and learn when a refactoring would be useful, and more importantly when it is unnecessary.
Know the landscape
As the outsourcing phenomenon is cutting rungs off the bottom of the traditional career ladder, I would say this: make your name out on the software periphery first, then go the center to make your fortune.
A couple...
A couple of pieces of advice..
1. Learn how to work without a drag-and-drop graphical IDE. Too many developers don't understand what goes on behind the scenes, it seems.
2. Don't stick to only one language. Languages come and go. Check out the competition; see how other languages do their thing. Learning C, for instance, provides many valuable insights into how Java and other higher level languages work. Try out completely different 'languages' like XSLT or prolog once in a while. And, please, use the right tool for the job.. don't implement a unix system daemon in PHP.
3. Find tools and learn how to them. Memory profilers, debugging tools, code generators, UI builders, bug databases, version control tooling, etc. They'll save you a lot of time.
4. Find a good editor and stick with it. Most IDE's I've seen come with pretty crappy editors, some of which can't even perform regexp search and replace or block inserting/replacing. A feature-rich, well known editor saves a lot more time than an IDE editor that pops up the parameters of the method you're calling.
5. Don't use Object Oriented programming to simply cut up your program in smaller pieces. Ideally, each object should be a seperately usable entity. This is pretty straight-forward but a lot of developers still seem to get this wrong. Mostly because they start with a prototype and keep enhancing that.
6. Read "The Pragmatic Programmer" (ISBN: 0-201-61622-X). It's full of information that's actually useable in the real world, plus it's a fun read.
7. The quick guide to documenting your code: Per class/method/function/procedure: What does it do, how does it do it, what do I put into it and what will I get out of it? Maintaining code would become a whole lot easier if people would just supply that information in their code. If you find yourself adding inline comments to your code, ask yourself: Do I really need to document this or can I also clarify it by refactoring my code?
8. (This is from the Pragmatic Programmer book). Don't assume it works. Prove it works. (i.e. read the specs/manual).
I could go on and on... but I'll stop here. ;-)
Advice
Firstly, to see if you really want to be a developer, by far the best descriptions of what 99.9% of developers do i.e. not writing operating systems or inventing the Internet are 'Close To The Machine' and 'The Bug' by Ellen Ullman. They deserve to be far better known than they are. The book that is usually mentioned is 'Soul Of A New Machine' but frankly how many of us actually design a new computer architecture?
Secondly, buy a new suit and shirts, keep them clean and pressed. Change after work. Look smart, arrive at work early or on time, smile at people. Socks, underwear and shirts need changing every day. Wash white shirts with other white things or they will go grey. Iron your shirts or pay someone to do it. Shower every morning. If you cycle to work unless you are not cycling very far and not very fast you need to shower after cycling.
Thirdly, the nature of the computer industry is that you will be typecast to what you start off doing, therefore if you don't fancy working on database front ends for the rest of your life it is probably better not to start that way.
Forgot one
4thly. If your code is not behaving the way you expect, do not tell everyone 'I've found a compiler bug'. 99.9999% of the time it will not be a compiler bug, and you will be laughed at and lose your credibility for evermore.
The correct thing to do is to ask a colleague / boss 'I don't understand what is happening here'.
Anyway, it would probably be better to break the code down into smaller expressions you do understand rather than waste time trying to work our why your more complex thing doesn't work.
Constantly ask yourself this question...
"Am I changing what I think I'm changing?"The correct answer to that question has been at the bottom of hundreds of hours of debuging frustration...where I've been stumpted by what I thought would be an easy to fix bug, only to eventually discover that I was looking at the wrong include file, or the wrong crontab file, or the correct webpage but on the wrong server, or the browser screen that was being cached by a proxy server, or a zillion other variations of that same pattern.
don't overengineer
but don't be a hacker ... experience teaches both evils if you pay attention