Doorstop

Hi Wil,

I’m sure you’ve noticed by now that reddit has found your Open Letter website and the peanut gallery is chattering away. Take their comments with a large grain of salt and skepticism, but I would encourage you to read through and try to pick out some constructive bits of criticism from all the noise.  I know reading personal criticisms and attacks can be difficult, and I also know that being unemployed can be emotionally taxing, even depressing. After graduating Cal EECS in 2000 I worked for a small startup for just under a year before it went out of business (like 90% of them did at that time), and I ended up being unemployed for a few months. It was hard. I got depressed.  I started to feel like there was something wrong with me. I also went through a lot of frustration — I knew I was a good software engineer, and that anybody would be able to see that if they’d just give me a chance, but I couldn’t get my foot in the door. I’m good in interviews, but I had to get a callback first. I spent a lot of time sending resumes to job ads and just hearing nothing in return.

I have a couple of specific pieces of advice for you after reading your letter and your resume. I hope I can phrase my recommendations constructively. I’ll start with the easy one:

First, on your resume: put the most interesting/valuable things first. I don’t know what AMPL is (even though there’s a good chance I may have used it in IEOR 162 or something). Put it last or leave it off. Sort everything by relevance, not alphabetically.

Second, I’d take down the letter. You may want to replace it with a sort of cover letter that presents your own strengths, not your perceived weaknesses in the hiring decisions of the companies you’ve applied to. Try to put yourself in the mindset of a prospective employer, and think about what they would want to see. This perspective can be hard without having been on the other side of the interview table. Speaking from experience, for a college grad, I expect to see, first and foremost, an eagerness to learn.

I know you just kicked ass at one of the top Universities in the world, you have a great education, and you feel good about yourself. And you should — you should be proud of what you’ve accomplished, but it doesn’t end there. I was arguably a better Computer Scientist on graduation day than I am now. But since then, I’ve become a much better software engineer. This is in part due to continuing to learn new technical skills, but mostly it’s due to the experience of working with lots of different people on lots of different types of projects, and being able to learn how to effectively work in different roles on a team.

You also need to position yourself according to your strengths. Are you trying to apply as a software engineer, or as a consultant to analyze and optimize their business? If the latter, what are your relevant qualifications and experience? What’s your track record? Stick to your strengths. You should try to get hired by a company that’s looking for a good software engineer, by showing them that you are a good software engineer. Don’t try to convince a company that you understand their business better than they do and can show them how to do it better. Even if it’s true (which, to put it bluntly, is doubtful given your level of experience), it comes off sounding very arrogant.

I hope this is still constructive, and that you can gain something from it.

Good luck, and Go Bears!

Vineet

It turns out that although I’d already solved project euler problem 14, for some reason or another, I didn’t have the code stored in my git repository along with all the rest of them.

So I sat down to write some code:

collatz 1 = [1]
collatz n = n : collatz next
  where
    next | even n = n `div` 2
         | odd n  = 3 * n + 1

That was my first definition of the collatz sequence. I rewrote it using unfoldr:

collatz = unfoldr next
  where
    next 0 = Nothing
    next 1 = Just (1, 0)
    next n | even n = Just (n,  n `div` 2)
           | odd n  = Just (n, 3 * n + 1)

… which I liked a little bit better.

Then I went on to actually solving the problem: looking for the integer with the longest collatz sequence (in the range 1..1000000). Here’s a straightforward approach:

maximumBy (comparing $ length.collatz) [1..1000000]

It almost reads like English. But of course, it doesn’t actually Just Work. We get a stack overflow, since maximumBy uses a lazy foldl:

maximumBy		:: (a -> a -> Ordering) -> [a] -> a
maximumBy _ []		=  error "List.maximumBy: empty list"
maximumBy cmp xs	=  foldl1 max xs
			where
			   max x y = case cmp x y of
					GT -> x
					_  -> y

So I wrote this using the strict foldl1':

main = print $ foldl1' max $ map (length.collatz) [1..1000000]

… which runs without overflowing, but of course, it doesn’t actually return the number I’m looking for (it prints out the length of the longest sequence, not the integer that generated that sequence). But anyway, it shows the proof of concept: strict evaluation of the fold avoids the stack overflow. So I just need a strict maximumBy', which is just the same as maximumBy but uses foldl1' in place of foldl1.

So now I have a program that runs and produces the correct answer, but it takes about 90-100 seconds.

It turns out my original definiton of collatz (not using unfoldr)  brings this down to about 70 seconds. So okay, I use that instead.

Then just for kicks, I wrote this:

main = print . snd . maximum $ map ((length &&& head) . collatz) [1..1000000]

… and to my great surprise, it ran in 8 seconds! There’s clearly something going on here that I don’t understand yet, and it amounts to a 10x speed difference.

This is totally childish.

Am I the only that thinks the ascii approximation _|_ for the up tack symbol ⊥, which represents the bottom type, looks a lot like the ascii approximation for the representation of an actual bottom (_|_) ?

I warned you.

There are many rumors circulating on various message boards today analyzing the last scene of the Sopranos, in vain attempts to piece together clues to figure out the “real” ending. After just re-watching it on my Tivo, there are a couple that can be put to rest:

1. Myth: When he’s sitting in the booth, Tony’s shirt is different when he enters the restaurant. Just not so. He takes off his jacket, but the shirt’s the same. You can see the same black collar when he pauses in the doorway.
2. Myth: The mysterious man that enters with AJ and sits at the counter is Nikki Leotardo. No, there’s no Nikki Leotardo in the credits. The credit for this man is “Paolo Colandrea, Man in Members Only Jacket.” Colandrea doesn’t have any credits in any previous Sopranos episode.

James Thomas suggests Rootly as an alternative to Google News in his life without google. His recommendation makes it sound good, but we all know how important first impressions are. Here was mine:

Compare this to google news, where the first thing you see is … news! Can you find the news in the rootly screenshot? (Hint: did you check that thin little strip above the horizontal scroll bar?)

I’ll continue to give it a try, but I already get the feeling that I’m not a very important customer because my screen isn’t wide enough, or I’m not using their favorite browser, or something.

Billy Newport complains that he can find code to do what he wants freely and easily on the Internet, but that he doesn’t want to have to go through the hassle of actually getting permission to incorporate it into an IBM product. He goes on to say that open source software doesn’t increase programmer productivity, because he can’t find code that he can use for his employer without any strings attached.

Open source code does increase programmer productivity within the open source community. If you go ahead and write the data structure code for IBM, then IBM owns it, and nobody but IBM reaps the rewards. Viral open source licenses give the open source community the same advantages. When I distribute code licensed under the GPL, the open source community reaps the rewards. It’s a feature, not a bug, that IBM can’t use this code without playing by the same rules. I, for one, would love to see IBM[*] gaining the rewards of participating in the open source community. This doesn’t mean taking what you want from the community without giving anything back (nor does it mean whining about what the community won’t give you for free).

If IBM wants the software, they can either build it or license it. Whining about it doesn’t change those options. The fact that the Internet provides an accessible software marketplace with plenty of code under a variety of licenses doesn’t change those options. You can either build it or license it. The references to Apache and GNU licenses in the original article are really just passive-aggressive FUD. If you find code you want, but you can’t agree to license terms with that code’s owners, then you either keep shopping for code you want to license or decide to build it yourself.

[*] I am aware that IBM does participate in the community. I’m responding specifically to Billy’s post, in which he assumes the role of a “commercial” entity himself, and says the GPL and LGPL are useless.

I started tinkering with Haskell a bit. In particular, I’m working through some of the Project Euler challenge problems. I’ve read some vague promises like “Haskell’s lazy evaluation gives you caching for free.” I’m still trying to figure out exactly what the scope of that is. For example, I’ve written some purely functional code:

factors n = factors' 2 n
  where
    factors' k n | k*k > n        = [1]
                 | n `mod` k == 0 = k : n `div` k : factors' (k+1) n
                 | otherwise      = factors' (k+1) n
d = sum . factors
pairs n = [x | x <- [1..n], d x /= n, d (d x) == n]

Same inputs gives the same outputs. (This is for problem 21, the amicable pairs.) But if I change this:

main = do
    print $ sum $ pairs 10000

to this:

main = do
    print $ pairs 10000
    print $ pairs 10000
    print $ sum $ pairs 10000

it takes 3 times as long to run, and it’s clear as I watch it print out each list as it computes it that it’s not caching these intermediate results anywhere, and is in fact recomputing them.

I have seen Haskell’s lazy computation of infinite streams and implicit caching associated there at work, and it’s cool. So maybe I need to take a different approach: say rather than defining d and pairs as functions here, I should instead be constructing them up as infinite lists instead.

OK, I tried it like this:

amicable =  filter (\n -> (d n /= n) &&  (d (d n) == n)) [1..]

main = do
	print $ takeWhile (<10000) amicable
	print $ takeWhile (<10000) amicable
	print $ sum $ takeWhile (<10000) amicable

And now it’s clearly not recomputing the amicable stream. So it’s caching, but I wouldn’t call it “for free”. Admittedly, adding in the cache was dead simple, but really it’s the equivalent of implementing memoization as in any language, so saying “Haskell ‘gives’ it to me” is a bit much.

Also, I’m just getting started with Haskell; I could just be doing something entirely wrong here. Maybe there is a way to have it cache function results in addition to this list memoization, or maybe it is caching but I need to tune my cache parameters to make it more useful.