Maximum PC

We are not getting into a pissing contest in this thread or in this folder. Period. Consider that a not-so-veiled warning.

Yea Jip, I agree with you.

Look, Gadget, I was just yanking your chain about LISP. Don't make it a hill to die on. It ain't worth it, dude.

Re-reading his comment, I've still got no clue why you got upset .. he certainly wasn't .. anyway .. back to the thread at hand ..

Oh, I wasn't upset at all. Gadget's comments, however, were very condescending and sounded like the usual stuff heard from someone who has had very little experience with software commercial development. I don't have religion about programming languages; all I care about is what works for what I need to accomplish. My original response was a bit too mean-spirited on reflection, so I deleted it.

He is an academic ... but knowing Gadget as I do, if you read 'condescending' into his post, you put it there.

Unfortunately, I don't know Gadget and I can only go by what he writes in the context of what was said in the thread.

In terms of ADTs, it is a Dictionary (key/value pairs), but it also needs to be capable of displaying the keys in sorted order. I don't want to have to scan 500+ keys whenever something goes wrong. I realize that you can do this in Java using a SortedHashMap (and I wouldn't be surprised if C++ has a similiar ADT -- that is no doubt far uglier -- LOL).*

Of course, the problem with using a hash table is that you cannot have duplicate keys. and song writers being somewhat abstract in their thinking, probably didn't take this into account when naming their songs. We'll just pretend that all of the keys are unique.

Anyways, I was trying to show how expressive LISP can be compared to many languages. When I was writing the initial code, I didn't think far enough in advance to realize that I would need to see the keys in sorted order later on . At this point, you would either have to rewrite your initial code to use a different ADT (and probably recompile the code) or write some additional code to sort the list of lists. Keeping in mind that you tend to work from an interpretor in Lisp, I decided to sort the list...



One line of code -- it literally took less than one minute! Of course, I could have done the same thing in Java, but it would have taken at least three or four minutes. Of course, if I had been working in Java, I wouldn't have used an a-list. The point is that Lisp is a really expressive language. You can get stuff done with it.

Don't fear Lisp. I feared it in college. You should learn from me and befriend Lisp instead.


* NOTE: Common Lisp has hash tables and other data structures available. A lot of people seem to have the mistaken notion that the only ADT available in CL is a list, which is completely wrong. I would highly recommend that all intermediate plus level programmers spend some time using Lisp. You can get CL books off Amazon for really cheap or just read Practical Common Lisp online (free!). After using Lisp for a little while, you really start to see where a lot of the features in modern languages actually came from. Just my 2 cents.

I didn't even see what you had written... don't worry about it. No biggie. =)

Thanks...

I'm not worried either. Everything's cool.

Ah, I didn't see this post before. Anyways, I didn't mean to come across as condescending. Sorry if it gave offense to anyone.

As Jipstyle eluded, I am a bit of an academic, which is to say, that I've had the good fortune to work extensively with a couple of great professors while completing "Uni"*; however, I also have six years of full-time commercial software development under my belt now. Most of it obtained while working for Boeing Satellite Systems.

Now this part MAY sound condescending to some people (but again, I'm not trying to be offense -- this is just my take on "industry"). I don't think that "industry experience" is all that a big a deal UNLESS you happen to be fortunate enough to work with some great people on great projects. I know a lot of people with commercial software experience; I know very few people that have been fortunate in this regard. One of the professors that I've work with quit a Summer internship at a very recognizable software company after two days because he felt like he was wasting his time. Of course, he was finishing a PhD at Cornell at the time.

Personally, I feel that I would be a better programmer and computer scientist today if I HADN'T gone into industry. Of course, I wouldn't be as wealthy as I am now either (not that I'm wealthy by any stretch of the imagination, just less wealthy!). In academia, you tend to work on small, but very hard problems, some of which have no known solution. In industry, most of your time is spent working on big, dumb problems (when you're not dealing with office politics, meetings, and the other BS that somehow manages to consume a large chunk of your time).

A glaring example of this is a friend of mine who spends 80% of his time parsing oodles of word docs written by a bunch of systems engineers then shoving this data into a Sybase database. As you can imagine, nothing good comes out of spending your days parsing word docs.

OTOH, being paid to program (even if it is dumb work) is a pretty cool thing too. Life is full of trade offs.

Perhaps, we should move this to a separate thread.

* I take that back -- I'll probably never "complete" uni. =)

Because a picture, or series of pictures, is often worth more than an array of words: LINK

We have different ways of looking at software development. I can be a bit abrasive sometimes. Hence, my user name!

I know what you mean by big and dumb projects. I would go crazy with a regular 8 to 5, Monday through Friday type of programming job.

Since I'm an independent contractor focused on entrepreneurial ventures, the kind of stuff I work on has usually been both large and difficult. Most every project I have developed in the past has been fun (game company) or it has been never-before-attempted sorts of things. I have had the good fortune of doing challenging work that can also be lucrative. My latest project is a very interesting web application that has been in development for the past three years (and there’s nothing like it out there as of yet).

My point is this: Don't sell yourself short. You can have the challenge of university work as well as the big payday. But it does require you to take more financial risk.

Personally, I feel the other way around. I wouldn't be where I am if I hadn't gone into the industry. Then again, I had the opportunity to work with great people on big projects.

I wouldn't necessarily say that it's all big dumb projects, sometimes you can get lucky and get a pretty unique problem domain. However, I enjoy working on projects that have fiscal benefits; be it small or large, dumb or not. My academic friends aren't worried about unit testing their work, but to me, there's no sense in researching languages or algorithms if, when they're implemented, aren't tested or degrade the quality of work.

Though the one place, I would say, where academia and industry meet is finance. Listening to my friends in that industry, I get to hear their stories of how various algorithms and their implementation details have profound effects in how their systems react to trades. Sometimes, the difference of 1ms can offset the actual trade by thousands of dollars. They have to produce code that's not only fast but also testable and accountable, to me that's always the challenge. Though I work in healthcare, that's one of my personal challenges: how can I structure code so that it's functional, accountable, traceable and testable?

<rant> =)


I should say that it hasn't been all bad. During the past five years (omg, how time flies!!!), I've worked on probably five or six new projects and helped with the maintenance of probably about the same number for three different teams. The cool part was that each of these teams was a different size and had different types of problems. The first team was small and (surprisingly) I had a good boss when I first started working for them. The programmers sucked. The upside that I was given a green light to develop two new projects in my first year and a half (with minimal technical supervision -- hours and hours of stupid meetings though).

Later, I was transitioned to a larger team with "more difficult" problems (ie bigger maintenance messes to clean up -- gotta love Unix). The shocker for me was that the small team was actually better in many ways. The technical leadership of the larger team made brain dead dumb decisions like writing their own XML parser in C, used zillions of environment variables (literally, 50+) because they were to incompetent to parse a configuration file, etc. And to top it off, you would never be allowed to go in and replace retarded code with this group because (1) you faced all of the usual politics and pettiness (what do you mean the xml parser is broken... the other team shouldn't have changed their "xml file format" type of stupidity), and (2) you actually had quite a bit of government oversight which meant that any changes had to go through various reviews and must be explained and... basically, it would make the leads and managers look dumb.

After five years in industry, I can honestly say that I didn't learn one thing that I didn't know starting out (although I did teach myself Java Reflection, but I was already familiar with the concept of "meta-programming" from Lisp). Certainly, I did work more on types of projects that I wouldn't have done normally (web programming, apps in C, etc) and used tools that I wouldn't have used normally (eg JBuilder and other assorted relics), but I can honestly say that I haven't learned one thing in terms of computer science. I was pretty astonished at the general level of incompetence at even a Fortune 20 size company. While some of the people that I've worked with in academia have been terrifyingly smart, none of the people in industry ever impressed me (nor my buddy Andrew who is starting a phd this year). Maybe I've just been lucky in that regard at USC and other people have found their professors or research labs to be less interesting.



The thing that surprised me about industry, especially with current "sexiness" of unit testing, is that NOBODY had written a single unit test in any of the groups that I worked. Plus, most of the people that I've talked to about it at other companies don't either (minus a couple of exceptions one and Sun and two at Google)!

Here is my unit testing hypothesis. I believe that people who come from better computer science departments (ie really study algorithms, language theory, compilers and have to write lots of hard code -- or paid the proverbial pound of flesh at some point) tend to gravitate toward writing automated unit tests. They've had to use them and seen the light.

While those people that come from the "dark side" (ie software engineering) like to write documents... design docs, req docs, testing docs, maintenance docs, process development docs, on and on... they write more than Mark Twain ever did. However, they never write unit tests because that is "code" and unit testing is not regression testing or integration testing, etc. They just don't get it, and somehow, they've been brainwashed into believing that writing a "test plan" in Word is actually a useful thing for stamping out bugs.

I always write unit tests. I have to for my academic projects because that programming tends to be hard. I'd rather spend a few "easy" minutes writing unit tests than an hour in a debugger doing the wtf thing. At work, most of the code is relatively easy, but I write unit tests anyways as a form of proof that "my code" works. There have been a number of occasions where someone has made filed a bad bug report concerning my code and I've been able to refute it with existing unit tests. SCR rejected! =)


Funny that you should mention that... I don't want to jinx anything, so I'm going to stay mum on the finance stuff for now.

Actually, I think that academia and industry meet in a number of places (eg research labs, startup companies, etc). The problem is that the vast majority of industry positions have changed from being the domain of a few highly accomplished, mathematically/technically inclined people, towards something more akin to the "army of programmers" engineering model, and unfortunately, academia has given in to this mentality. Everything seems to be dumbed to down to the level of middle management now. For example, one of the groups that "interviewed" me at Boeing had never even heard of Lisp. There were three managers (all former software guys) and four developers and NOT ONE OF THEM HAD HEARD OF LISP*!!!!! Not surprisingly, the program was $80 billion dollars over budget and cut early last year (FCS). Anyways...

* I didn't bring it up; They were reading my resume. At Boeing, your constantly being shuffled around from one small group to another and you "interview" for each one. I've probably spent 10 hours in "interviews" during the past two or three years and I don't think that I've been asked more than three technical questions -- total.

I believe that you'll always have ideas coming out of academia being implemented in industry -- IBM, Google and Akamai are three examples among many more where a new company basically formed around a new algorithm. As Gates has noted, most modern businesses don't have a long enough time horizon to really work on something akin to what the Wright brothers did. IMHO, academia fills that niche. You have startup companies springing up out of the big university labs -- Symbolics in the 80s, Sun in the 90s, iRobot in the 00s (among several other companies and industries). The established research labs at major companies continue to work on interesting new stuff. Academia and industry certainly have overlapping shared interests, but it really is the exception for most jobs. Of course, big companies eventually buy these smaller companies and kill the culture, but this is another story.


That's pretty cool. It sounds like you are still allowed to do the "right thing" as opposed to the "worse is better" thing that started with Unix. See my next post in a bit.

</rant>

My buddy Andrew call which reminded me of something. Keep in mind, we're both huge nerds (although he's jealous because I have an older edition of The Art of Programming and have met more Turing award winners -- LOL). Anyways, one day we were riding up in the elevator and two groups of guys that we didn't know get in with us. One of them says, "we'd like for your tool to tell us when one of our programs is going to error AND tell us how to fix it."

We just about couldn't contain ourselves. Basically, they were hoping to solve the halting problem (or at least a variation of it... it's been a number of years) AND they wanted to go a bit further and actually offer a solution after detecting the reason for a halt. Really, they had NO IDEA... and I wouldn't be surprised if their boss green-lighted their idea thinking he was going places. =)

Actually, I'm moving in that direction as we speak... one of the things I've always hated is having to maintain someones craptastic code. One of the nice things about consulting is that you tend to get in and out, not stuck in the maintenance mess. =)

A couple of comments...

Unit testing isn't the be-all-end-all of testing. Test documents and test plans do have a real place in the world. I personally can't stand making them or following them, but they serve a purpose.

LISP is not the be-all-end-all either. Who cares if those people at Boeing haven't heard of LISP? You make it sound like their lack of LISP knowledge is the reason for the project being over budget and canceled. I hope you weren't saying that but it read that way. It is ridiculous to think that it would be a deal breaker.

Most Aerospace companies work that way. It makes sense, but they should spend more time with the technical stuff. I think it is actually a good way to keep your employees fresh and productive by giving them constant new challenges.

Heh. This is the first thread I have seen that was brought back from the dead twice.

You also make more money while working.

I'm working half as many hours as I was in February and bringing in slightly more money in total. If I worked full time, I'd double my income. However, the sun is shining, the rock is dry and I'm taking advantage of the ability to climb during the week when no one else is about.