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."
Slashdot Math Returns!
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...
Most programmers are not female. Using "She" makes
the work sound peculiar and unprofessional. It
implies a anti-sexist bent which has nothing to
do with the subject matter. Either write things
in passive verse to avoid pronouns, use "they" or
in the few cases where you really need to, use
"he". Anyone who thinks this is sexist has a
problem which your essay is not here to
address.
I saw the section on debugging and much of it is common sense. Unit testing is common sense. Personal Skills??? When did programmers get those?? Most good programmers figure all this out on their own. I'm afraid that most of the people reading this, will never be good programmers, because they lacked the initative to figure out most of this by themselves. I've been programming almost 20 years. Most of this stuff I figured out on my own when I started programming.
Good programmers don't need to be told how to program.
Bad programmers are always bad no matter how much they are taught or how much they read.
90% of programmers are bad. 9% are pretty good. And 1% are incredible.
I'm afaid most of the people that have to read this are lousy programmers or "script kiddies" anyway that won't be helped by it.
3. cry when indian/russian/chinese programmer ignores "US Copyright Law" and develops and markets product for themselves.
...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
Wrong. If you want to get into computers and don't know where to start, don't go to college/university. You'll end up wasting major bucks on four years, 75% of which you'll never use.
Start with either computer classes at a local community college (save big $$) or a technical school for computers or engineering.
Four year public college will teach you a bit about computer theory and algorithms, but not much else useful in the real world. I know, I went. And for that little piece of paper, you have to wade through countless hours of "well rounded courses" like child psycology, Ethiopian woman's studies and pottery.
I'd hire someone with a technical or vocational degree and two years real world experience over someone fresh out of a four year liberal arts school.
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.
When I teach intro-level university CS courses the first thing I tell students is to forget everything they know about "programming" and spend the semester learning to be a problem solver. "Programming" seems to imply throwing syntax at a problem, and experience shows that the typical programmer just keeps throwing more syntax at a problem until no more bugs are visible. If we're ever going to get IT out of the mess it's in, we're going to have to encourage higher-order thinking than to "program".
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
I have to agree. Why can't people just accept that in English the pronoun "he" is used for both male and undetermined gender. Instead, the author uses "she" as a pronoun, which, in normal, non-PC usage, refers only to females. It annoys me to the point of distraction. At the very least, he could have used "he or she" or, if that would add too much to book length, "s/he" might have been a more acceptable alternative. Personally, I avoid buying books where the author is obviously trying to be PC just for book sales, especially in a male-dominated industry.
Real software engineers regret the existence of COBOL, FORTRAN and BASIC.
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
If someone is looking for available skilled labour, willing to work cheap, they don't have to go to India/Russia/China these days. :^(
One line blog. I hear that they're called Twitters now.
how to thrive in a seclusive career path that is extremely difficult to find employment in and you end up having very little contact with the softer gender
:-) Others may differ. But being a geek does not somehow magically exclude one from dating. Learn to interact with people and develop some social skills. Lots of people must learn to do this.
Maybe you should change career?
Some of us either aren't seclusive, or don't see being seclusive as a problem. Or maybe seclusive means "not hanging out with stupid people". If you are in an environment with mostly stupid people, and noone smart to hang with, then you might seem seclusive.
Some of us are employed. On another point: the economy is bad right now. But even if the slump is permanent, some of us are, and it is possible to be employeed doing things that are somewhat insulated from economic cycles, but maybe aren't as glamorous as the dotcoms were.
Finally, while I'm sure this only applied to a minory of us, I am happy to avoid contact with that particular gender.
My point: Some people think being a geek is bad. I think it is good. You can find joy and happiness in being a geek too. Stop thinking of "How to be a programmer" as "How to have a miserable life." It's baloney.
I'll see your senator, and I'll raise you two judges.
Anyone else think it is strange that the author has an email address at hire.com and dedicated the paper to hire.com? He also cited the book Extreme Programming in the references. Those two points make me skeptical about the integrity of the paper however the paper is pretty good.
If you think about other people who maintain your code and you make their job easier - then good maintenance of your code begins from you.
But if you think that you are too busy for that then it's a big (and growing) chance that your code is useless and another programmer will dcide: "it's easier to re-write it".
See the thread about JUnit for example.
Less is more !
I, at least, would consider algebra skills to be part of the basic abilities/skills needed to be a programmer.
Life sucks, but death doesn't put out at all....
--Thomas J. Kopp
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.
To be fair, commenting code is a slippery slope.
A little commenting can go a long way to helping someone else understand the system.
A lot of comments can be a burden. Why?
Nobody updates them, and lots of people don't read them. Additionally, it takes a long time to write lots of well-written comments - time that is usually better spent re-architecting the system to make it easier to understand.
Every day I come to realize more and more that comments are, on the whole, a waste. Sure, a little comment here and there when something non-standard is going on, or unintuitive. But it is neither feasible nor necessary to comment all the code in a large system - just write better code!
Note that this is NOT meant to say that documentation is worthless. On the contrary, in my experience, the most useful documentation is that which describes the system as a whole, the assumptionst that are made, how the subsystems interlock, etc... Those are things that are not easily gleaned from code, no matter how well written.
Additionally, lots and lots of comments get in the way for the coder navigating the source. It can be a serious slowdown if comments are used too much.
Don't comment, but DO document.
Your employer may make widgets, or run delivery trucks, or process financial transactions, or manufacture cars. Your goal is to help in that process.
Programmers can have a tendancy to be easily "disconnected" from the mission of employer, and can think the goal is to write some cool Java, or to make the source code library work better. Yes, that's the job at hand, but it's not why they pay you each month. They pay you to help them build cars and sell them at a profit. It's an important thing for programmers to have at least somewhere in their conciousness.
Who is enamored with SQL.
You have selected a certain case where it may make sense to use SQL, however, you have missed the large picture, since it is absoultly pointless just to move some data.
Part of the decision you need to make is where to partition the process(es). How much should you do in SQL, how much should you do in C, how much should you do in whatever and so forth.
All of this depends on which system you are developing, who your users are, and how you are planing to administrate/upgrade. There are more reasons to use something else than SQL.
In general I thought that the author's heart was in the right place, but I thought that the text needs work in some areas - especially if this article is supposed to be read by novice programmers.
For instance, the section on Source Control boils down to "Source Control is good. I use it all the time". Why not describe what Source Control is, give arguments as to why it is useful, and give some tips on how to use it to its fullest potential.
There are other sections that need similar fleshing out, beyond just the mere mention.
Also, I would play with the ordering of things. It doesn't quite seem right to dive right into a detailed discussion of debugging at the beginning. I think it would be better to take on some of the more general issues first in order to ease into the technical stuff. Alternatively, you may want to split the article into two. One which discusses the "soft" issues, like working with teams, etc, and another which discusses the more meaty subjects like logging and code comments.
Anyway, best of luck to you in your endeavors.
------
www.moneybythenumbers.com
The article recommends against comments in code using the usual lameass excuse:
Code and comments might get out of sync due to maintenance
Hogwash. Try maintaining code you yourself wrote 10 years earlier and see if the egotistical horseshit that "reading the code is all you need" for documentation is as true as you think...
On second thought, nevermind... come back and read this in 10 years after you -have- 10 years of experience!
Guys, there is no holy grail guide for being a good programmer. It's all down to a person's abilities to understand the system overview as well as the local details of each subsystems and how those subsystems corellate to each other and how they affect the overall progress of the total system.
I've seen quite a few programmers. The best ones are those types that are really interested in the programming concept, and what makes a program beautiful. Once these concepts are understood, then the programmer ceases to be interested in using the latest and greatest features of the underlying development environment and only cares to leave behind a system that works, is easy to expand and debug and easy for others to understand.
A key point to being a good programmer is understanding why an API is bad or good and why the programming language X is better than the programming language Y for project Z. I may not be a good programmer, but I really understand why MFC sucks and why WxWindows is better and Qt the best; or why Visual Basic sucks as a programming language, C and C++ are difficult languages but the most rewarding and why Java is better for most projects(of course this is my opinion and you don't have to agree or disagree, I just mention it here as an example of the issues a programmer has to understand).
But all these are down to personal interest and abilities rather than some guide that people can follow to become successful. I guess this is true for every profession, but it is more important in programming.
All these have a direct impact on the social aspect of the programmer job. A programmer that cares more about programming than others may initially be more drawn to his/her computer rather than to the social interaction with his/her colleagues, but in the end that person will have a much better understanding of what is going on and be a much better candidate for a job that is higher in the company's pyramid (manager, engineer, architect).
Flame suit on...
;-)
;-P
I found his paper interesting for the most part. It's very helpful in giving new programmers an idea what to expect.
Is it just me, or does this guy seem to have a huge ego? I've worked with enough programmers to know there are good and bad ones, easy going and egotistical ones. He seems to have a pretty low opinion of "non-engineers", by which he means non-programmers as opposed to mechanical engineers, electrical engineers, etc.
My favorite section is "How to talk to non Engineers".
Non-engineers are smart, but not as grounded in creating technical things as
we are. We make things. They sell things and handle things and count things
and manage things, but they are not experts on making things.
They are not as good at working together on teams as engineers are (there
are not doubt exceptions.) Their social skills are generally as good as or bet-
ter than engineers in non-team environments, but their work does not always
demand that they practice the kind of intimate, precise communication and
careful subdivisions of tasks that we do. Their teams are more like groups.
Non-engineers may be too eager to please and they may be intimidated by
you. Just like us, they may say yes without really meaning it to please you or
because they are a little scared of you, and then not stand behind their words.
Non-programmers can understand technical things but they do not have
technical judgment. They do understand how technology works, but they cannot
understand why a certain approach would take three months and another one
three days.
It's obvious to me when an engineer has this attitude. They usually come across as cocky and condescending. I find that if you treat your coworkers with respect, and assume they have a clue, that your working relationship will be much better for doing it.
I have a B.S. degree in Comp. Sci. but work as a sysadmin now. Everyone knows that without sysadmins like me, everything would fall apart, and engineers would never get anything done. Ask me how many times I've had to fix an engineer's CVS repository because they didn't have a clue how it worked.
I think engineers/programmers need to have more appreciation for their fellow technical workers. Maybe I'm just being sensitive, but last time I checked, my job required building things & fixing problems (complex server systems, and repairing many system level and code level problems). I also have to do job estimation with a good understanding of the technical merits of different approaches.
And, I hate to disappoint everyone.... but non-engineers are not eager to please or intimidated by you... They might just be too polite to laugh at you to your face when they see how big your ego is getting.
The best engineers I worked with were extremely bright, did an excellent job, and were very good at getting along and working with everyone, whether engineer or sales rep. They were recognized by everyone, technical and not, as our best engineers. Everyone knew they were the core of our company. I would break my back to get those guys what they needed, because they treated me as an peer, and respected my own expertise.
The worst engineers I've dealt with had egos bigger than the buildings they worked in, and chips on their shoulders almost as big. Those were the type I stayed away from. They were also the type that insisted their ideas were right regardless of the facts.
The last jackass engineer/programmer I worked with insisted our company of 50+ people didn't need a corporate firewall "because we use Windows development systems, and Windows software is secure". And this guy was our most Senior Engineer, I am NOT making this up.
Well, thanks for letting me get that off my chest!!
"The author only mentions how to be a decent programmer for your employer. What I want to know is how to be a programmer; I and almost everybody else I know have followed the following steps:" What poeple rarely consider when choosing a school is how well the school does at placing graduates. I had three offers before graduation and I didn't even start interviewing until 2 months before graduation. Of course that was then and now we have a huge glut of experienced programmers looking for work. One word of advice, though, if you are trying to get a job at a small company where everyone wears jeans and sneakers, forget it. Those companies have neither the time nor the resources to train and nuture you. Unless you graduated top of your class from MIT, you're going to have to put in your three years in cubicle hell. If you live in California, consider moving. Washington D.C., where I happen to reside has tons of job opportunities and never fear, the traffic is almost as bad (anthrax and small pox are survivable.) Last of all, get a decent suit, cut your hair, smile, be polite and humble, and read a book on interviewing for jobs. Never, ever BS in a technical interview. Good luck to you.