Slashdot Mirror
How to be a Programmer
Martin L. Smith writes "Rob Read has posted his magnum opus, "How to be a Programmer: A Short, Comprehensive and Personal Summary" to Samizdat Press where it can be scarfed by the masses. Rob's book is a forty-page tour through the million-and-one things he thinks a programmer ought to know as he sets out into deep water. One of the reasons he posted this was to get some feedback, so tell him what you think. Samizdat Press is maintained by the Colorado School of Mines to provide a distribution point for free (mostly earth-sciences related) texts."
ok, i just skimmed a couple lines of this thing but it seems to that he glosses over some major areas: "Idealists may think that design...is more fundamental [than debugging] but they are not working programmers." IMHO it's nearly impossible to implement a major system without doing some serious design work first - debugging can fix logic errors, but not design flaws.
How to deploy the software and updates to it.
It gets quite complex in custom business applications where you have to distribute client, middle tier and database updates to production systems.
Anyhow, my 2 cents.
Here's what is important to me as a programmer:
1. Always keep learning - it's not as important how much you know - it is important how fast you can learn new things
2. Don't just implement something for the sake of doing it, or because it will look cool on your resume. Make sure you have valid reasons for what you do, preferrably backed up by some research. Change isn't bad unless it is change for the sake of change.
You find this humorous, centurion?
This looks like it should be titled "How to be a Developer", as much of it is oriented towards programming for a project or coporation...
...Is to use this site as your programming bible :-P
It is a *must* read for any budding or experienced programmer! (You might split your sides from laughing too much).
Are you local? There's nothing for you here!
I agree with the poster above, but I would like to add a twist. I have found that few successful programs are successful at simply programming. To be truely successful, you must be good at learning to program.
It doesn't matter how much you can do or have done. The market for programmers will always be in untested areas doing the impossible, or at least the highly improbable.
In the end, your actual training and experience is bunk, unless it used as the basis for learning more. The truely gifted programmer does not build static project. He or she builds a tome of routines and knowledge that are the foundations for code used decades later.
Meditate on this, Grasshopper
"Learning is not compulsory... neither is survival."
--Dr.W.Edwards Deming
I like this quote from the document:
"Life is too short to write crap nobody will read. If you write crap, nobody will read it."
As I read through the comments here, it's apparent that virtually none of the posters clicked on the link much less read the document, and a good 90% of them didn't even read past the posting title.
Anyway, the article touches on good points, but it's very clear where the author has personal experience with something and where he doesn't. Some of those times he starts to sound like the books he recommends (all excellent recommendations). Other times (e.g. 4.1. How To Stay Motivated), he simply states something that would be good, but doesn't describe how it should be done.
He recommends "Succinctness is Power" by Paul Graham. Given the document's spottiness, he probably should've gone alnog those lines instead. Written down a little ditty about why you should read the material, and then his list of books and articles to read on how to be a programmer.
If half of the programmers I've known had read his recommended list, I'd have a hell of a lot more trouble staying far enough ahead to have time to review articles and post on slashdot.
I've been coding in an enterprise environment for quite some time now, and I have one rule that is cast in gold:
Always optimise source code for legibility above all else. Never trade legibility for performance unless you have no other choice, and then document your cleverness in the code so that those who follow behind you can keep up.
Here's why:
When you first write a system, it will spend its first few months of life in a very intensive quality control feedback loop. Bugs are found and very quickly exterminated. The code is still fresh in your mind and you're "in the zone".
But as the system stabilises, there is less and less reason to go back to the code, so that freshness wears off. After a little while, other priorities will take over and the internal model of the code will fade away.
But there's still bugs in there - there always is. But any bug that makes it past the first few months is non-obvious, intermittant, rare, and so on (thus, harder to find)
When one finally surfaces, _somebody_ is going to have to fix it. Sometimes it will be you, and you will appreciate code legibilty when you have to dust off source that has laid untouched for years. Not only does it increase the probability that you'll be able to actually find the bug, it cuts down on the time needed to fix it.
There's nothing like being the guy who finds and fixes bugs within seconds of them being pointed out to enhance your reputation.
But more often than not, it will be some other poor sap who gets saddled with your code and a deadline to get it fixed - and the guy who draws the short straw is normally not the biggest brain in the shop. There is no gratitude like the gratitude from someone forced to dive into somebody else's code, and who subsequently discovers that you have gone out of your way to make it easier for them to understand.
This is _also_ a reputation enhancer. "That code was so well written that not only did it take no time at all to track down the bug, but I also learned a couple of new techniques in the process!"
The true guru is a TEACHER.
Oh, and ALWAYS check the return code from every system call and provide appropriate error trapping. That's good too.
DG
Want to learn about race cars? Read my Book
Be prepared to be wrong.
Be prepared to be proven stupid, to go in the wrong direction and have to forget it, to bust your ass for weeks only to discover you're doing it the dumb way.
Be prepared to take criticism at this point, to learn the right way and actually practice it, to laugh at yourself and to not gloat over your fellows when they make the same mistakes. After all, the next time you do something dumb, they're the onces who will be pointing it out.
These are skills that will get you by in any field, but in programming they'll save your ass.
Hey freaks: now you're ju
Personal Skills are more important than most programmers think. With personal skills,a programmer is able to chat with marketing and managers to figure out what projects THEY should be put on, which helps build their skills and keep the job interesting. Personal skills gives the programmer the ability to influence managers to get the good projects. Personal skills will also promote a programmer in the eyes of of management, an equivelent programmer that doesn't communicate with management will be more quickly forgotten when raises are given out.
Don't forget, the squeeky wheel gets the grease.
love is just extroverted narcissism
you end up having very little contact with the softer gender
I don't know where everyone gets this from. Maybe this was somewhat true 10-20 years ago, but not now. Not all programmers are socially inept dorks with no lives outside of computers. Or am I the exception to the rule? I tell women I'm a software developer and it *increases* my chances with them (I suppose they think $$$). Hey, and I've been a geek most of my life--and I still spend much of my free time on computers. Women like a guy who can fix a computer. Trust me. Being somewhat successful in your profession helps also, so reading "How to get a Programmer" will indirectly help you get chicks.
If you're a geek, you *can* have luck with the ladies; especially if you've got a job and some cash to spend. Shave that beard, get a decent haircut. Buy some nice clothes. Go out, drink a coupla beers, and just talk to women. There are ladies out there for everyone. Trust me, they are just waiting for you.
Zoot!
And because he had never read -- because of the extra 2 weeks he took writing that function -- the whole dot com industry collapsed.
Nothing great was ever achieved without enthusiasm
You only need to stay 15 minutes ahead of the others for them to think that you are a genius.
Several things you can do:
Get the idea? Learn by doing privately and learn more by teaching. To be really great, you need more than coding skills. You also need writing, teaching, leading, and public-speaking. But most of all, don't try to do it in a vacuum. You can learn from others while you are teaching them. You can't get there overnight, but by constantly picking at it, one little piece at a time, you will get there.
Downside is that marginally-abled management will see you as a threat to their jobs.
p.s. For goodness sake, learn to punctuate and use a spell checker. (No touchbacks.) You don't get points for looking professional; you lose for not.