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!
but a rock star.
Anybody's got an idea?
I think that 90% of the people here already have the whole "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" thing down pat, thank you very much.
Be prepared to gain 60 pounds, its part of what it means to be a programmer
Buy and read "HTML for Dummies" from cover-to-cover.
All the other steps are optional.
---anactofgod---
"Equal opportunity swindling - *that* is the true test of a sustainable democracy."
1) Write a spec ...
2) Send spec to Indian/Russian/Chinese Programming Outsourcer
3)
4) Profit!
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.
That one can't learn from reading Dilbert and watching Office Space.
"Why didn't you put a cover sheet on the TPS report!" - "Terrible" Terry Tate.
---anactofgod---
"Equal opportunity swindling - *that* is the true test of a sustainable democracy."
way to stick it to the CLiT
...Simple, just keep doing the stuff they give you. When one tool doesn't work, pickup and learn a better tool. I remember taking on a student job as a programmer, back in 1981. The path has twisted and turned a bit, but I'm still doing it until I find something else I really like ... or win the lottery ;-)
A feeling of having made the same mistake before: Deja Foobar
How to be a programmer?
How not to be a programmer is the question.
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?
1) Crash Test Dummy ...
2) CowboyNeal's PR agent
3)
The list is endless.
Modest doubt is called the beacon of the wise. - William Shakespeare
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...
The 'Thrown Out Like an Old Sock' chapter.
It's Christmas everyday with BitTorrent.
1) Write code
2) Avoid commenting your code at *all* costs
3) Obfuscate code, heavily and often.
4) Make sure everyone sees your code. This will culture a sense of fear and awe in your coworkers. Particularly if you can make your Perl code look like assembler.
With these 4 easy steps, you too can be one of the last people to be laid by your employer!
Karma: 0 (But I wield a mean +10 Vorpal Apathy)
just read this handy guide to writing unmaintainable code and do exactly what it suggests
There is no substitute for experience, but there is something resembling a fast track.
Get paired to a senior programmer/systems engineer
If you have the opportunity to work with a senior on a one-to-one basis, grab it with both hands. There will not be many times when an experienced guy is willing to work with you or coach you, so rejoice when the opportunity presents itself, take it. A colleague of mine asked me which project he should take: a glamorous one where he would be working in a large team with no coaching, or a boring-looking but difficult job, working under one senior programmer. I adviced him to take the latter... which he did, and while he often complained about the job itself, his programming skills improved by leaps and bounds, which made him a senior programmer on the next assignment. I was glad to see he has taken it upon himself to teach in the same manner and spend lots of time with the junior guys.
If construction was anything like programming, an incorrectly fitted lock would bring down the entire building...
Ok, I started reading the paper and got to the intro where HE starts using SHE for a pronoun. That's it, I refuse to read the rest. Gawd that annoys me! If a woman writes, by all means use "she", but it smacks of political correctness, IMHO, when a man does it.
I know, I am too easily annoyed.
It's really funny that the second sentence of the 'Learn to Debug' section has a heinous grammatical error.
Take each page number in the index, and add two. :)
Other than that, it looks very nice
Choose no life.
Choose no natural light.
Choose cafeine.
Choose to have RSI.
Choose no girlfriend.
Choose to work long hours and the weekends.
Choose to use C.
Choose to use JAVA after talking to the boss.
Choose to have a bloody big 21 inch monitor.
Choose to comment code.
Choose to have to comment other people's code.
Choose to run a sourceforge project on the side.
Choose to be abused by mindless helpdesk jockeys.
Choose Comp Sci.
Choose D&D geeky friends.
Choose Slashdot.
Choose an early grave.
Choose something else.
Just few quotes:
There once was a master programmer who wrote unstructured programs. A novice programmer, seeking to imitate him, also began to write unstructured programs. When the novice asked the master to evaluate his progress, the master criticized him for writing unstructured programs, saying, ``What is appropriate for the master is not appropriate for the novice. You must understand the Tao before transcending structure.''
Less is more !
School is good for nothing more than the piece of paper required for most people to get a job as a programmer. If you need to go to school to learn to be a programmer please change your major now... There are enough mediocre programmers in the world and I'm tired of rewriting all your crappy code!
I had trouble getting the paper to have its intended effect, so I ran in through my grammar debugger and found the reason:
Page 10, Line 30, Character 51: 'r' should be an 'f'
#include
int main(int argc, char *argv[]) {
printf("Hello World\n");
}
The trick is to write unmaintainable code, therefore ensuring job security.
Details are here:
http://mindprod.com/unmain.html
I especially like:
There is a lot of room for miscommunication about estimates, as people have a startling tendency to think wishfully that the sentence:
"I estimate it might be possible if I really understand that problem that it is about 50% likely to be completed in 5 weeks if no one bothers us in that time."
really means:
"I promise to have it all done 5 weeks from now."
Heh heh heh...
This essay abuses the English language and insults the programmer-reader with its persistent use of the female singular pronoun, where (actually gender-neutral) "he" would be correct.
Heck, my Perl code doen't look like assembler.
It looks like machine code!
You cannot choose or learn to be a programmer, you are born with it or you should get the hell out. No amount of school or instruction or determination can change you into a programmer.
The script reads like a collections of untruths, half-truths, whinings, myths and philosophical twaddle. The person writing it does not have the experience to write it, nor the insightfulness to realise they should just put up and get back to work. Clearly written after too long a session in front of the glowing tube.
The Glossary is outright wrong; maybe it's the footnote from some SNL show on educational tom-foolery?
This rambling, ill-thought out work would be a terrible handicap to some junior scholar thinking they could read this and jump into the big pot we call IT.
I guess if it gets published the author can collect their royalties. My advice to those that ask me, and many do, will be to avoid this like the plague.
Well, I guess I just sank my Karma!
they use things like design patterns and standards that make code unmantainable. I mean why would I spend an evening learning a session facade when I could just call the EJBs remote interface directly from a JSP? Languages ussually only have 40 some keywords and who needs an education to know what 40 things do? I don't because I can just figure things out and the first thing out of mind is always the right and only solution to a problem.
The ability to program is a gift from God. If you need to read books on how to be a programmer you are wasting your time and every real programmers time when they have to rewrite your crappy code.
Another good reference for this type of info is The Pragmatic Programmer. It lays out how to write flexible, dynamic, and adaptable code, as well avoiding traps that a lot of new programmers fall into. It takes the time to explain the "why's" behind a lot of the engineering approaches advanced programmers take. It is definitely aimed at "junior" programmers, though. Usually when we get someone just out of collage, I point them to this book.
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.
http://leech.dk/afrodot.jpg
This is where I would cue up "It's a Small World After All," were it not for the fact that Disney would sue me if I did so...
Lawrence Person (lawrencepersonh@gmailh.com (remove all "h"s to mail)
http://www.lawrenceperson.com/
Cheez-Wiz, this paper doesn't sound anywhere as glamorous as those 'Lincoln Tech" ads on late night television promising me millions of dollars and pretty women. Foo!
Actually, it is interesting to see he starts out with debugging -- how many of us have seen wanna-be programmers come and go when the project hits the dreaded maintenance cycle. Provided of course they can make it through the Yourdon-esque death-march.
--- have you healed your church website?
Just downloaded it, only skimmed the contents so far, but he seems to be trying to cover a load of stuff that isn't directly related to programming, and, in addition, is highly context-specific. For example, do all programmers have a team for which they have any responsibility? Do they all get involved in the quoting process? I wonder whether a couple of pages on how to negotiate a contract is worse than nothing at all...
Virtually serving coffee
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.
Yes! I completely agree with you! For those of you not lucky enough to be born programmers just think... You can always become a teacher or professor :)
Some quotes from the first few paragraphs:
"I confine myself to problems that a programmer is very likely to have to face in her work."
"Even if she is perfect, she is surrounded by..."
Considering that the female to male ratio in this business is something close to 1 to 100 and that some of us can still work many years in the field without ever meeting a female programmer, I found that somewhat amusing. But I guess it gets boring pretty quick, reading he talk about a generic "she" no one will ever meet...
Time estimation must be blind. Everyone should be working the estimates privately, and the estimates should be aggregated in such a manner that the source of each part of the estimate can never be uncovered. The group pressure to meet schedule is obvious to all concerned. Being the one who said the schedule is too agressive marks you as not being a team player, the "nail that sticks out". In the era of mass firings (er, "right-sizing") employees know the risk of being the department heretic. They learn to keep their opinions to themselves, lest they be the next one purged.
"... programmer does not live in an ideal world. Even if she is perfect, she is sur-
rounded by and must interact with code written by major software companies,
organizations like GNU, and her colleagues."
Yeah, right. Next.
If you happen to work with Java, there are quite a few good commercial profilers around that are really easy to setup and use (such as JProfiler or Optimizeit). Try working with one of these for some time and observe how your way of programming changes for the better. Most importantly, you learn not to pre-emptively "improve" performance - one of the deadliest sins of programming which is responsible for a lot of bad and unreadable code.
First you gotta get a cool name like Compu-global-hyper-mega-net,
Then wait for Bill Gates to "buy you out"
...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'd much prefer a "Why be a programmer".
I am a genius; therefore, you suck.
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.
It looks fairly sensible, but the main problem is that (1) good programmers know these things and (2) bad programmers usually can't or won't learn. This makes the audience pretty narrow, i.e., inexperienced programmers with decent raw skills.
And this bit made me laugh (2.5):
What do you do when you start to run out of low-hanging fruit? Well, you can reach higher, or chop the tree down.
It just seems like a funny metaphor (picture it in your head, chopping down the tree is sort of overkill just to get more fruit :), although I understand what he's getting at.
czth
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".
Rule number 1: do not put PDF on your website
first...write microblogger.
then, complain about something.
then, post to slashdot as if you have some brains, which you don't.
then, act like calling people "fags" is the most fun EVER.
then pretend like you have something better to do than boost your tiny ego.
then complain that no one is listening to you. (aw.......poor baby)
then that's it!!! you're a famous fucking jackass!!! like MEEEEE!!!! whooopeeee!
Bowie J. Poag
Project Founder and Head Jackass, PROPAGANDA Desktop Enhancement Dweeby Useless Background Tiles
With these 4 easy steps, you too can be one of the last people to be laid by your employer!
Mere typo, or Freudian slip?
No, just an accurate assesment of the workplace - if no-one but you can understand your code then you'll be one of the last to get f**ked over by your company.
I'm not disagreeing with you, but the author of the paper is a PhD, so I suspect he values a college education.
-- Solaris Central - http://w
Right on. Been there, rewritten that.
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
offtopic!!!??
no, this is the best way.
-pyrrho
4 years ago, I (Mechanical Engineer, major in Design Engineering) was involved in a bigger software project: Building a modular simulation system for vehicles, based on a database and a Multi-body code with output to Excel and lots of fancy stuff in between to make it all work. Since the customers and users were the people from our Design Dept, i.e. Engineers, I asumed that they would have thought through all the specs and that we basically just had to start.
Big mistake! Being good and great Design Engineers in the mechanical and electrical domain, regarding software they were as clueless as any Marketing Drone. Whenever we tried to extract specifications, all we got was "make it work like that old APL code we have, but better and more modern and let is calculate/simulate more correct results". Aaaarrrrggggghhh...
Unnecessarily to mention, that only very few actually knew how the old system worked and under what assumptions it was built.
Well, we boxed our way through and today I am the only person in the company that has the total insight (the other 2 left). Unfortunately, we were never given time to properly document the system (of course the code itself is quite well documented but there is more to do than just that). In my naïvité I thought that the Design Dept with their fixation on drawings and Supplier Specs and Purchase Reservations and Engineering Change Notices should understand the value of proper documentation...
A reflection I can now make: Hiring us Design Engineers to make the work instead of professional Software Engineers was probably the only way for the company to get the job done within reasonable time & budget. Non-existent specs, poorly understood assumptions for certain calculations - what a nightmare for any professional software developer!
Excellence: Moderate (mostly affected by comments on your karma)
I'd love to just print this out and give it to my boss, because once you've gotten over the typos it's an effective piece of writing.
But when it contains paragraphs like this:
The solitary program[er] who loves his work can use the best language for the task. Mosting programmers have very little control of the language they will use. [snip] In other cased the very real benefit of unity among the team....
I ge the feeling that the author thought that the spell checker did the same job as proof reading. In actual fact they do two different jobs; spell checking corrects spelling mistakes, proof reading ensures it makes sense.
Yes, the author has a better chance of becoming a dull professor than a programmer of any significance....
Like any profession you're born with some inate abilities to do things which schooling can then direct and improve towards being skills you can use to make a living.
Some people are born to be athletic but without the proper training those people will never reach their full potential and make a living out of it.
Ben
Work Safe Porn
Are there any male coders out there? Or is this HowTo aimed at women?
Abiit, excessit, evasit, erupit.
It's true! My cousin was finger painting in BASIC when he was a baby. When he turned three he hacked his Etch a Schetch to run Linux. He's seven now and he is writing his own OS! ;)
Such sagely wisdom
With anonymity you write
Knowing and unknown.
A feeling of having made the same mistake before: Deja Foobar
I stopped reading as soon as I realised he was consistently referring to the programmer as "she"... YECH!
> That would be because programmers have become the Wizards and Necromancers of our modern society. They have inherited the fantanstic ability to do the impossible. They also have a tendency to go a little loopy, and hallucinate too.
Lisa: Dad, we did something very bad!
Homer: Did you wreck the car?
Bart: No.
Homer: Did you raise the dead?
Lisa: Yes.
Homer: But the car's okay?
Bart & Lisa: Uh-huh.
Homer: All right then.
Money I owe, money-iy-ay
Maybe, buy you are assuming that one becomes a programmer to "make a living out of it". Sure school is necessary for that. But a programmer reaching his full potential may not have anything to do with proper training and money.
as well as everyone here... treat your peers with respect. A real programmer has nothing to prove.
Using the masculine sense for the indefinite article is correct. I don't know about you but all that 'she must do this with her whatever' stuff is quite distracting.
In Soviet Russia, hot grits put YOU down THEIR pants.
Abstraction is key to programming. One should choose how abstract one needs
to be carefully. Beginning programmers in their enthusiasm often create more
abstraction than is really useful. One sign of this is if you create classes that
don't really contain any code and don't really do anything except serve to ab-
stract something.
You think they are talking about struts?
love is just extroverted narcissism
write code.
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.
Methinks this non-lady doth protest too much. Why should it be "weird" to use she? Is it any mistake that when we think of great doings of the past we think of HIStory and hot HERstory? As a society we are gradually unburdening ourselves from centuries of ingrained racism and classism that permeated our unconsciousnesses. It seems fitting to me that we make strenuous efforts to also rid ourselves of unconscious sexism. I think this poster needs to think about why using the female pronoun makes him feel uneasy.
Da Blog
haha nice troll. :)
I have yet to meet someone that could not be taught to program. And if they are teachable they can become skilled if they are motivated. Sorry to have to be the one to tell you this, but your skills aren't 1337. I could teach anyone with algebra skills to program.
me karma am bad
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!
Too often there is no opportunity to maintain your own code. I find I'm sitting around idle most of the time if all I'm doing is maintaining my code. So of course if I were working in the programming field (I'm not, although I have done some programming projects on the job before) the project manager would end up moving me around to keep me busy (and challenged). Where's my old code? It's running in that other department or that other company. If I do end up doing any code maintenance or changes, it's someone else's POS.
now we need to go OSS in diesel cars
It is straight-ahead, grammatically incorrect to use a pronoun other than "he" when one refers to a gender-nonspecific third person. "He" in that sense does not even indicate male-ness by default, although unfortunately it is the same 2-letter combination we use for the male pronoun.
It's unfortunate that geeks so often exercise subjective opinions about what makes acceptable English, but will go nuts over marginal overuse of the C preprocessor...
You, neckbeard! Mod me down some more for my insensitivity to the social agenda of your sandal-wearing, military- and sports-hating claque.
>>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.
More than likely that person will have the interpersonal skills of a Gila Monster and all the critical thinking skills of an American Idol poseur.
This is a pretty good troll, my man.
But its still a troll.
The only thing you attempt to refute, is HIS OWN glossary! I can say "to beeblbrox: act like a king while involved in shenannigans" and be correct. Why? Becuase its MY terminology I'm explaining.
The rest of your wide sweeping generalizations are baseless.
Grade: D+
Please have your parents sign this assessment and return to me.
In the future, I would want to not be isolated from my friends in the Space Station.
that focusing on producing legible code can reduce the number of bugs you have to begin with.
I have seen programmers (myself included) be a "victim of their own cleverness" too many times. These days I spend a lot of time thinking about how to make the overall structure of my code clear and directed for a long time before I start pounding the keyboard. It has made all the difference in the world, both in the quality of my code and my stress level as deadlines loom.
I have become a big fan of simplicity and clarity.
The funny thing is, my pursuit of these things has taught me more about unravelling needless complexity than just "hacking away until it does what I want" ever did.
I'm not sure if your smacking the language are smacking EJBs or are just ignorant about Java.
The biggest clue that the writer has no clue about computer programming is his statement that 50 hour weeks are typical and 60 hour weeks are his limit. If you are writing code for more than about 2 hours a day, you are writing bad code that is horrible and buggy. I always try to explain what I do to people as very complicated math homework. Noone can actually do math homework for 60 hours a week. It is far too draining.
The majority of most programmers days at work is spent processing ideas in the back of their heads while they do other things (like post on Slashdot). The 2 typical tasks in programming, adding a new small feature to an existing program and debugging a bug are about 100 lines of code and 2 lines of code respectively. These would take in theory half an hour and 2 minutes respectively. But as the old story goes, its knowing which $1 component to replace in the $1,000,000 machine that costs the $10,000. So it is in programming.
Knowing how to integrate the new features and bug fixes without horribly ruining the existing design is the mark of a good programmer. Actually coding the fix or feature once it has been designed (on paper or in your head) is trivial. Overworking yourself leads to bad design and more bugs, which take even more of your overworked self to fix. This escalating behavior leads to burnout as well as the human brain can not spend that much time working on difficult problems every single day.
Anyhow, now that my brain has figured out how it wants to implement the new feature Im working on, while writing this comment, its back to work to toss out my 100 lines of well designed code. If my writing seems confusing or poorly structured, its because my brain was working on code design, not paragragh design.
Come on, taking shots at the prez as AC? Amateur.
If you're a programmer (well, IT geek in general, really), you're also:
Supposed to hate watching football (US-style) and love to tell everyone about it,
Attack people on message boards in a way you never would dare to in person,
Let yourself go physically and emotionally so you're nothing but a soft shell that likes to poke holes in anything anyone says, and
Lean way to the left.
So, get going, it seems you have some work to do.
So long, michael. Don't let the door hit you...
A lot of people are claiming that using "he" is gender neutral and/or the correct pronoun to use when the gender is indeterminate.
However, my girlfriend (who has an English degree and a diploma in technical writing, although she's more of the researcher type) once told me that the way she was *always* taught was that the only correct way to refer to a gender indeterminate human in a document is to say "he or she" (and it has nothing to do with being PC either - she's about as PC as a smoking monkey in a leather thong). Also, IIRC, using past tense or "it" is incorrect and even s/he is frowned upon. All her style guides and textbooks back her up on this. A lot of the technical writers in her classes argued against this point but the instructors always backed her up.
Does anyone actually have a source on "he" being a gender neutral pronoun? What major style guide is this rule published in? (This isn't flamebait, I am honestly curious).
Robots are everywhere, and they eat old people's medicine for fuel.
#include <stdio.h>
int main (int argc, char *argv[])
{
printf("\n"):
printf("To first learn howto write software,\n");
printf("you must first recognize the syntax \n");
printf("of the programming language chosen \n");
printf("%s its standard %s operate\n", "and how", "IO functions");
printf("The reason is to %s", "find the tao.\n");
return(0);
}
Prediction: Thousands of angry followups to this post by people who taught themselves to write C, consider themselves to be 'hackers', and think untypesafe code is 'l33t', saying something along the lines of; "People who teach themselves are just as good as people who have had a proper education". ;)
Fortunately, most sensible employers ignore this kind of attitude...
Here's some feedback.
...
... there is even more you can do. Move I/O handling to a seperate thread (more on this in my next comment.)
...)
Re: Divide and Conquer debugging approach
Knowing *where* to split requires less skill than he suggests. While binary-splitting is useful from an algorithmic point of view, in the arena of debugging, there is no reason to be binary. I will typically split the problem many times (8 or more) at each step. This observes the fact that usually the cost of splitting the code is much less than re-running the scenario to test to see which split it makes it past, or fails to run properly.
Neglecting examples in the debugging section is bad. In particular miss-synchronization of multi-threaded applications is an example that should be shown.
Re: 2.6 How to Optimize Loops
Ok, this is a really short list, and it misses the important principle of "caching", and some of the suggestions are wrong, or typically inconsequential.
1. Sometimes floating point can actually be faster than integer code. This is especially true if the code can be completely pipelined. In particular trying to change from floating point to fixed point algorithms in modern CPUs may actually *decrease* performance. The details of this requires a lot more discussion.
2. Inlining will be ineffective if the function routine is too large, or if the procedure prologue/epilogue cost is either low or unremovable.
3. Fold constants together -- you should be more explicit about what you mean here. Certainly sub-expression elimination is a common technique that usually works well (but compilers are pretty good at finding that for you) but in some CPUs like the x86, immediate absolute value operands are practically cost-free. Perhaps he means "hoist" whenever possible? That certain does help.
4. As to moving I/O into a buffer
5. Try not to divide and avoiding expensive casts requires much more detail. The best thing to say here is the understanding these costs requires understanding the underlying machine code that results from these operations. (Floating point division can actually be relatively cheap in the right context, and differentiating between cheap and expensive casts can sometimes be difficult, and require context as well.)
6. Using pointers rather than indicies -- x86's have sophisticated addressing modes wherein there is commonly no difference between these two alternatives.
Re: 2.7 How to Deal with I/O Expense
An important principle to apply is to realize the parallelism via multithreading can substantially assist these problems. For example if some IO is non-negotiable, or non-predictable, then at least it can be blocked, or streamed in a seperate thread. The reasoning behind this is that modern operating systems can yield (i.e., block) program control (i.e., your execution resources) from a slow to respond thread to the faster ones. So you can overlap all your algorithmic work with the delays while waiting for the data.
Re: 2.8 How to Manage Memory
Something should be said about caching versus non-caching. First of all, point out the cached memory can be tens to hundreds of times faster than main memory (in modern CPUs.) Variables on your local stack, and globals that are commonly used in your inner loops, will tend to be cached. However array streaming will tend to de-cache your data.
Running through your streamed data in multiple passes is especially bad, as it will require reading your data into the cache multiple times.
Again much more can be said here.
Re: 2.9 How to Deal with Intermitten Bugs
This is an important topic. Its because it represents the hardest debugging problem. We all run into it sooner or later. Even if it is a hard subject to tackle, it has to be expanded on. Giving examples here are invaluable. You have to show that as hard as it is, it is possible to ferret out such bugs.
Re: 2.10 How to Learn Design Skills.
The biggest thing to explain here, I think, is to just explain that all code can and should have seperate documentation corresponding to it, that is written *before* the actual code is written.
Re: 3.6 How to Work with Poor Code.
Remember that people may be more open, or willing to learn than you think. If you decide you have to recode something for someone, it may be beneficial to be explicit about this and show them the results. But for such a thing to be effective, and to get over any potential ego problems, you have to make sure the rewrite is absolutely, clearly, obviously better (it should be shorter and more easily readable.) Your goal should be to make sure the programmer that is the target of the rewrite, considers the results to be a better approach that is worth emulating themselves. (Give a man a fish
Section 3.7 needs to be tied to the last paragraph of section 2.1. Scribbling over some "pristene" (sp?) code is irrelevant if you can easily recover it (which you can with good source control.)
Re: 3.8 Unit testing -- my experience with this is a bit depressing. Unit tests always start out being a good thing, but over time, they are an extreme PITA to maintain. Unit testing is a good thing for what I consider *totally generic modules*. The reason being that truly generic modules do not evolve over time, while other code invariably does.
Unit testing can only be effective if there in an enforced automated testing mechanism. I.e., a failure causes an automatic and non-negotiable rejection of code checked into the tree. I have found it remarkably difficult to convince people that such a policy is worthwhile. (SGI used to use such a mechanism, and, of course, it worked wonderfully for them.)
Section 3.9 and 2.4 Belong together. How is 3.9 a team skill?
Re: 5.2 How to Manage Third Party Software Risks
In my experience, this is trivial -- rely on track record. Its more indicative than anything else. If the software has already shipped and has a history, then there is no problem. If it has not yet shipped (and you are hoping that it will in time for you to use it), then you are going to get version 1.0 software at best and more likely you are providing a beta test environment for the third party developer. Just put yourself in the shoes of the third party developer. In what way will they maximize the take away from their involvement in a relationship to sell you software? Remember business relationships can tend to dominate technical ones.
Re: 5.4 How to Communicate the Right Amount
In here you write: It costs its duration multiplied by the number of participants. Please underline and boldface this. It amazes me how managers don't understand this.
Re: 6.1 How to Tradeoff Quality Against Development Time
Remember that a good *design* will be resilient against poor code implementations. If good interfaces and abstractions exist throughout the code, then the eventual rewrites will be far more painless. If its hard to write clear code that is hard to fix, consider what it is wrong with the core design that is causing this.
Re: 6.2 How to Manage Software System Dependence
The harps back to a concept I referred to above as *totally generic modules*. These are just libraries that provide useful functionality and can take input without making any non-trivial assumptions, and contains no dependencies whatsoever.
An example of this is the C run time library. A good example that will help make this clear is that the C run time library is able to provide a quicksort implementation without knowing anything about the underlying array it is sorting.
State-less, assumption-free, zero-dependency code is very valuable. Its maintenance and development will be finite in cost, while its utility is on-going. Imagine the cost of rewriting the C library every time you use it.
Impressing this upon programmers will help them recognize the value of reducing dependencies.
Re: 7.2 How to Utilize Embedded Languages
Ony option you seem to have avoided is the possibility of embedding pre-canned languages. The real problem with embedding a language is that useful language design is harder than you might think at first. People's aversion to using/learning it is bad enough, what happens when they uncover a flaw in your language that is fatal to its design? People who design real languages put a lot of work in them, that cannot be trivialized. Whipping up an embedded language is unlikely to yield the most stellar results.
That said, there are currently numerous options for embedded other pre-canned languages. Python, Lua and Ruby come to mind. Before going off on some adventure of trying to design your own language, consider whether or not you are going to be able to do a better job than what you could do by embedding one of these languages. From my personal experience, I can tell you that Lua can be embedded in a few hours, and has probably the smallest learning curve of any language in existence.
How to be a Professional Programmer:
Demand to get paid for your work.
Why is this offtopic? I think it is good advice.
One day a Novice came to the Master.
Master, he said, How is it that I may become a Writer of Programs?.
The Master looked solemnly at the Novice.
Have you in your possession a Compiler of Source Code? the Master asked.
No, replied the Novice. The Master sent the Novice on a quest to the Store of Software.
Many hours later the Novice returned.
Master, he said, How is it that I may become a Writer of Programs?.
The Master looked solemnly at the Novice.
Have you in your possession a Compiler of Source Code? the Master asked.
Yes, replied the Novice.
The Master frowned at the Novice.
You have a Compiler of Source. What now can prevent you from becoming a Writer of Programs?.
The Novice fidgeted nervously and presented his Compiler of Source to the Master.
How is this used? asked the Novice.
Have you in your possession a Manual of Operation? the Master asked.
No, replied the Novice.
The Master instructed the Novice as to where he could find the Manual of Operation.
Many days later the Novice returned.
Master, he said, How is it that I may become a Writer of Programs?.
The Master looked solemnly at the Novice.
Have you in your possession a Compiler of Source Code? the Master asked.
Yes, replied the Novice.
Have you in your possession a Manual of Operation? the Master asked.
Yes, replied the Novice.
The Master frowned at the Novice.
You have a Compiler of Source, and a Manual of Operation. What now can prevent you from becoming a Writer of Programs?.
At this the Novice fidgeted nervously and presented his Manual of Operations to the Master.
How is this used? asked the Novice.
The Master closed his eyes, and heaved a great sigh.
The Master sent the Novice on a quest to the School of Elementary.
Many years later the Novice returned.
Master, he said, How is it that I may become a Writer of Programs?.
The Master looked solemnly at the Novice.
Have you in your possession a Compiler of Source Code, a Manual of Operation and an Education of Elementary? the Master asked.
Yes, replied the Novice.
The Master frowned at the Novice.
What then can prevent you from becoming a Writer of Programs?.
The Novice fidgeted nervously. He looked around but could find nothing to present to the Master.
The Master smiled at the Novice.
I see what problem plagues you. said the Master.
Oh great master, please tell me. asked the Novice.
The Master turned the Novice toward the door, and with a supportive hand on his shoulder said, Go young Novice, and Read The Fucking Manual. And so the Novice became enlightened.
This is right on - the jobs I've been most attracted to are the ones where they asked me the most technical questions. I'm surprised how little of this sort of questioning many people do when hiring. When I'm interviewing people, I try to put them through their paces as much as possible.
I had one engineer help me take apart a vacuum feedthrough, clean it, and put it back together. She jumped right in and did it. I offered her a job on the spot.
It's not wasting time, I'm educating myself.
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.
JFYI,
. html
Samizdat
Literally, self-publication. Russian word for the printing and circulating of literary, political, and other written manuscripts without passing them through the official censor, thus making them unauthorized and illegal. If published abroad, such publications are called tamizdat (q.v.).
Source http://memory.loc.gov/frd/cs/soviet_union/su_glos
"If you want an opinion or a value judgment that takes into account some
unique circumstance, talk to an expert. For instance, if you want to know if
it is a good idea to build a modern database management system in LISP, you
should talk to a LISP expert and a database expert."
Or just Ask Slashdot!
graspee
Should I check for the failure of malloc in C? I mean, if malloc does fail, what's the proper way to handle it? Print "Out of memory" and then exit(-1)? How is that any worse than just catching SIGSEGV and aborting the program more gracefully in that case? Could someone enlighten me?
His advice seems to be "To stay motivated, work on things that are motivating." At the same time he admits that programmers often end up working on things that are not motivating. Thus he leaves the big question unanswered: How do we stay motivated when working on things that are not motivating?
Anybody have any thoughts on that? Favorite tactics? A few years ago, a good response would have been "Just quit and find a new job that's more fun." That's not so appropriate these days, it seems.
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
Do we need another "How to be a Computer Person book?"
I am already a programmer, and systems technician, I don't need a book on that any more than Snoop Doggy Dog needs a book on how to be a rapper. How about a book on "How to be a CEO", now that is something that I would want.
In the big leather CEO chair, talking to the intercom
Me: Louise, hurry up with my Chocolate Latte, I got a business to run!
Louise: With, or without whip cream?
Me: What do you take me for a fool, WITH!
Step 1: Be sure you are doing it because you like it, not for the "money", "publicity", or something else.
Step 2: Get hired in that field, somewhere, anywhere. You might need to get a degree of some kind, so find somebody who will help with your tuition and other costs.
Step 3: Profit!
Karma: Food Fight (Mostly affected by Date Plate).
Someone suggests not all people could grasp pointer/reference.
No, really, Teach Yourself Programming in Ten Years.
It is straight-ahead, grammatically incorrect to use a pronoun other than "he" when one refers to a gender-nonspecific third person.
Nice way to emphasize a point with "straight ahead." Unfortunately, you're wrong for a few reasons.
1. It is arguable that "he" is the only acceptable neutral gender pronoun.
2. It is "staight ahead" sexist. Right or wrong, it's still sexist (period, bold, underline, exclamation mark.)
3. It's isn't "unfortunately" the same word used for the male pronoun, it was made to be that way by sexist dominant males because most people in gender neutral situations were men. Now it's changing, and the language needs to change too.
4. Your last statement is unnecessary.
sig: There are two mistaakes in this sig.
First look read as:
"How to be a Short, Comprehensive and Personal Programmer"
But I already am.
http://pcblues.com - Digits and Wood
For no other reason than the way that the phrase hits the ear.
"Phrases" don't hit your ear. Amplitude- and frequency- modulated sound vibrations are detected by your ear and eventually converted into electrical impulses that are interpreted by your brain. During the initial construction nothing jars. Yet at some level, the phrase "she" is recognized within your mind and this is what you find upsetting. "grammar fascist" is right. You need to ask yourself how deeply ingrained is sexist language within our minds that some simple pronoun usage can feel deeply disturbing to us. How important you think language is to the development of people's minds depends really onyour attitude to the Sapir-Whorf Hypothesis (linguistic determinism and linguistic relativity).
Da Blog
Please expand on this, and try to post earlier next time. I see the makings of a really good troll here. Good start.
No, Thursday's out. How about never - is never good for you?
That reply to my comment is excellent. It deserves the mods.
now we need to go OSS in diesel cars
lol, guess my wife gets pissed though when our waitress gets a $50 tip.
Being a software developer is like winning the lottery, just a tad slower to collect the earnings.
1. Get degree
2. Get job/apply degree
3. Find area of need or opportunity
4. Start own business in field (if fail go back to #2)
5. Profit!!!! (just starting to get there...)
While I'm not a grammar fascist, I am irritated by the uncommon usage of she in contexts where clearly the accepted use of the word 'he' applies. The worst offenders are typically baby raising books, the section where I presume the most liberal authors hang out. They literally switch pronouns every few sentences, just to see if you're paying attention. They're unfuckingreadable. I use them for kindling now.
Technical papers should steer clear of using gender pronouns entirely, instead choosing 'the programmer' or 'the user', or avoiding them entirely. At least, that's what I've been instructed to do when writing documentation.
Any connection between your reality and mine is purely coincidental.
Having developed for many years as a profession as well as a hobby. I manage and design more these days however. I believe that the 'HowTo' should have focused more on two things. 1) Problem solving. languages, architectures, and methodologies come and go. What remains constant are the problems. I consider myself more of a problem solver than a programmer. Programming is just the media in which we implement solutions. 2) Design. How can I put this....Bad Design = Bad Programs. It causes, bug-riddled, and potentially unmaintainalble products. The bigger the product the bigger the problems. Design allows us to think thouroughly about our problem (most of the time), which allows us to identify, potential problems and exeptions before a line of code is even written. Life is much easier this way.
If you're not a good programmer none of that will make sense. If you are, then it's stuff you already know. Go figure, huh?
:)
As a programmer, the three most important things you need to be able to do are:
debugging
optimization
implementation
probably in that order. Note that there isn't much difference in the skillset needed to debug and to optimize. The basic techniques are the same, it's just the specific tools for each are a bit different. Both require that you keep the model of your thing in your head for extended periods of time, as well as the execution environment.
Implementation is easy once you look at it from a debugging and optimization standpoint. Design becomes a bottom-up process; whether that's good or bad is subjective, but it sure does make it easier to debug when a program is written to be easy to debug and optimize
When a person on slashdot identifies themselves as a member of the female gender, DO NOT BELIEVE THEM! They are really hairy old men sitting in front of their computer wearing stockings and high-heels getting off on the fact that they think that others think that they are women!
90% of our codebase is perl.
Yes Virginia, perl source CAN be written to optimise for legibility.
DG
Want to learn about race cars? Read my Book
I find that avoiding computer talk at all costs also works.
.look her up and down then look her in they eyes and smile. To my surpise she asked me to kiss her?!? Naturally being a geek I fumbled the first attempt . . . but she wasn't put out and stuck around for another round. It get's better from here but I'm digressing from advice to bragging. The point is I supressed my natural urge to talk about programming, said nothing of importance, danced close and held her tight then got laid. Don't talk about programming.
A girl might might start the conversation by asking what you do but don't interpret that question as an invitation for a 1/2 hour lecture on the merits of postgres over ms sql server. Instead move the conversation back to what she does for fun. If you can't think of anything to say then say nothing at all!!
The later technique worked for me this weekend. I was in a local pub with a couple friends. After dancing close with a cute blonde we sat down to talk and have a drink.
The conversation lasted about 1.5 minutes. I tried desperately to think of an intersting topic to talk about but could only think of that days slashdot headlines. So instead I asked her back to dance. While dancing to some salsa music I tried the "Joey Tibbiani" approach. You know . . .
You should go home if you are thinking suicidal thoughts.
Umm, are you sure that being home will help if you're suicidal? I mean really... how many people *actually* commit suicide at work?
You should take a break or go home if you think homicidal thoughts for more than a few seconds.
Actually, if you are a programmer and aren't planning on committing homicide at some point during the day - I'd be worried... Those damn users!
You should send someone home if they show serious mental malfunctioning or signs of mental illness beyond mild depression.
Oh yeah, that's gonna help them... You send them home and they think that they're getting fired... it's realllllly gonna help the depression eh?
If you are being tempted to be dishonest or deceptive in a way that you normally are not due to fatigue, you should take a break.
Naaaa... how else are you going to come up with those fantastic ideas to score with chicks if you're not hallucinating due to fatigue? Come on... be a REAL programmer!
Don't use cocaine or amphetamines to combat fatigue.
In THIS economy? Are you kidding? Maybe during the dotcom era when the employers were sharing theirs, but not now... The last thing I need is to sell the TV in order to score a line or two...
Don't abuse caffeine.
OK, now I know this guy abuses coke... Is he fucking kidding? I took a solem oath long ago to abuse caffeine and I plan to do it for as long as I possibly can... For me to not abuse it, I'd probably go into shock and die... Now where's that coffee...
My SO used to get pissed when told "of course 'he' doesn't imply exclusively 'male'; get used to it, 'he' is inclusive and generic, why are you so sensitive?"...
i don't know, but if someone really want to read a book/article about How to be a Programmer?. i always recommend this book: The Practice of Programming, by Brian W. Kernighan and Rob Pike.
you know what's wrong with your article? you just list a few books, and say: "go learn programming there", then you start talking about debugging, in section Beginner! what a misleading...yes, i know bug happens, we can never finish a project without debugging, but, you should not emphasize this and forgot the more important thing: Write Simplicity/Clarity/Generality code, eliminate bugs (not all, of course) at the first place.
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.
I knew one programmer who didn't shower (except maybe once a year), didn't wear nice threads, was a very difficult person to deal with, and I really wished that they would have either moved his office or given him a chair with a full back to hide his plumbers butt that was stairing at you as you climbed up the stair. Ya know what, he found a wife who was just like him. To each their own.
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.
it'd probably be modded as Flamebait.
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:
1) go to college
2) get accepted into the CS program
3) graduate with a very good GPA
4) have employers tell you to piss off because you don't have experience
5) have other employers invite you to come back after finding the fantasy, nonexistant company that hires entry level programmers
6) have most employers just ignore your resume
7) have non-computer employers look at your resume, see your education, compare what they are paying to the $50,000 a person could get if entry level jobs existed, and label you overqualified
8) get accepted into grad school
9) listen to the people who just earned their MS degrees describe steps 4, 5, and 6
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.
See, I like to program. In relation to the article, I don't mind team-work if my team is somewhat knowledgeable with coding as well as the problem presented. What I DON'T like is having someone added to our team simply to please the "brass."
This lowers morale. Has anyone else felt utterly expendable even though they literally gave their life to a project?
Now, where did I put that depilatory?
1) distributing a UI over the web to be used within a web browser?
2) The other reason to use java is when you bills are being paid by programming in java.
reguardless of the reason, if you need to know why your app is running slower than it should, profile it if possible.
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
I've had employees try this shit on me and they're out the door. If you can't work more than 2 hours a day then you're just not cut out for a programming job. You're only being a asked to work for 8 hours out a 24 hour period. I suppose you expect to be paid thousands for your 2 hours of hard labour. Do you even have a job?
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!
Doing some work on a object management system for games... and i think this is heading towards the worlds worst c macro
those who control the past, control the future. those who control the present, control the past.
I have worked on 3 person company. And that never happened. So you must be talking about 2 person company, right?
But in that case, who the fsck is the sales/marketting manager... Aaah, I get it. It is the sales and marketting manager of next door neighbour two person SW shop.
Now, that sounds industrial espionage to me. And that is not nice. Did he even buy you people beers for using your code, or was it that you were wrinting free ("as in freedom") software?
In dream society, people could be given the ability to mod replies. In real life, it would be disaster.
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).
I knew one programmer who didn't shower (except maybe once a year), didn't wear nice threads, was a very difficult person to deal with, and I really wished that they would have either moved his office or given him a chair with a full back to hide his plumbers butt that was stairing at you as you climbed up the stair. Ya know what, he found a wife who was just like him. To each their own.
Yeah, maybe owning Microsoft does have an effect on the chicks.
Offtopic, Inflammatory, Inappropriate, Illegal, or Offensive comments might be moderated up.
That's no way to speak about Alan Cox.
That's quite valuable topic. You can publish it. :) But you just forgotten one thing, in order to be a programmer, a good programmer, you must be born for programming, and have a logic turn of mind. If you don't interesting in it or like it, you will never be a programmer. Even if you'll read that topic thousand of times... So, don't be mistaken in yourself and in your abilities, don't be a programmers!!! ...if you don't want it indeed.
With the best regards, Masik
Change isn't bad unless it is change for the sake of change.
Isnt this a cheezy cliche. Change for the sake of change.
Its always good to change and shuffle things around, whatever the reason is. It eliminates monotony.
As a programmer, I think the most important thing that often works for me is change for the sake of change. U can easily be stuck with the same old techniques that u learned in college, courtesy ur teacher and colleagues. There are so many different ways to implement the same thing. You should, every now and then try to shuffle things a bit and in the process learn new, efficient metthods.
... hee2 is stuck under the bed.
I find myself unable to decide all the time, so I would be really curious about this method. Google produced unconclusive results, though. So any hints as to the nature of the method mentioned in the book would be most welcome!
Write using TeX.
-- "The reward of suffering is experience." - Aeschylus
Eveything was fine until I got to this bit at the end. What's he talking about?
9.10 How to Deal with Organizational Chaos
There are often times of great organizational chaos. These are unsettling to everyone, but perhaps a little less unsettling to the programmer whose personal self-esteem is founded in her capacity rather than in her position. Organizational chaos is a great opportunity for programmers to exercise their magic power. I've saved this for last because it is a deep tribal secret. If you are not a programmer, please stop reading now.
Engineers have the power to create and sustain.
Non-engineers can order people around but in a typical software company can create nothing on their own and only have the power that engineers grant them. They can create and sustain nothing without engineers. This power is proof against almost all the problems associated with organizational mayhem. When you have it you should ignore the chaos completely and carry on as if nothing is happening. You may of course get red, but if that happens you can easily get a new job because of the magic power. More commonly, some stressed-out person who does not have the magic power will come into your cube and tell you to do something stupid. It is best to smile and nod until they go away and then carry on doing what you know is best for the company.
This course of action is the best for you personally, and the best for the company you work for. If you are a leader, tell your people to do the same thing and tell them to ignore what anybody other than yourself tells them, including your own superiors.
"Oh!" I said to myself as I skimmed the table of contents, "there is a section on How to Stay Motivated". I've haven't been tearing it up lately and so I quickly scrolled to page 20 looking for some helpful ideas... in a nutshell the author suggests I work on "beautiful, useful, or nifty" things.... Great. Thanks. I'm fired up now.
You have upgraded from a troll to a critical analysis!
And I think you have valid points- telling anyone "This is the way to get a promotion" is absolute crap- but thats a flavor of "advice" that everyone gives and no one has a clue about.
As for not documenting code, this dewd should put in a MAJOR revision. I work on legacy systems and I've seen places where the commentary in the code is just plain factually incorrect. Which is right? THe code? or the comment? Was the code changed by a developer 8 years ago and he didn't update the comment? WTF?! You need to get a consensus between the docs, the comments, and the code to figure it all out.
As for the glossary, maybe he needs to put a disclaimer on it (These are all my words and my meanings) and put that in the FRONT of the book, so you can speak the authors brand of geek from the get go.
If you aren't gonna e-mail these revisions to him, I'll do it for you!
In the future, I would want to not be isolated from my friends in the Space Station.
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!!
Am I the only one who has (a) never used the term unk-unks, and (b) would never dare refer to them as that?
--<Mike>--
The table of contents sounds exciting, but I can't see the point of a male, writing to a mostly male audience in english referring to people of unspecified gender as "she." Yeah, it was funny the first time it was done, in 1832, but now you just sound ignorant.
the sad thing is, that I know what SO stands for
to describe a man? That would be weird.
to describe a neutral gender? Not weird, just wrong.
What do yo mean nothing to lose. I lost my virginity that way.