Have you heard of mastermind? It’s a logic game in which one player repeatedly tries determine the secret code that another player set at the beginning. With each guess, the player is given information on how many correct pegs his guess contains, and how many are in the correct position. For more details on the rules, check the wikipedia article.
I built a Clojure implementation of Mastermind as a learning project. (Code and details of functionality at github.) My primary goals were to gain familiarity with the language, and to see what the functional programming paradigm feels like when working on a project that is larger than one big function. After I finished, I re-implemented (almost) all of the features in Java for a comparison. (Code also available at github.) Interested in the results? read on.
When I was an undergraduate, it bothered me that I never finished reading any of my math textbooks. But in graduate school, I noticed that I had learned much of the content of some of those unfinished chapters, and the content that was still mysterious seemed far less central to the subject than it had previously.
Using a textbook or a technical book is like using a highway: To get where you want to go, you need to find the right exit. The end isn’t a real goal, and it likely isn’t that interesting, anyway.
How do you know when to exit? Know where you want to go. If your goals are very specific, this is trivial, and you can use the book as a reference, rather than reading. But if you are learning completely new technologies or concepts, it is sometimes hard to know where exactly you hope to go, but I find the following techniques useful:
- Read from a combination of sources: one or two books, along with tutorials and blog posts.
- Combine the book learning with a toy project.
- Pay attention to your progress — finding the material too difficult could be an indication that this isn’t what you most need to learn right now, or that it is poorly written.
- Talk (you know, face-to-face) with others that have similar goals
If you start with a goal, and continue to adjust your course appropriately, you make much progress with books, they will often take you within miles of your destination. But if you confuse the books with the goal, you can go the entire length of I-95 without seeing anything more interesting than some roadside attractions.
So you’ve been studying computer science or a related field, and you are hoping to get a job as a programmer when you graduate. You do your best to keep a good GPA, and you are planning on applying to some internships. Maybe you have some hobby projects that you are working on to augment your resume.
But there’s another important part of the job-seeking process. The career services all tell you that networking is important, that you should “network” with professionals in your field, and develop those all-important contacts that lead to interviews and jobs. I’d guess that 90% of aspiring programmers make no effort to build a professional network before graduation, and that 90% of those that do try are completely ineffective. After all, if you enjoyed talking to strangers and building relationships, you wouldn’t be a computer science major, right?
Building a professional networking is actually not that difficult, it just looks very different from your imagination. Read the rest of this entry »
As a programmer at a fast growing start-up, I’ve been able to gain a bit of experience on the other side of the table. I’m not a hiring manager or a recruiter, I don’t choose which resumes to call or negotiate salary and benefits. My part is the technical screening.
Some technical interviews obvious successes, and many others are obvious failures. But there are many that are muddled and hard to interpret, often in ways that were preventable. Read on for my thoughts on how you can make the best of the technical interview.
Sometimes you need to pass around a function. In Java, since “Everything Is An Object”, you make a class, and define the function as a method in that class. Of course, you need a separate source files for this, since you want this class to be public.
Before long, you find that in a different situation, you want to pass a different function, so you make an interface, another class, and make both classes extend the interface. Now the two functions that would have logically fit in some already existing file have generated three source files.
Does it have to be this way? It’s a lesser known fact that in Python, everything is an object. A function is an object, a class is an object, a module is an object. But somehow, a commitment to everything being an object didn’t lead Guido to conclude that everything should have it’s own class file. Somehow “Everything Is An Object” doesn’t imply (in Python or Ruby) that functions must be defined in classes.
I’ve been using Spring with Java, and that is certainly preferable to me than Java without Spring, for medium or large projects. But it strikes me that much of what Spring helps me manage is the simple fact that I need many functions available in situations where I don’t want to instantiate an object first. When I use Spring to inject a singleton object, often what I really want is a handful of related, stateless functions. I would guess that about well over half of the classes in my projects are essentially one of two things: glorified namespaces or data types without behavior.
More to the point, as I build complex applications, I fear that building them in Java significantly adds to the complexity. I fear that I’m building in a way that requires some acclimation to a handful of patterns and a framework that ultimately shift the complexity of the problem to a different sort of complexity. It seems that this is the best that the Java world allows: familiar patterns of complexity.
So what’s a Java developer to do? Where to go from here? Read the rest of this entry »
I’ve enjoyed building a Naive Bayes classifier to classify user submitted content at Manta. I wrote a post about how one might implement this on Manta’s engineering blog. I’m giving a colloquium on this at Wittenberg University today, and the slides to that talk are available after the jump. Read the rest of this entry »
One of the mantras of the Agile community is that you do “the simplest thing that could possibly work.” As I tried to follow this maxim when launching two personal projects (a batch job that sends tweets, and a web application for home use) I found myself wishing that I had done more. Such as: