Fog Creek Software
Discussion Board




How many of you know all of this?

Devon Grey said:

<<<<<++++
Here is my opinion of what the "short list" that makes a real programmer is composed of:
-------------------------------------------------------------------------
A serious computer language (No, PHP will not do. Neither will Java or visual Basic. These are fine tools to build things with once you understand the principles that a lower-level language teaches. But they do too many things for you to allow you to truly learn what's going on.)

A nodding familarity with assembly language. (At least enough so that you understand 2's complement, use of registers, activation frames and the execution stack, and so on.)

Object-oriented design.

Complexity analysis ( O(x), o(x), theta(x), etc, including analysis of recursive functions. This is basic stuff.)

Basic data structures ( linked lists, square lists, stacks, queues, hash tables, heaps, graphs, binary trees, n-ary trees, balanced trees (AVL, red/black, etc)).

Basic algorithms (Binary search, heap- and quicksort, KMP string-matching, Dijkstra's algorithm,  reisdual flow, etc) and algorithmic principles (greedy, divide and conquer, recursion vs iteration, dynamic programming).

Discrete mathematics and combinatorics.

Finite automata.

Regular and context-free languages.

Some familiarity with computability and complexity theory.

An understanding of concurrency and synchronization (spinlocks and semaphores, the Lamport Bakery Algorithm).

Some clue how compilers work (ASTs and symbol tables, lexical, syntactic, and semantic analysis. Ideally, try writing one at least once.)
--------------------------------------------------------------------------

Nice-but-not-necessary are such things as AI basics (A* search, classifiers, optimizers and simulated annealing, etc.), microarchitecture, linear algerbra, and so on, and so on, and so on.
++++++>>>>>







I want to know:  are all of you educated thoroughly in these topics?  How motivated are you to stay up on these things if your real life doesn't require this knowledge?

(Obviously, I am of the opinion that real world software development outside of certain scientific or defense or NASA applications, you wouldn't be using more than 10% of this stuff).

bored
Tuesday, August 31, 2004

I don't know about AI or KMP string-matching, Dijkstra's algorithm or reisdual flow.

But all the rest, yes.

Sapporo
Tuesday, August 31, 2004

Oh and no I don't stay on top of advancement in it but if it comes up in a conversation I am usually interested.

Sapporo
Tuesday, August 31, 2004

>>A serious computer language
yes

>>A nodding familarity with assembly language.
a little

>>Object-oriented design.
a little, but enough to keep far away from "Design Pattern"

>>Complexity analysis ( O(x), o(x), theta(x), etc,
really a little

>>Basic data structures ( linked lists, square lists, stacks, >>queues, hash tables, heaps, graphs, binary trees, n-ary >>trees, balanced trees (AVL, red/black, etc)).
only lists, hash, stacks

>>Basic algorithms (Binary search, heap- and quicksort, >>KMP string-matching, Dijkstra's algorithm,  reisdual flow, >>etc) and algorithmic principles (greedy, divide and >>conquer, recursion vs iteration, dynamic programming).
Binary search when I am in primitive school

>>Discrete mathematics and combinatorics.
nothing

>>Finite automata.
I know there is such a word

>>Regular and context-free languages.
NO

>>Some familiarity with computability and complexity >>theory.
Not at all.


>>An understanding of concurrency and synchronization
>>(spinlocks and semaphores, the Lamport Bakery Algorithm).
NO

>>Some clue how compilers work (ASTs and symbol tables, >>lexical, syntactic, and semantic analysis. Ideally, try >>writing one at least once.)
Yes, I have written one because my boss forced me do it. I hate invent wheels


>>Nice-but-not-necessary are such things as AI basics (A* >>search, classifiers, optimizers and simulated annealing, >>etc.), microarchitecture, linear algerbra, and so on, and >>so on, and so on.
no, no,no

D2KSoft, Different and Elegant
http://www.d2ksoft.com

redguardtoo
Tuesday, August 31, 2004

Anyone knows about classic controlling theory?
especially negative feedback theory?

I think it is much useful in software development.


D2KSoft, Different and Elegant
http://www.d2ksoft.com

redguardtoo
Tuesday, August 31, 2004

I didn't study programming at school.

I know a serious computer language (if C/C++/C# count as serious), assembly, OOD, some complexity analysis (enough to understand O(nlogn), 0(n^2)), basic data structures (excluding "square" lists, and different tree-balancing implementations), not many basic algorithms, state machines, and multi-threading.

I'm motivated enough to have e.g. attempted to read the Dragon book on compilers for fun, and to have read the implementation of a little one, and to hang out with you guys and gals, but not so motivated as to have written a compiler.

I learned the above from writing telecom software.

I wish I knew more AI and mathematics (starting to work on medical signal pattern recognition).

Christopher Wells
Tuesday, August 31, 2004

well, personally, most.  That is what comes of making games on my first 286 I guess..

However, the how premise (that a shopping list of 'skill' equates to a good programmer) seems flawed to my way of thinking.

I don't think that some languages are more 'toy' than others.

I think programmers can be graded (subjectively) by peers based upon problem solving and speed.  I've met programmers who know only one language well (e.g. VB) and (I expect) would absolutely perform the pants of you at programming business systems.  And they know nothing about assembler.

How many people might learn your shopping list rote at college and never be able to actually meaningfully apply it?

If we could come up with a way of measuring capacity for understanding the items on your shopping list (as opposed to actually having already learnt them), then we'd be onto something...?

i like i
Tuesday, August 31, 2004

Basically, this is just a list of the topics that are covered in most BSCS programs.

Yet another anon
Tuesday, August 31, 2004

I would think I have most if not all of that list (apart from annealing whatever that is if its not sealing holes by ablating the medium itself), in my background, but I haven't consciously used any of it for a long while.

Personally, I'm more interested in whether people know if their trousers are secured properly and how to cross the road.  Everything else can be taught.

Simon Lucy
Tuesday, August 31, 2004

Oh, I use O-O design most days, my brain skipped that.

Simon Lucy
Tuesday, August 31, 2004

Nearly all of those (although the details on some stuff have faded through the mist of times, but should be recallable given an armchair, a fine Scotch and ample minutes).
It looks like a laundry list ofl staple ingredients of a CS degree.
What this has to do with "being a good programmer" is another question. Most fresh out-of-college CS boys are probably going to be better at those than most "programmers" with x years of experience under their belt. It is a rare case where a new CS graduate makes a good (or even moderate) programmer.

Just me (Sir to you)
Tuesday, August 31, 2004

Yes, this is just a shopping list that any moron can acquire if they go through a CS course. Having had to teach such people when they were working for me, and sometimes to fix dreadful messes, I can say that knowledge of the shopping list does not make a programmer.

On the other hand, any good programmer ( as defined and hired by me) could read about and learn whatever they wanted when they needed it.

Management material
Tuesday, August 31, 2004

I don't actually know all that lot now -- but I did learn it once...

This is part of the difference in hiring someone who went to university. When something in those lines comes up they go "Hey -- hang on, I faintly remember being taught stuff like that... I've got the course text somewhere..." instead of trying to invent their own partial solutions.

As for being able to spout it out on the spot... erm. You'd be wanting someone autistic. And they're less of a team player than you want...

Katie Lucas
Tuesday, August 31, 2004

This list would make sense if we could find out how much of it a person knew before going to college. I learned a substantial portion of it in my teens (data structures, Object Pascal, C, assembler), with a couple of friends with whom we could sit all night writing code. Then I went to study CS, and NO ONE of my classmates knew anything on this list, until it was spoon-fed into their heads.

Egor
Tuesday, August 31, 2004


A very good list of fun topics!

IMHO, point 1 should grow to include at least 2 serious languages.  A mainstream imperative language along the lines of C, C++, Java, C# plus a functional language of LISP, Haskell, ML, erlang.   

Func. PL lights up the mind for different ways of approaching the problem.  More recursion, more abstraction, shorter syntax, ...  Useful thinking skills even back in C,C++,Java, C#.

Zane
Tuesday, August 31, 2004

When people stop running off the end of arrays in C/C++, I will agree that we need to know a language like that.  Otherwise, it seems that even the best programmers make a fairly fatal mistake by picking a language that requires 100% focus on what the computer's actually doing on the board, no matter how simple what you want it to do really is.

devinmoore.com
Tuesday, August 31, 2004

Somehow, some way, I've managed to be a computer programmer for 5+ years now and I've still yet to learn C fully.  I mean, I know a bit of C++, but not enough to do Windows (beyond console) programming, and very little of that.

On a side note, it amuses me that most developers who know C seem to be utterly convinced that knowing C is absolutely necessary to understand the fundamentals of programming.  You couldn't possibly digest them ANY other way.  :)

muppet
Tuesday, August 31, 2004

Hmmm - I know C#, Java, PHP, Perl, a bit of LISP, that kind of thing. I studied most of the things there related to concurrency, algorithms, functional notations, combinatorial logic, etc. as part of the courses, as well as standard algorithms, Dijkstra's as pointed out, etc.

C and C++ I know almost nothing, but given a few weeks I dare say I could work out what was going on sufficiently to bluff my way through most things.

And that's just it really. Whenever I read questions on interviews where people are asked to reverse a linked-list in place or some such triviality, I think "there's no way i'd know what to say". I also think that's rather silly - if I had to know how to do that, i'd just look it up.

I'm a fairly reasonable programmer because i'm good at solving problems, and I know more than just the code. I study project management, systems maintenance, re-use principles, HCI, accessibility design, defensive design, and various other things. I think i'm ok not because of my technical knowledge, but because of my ability to see the bigger picture, and to come up with things that are both useful and usable.

Provided Google doesn't cease to exist, and I can still read, I don't see not knowing any of those things off the top of my head as being a big barrier.

Certainly if I was coding a 3D FPS, then i'd need to revisit ASM, etc, but for what I do? (Desktop and Web Apps) I know enough that they do get programmed efficiently.

Andrew Cherry
Tuesday, August 31, 2004

Imagine you are an employer and you get to pick one of two candidates.

The first is a new graduate with a PHD from a top university.  He has everything on Devon's list.  He is arrogant and a poor communicator.  When you ask him about GUI design he sniffs and states that the command line is adequate for any task.

The second has no degree, but a solid commercial experience.  He communicates well, shows a solid understanding of your customer's needs.  He has some demonstrations of some well design applications that are easy to use. 

He has no understaning of finite automata and has only ever programmed in Visual Basic.

Which of the two candidates do you choose?

Ged Byrne
Tuesday, August 31, 2004

I need to read sequentially. But OTOH, all you angel- counters should look at the outside world and relate the relevance of software stress analysis to miles per gallon.

IMHO, the market exhalts mpg. Not a bad thing given the oil outlook. So how many of you software dudes consider (SAY) thinness of cylinder walls, is it
for a lean, clean performance machine
CHEAPER TO WARM UP UP NORTH
less cost to make
to cut out the aftermarket oversizers
or to get a paper published.

What you know doesn't map into what you do.
It's not what you know, it's who you know. (Go ask Dick.
)

trollop
Tuesday, August 31, 2004

Whichever one gives the lesser salary requirement with their resume.

muppet
Tuesday, August 31, 2004

Dick is available until November

trollop
Tuesday, August 31, 2004

Trollop, have you been eating seeds today, dude?  Your second to last post in this thread is completely unintelligible.

muppet
Tuesday, August 31, 2004

>>C and C++ I know almost nothing, but given a few weeks I dare say I could work out what was going on sufficiently to bluff my way through most things.

What about template, maybe you will have a little difficulty to learn it.

Now I know my love for C++ possibly makes me prejudiced.

So please make your own judgement on what I will say.

Some popular language is not designed diligently. So it has some limitation on the the language user. thus the language users lack some design techniques(maybe the language users donot realize the fact). If the user are still statisfied with the language , maybe he (or she ) just doesnot meet the truly difficulty problem in the real world.

I am not going to start a language war.
so just let me give an example.

In a real problem, I will share some data between two *processes*. Since this is a big commercial project, it is important for me to encapsulate the data in a class and the class have to utilize polymorphism.

I cannot use dynamical-polymorphism (some java programmers know and only know dynamical-polymorphism) because a shared pointer is meanless between *processes*. (the essence of dynamical-polymorphism is  pointer-arithmetic, right?)

I will not use com or corba because this is a cross-platform project and as a project leader, I can not take the risk to let my project dependent some big and complicated library.

As a C++ programmer, I just use template technology to change my design from dynamical-polymorphism to static-polymorphism. Just change thirty lines, that's all.

My point is, when I meet some real difficult problems (of course, I know how to google for the free codes, free controls), I can still count on C++, the language itself,  instead of just waiting a new version of some libraries released.


redguardtoo
http://www.d2ksoft.com

redguardtoo
Tuesday, August 31, 2004

Well, these are all nice to learn, but no one ever talks about where people are supposed to learn them from. The right book? That's nice, but what would be really better is if languages supported them, so one can experiment with the ideas.

I knew state machines before, but being able to use them directly in a language made the lesson so much more powerful. I consider them a control structure, just like a for() loop. Lots of people understand iteration, but not "finite automata."

Ged's comment is relevant. People think you need a choice between some illiterate who can "git stuff dun!" and some overeducated prick who uses his pinky finger way too damn much.

One of those last things you mention, simulated annealing, is not a hard concept and has a cute story behind it. But the distance between knowing it and being able to express it is too far. People won't make the journey. And they shouldn't have to -- this is something expressible in code. All these are, without the mechanics getting in the way. People should be able to use them directly, then probe deeper as curiosity drives them.

Tayssir John Gabbour
Tuesday, August 31, 2004

I know about half that stuff, but never use much of it.

While there will always be "better" ways to do stuff, it is important to avoid the trap of premature optimization.

Nemesis
Tuesday, August 31, 2004

Hehe, I thought my comment of being able to bluff C++ in a couple of weeks would get a reaction. I'm certainly not claiming that i'd be any good, and certainly my knowledge of the STL, etc. would be pretty much crap.

But the thing is, I could reason it out from first principles if I worked hard. Which is why interview questions being in C, and never something like Java, is a mockery. The only thing worth testing for a prospective programming employee (if you can test these things) is how quickly they adapt, how quickly they pick up new ideas, how good they are at problem solving and lateral thinking, how organised they are, and how good they get on with others/fit into a team.

If I found someone who I thought was excellent on all those fronts, i'd hire them whether or not they'd ever done anything more than HTML. Someone with all those qualities is going to be much more useful to your average employer than any algorithm and structures obsessive.

Of course, if I was hiring someone to do compiler, parser and lexer design... That would be different...

Andrew Cherry
Tuesday, August 31, 2004

I think Andrew has it about right here, those are the qualities you need in a team member.

Sadly, HR departments will never be able to work in this way, as that doesn't fit into their "xx years of yy, with zz certification/qualification" mentality. They just don't get it and don't/can't add value.

My theory is to never work for a firm where they get developers to interface with the HR department.

Nemesis
Tuesday, August 31, 2004

Hi muppet, glad you're around.

I was trying to illustrate a typical design tree faced by engineers. Parallels with CS do exist. Frex, building Btrees in Fortran with Assembler for the curly bits  - reason? nothing else to hand. ow we surf and exploit & What are seeds?

go google farnarkling.

trollop
Tuesday, August 31, 2004

In response to the OP, I know pretty much everything in the list except:

> Finite automata.
Learned it in School, forgot it.

> Regular and context-free languages.
Learned it in School, forgot it.

> AI basics (A* search, classifiers, optimizers and simulated annealing, etc.)
Read some books AI books on neural nets out of interest, never used it. I don't think I know the other stuff.

Most of the stuff in the list isn't necessary to be a good engineer in most vertical markets, domain knowledge and good engineering practices are more important. There is a reason you hear way more about UML, eXtreme Programming, Unit Tests, etc than you here about AI, B-trees, Linear Algebra, etc. Its because for most programming isn't CS intensive, but any medium sized project (say 20k lines and up) quickly becomes unmanagable without good engineering practice. In other words, using good engineering practice is far more important to far more projects than propellerhead CS stuff. With the exception OO design, Devin doesn't mention anything thats meant to improve engineering practice and code maintainability. Odd.

In response to others:

I think C is an excellent langauage to learn, because nearly every popular API and OS has facilities for C. Frequently its the only way you can interface with certain APIs. Although this is slowly becoming less true as more languages adopt the ability to do C callouts and callins. Java is a notable exception, unless something is changed JNI is the only way to do C/C++ callouts/callins. C is straightforward and relatively easy to learn, once you get past pointers. In other words, learn C because it can help you get stuff done (but dear god, don't write a whole business app in it)

I wouldn't learn C++ unless you know you are going to use it. The language is way to big and archaic, and different compilers will interpret seemingly simple constructs many different ways. I'm not biased against it, I've made my living with C++ for quite sometime now, and I can say its rarely the best choice, other languages will do just fine. There are some cases where its the right choice, but unless you writing a language runtime engine, 3-d games engine or something similarly processor intensive, don't bother.

ronk!
Tuesday, August 31, 2004

I have observed  that experienced HRs are better at finding talents then engineers are.

The requirements like "xxx years of experience" are made up actually by engineers. HRs tend to be more versatile.

Many software engineers prefer to ask useless interview  questions like "do you know what is adapter patten or bridge patten?"

Thanks to those interviewers, now I got many senior software engineers as team-members who do-not-know  and alway-refuse-to-use ASSERTIONs.

I want to know how many American programmers who regard himself as qualified SE (not mentioned hacker) have ever ASSERT any code?

How many assertions one American programmer use in, for example, 200 lines of C code or java code?

I have noticed that there is no assertion in a 200,000 lines  C project (a Japanese project) .

Now I take part in a big C++ project with team members combined by  15-year-experienced consultant to several at-least-5-year-experienced American SSEs. I have read 20-30 source files and find only one assertion. I am just wondering how those people can claim they produce better  codes and better design?

redguardtoo
http://www.d2ksoft.com

redguardtoo
Tuesday, August 31, 2004

These kinds of discussions are hilarious.  Its like saying, "if you can't play Brahm and Beethoven, you aren't a real musician."  But of the first chair violin and the lead guitarist of the rock band, which one is gettin' paid and gettin' laid?

There are problems that need to be solved.  We solve them.  Customers are happy because they can do things better or faster, and we are happy because we get paid.  Now we can hang out with our families, or drive a reliable car, or lounge on the beach.  Don't need a CS degree to learn that.

Clay Whipkey
Tuesday, August 31, 2004

*These kinds of discussions are hilarious.  Its like saying, "if you can't play Brahm and Beethoven, you aren't a real musician."  But of the first chair violin and the lead guitarist of the rock band, which one is gettin' paid and gettin' laid?*

Great analogy.  I used to be a classical musician, and I majored in music my first two years of college.  All the pomp and circumstance and stuffiness got on my nerves, so I dropped it.

What attracted me to programming was/is its lack of pretense, or so I thought.  If you can do the job, you get the job.  That is less so, today, I fear.

bored
Tuesday, August 31, 2004

> Anyone knows about classic controlling theory?
> especially negative feedback theory?

You mean linear control systems? Pole zero plots and designing analog feedback control systems using rubber sheets and the black marker?

Yes, I have done that. Not relevant to digital computer work though, although I do of course use the digital counterparts a fair bit. However, in general that stuff is quite passe. There are much better techniques now for designing control systems.

Redguard, you must design missles for red china then. The last time I used that analog stuff was in guidance control systems. But mainly as a history lesson and in being able to understand some of the older hardware - things nowadays use entirely different methods completely unrelated. I've said too much already. Bye.

Sapporo
Tuesday, August 31, 2004

Sounds pretty close to my Computer Science curriculum.  6 years later I only remember the basic ideas behind a lot of that.

chris
Tuesday, August 31, 2004

I know a guy who has a degree in (classical) music.  Last I heard he was working as a delivery driver.

OffMyMeds
Tuesday, August 31, 2004

"Which of the two candidates do you choose?"

Neither.  An arrogant command-line-only snothead won't be of any use, and unless my department will be using nothing but VB for the next few years, a programmer that only knows VB (not even learned other languages in college or via self-learning) is even more useless.

NoName
Tuesday, August 31, 2004

"A serious computer language (No, PHP will not do. Neither will Java"

You've clearly never used Java - it's as much a serious language as C++ or C#.

And yes, I know all that stuff - MS Comp Sci 4.0 GPA Johns-Hopkins.

DryWell
Tuesday, August 31, 2004

I think the greatest thing I learned in school is the realization of the FACT

that there is a difference between my potential and my current skillbase.

Hear me out: coming straight out of high school, I had a programming ego ("I can do that, that's probably easy").  Coming into some incredibly difficult courses, including the project for software engineering and the project for my compiler class really instilled a weight of respect for software that I did not have in high school.

In short, less sneering in my attitude.

pds
Tuesday, August 31, 2004

>It looks like a laundry list ofl staple ingredients of a CS degree...

Yeh, I have never ever held a job as a programmer, yet I  can do all the stuff on the list everything...CS degrees are good for something....

What I lack is proficiency in it, particularly in a good language, I do use C++ sometimes, but a few programming assignments and a little bit of playing around with AI (using C++) does not really cut it.

I can see out this sort of thinking would be good to have in the repitoire though.

Aussie Chick
Wednesday, September 01, 2004

I know a guy who has a degree in (classical) music.  Last I heard he was working as a violin player.


Wednesday, September 01, 2004

*  Recent Topics

*  Fog Creek Home