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."
In the real world, if you're designing large systems, you're not a programmer, youre a systems architect.
.. architects design the huge thing .. programmers build it, and make localized design decisions.
... so I think your point is more one of semantics.
Think
But I dont think its fair to say programmers must be good at large scale design since thats a career path unto itself. And those who can design large scale systems are usually not so good at the nitty gritty
"Old man yells at systemd"
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...
I totally DISAGREE. Good programmers have a total picture of how thier programs work and interact and that is why they work and interact very well (the nitty gritty is done with a debugger and testing). If a system architect was not at one time a very good programmer then he is probably a bad system architect. Of course thier are tons of bad programmers who then become bad system architects FWIW.
I miss the Karma Whores.
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
Since I'm doing that "system architect" job at the moment, I feel like I can reply to this :->
:-D. I can't dictate, but if it doesn't fit in with my architecture, I have a veto - and I'm consulted on every technical decision that's not already delegated to someone for implementation (I review those).
If I didn't have years of prior experience hammering systems together, debugging custom code and off-the-shelf things made to play together in new and unforseen circumstances, and a few tens of thousands of lines of multiple languages of coding, I wouldn't be able to avoid the land mines that the folks who designed THOSE systems subjected me and my "tribe" to.
One of the glaring gaps in the last 15 years or so has been the one between the classic "system engineers" and "software engineers". The "System Engineers" have usually been hardware types, and have no problem saying "it's a software problem - deal with it" and making the poor code monkeys cope with their bad decisions. It's taken me years to get the credibility among those folks to make them listen to my opinions and actually change their minds; I was just a software guy, not a Systems Engineer. Now, I have a program manager who's former software, and a software manager who's former software, and I'm senior to our chief system engineer
This may actually be my dream job - fortunately, we're doing well on it, so we're thought of well inside the company; unfortunately, we're meeting our schedules, so it'll end within the year *sniffle*. Then, I'll just have to find a way to keep myself out of management....
I love vegetarians - some of my favorite foods are vegetarians.
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!
One thing I have learned is to not invest a lot of prideful ownership in a particular design decision I make. When reviewed by the team, it invariably gets modified somewhat, sometimes outright rejected. Taking ownership of a subproject (in my case) is one thing, but you have to be malleable enough to "give them what they want". Otherwise you end up beating your head against a wall.
Oh and lose any aversion to eat crow is also a good idea. At some point you will pronounce "There is no way I made that mistake" only to see your log-in in the RCS/CVS log.
I forget...are we at war with Eurasia or East Asia?
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.