4 posts tagged “cs”

Whereas Joel Spolsky thought recursion and pointers were the measure of eliteness when it came to computer programmers, Steve Yegge has chosen to be more specific, saying the real key is compilers .  I think I agree with Joel more that the fundamental theories are the key.  Steve puts too much emphasis on one facet of many in the realm of computer science application.  I took the compilers class and I understand compilers, but there's a lot of other CS out there that doesn't necessarily use compilers which still requires very good programming.

In any case, one thing they can agree on is abusive insults towards Java and Web 2.0...they are, after all, both very smart guys. ;o)  From Yegge,

Designing an effective undergrad CS degree is hard. It's no wonder so many ivy-league schools have more or less given up and turned into Java Certification shops.

If you're a conscientious CS student, you'll at least take OS and AI. You may come out without knowing exactly how compilers work, which is unfortunate, but there will be many problem domains in which you can deliver at least as much value as all the other people just like you. That's something to feel good about, or at least as good as everyone else feels at any rate.

Go team.

Most programmers these days, sadly, just want the degree. They don't care what they learn. They want a degree so they can get a job so they can pay the bills.

Most programmers gravitate towards a set of courses that can best be described as the olive-garden of computer science: the places where dumb programmers go to learn smart programmer stuff.

I hesitate to name these courses explicitly. I wouldn't be agile enough to dodge the game of graphic bloodshed aimed at me by animated, project-managing, object-oriented engineers using Java and Web 2.0 technologies to roast me via user interfaces designed rationally through teamwork and modern software methodologies. I'd become a case study in the ethics of software and its impact on our culture.

Relatively speaking, I think I've had a lot of technical interviews for such a short career.  Before joining my current company, I'm pretty sure I had at least 10 programmer related interviews, including Google (twice), IBM, Computer Sciences Corporation, two Seattle startups (BList.com and Billmonk.com), and a company that writes the embedded code that is probably streaming and decoding the digital data in your home's digital cable box as I type...

After the more challenging technical brain-bending interviews, I'm amazed at how much I actually LEARN.  Interviews have single handedly kept me from forgetting the details of big-O complexity analysis, and what the standard complexity cases are for most data structures and search types.  They have provided huge insight into the basic nature of different types of search and data-manipulation algorithms.

For example, I made the same mistake in two recursive routines of trying to carry an entire Array data structure with me, instead of marking a global structure and then peeling off the marks when the recursion rolls back up. (fixed).

I'd forgotten so much about the nature of binary trees.  I'd forgotten skip lists.  I'd forgotten exactly how to implement a Hash in C.  I don't think I'd ever known merge-sort before interviews...

The insight of how to intersect two sorted sets of integers by just reading each off the top, which I learned in my very first google phone screen, has been invaluably applicable in a number of problems...

I think toying with complexity analysis in interviews has actually taught me how to determine something is O(n*log(n)) way better than my class ever did...

My advice is to practice and interview as much as possible...don't interview at your dream job first.  Make sure to just relax, no interview is the end of the world.  Search for patterns in the nature of your solutions that you can reuse later.  And make sure you remember the simple facts that you look stupid not knowing.  (What's the complexity when searching a sorted list? O(log(n))...you get an instant F IMHO if you don't know that, and exactly why it is so).

I don't have anything against Java as a language for implementing things...

I have ruminated and ranted about Java for a while now.  Just yesterday I stumbled across a Joel on Software article that made me shout, "that's exactly what I've been saying!":  Perils of Java

For starters, Java is too easy:

The lucky kids of JavaSchools are never going to get weird segfaults trying to implement pointer-based hash tables. They're never going to go stark, raving mad trying to pack things into bits. They'll never have to get their head around how, in a purely functional program, the value of a variable never changes, and yet, it changes all the time! A paradox!

They don't need that part of the brain to get a 4.0 in major.

And the fundamentals you miss by going to a javaschool *are* important:

Now, I freely admit that programming with pointers is not needed in 90% of the code written today, and in fact, it's downright dangerous in production code. OK. That's fine. And functional programming is just not used much in practice. Agreed.

But it's still important for some of the most exciting programming jobs. Without pointers, for example, you'd never be able to work on the Linux kernel. You can't understand a line of code in Linux, or, indeed, any operating system, without really understanding pointers.

Without understanding functional programming, you can't invent MapReduce, the algorithm that makes Google so massively scalable. The terms Map and Reduce come from Lisp and functional programming. MapReduce is, in retrospect, obvious to anyone who remembers from their lisp/scheme class that purely functional programs have no side effects and are thus trivially parallelizable....

But beyond the prima-facie importance of pointers and recursion, their real value is that building big systems requires the kind of mental flexibility you get from learning about them, and the mental aptitude you need to avoid being weeded out of the courses in which they are taught. Pointers and recursion require a certain ability to reason, to think in abstractions, and, most importantly, to view a problem at several levels of abstraction simultaneously. And thus, the ability to understand pointers and recursion is directly correlated with the ability to be a great programmer.

That's a good start.  I also think the ability to understand predicate-logic based code (i.e. Prolog) is correlated with being an even greater programmer. ;o)

As an employer, Joel complains that Java is not weeding out the mediocre programmer.

For me,  find it particularly annoying when Javaschool graduates extol Java and denigrate C++ and other "old" languages as antiquated crap.  From their perspective, a devotee of a language such as Scheme is just behind the times, and not enlightened to deeper patterns in programming.

The reality is pretty much every application you rely upon on a daily basis is written in C/C++.  To give a short list:  OS, browser, outlook, word processor, photoshop/illustrator, instant-messenger, ITunes, powerpoint, acrobat...I'm just reading the list of apps currently running on my machine. ;o)

My job history is manic.  Since graduation I've had 4 jobs, all of which lasted for more than 6 months, but none of which lasted as long as a year.

With every company thus far I've found some reason or another why the company/environment upset/angered me.  Usually they'd revolve around painful exchanges with coworkers, overtime demands, or tight-fisted corporate policies that wouldn't foot the bill for a pretty LCD monitor, training program, etc.

I've watched my coworkers suffer similar abuses, and they agree it sucks, but manage to shrug it off.  I certainly have never, nor do I think I ever will, develop a sense of loyalty to what is an organization whose undoubted singular goal is to make money.  So my job choices are always selfishly my own.  If I am working somewhere it is because it is in my own best interest--I am not charitably contributing for the better of my company.  If anybody finds themselves staying put simply because they don't want to hurt the company, they may want to re-evaluate, and realize that unless legally obligated, that company will not take care of you for very long if you aren't contributing to their bottom line.

Loyalties aside, there are still good reasons not to switch jobs TOO often.  Primarily because it looks bad on the resume.  So I am trying my hardest to learn patience, and stoically sail past annoying coworkers and/or unfair corporate practices.

I just read in Newscientist about two kinds of people when it comes to decision making:  Maximizers must try every option to make sure they get the best, but they are driven nuts by never settling, whereas Sufficers settle with the first thing that seems "good enough", but may miss out on something better.

They followed college grads and found that those who were "maximizers" got 20% higher salaries in their first jobs, but were actually less happy by almost any psychological measure, because they kept fretting about what better job they may still have missed.  I am definitely a maximizer--hoping to reform to be a bit more sufficing...