Me: Thanks so much for your fix to my issue. My friend, who majors in business, once told me that I should no longer major in Computer Science because “programming is like banging your head against the wall repeatedly, but with less reward.” I find that to be a rather rash dramatization, but I know in dealing with bugs as subtle as these it may feel that way. I hope at least the end-result is rewarding for you.
Programmer: Are you a Computer Science major? If so, don’t let your friend discourage you. Just ask him about “head banging” when those business majors find that their product development and marketing efforts fail to work after spending millions of dollars.
Me: Yes, I’m a CS major. And you’re right — the reward is great in software, and the cost of building an useful product is relatively minimal. That is one of the reasons I chose this path. It’s why I love helping out honest, intelligent developers such as yourself in any way I can. I have found that hardworking CS majors who are not only better programmers, but more often than not better thinkers and better managers — if you’d give them the chance. I am happy in my decision, and still have that naivete that perhaps I can change the industry a bit, shake things up, come up with an idea that changes everything, innovate in whatever way I can. Big aspirations; we’ll see what happens. For now, I’ll just keep respecting the good software I find in the world, such as yours.
It’s hard to find me gushing more unapologetically than when I talk about the virtues of my favorite programming language, Python.
Indeed, my life for the last 3 years has been dominated by the language. In many ways, pursuing a startup and enduring the associated financial hardship was partially because I had become frustrated with using Java in my full-time work and wanted to convert hobby projects I was building outside of work hours into full-fledged projects.
And, sadly, our top engineering graduates don’t always become engineers. They move into finance or management consulting — both of which pay far higher salaries than engineering. I have seen the dilemma that my engineering students at at Duke University have faced. Do they take a job in civil engineering that pays $70,000, or join big Wall Street financial firm and make $120,000? With the hefty student loans that hang over their heads, most have made the financially sensible decision. In some years, half of our graduates have ended up taking jobs outside of engineering. Instead of developing new types of medical devices, renewable energy sources and ways to sustain the environment, my most brilliant students are designing new ways to help our investment banks engineer the financial system.
[…] We also need to make the engineering profession “cool” again, with the same sense of excitement and urgency in engineering and science that we saw during the Sputnik days. Back then, engineering was considered essential to the nation’s survival. Engineers and scientists were national heroes. It’s not that we don’t have problems to solve. The economy is in dire straits. Natural resources such as food, water, and crude oil are becoming scarce. Drug-resistant bacteria threaten us with doomsday plagues. But we’re not offering our best minds incentive to solve them.
Luckily this is happening already in high tech in NYC, thanks to awesome programs like HackNY and collabraCode (both of which my startup Parse.ly formally supported). As much as it pains me to say it, I also think The Social Network may be seen as a cultural catalyst for software engineers becoming “cool”.
But high tech is only a small piece of the puzzle — we need the same active marketing for students’ minds in biotech, education, medical research, civil engineering, etc.
The programmer, like the poet, works only slightly removed from pure thought-stuff. He builds castles in the air, from air, creating by exertion of the imagination. Few media of creation are so flexible, so easy to polish and rework, so readily capable of realizing grand conceptual structures. Yet the program construct, unlike the poet’s words, is real in the sense that it moves and works, producing visible outputs separate from the construct itself. It prints results, draws pictures, produces sounds, moves arms. The magic of myth and legend has come true in our time. One types the correct incantation on a keyboard, and a display screen comes to life, showing things that never were nor could be. … The computer resembles the magic of legend in this respect, too. If one character, one pause, of the incantation is not strictly in proper form, the magic doesn’t work. Human beings are not accustomed to being perfect, an few areas of human activity demand it. Adjusting to the requirement for perfection is, I think, the most difficult part of learning to program.
Frederick Brooks, author of the The Mythical Man-Month, disinguished between two problems in software development: the accidental problems and the essential ones. (Read Brooks’ watershed article, “The Silver Bullet“.) The industry likes to argue that we have made huge leaps in terms of the accidental in recent years. Programmer productivity is better with the help of better software revision systems, but more importantly there are RAD tools like GUI designers, powerful IDEs like Eclipse/VS.NET. Do I think we’re headed in the right direction?
In a sense. I think those tools are useful, but only because I think all we can do is shrink the accidental problem as small as possible, and then do our best to tackle the essential. The major win in terms of the accidental and even the essential is high-level programming, and I mean really high level, like Python. Why is this important? Well, Brooks once talked about how PL/I was a great software engineering language because the statements written to the compiler are “pretty close” to the “thought stuff” the programmer is working with in his head. But PL/I is nowhere near there (neither is C++, or even Java or C#). However, Python heads in that direction.
In my head, unless I really am immersed in C code all the time, I don’t think of things like types, memory management, or, God, pointer arithmetic. When we solve problems, we solve it in something computer scientists have used for years: pseudocode. Pseudocode is nothing more than code that expresses an algorithm or approach without worrying about the gory details of the underlying hardware.
Python isn’t quite pseudocode, but it’s closer than anything else I’ve seen. And that’s a huge help to productivity not just from the point of view of the single developer, but, I’d argue, also from the point of view of a team of developers. Code readability is hugely important in team environments. C and Perl can be very unreadable, which makes them ill-suited to team development. Java and C++ are better, but even they suffer from some readability problems (where the actual solutions can be masked by “best practices” and strange ways of exploiting constructs of the language). Python can be hacked too, but it tends not to be, and it tends to have very high readability.
But what about the tools mentioned above (Eclipse/VS.NET)? I often wondered about all the *nix programmers (including many of my Computer Science professors) who still load up X11 and dump into vim or emacs for their programming needs. Wouldn’t they benefit from the latest and greatest in IntelliSense, Refactoring, CallTips, SaneOnlineDocumentation, and any other CamelCase ideas I can think of for a development environment? Most *nix users would say that stuff is unnecessary–and in many senses, they are right. The essential problem remains, no matter how fancy your IDE is.
A lot of *nix developers shrink their accidental problem on a “as-needed” basis, by coding plugins or complex configurations for their highly-extensible text editors. But nowadays, productivity is starting to be a concern even in the OSS world, where things have traditionally stuck with the old “mortar and pestle,” or, should I say, “gcc and gdb”. That’s why we see projects like Mono gaining a lot of popularity.
But Python offers a nice, alternative path, I think. The accidental problem is worth shrinking, and I think it can be done simply by one major refocus:
(1) make the language usable, not the tool. (IMO, already done with Python)
(2) create source code analyzing tools that integrate with development environments to make the language-bearer more productive.
You can see enormous success in (2) with the Eclipse IDE project. My main problem: Eclipse’s focus is on a language that isn’t very usable. Java is certainly better than C, but still, it has significant problems that stop it from connecting me (the programmer) with my problem-solving ideas (the thought-stuff of programming).
At my new job, I work with Java eight hours a day, but my code just doesn’t read and work like my Python code, which is much closer to the underlying algorithms and approaches. Java certainly pushed forward OO on the masses of computer programmers, but it did so without learning non-OO but very handy scripting language concepts, like having Lists and Hashes be built-in types, with tons of syntactic sugar, for crying out loud. Most problems break down to List and Hash problems, after all. What’s more, OO on its own isn’t a panacea: I’ve seen many convoluted OO designs that I wish were written procedurally, and which might have been more performant if they had been. The software engineering community thinks that there will be a silver bullet (OOP! AOP! XP! MDE!), but I think just getting programmers closer to the “thought-stuff” will be an effort with better rewards.
Sak and I were recently discussing how upset (read: envious, depressed about our own lives) we were about The Facebook seeking $2 billion.
The main reason we’re depressed is because, though both Sak and I like the Facebook and are users, we can’t help noticing one thing:
It’s not that complicated to build a website like that.
Now, we know that business opportunities don’t have to be complicated to make money. They just have to be Right, that is in the Right place, with the Right look, taking advantage of the Right fad, etc.
But doesn’t it seem to you that a straightforward PHP/MySQL application just isn’t worth $2 billion? I mean, that’s $2,000 million. That’s $2,000,000,000.
Yet, I can’t say I’m entirely unhappy about it. Mark Zuckerberg, here’s to you, man. You’re my age, and you did exactly what I wish I had done. Built some crappy website, and made out like a bandit with sacks of cash. Kudos. You’re honestly my fucking hero.
I read this response to an article at eWeek on Bill Gates’ views about Computer Science research, graduates, spending, and company strategies.
I think it’s pretty clear that despite the disagreements I have with Mr. Gates over a subject known as “business ethics” (if such a subject truly exists!), he does seem to be a genuinely patriotic guy who loves technology. I mean, what good is it for more Americans to get into CS, if other countries are diving in and filling whatever knowledge gap may exist? Can’t Bill just hire those workers, and what’s more, for less money per hour?
Well, I think Mr. Gates really wants innovation in computer software to remain “America’s Great Industry.”
I was very intrigued by this response to the article:
Everyone knows that Open Source is taking over the software development industry. And according to the Open Source philosophy; developers should be enslaved, source code should be free. No, no, that’s not politically correct, let me try again. Developers should give their work away because code needs to be free (as in speech) and the needs of the code is more important than the needs of the people who create it. Well, that doesn’t sound quite right either but in any case, it doesn’t really matter to me because my kids won’t be studying computer science.
This is a very interesting post. True, it will be seen as a troll by some, since open source philosophy definitely doesn’t say anything about programmer enslavement. But his point is real and felt in the industry. That is, if you aren’t selling software, how are software developers to make money from it?
I think the response to this was best-articulated by Eric Raymond, when he pointed out that of programmers, only about 1-2% make their cash from off-the-shelf software sales. Instead, most make their money from “in-house” or “custom” software solutions. In other words, the majority of developers aren’t working on the Adobe Photoshop team, they’re working on Acme Inc.’s payroll or issue tracking system.
I kind of love this sort of propaganda, though. Because it is all good news for me.
When I first decided to do CS, I considered the possible effect of outsourcing and other factors on my employment possibilities. I thought, what if there are no jobs when I get out of college? But I stuck with it.
Well, it turns out, everyone had a hunch similar to mine, but they were more wooed by it than I was. So everyone fled CS. And now I’m the only one left. (An exaggeration, but you get what I mean — my computer science classes are nearly empty, whereas they were packed during registration only a few years ago).
It turns out, firms are hiring more than ever before. Why? Because the dotcom bubble is over, and green-eyed imposters are getting flushed out of the industry. But the demand is still there. Software is pervasive. Everyone needs software development done. There simply isn’t anything under the sun that can’t benefit from a little software developer finesse.
You can’t have all this work done in India and China because, it turns out, people want software developers to work with customers (big surprise). They want applications which meet their sensibilities, and they want them changes when the environment changes.
I liked that Mr. Gates said the #1 thing he’s looking for is project management IT types. Funny, it’s the #1 thing I’m looking for, too. Software developers are a dime a dozen. Find me a software developer who doesn’t get nervous when you ask him a tough question, or ask him to write, in plain English, a high-level overview of the system you’re asking him to create, and you’ve got yourself someone who’s valuable.
Mark Shuttleworth has written a nice little blog post about the tools we learn through life and how we discard old tools and learn new ones.
I personally find this to be very true in my life.
I think Mark’s onto something. Changing toolsets often is definitely useful. Even though I couldn’t write full programs for you in Perl nowadays, what I do know about it (its limitations, capabilities) is definitely good enough to see when it may be the best choice for the job.
As for academic tools — very true. A lot of techniques I learned in e.g. Discrete Math, Linear Algebra were in one ear and out the other. Alas, I think the main point is to learn them once and then be able to Wikipedia them later, when needed 😉
That said, stuff I learned in my algorithms and data structures and operating systems courses have stayed with me. I think some of that stuff is just essential.
I am taking “remedial” Calculus II alongside Numerical Computing this semester. My Calc course is “remedial” in that I haven’t seen any Math over the reals for about 4 years (took Discrete Math and Linear Algebra, which both focus on integers) and this semester I am overloading on real numbers (and even complex numbers) just when I had forgotten they even existed 🙂
That said, after spending some time in the humanities (where writing quality is high) and much time in Computer Science (where literacy is defined as being able to read code), coming back to traditional math textbooks has been quite a culture shock. They are so horribly written, it really blows my mind.
So, in response to my horrible Calculus II textbook (published at NYU only for NYU classes, this book features minimal explanation and the maximum amount of notation), I have been using it only for the homework problems and using instead James Stewart’s excellent book, Calculus: Early Transcendentals for rigorous proofs of concepts (because Stewart really does present them nicely), and the lighter but infinitely more illuminating Calculus Made Easy, by Silvanus Thompson.
A somewhat controversial book, Calculus Made Easy chooses to skip the notation-laden explanations of Calculus concepts provided by typical textbooks, and opts instead of a clear, textual elucidation of core concepts in the context of their applications. The philosophy of the book is well-described by this excerpt from the Epilogue.
I think this is wonderful writing, however damning it may be:
It may be confidently assumed that when this tractate Calculus Made Easy falls into the hands of the professional mathematicians, they will (if not too lazy) rise up as one man, and damn it as being a thoroughly bad book. Of that there can be, from their point of view, no possible manner of doubt whatever. It commits several most grievous and deplorable errors.
First, it shows how ridiculously easy most of the operations of the calculus really are.
Secondly, it gives away so many trade secrets. By showing you that what one fool can do, other fools can do also, it lets you see that these mathematical swells, who pride themselves on having mastered such an awfully difficult subject as the calculus, have no such great reason to be puffed up. They like you to think how terribly difficult it is, and don’t want that superstition to be rudely dissipated.
Thirdly, among the dreadful things they will say about “So Easy” is this: that there is an utter failure on the part of the author to demonstrate with rigid and satisfactory completeness the validity of sundry methods which he has presented in simple fashion, and has even dared to use in solving problems! But why should he not? You don’t forbid the use of a watch to every person who does not know how to make one? You don’t object to the musician playing on a violin that he has not himself constructed. You don’t teach the rules of syntax to children until they have already become fluent in the use of speech. It would be equally absurd to require general rigid demonstrations to be expounded to beginners of the calculus.
One thing will the professed mathematicians say about this thoroughly bad and vicious book: that the reason why it is so easy is because the author has left out all the things that are really difficult. And the ghastly fact about this accusation is that — it is true! That is, indeed, why the book has been written — written for the legion of innocents who have hitherto been deterred from acquiring elements of the calculus by the stupid way in which its teaching is almost always presented.
I should note that my Calculus professor is actually quite good, and provides very nice explanations of complex topics, usually beginning with an elucidation of the general idea, and then going on to the formalities. But our assigned textbook is not nearly as clear, and many professors I’ve had in the past have lived entirely inside their constructed notational apparatus.
This reminds me of an old joke I heard awhile back:
A math professor begins his lecture by writing on the blackboard. He only pauses for brief moments of notational explanation, but continues writing and writing, one symbol after the other, for thirty minutes on end. He fills up six blackboards full of derivation, algebraic manipulation, and what have you. At the end, he smiles and draws the open box, indicating the completion of the proof. “Is that clear?” the professor asks. Blank stares all around.
At that point, the professor stops himself. “Oh, no, I believe I’ve made a mistake.” He then looks at the six boards of writing, and begins pointing at certain sections while nodding his head, clearly doing calculations internally. He then paces back and forth across the front of the classroom, with his head bent down and his fist to his chin. For five full minutes, he paces and nods, thinking about the proof just presented.
Then he stops pacing, looks at the students, and says, “Ah, yes, yes. It’s clear.”
Here’s an interesting read, by the way. Came as especially relevant to me, as I “rediscover” math for math’s sake.
I gave a talk last Tuesday called “Open Source Development: A Rapid Introduction.”
Here’s the blurb I sent out when I advertised the talk:
Have you wanted to work on open source projects, but just don’t know how to get started? This talk will provide the basics you need to start working on open source software the next time you sit down at your computer.
In particular, this talk will cover:
(1) A brief overview of open source development in the industry and press.
(2) The UNIX development platform. A brief and whimsical overview of the UNIX shell, its surrounding tools, and the power of shell scripting. (Useful to anyone wanting to learn more about UNIX tools.) Learn how to do in a few lines of shell script what you only thought was possible with a big, extravagant hundred- or thousand- line program, and learn why so many of the world’s best hackers hack on a *nix system.
(3) The basics you need in order to hack on open source project: how mailing lists, wikis, bugzillas, source code revision systems all come together to form an organic code management process, and how to get started using those tools and others to learn about a project and what parts need development work done. This will include a brief introduction to CVS.
(4) The last part of the talk will involve actually watching open source development in action. In particular, the speaker will checkout some code from a source repository, make a change to it, create a patchfile from that change, then track down the mailing list or bugzilla related to the project and submit the patch to the maintainer. You will actually get to see open source “in action,” and will want to do it right when you get home!
If you’re a Windows or Mac OS developer who has always wanted to learn more about *nix systems, or if you’re a developer who wants to either take his own project open source or work on existing open source projects, this talk is for you.
Of course, if you’re someone who is just interested in the concept of open source, this talk will give you an inside look at “how things get done” in this community.
This talk was at least partially inspired by Nat Friedman’s blog post, check it out here:
The talk was a general success, I think. About 12 people attended. You can see the talk in PDF or ODP formats, and you can also download the patches I wrote specifically for the talk to illustrate “open source development in action.” The patches are pretty stupid, but do illustrate the point, at least. Plus, each of the three patches served one of my own goals (hacking my CPU frequency scaler, fixing a gnome-terminal bug, and hacking galeon “for fun”), so that’s that. I think it’d be cool to give this talk again (maybe a little refined to include less basic UNIX tools and more hacking stuff) at a later date. We’ll see.
To start out at a small software firm, or to go with one of the big guys? I’m wondering myself what the right decision is, what advice I’d give someone.
On the one hand, big guys mean bigger projects, more formally managed projects, and at least from that point of view, harder “software engineering” problems.
Small firms are less formally managed, but you may be pushing some technology to the limit, rather than just providing some service (however essential it might be) to the company. It’s the software that matters, not “the System.” And you’ll probably be working with better coders. (The best coders fill up the small shops, whereas they are just diamonds in the rough at the bigger shops).
In either case, this is turning into one of those things your parents always warned you about. You know, when they say it isn’t about the company, but it’s about you and what you put into it. Just like college was. I honestly could have gotten just as much out of college with a library card and Internet connection, and lots of free time.
Now that I’m moving up to the “real world,” I keep thinking: no matter what I do, it’s gonna be my responsibility to grow my skills and knowledge, and no one else’s.
It’s definitely going to be an interesting year…