The Joel on Software Discussion Group (CLOSED)

A place to discuss Joel on Software. Now closed.

This community works best when people use their real names. Please register for a free account.

Other Groups:
Joel on Software
Business of Software
Design of Software (CLOSED)
.NET Questions (CLOSED)
TechInterview.org
CityDesk
FogBugz
Fog Creek Copilot


The Old Forum


Your hosts:
Albert D. Kallal
Li-Fan Chen
Stephen Jones

Things all good programmers should know.

I have been programming for about 3 years now and I am a freshman in Highschool, mostly in C++ and submitted a few patches to opensource projects written in C.
I wan't to broaden my horizens and would like to know what you guys think every good programmer should know. C and C++ are the limits of the languages I know and I almost only use Windows.
SeekerOfGoodness
Thursday, September 01, 2005
 
 
That the ability to find things out when you need to is more important than the ability to remember lots of things.

More of your time will be spent reading code than writing it.

Read "The Pragmatic Programmer". It's a book full of things every programmer should know.
John Topley Send private email
Thursday, September 01, 2005
 
 
I don't agree with you John. We all know that if we remember things correctly, we'd save a lot of time reading new stuffs.

Dear OP, if you code, then you must know why you code. A lot of programmers don't even know that. Christopher Baus has written a great article; Talkers and Doers www.baus.net/doersandtalkers . In your path you'll see people brag about their method being the best; and you'll also see some that would take action (not caring about methods). You should read Joel article on software methodologies, and his annalogy with Mcdonalds here: http://www.joelonsoftware.com/articles/fog0000000024.html
I bet that the first two things a programmer should know. The third being; you're wrong if you think you'll get a lot of money being a programmer :)


I hope I've helped you a bit. I'm in your same situation. One last thing, nowadays
vic Send private email
Thursday, September 01, 2005
 
 
nowadays, everybody is a kind of programmer, so you must be more specific.
vic Send private email
Thursday, September 01, 2005
 
 
As I don't know what attracts you to programming, this of course may not apply to your situation.

I personally found learning Common Lisp the most interesting part of programming, as it allows one greater control over the coding environment, even in some nonobvious ways. A skim through this may help you decide whether it's interesting to you.
http://www.gigamonkeys.com/book/

Alan Kay is certainly someone to read up on, particularly as the programming world is now noticeably evolving into the direction he helped trailblaze decades ago. This is part 2 of a talk he gave, and I find it quite interesting.
http://www.archive.org/details/AlanKeyD1987_2

I think learning econ is definitely useful, but not the shifty stuff they usually teach at school though. If you're interested on this topic, I'm sure people could expand...
Tayssir John Gabbour Send private email
Thursday, September 01, 2005
 
 
"I don't agree with you John. We all know that if we remember things correctly, we'd save a lot of time reading new stuffs."

So you think that I should memorise the entire J2EE platform API?
John Topley Send private email
Thursday, September 01, 2005
 
 
Read the Mythical Man-Month.
Colm O'Connor Send private email
Thursday, September 01, 2005
 
 
I must say I agree with John on that point. I'd rather work with people who can find the information quickly rather than those that have it all locked in their head.

The reason being it's virtually impossible to remember everything about everything, even if you limit yourself to a single language.

There will come a point where you need to do something you haven't done before and Mr Remember it all won't be able to, he will then spend a huge amount of time messing around looking for the answer.

But it should be pointed out that Mr Find's Stuff Quick also remembers stuff, possibly 90% of what he needs to know during the working week.

It's not about being able to find information, it's also about making sense of it, knowing what's relevant and what's not and knowing when to knock something on the head and move on when it's not producing any results. I find the  arrogance of Mr Remember get's in the way of the last point.
gilf Send private email
Thursday, September 01, 2005
 
 
gilf, plus: you need to know how to read. This bothers me a lot, because I plow through a whole lot of information every day, but my coworkers don't even seem to be able to read a help screen!

why?
Daren Thomas Send private email
Thursday, September 01, 2005
 
 
You must know a little about a lot before you can genuinely know a lot about a little.
Philip Prohm Send private email
Thursday, September 01, 2005
 
 
Read Yourdon's Deathmarch.
trollop
Thursday, September 01, 2005
 
 
1. How the hardware works,

2. How the compiler works.

Programmers who don't know this will not be able to write the most efficient software, and thus can't be considered "good".
Frank de Groot Send private email
Thursday, September 01, 2005
 
 
Remember that the majority of programmers, like many other specialists, are more interested in the technology for its own sake than in what the benefit of the technology is to mankind. Try not to become like that.
Daniel McBrearty Send private email
Thursday, September 01, 2005
 
 
SOG,

Please define what you mean by "good programmer". There are so many possible definitions of "good" that you're not likely to receive many useful answers without this definition.
Mark Pearce Send private email
Thursday, September 01, 2005
 
 
I'd recommend anything by McConnell (Rapid Development, Code Complete, Software Project Survival Guide, etc) for in-the-trenches development/project information.

For application-level stuff, go with Martin Fowler (Refactoring, Patterns of Enterprise Application Architecture).

And learn about data structures....
KC Send private email
Thursday, September 01, 2005
 
 
No, you don't have to remember all J2EE platform API. And I didn't say to the OP to remember everything. But there are important things to remember.
vic Send private email
Thursday, September 01, 2005
 
 
Learn how to deliver a product, ideally to a machine that you don't control.  This is hard, and the first time I did it I was surprised at how much I didn't know.  If you can come out of high school already having delivered a product that people can install without being technical gurus, you've already got a huge resume point that most people graduating college don't have.

Some goals to shoot for:

1. ./configure; make; make install are not part of your installation instructions.

2. There is no dependency on the existence of any absolute paths.

3. The user isn't involved in moving individual files.

4. The user doesn't need to figure out dependencies on their own.

5. While you have a manual, your interface is so obvious that nobody needs to read it.

6. People are actually using your software to solve real world problems.
Clay Dowling Send private email
Thursday, September 01, 2005
 
 
There are lots of ways to broaden your horizons. The pragmatic programmers is a very good suggestion, as are the other books mentioned above. Their website, http://www.pragprog.com, can give you a good introduction into what they are all about. The book is full of many things that will help, but I believe the single greatest bit of advice they give is:

Learn a programming language a year - I think a language a year is a stretch and you will never master a language in a year, but there are several benefits to this other then learning yet another language syntax. One is it keeps you fresh, which is good for finding a job. The other (and in my opinion the more important one) is that different languages make you think differently about problems. All languages have strengths and weaknesses (Even lisp does, though some believe it to be all powerful) and the more tools you have in your kit, the better you will be at solving problems and more useful you can be to the people you work for.

Since you have a Windows machine, I would also get Knoppix or one of the other live CD based Linux distros (I'm only familiar with Knoppix, though I know there are plenty of others) and at least become familiar with moving around in a Unix environment. Repeat this until it becomes second nature "The shell is my friend." If you go on to college, assuming things are remotely like they were 10 years ago, you'll have plenty of powerful Unix machines to play with. I was only familiar with Apple II e's and their ilk when I went to school and had to take some time to get familiar with the Unix way of doing things. Having had gobs of Unix experience before Windows experience I was continually scratching my head about certain decisions Windows made. Heck, I still do that. That being said, read The Art of Unix Programming. It's free and online and has some very well thought out arguments. http://www.faqs.org/docs/artu/. Just ignore Eric Raymond's anti MS rants if they bother you. There is a lot of good stuff in that book that is ignored at your peril.

In addition, to expand on what Daniel says above, while the technology in and of itself can be a lot of fun, you need to step back when working on a project and realize that you are trying to solve a problem for people. That you know the efficiency of every sorting algorithm, can razzle dazzle your friends with your command of TLA's and all of the uses of const in C++ and have the ability to write lisp macros in your sleep will not matter one iota to the people you are really writing the application for, your customers. In fact, they'll probably just look at you like you are speaking latin and will try and find a normal human being elsewhere. Learn how to interact with your customers. Make an effort to be able to explain what's going with your software in terms that either a five year old or a senior executive can understand.

Lastly, and this is the hardest thing since it has nothing to do with picking up yet another programming language, text editor, IDE or OS, learn to check you ego at the door. If you're really good at what you do, you don't need to come off as an arrogant prick. In truth most people that do come off as loud mouthed know it alls tend to be the sorts of people others don't want to associate with. Usually it just covers up the fact that they don't know anything. I know in high school this little piece of advice would have had no meaning to me, so just file it away somewhere in the back of your mind. At some point you'll have an enlightening experience, likely nothing to do with programming, that will teach you the perils of ego, such as the following.

My best friend and I were home from college on break one winter and we went skiing. It wa my first time. I was an ok athlete most of my life, so by the middle of the day I was doing ok. I was able to make it down the beginner and intermediate slopes without falling more than once or twice and I was having a pretty good time. So we're going up the lift and my buddy says "You want to go down the Gunbarrel?" which is the black diamond on the mountain we were on and I said, "Nah, I probably shouldn't". He simply said "What are you, a pussy?"

Well, I certainly wasn't going to take that so I said "Fine." Needless to say, I spent three quarters of that trail going through moguls face first instead of over them on my skis. I swear I had half the snow on the mountain down my coat and pants. I knew I shouldn't have bothered but hey, nobody's going to call me a pussy and get away with it.

Lesson Learned.
Bart Park
Thursday, September 01, 2005
 
 
a) there's always a better way.  keep improving.

b) learn the business side.  coding isn't just 1s and 0s.  people have to actually USE what you write.

c) write code that's idiot proof.  just 'cause it looks obvious now doesn't mean it'll look obvious to you a year later.

d) save time by writing reusable blocks.  document where these blocks are.  make it easy to find them.

e) learn how to work in a team. 

f) learn peripheral stuff like graphics, office type products, network admin...

g) get in shape.  get plenty of sleep.  eat well.
Kenny
Thursday, September 01, 2005
 
 
You're still at school, so ignore all that business oriented stuff for now.  You'll have to worry about that enough when you enter the work place.

Since your still in education you can have the pleasure of devoting yourself to all the impractical, esoteric stuff that is just plain fun.

For example read SICP and implement your own LISP Compiler.
http://www-mitpress.mit.edu/sicp/
Ged Byrne Send private email
Thursday, September 01, 2005
 
 
Yeah, but learning the business side involves, mostly, figuring out how to talk to people. In addition to helping him much later in life, it will help prevent him from getting stuffed in lockers and he may actually be one of those rare geeks that has dates in high school.

Of course, being somebody who can write lisp compilers and get a date puts you in a weird category where you don't get along really well with anybody because the jocks and "cool" kids don't understand compilers and all the geeks will be jealous that you found a girl by a method other than Google image search. On the flip side, you'll be well adjusted enough that you won't likely get beat up for your lunch money.
Bart Park
Thursday, September 01, 2005
 
 
A few tips: Being humble. Don't think that you are the greatest programmer that ever lived. Because there is always someone who is better. Always... Acknowledge the fact that when talking about programmers different people are not equally strong on everything, some are good at low level other at high level stuff and the trick is getting a good mix to become really good at what you do. There are guys I know that are experts when it comes to assembler and processor pipelining, but can't get their head around OO. Also I know people who are exact the opposite. As for me I'm somewhere in the middle, but as for my skill I'm good but I'm not the best when it comes down to either end of the spectrum. Reducing the ego has some other positive side effects that you don't bite of more than you can chew when it comes down to time estimates and performance projections. Also it could save you from becoming the "hero" that always saves the day and don't trust anyone else to do his/her job.
PPR
Thursday, September 01, 2005
 
 
I think it's because I'm getting older. I've been thinking
about this what with turning 50 on my next birthday and
still making a living, somewhat to my surprise, as a
software developer. As time goes by, it's the big,
maybe unsolvable, problems that become more interesting.
Yes, I could become an expert in another programming
language. But after learning a couple of dozen since I
start coding at age 15 (using steam powered processors
the size of small glaciers), it's hard to find anything
that wasn't already done in Prolog, Snobol, LISP, PL/I. I
think of my speciality as applying OO techniques to
embedded, device, and real-time problems. That sometimes
sounds leading edge, but in fact the earliest example of
that I recall seeing was the I/O subsystem in OS/360.
Written in assembler, true, but an OO design none the less.
The half-life of almost all technical knowledge is about
five years. I love Java as a language, but I know ten years
from now it will no longer seem mainstream. Oh, yeah, I've
wandered off the topic. What big problems? How to
coordinate 200 developers on four continents to produce a
product that doesn't suck. How to produce anything,
software or otherwise, that doesn't suck, in a culture in
which we've confused "More for Less!" with "More of Less!",
where the priority seems to be to enrich upper management
at the expense of everyone else. I'm not actually cynical.
I believe we can produce stuff that doesn't suck. But
the ability to produce non-sucking stuff is more and more
falling to the small shop not stuck in the "innovator's
dilemma". And for all the advantage of the small shop,
there are some Big Problems that cannot be solved by the
small shop. But maybe they can be solved by a lot of
small shops working together. Yawn. I need to go take my
meds now, maybe take a nap. Did I ever tell you the one
about...
John Sloan Send private email
Thursday, September 01, 2005
 
 
There's lots of good advice in this thread; I just want to add a couple of items from my personal experience.

I learned more about operating systems and programming by looking at things that were completely different than I would have staying in my own little corner of the world. I learned more about Windows when I switched to Linux than I ever knew when it was the sole OS I had experience with. Playing with functional programming techniques taught me a great deal about procedural and OOP. Reading K&R improved my Perl. Studying a couple of Java/J2EE books had a huge influence on my web development techniques using other languages.

Think of it as travelling. I learned things about western Canada when I visited Montreal that I'd never realized in years of living in Alberta and British Columbia. Home never looked quite the same again.

Also, I would second Bart Park's note about ego. The more I learn, the less egotistical I get about what I already know (it's always less than I think it is.) Realizing this opened my mind to possibilities I hadn't considered before, because I obviously already knew it. Nope, I didn't.
dwayne Send private email
Thursday, September 01, 2005
 
 
See: http://samizdat.mines.edu/howto/HowToBeAProgrammer.html - "How to be a Programmer: A Short, Comprehensive, Personal Summary".

Thursday, September 01, 2005
 
 
If you've got C and C++ that early, you'll never have trouble with the technical end of software.

Someone (perhaps Fred Brooks?) said that the primary difficulties in developing software are not techical; they're social. It's easy to build the system, but the hard part is finding out what system to make. Dealing with your customers (hell, even identifying them sometimes) is much harder than writing code.

Become good with people; I say this knowing that I am not, and was very very bad with people when I was your age - which was not so long ago that I don't remember it. Get good at meeting people (this applies to any profession); that'll get you the good jobs.

Learn to say 'no', so you aren't stuck being exploited and working 80 hour weeks.

Learn to manage your money. There's something very satisfying about being completely secure, being able to walk if they lowball you. You're a freshman now; try setting a goal like buying a car in cash (no loan).

Get in shape and stay in shape; it's hard to do if it's not habit once you're working full-time.

I suspect this isn't what you meant when you asked about what a good programmer should know, but it's important: these are things that all successful people know, I think. A number of friends of mine would do well to learn them.
Anon to protect the guilty Send private email
Thursday, September 01, 2005
 
 
The most important thing for a good programmer to know:

Most programming is boring. Figure out which types of software development bore you (for me it's web development, and pretty much anything "enterprise", since they mostly just read and write from databases without doing any interesting analysis or computation). Once you know which types of software are boring (for you), avoid them at all costs.

Figure out a few problem domains with extremely difficult problems. I'm talking about problems that won't be solved within the next twenty or thirty years. I wrote about a few of these in this post:

http://discuss.joelonsoftware.com/default.asp?joel.3.132617.118#discussTopic133029

So pick some type of software in which you can develop an expertise and where your years of experience and domain knowledge will be eventually be extremely valuable.

If you become just another web devloper, you're going to be interchangeable with the other ninety million web developers flooding the market. But if you develop an expertise in using computer software to solve some sort of difficult problem, you'll always be marketable.

And, more important than being marketable, you'll be a lot less likely to get bored and burned out in your career if you specialize in something which truly fascinates your intellectual curiosities.
BenjiSmith Send private email
Friday, September 02, 2005
 
 
Here's one more thing.  Get good grades so that you can get into a top CS college.  It is true that CS != programming, but unless you've been reading CS books/webpages (and maybe you have, since there is much more of this information available now with the Internet...), you don't know if you like it.  Going to a good CS school gives you these advantages:

* You have a greater chance of being around other smart people
* It opens doors for working at better companies (Yes, you can do it just based on skill and writing a lot of software, but it will probably let you do something that you otherwise couldn't sometime in your life...)
* You will be less likely to be annoyed with your professors (you want to avoid having a "CS" professor that teaches a class on "JAVA"); these things don't exist in credible CS programs
* You will get opportunities to do CS research (and find out if you like it...)  You'll have a better chance of going to a good grad school (if you find that you like academia...)
* Just going to a good university in general gives you a different understanding of life than most people get.

Also, as a previous poster suggested, consider specializing in a tough area of programming or computer science (i.e. graphics, compilers, kernel programming, etc.) where your extra years of experience will be of value.  Try reading journal articles if you can just to get an idea of the most complex stuff out there (i.e. look at scholar.google.com.)  You probably won't understand it now, but eventually it should make sense.

Something else which you might want to think about is writing to famous people in a clueful way.  Young people who show a lot of initiative tend to get a lot of breaks; if you make yourself visible enough you could even get internships at top companies and startups while in high school to have a really nice career. (I'm not sure exactly how you go about doing that but I've heard that it does happen...)

I don't know if the stuff in this post would really be helpful or not, but I would have to think being exposed to a lot of stuff early would be helpful...
- Send private email
Tuesday, September 06, 2005
 
 
pointers (as in C/C++)

data structures (hashes, trees, lists and variations thereof)

objects and classes (some "programmers" are surprisingly shakey on this)

C++ because its the only language that will really punish you when you get the above points wrong, yet really reward you when you get them right.

Some other languages as well- you will probably get the job done quicker in these.

Use at least 3 contemporary desktop/server operating systems on a regular basis. Choose a flavour of each from mac, windows, linux, unix.

Be nice- its nice to be nice. People will not communicate with dickheads, and only good communicators are good programmers.

Be good at explaining comlicated things in a simple way (not simple things in a complicated way). If something seems too complicated to explain, then it needs to be broken down into simpler bits.

Actually understand what your fellow programmer, underling, boss or user is telling you. If you dont understand, make them tell you agin in a way that is understandable (see above).

Finally, and most importantly, being a programmer sucks- you need to get a new job!!

evil_one666
evil_one666
Tuesday, September 06, 2005
 
 
As another option to choosing a difficult problem or problem group and focusing there, you can choose the "business problem" group.  This means, basically, spend your time figuring out how you can give business people what they want faster and cheaper.  This has the side effect of making you a lot of money.  If the "making it faster and cheaper" part is what interests you, I certainly suggest this route.
Joshua Volz Send private email
Tuesday, September 06, 2005
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz