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."
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.
1) Write a spec ...
2) Send spec to Indian/Russian/Chinese Programming Outsourcer
3)
4) Profit!
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."
In the real world, if you're designing large systems, you're not a programmer, youre a systems architect.
.. architects design the huge thing .. programmers build it, and make localized design decisions.
... so I think your point is more one of semantics.
Think
But I dont think its fair to say programmers must be good at large scale design since thats a career path unto itself. And those who can design large scale systems are usually not so good at the nitty gritty
"Old man yells at systemd"
How to deploy the software and updates to it.
It gets quite complex in custom business applications where you have to distribute client, middle tier and database updates to production systems.
Anyhow, my 2 cents.
Here's what is important to me as a programmer:
1. Always keep learning - it's not as important how much you know - it is important how fast you can learn new things
2. Don't just implement something for the sake of doing it, or because it will look cool on your resume. Make sure you have valid reasons for what you do, preferrably backed up by some research. Change isn't bad unless it is change for the sake of change.
You find this humorous, centurion?
This looks like it should be titled "How to be a Developer", as much of it is oriented towards programming for a project or coporation...
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...
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 !
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...
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.
I totally DISAGREE. Good programmers have a total picture of how thier programs work and interact and that is why they work and interact very well (the nitty gritty is done with a debugger and testing). If a system architect was not at one time a very good programmer then he is probably a bad system architect. Of course thier are tons of bad programmers who then become bad system architects FWIW.
I miss the Karma Whores.
I like this quote from the document:
"Life is too short to write crap nobody will read. If you write crap, nobody will read it."
As I read through the comments here, it's apparent that virtually none of the posters clicked on the link much less read the document, and a good 90% of them didn't even read past the posting title.
Anyway, the article touches on good points, but it's very clear where the author has personal experience with something and where he doesn't. Some of those times he starts to sound like the books he recommends (all excellent recommendations). Other times (e.g. 4.1. How To Stay Motivated), he simply states something that would be good, but doesn't describe how it should be done.
He recommends "Succinctness is Power" by Paul Graham. Given the document's spottiness, he probably should've gone alnog those lines instead. Written down a little ditty about why you should read the material, and then his list of books and articles to read on how to be a programmer.
If half of the programmers I've known had read his recommended list, I'd have a hell of a lot more trouble staying far enough ahead to have time to review articles and post on slashdot.
I've been coding in an enterprise environment for quite some time now, and I have one rule that is cast in gold:
Always optimise source code for legibility above all else. Never trade legibility for performance unless you have no other choice, and then document your cleverness in the code so that those who follow behind you can keep up.
Here's why:
When you first write a system, it will spend its first few months of life in a very intensive quality control feedback loop. Bugs are found and very quickly exterminated. The code is still fresh in your mind and you're "in the zone".
But as the system stabilises, there is less and less reason to go back to the code, so that freshness wears off. After a little while, other priorities will take over and the internal model of the code will fade away.
But there's still bugs in there - there always is. But any bug that makes it past the first few months is non-obvious, intermittant, rare, and so on (thus, harder to find)
When one finally surfaces, _somebody_ is going to have to fix it. Sometimes it will be you, and you will appreciate code legibilty when you have to dust off source that has laid untouched for years. Not only does it increase the probability that you'll be able to actually find the bug, it cuts down on the time needed to fix it.
There's nothing like being the guy who finds and fixes bugs within seconds of them being pointed out to enhance your reputation.
But more often than not, it will be some other poor sap who gets saddled with your code and a deadline to get it fixed - and the guy who draws the short straw is normally not the biggest brain in the shop. There is no gratitude like the gratitude from someone forced to dive into somebody else's code, and who subsequently discovers that you have gone out of your way to make it easier for them to understand.
This is _also_ a reputation enhancer. "That code was so well written that not only did it take no time at all to track down the bug, but I also learned a couple of new techniques in the process!"
The true guru is a TEACHER.
Oh, and ALWAYS check the return code from every system call and provide appropriate error trapping. That's good too.
DG
Want to learn about race cars? Read my Book
Since I'm doing that "system architect" job at the moment, I feel like I can reply to this :->
:-D. I can't dictate, but if it doesn't fit in with my architecture, I have a veto - and I'm consulted on every technical decision that's not already delegated to someone for implementation (I review those).
If I didn't have years of prior experience hammering systems together, debugging custom code and off-the-shelf things made to play together in new and unforseen circumstances, and a few tens of thousands of lines of multiple languages of coding, I wouldn't be able to avoid the land mines that the folks who designed THOSE systems subjected me and my "tribe" to.
One of the glaring gaps in the last 15 years or so has been the one between the classic "system engineers" and "software engineers". The "System Engineers" have usually been hardware types, and have no problem saying "it's a software problem - deal with it" and making the poor code monkeys cope with their bad decisions. It's taken me years to get the credibility among those folks to make them listen to my opinions and actually change their minds; I was just a software guy, not a Systems Engineer. Now, I have a program manager who's former software, and a software manager who's former software, and I'm senior to our chief system engineer
This may actually be my dream job - fortunately, we're doing well on it, so we're thought of well inside the company; unfortunately, we're meeting our schedules, so it'll end within the year *sniffle*. Then, I'll just have to find a way to keep myself out of management....
I love vegetarians - some of my favorite foods are vegetarians.
you end up having very little contact with the softer gender
I don't know where everyone gets this from. Maybe this was somewhat true 10-20 years ago, but not now. Not all programmers are socially inept dorks with no lives outside of computers. Or am I the exception to the rule? I tell women I'm a software developer and it *increases* my chances with them (I suppose they think $$$). Hey, and I've been a geek most of my life--and I still spend much of my free time on computers. Women like a guy who can fix a computer. Trust me. Being somewhat successful in your profession helps also, so reading "How to get a Programmer" will indirectly help you get chicks.
If you're a geek, you *can* have luck with the ladies; especially if you've got a job and some cash to spend. Shave that beard, get a decent haircut. Buy some nice clothes. Go out, drink a coupla beers, and just talk to women. There are ladies out there for everyone. Trust me, they are just waiting for you.
Zoot!
One thing I have learned is to not invest a lot of prideful ownership in a particular design decision I make. When reviewed by the team, it invariably gets modified somewhat, sometimes outright rejected. Taking ownership of a subproject (in my case) is one thing, but you have to be malleable enough to "give them what they want". Otherwise you end up beating your head against a wall.
Oh and lose any aversion to eat crow is also a good idea. At some point you will pronounce "There is no way I made that mistake" only to see your log-in in the RCS/CVS log.
I forget...are we at war with Eurasia or East Asia?