Distractions, or how I learned to shut up and love the list

I hate getting distracted.  I always amaze myself when I get "in the zone" and slam out some really great code.  Unfortunately, I'm in a college dorm (one of the most distracting places in the world) with an internet connection.  What's a poor ADD kid to do with all this information overload?

I've tried lots of things.  Post-it notes, coffee, regular sleep schedules, moving to the library, giving myself too many breaks, not giving myself enough breaks (fine line there) Writing Things Down, Pomodoro, etc, etc.

There's a zillion "productivity" websites, books, what-have-you out there each claiming that they've got "the best" way to Get Things Done.  (Spoiler: they're all wrong).  One of the awesome things about us humans is that we are all different.  There's no best way.  We've all got our own way of doing stuff, from The Four Hour Workweek to coding six days a week because we're having a blast.  Thus, take my advice with a grain of salt.  This is just what works for me.

I tend more toward six days a week.  I love building stuff.  My work usually can be divided up into two categories:

Stuff I don't want to do
Sadly, this is the majority of work I've gotta do.  While it's less of a majority every passing year, there's still a whole lot of it.  The big problem is that I'll spend most of my time inventing creative ways to avoid this kind of work.  In my mind, I've got a gigantic ball of homework, errands and todo to get done.  Creating a list of some sort (my favorite style is to put each task on a Post It, that way I can tear it up when I'm done) helps me conceptualize my workload.  It's a lot more realistic when I've got everything written down.

Stuff I want to do
Coding.  Lots and lots of coding.  Also, some learning and other coding-related activities.  While this is the "fun" stuff, it's still difficult to avoid distraction.  Good coding requires good focus which requires few distractions.  The advantage here is that I can get in "the zone" once I've started.  It's much harder to start than one may think.  The trick is to keep a todo list - it's much easier to overcome my stagnation when I have a goal.  I also semi-organize my list by the size of task.  It's great to start off with a quick, easy task to get that immediate sense of accomplishment.

Once I've started, it's easier to keep going.  The cycle of success pushes me onward to achieve more.  That is, until I hit a bug.  Bugs are evil.  Some bugs are simple and are only the result of my inability to type.  Others are fiendish little things that explode into an entire afternoon lost to misconceptions and other idiosyncrasies.  As time drags on with no new progress, it becomes harder and harder to rationalize continued work.  It'd be nice if I could just "work on something else" but these sorts of bugs usually block a large segment of the project.  We'll see if this changes as our codebase grows (don't worry, we're keeping it modular).

Stuff I want to do but gets in the way of stuff I really should be doing.
Hacker News is great.  You guys have a way of promoting absolutely fascinating articles.  I just spent half an hour watching and reading about lots of 0s and 1s blowing each other up in spectacular fashion.  There's two dozen inspiring articles that hit the front page every day all of them begging to be read.

Truth be told, I only actually needed to know about .5 of these articles, maybe more depending on what stage my startup project is at.  This is where I could use some improvement.  I've got to figure out a way to limit the amount of time I spend reading blogs.

Got any suggestions?  I'd love to hear them.

Learning new things is stupid

I'm tired of learning.  I want to do something.  This may come out of the fact that I started (briefly) with Ruby, then actually got started programming with Python.  Our CS program did a rather obtuse about-face and taught us Java for two years, then had a rather abrupt plunge into PHP as I tried having a real job and finally am settling down with JavaScript.

Along the way, I've had all sorts of cool projects [0].  Most of these projects were fairly basic.  Along the way, I learned several things that were building blocks for the next "level" of project (which you'll notice is the whole basis behind my project learning model).  I jumped onto a different language before I could make that the next jump in learning.

I was forced back into the basics after every language switch.  See, learning's different at the basics.  Time spent programming is mostly time spent learning programming.  There's less time spent learning as you tackle each subsequent language but that advantage only goes so far as you've learned in the previous language.  If I spend 50% of my time learning Java while I'm "programming" and then switch to JavaScript, I'll have a speed advantage until I hit that 50% time.  Roughly.  Things like data structures and design patterns tend to stick beyond languages.

As we move from spending our time learning to building, a curious change happens.  More of the learning time is spent fixing mistakes, rather than determining how to do things the first time.  I'm only qualifying part of debugging (mistakes due to language/framework) as learning here.  For instance, Jade allows inline JS as control flow for HTML output, but the indentation's wonky.  I lost no small amount of time to this, eventually creating a StackOverflow question/answer pair so others could figure out what went wrong.

These debugging moments are different than others because of the technicalities learned.  If I spend a day because I wrote var hammerTime; instead of var hammerPants; then my time was spent learning how to code better rather than if I had misused var, which would be me learning to code.  Got it?  [1]

Alright, back on track.  Learning new things is a tedious process, not to be undertaken lightly.  Half the point of coding today is to become the person who'll want to strangle your now self.  I've written "Hello World" in everything from lisp to Java.  I'm coming very close to actually building something worthwhile.

Or at least I think so.  Every project has been worthwhile in a sense.  Sure, coming up with crummy haikus that only occasionally explode doesn't feed the hungry, but I enjoyed the project and it's provided people with some entertainment.  I certainly have created wealth, if only a small amount.

So when I say "I hate learning [the basics....again]" what am I saying?   What's this "worthwhile" project I keep pursing?  I'm beginning to believe that this project that'll actually do something is my next  project, and always will be.  I'm ok with that.

Working on a current project is absolutely fun but there's a certain dissatisfaction with a solved problem.  The dissatisfaction differs among developers as well as the definition of "solved."  Speed isn't that much of an issue to me but others may see anything as unsolved if it can go faster.  Either way, problem solving, not learning, is the priority.  The best learning happens to be a blissful side effect of the problem solving.

What I want to do is learn clever ways to do things I already know how to do, instead of the basics.  I'm tired of "solving" problems in a new way.  I want to go deeper instead of wider in the T paradigm.  Thanks to Node's help, I finally have a language to do it in.  Now, where do I start?

console.log('hello world!');

Again?!?

[0] For various levels of cool in various completed states.
[1] Yeah, there's lots of semantic games you could play with those two paragraphs for karma on Hacker News.  You could also do something productive with your life.  It's your choice.

Mitnick: Both sides of the law

[Ed: this is adapted from an essay for class, so the style might deviate from the usual]

Kevin Mitnick is a perfect example of Paul Graham's “unruly” hacker who breaks into things not out of malicious intent but simple curiosity. Or so Mitnick claims. Before he was arrested, he was the most wanted “cyber-criminal” on the FBI list. After his release, he has authored several books and become a world-famous consultant. In a recent Twitter update looking back on his incarceration, he says “Glad that nightmare is far behind me. How things have changed.” [0]

Apollo Robbins (a theatrical pickpocket in Vegas who some consider to be the best in the trade[1]) also had dreams of creating a team of ex-cons turned good consulting with security forces around the world. Apollo found that his teammates were “nervous” when working with law enforcement and both members of the team with a criminal record had relapsed.

There are many other examples of criminals turning the tables and working in the same field, this time as law-abiding citizens. Some relapse, some don't. Most people are reluctant to hire an ex-con which contributes to the relapse rate. The potential downside is so strong that many don't consider the statistics.

Back in the days of Mitnick, cybersecurity wasn't nearly as understood as it is today. (Heck, they still used “cyber” as a prefix). One didn't go into “Information Security” as a profession. Even tech companies dropped the ball on security. The lack of employment opportunities combined with the social “hacker” stigma and corporate resistance to change meant that most security opportunities lay outside the law. This is not to say that everyone working in security was malicious. Many were initially motivated by simple curiosity – there was a whole new world to be explored. Some, like Kevin Poulsen started using newfound skills for material gain. (Poulsen manipulated the phone lines of a radio station to win a Porsche [2].)

As rogue crackers exposed the need for technical security, large organizations found that these very crackers were the ones who were the best at what they did. It suddenly became advantageous for hackers like Mitnick and Poulsen to consult. A new breed of hacker emerged: the reformed criminal. Suddenly, having a criminal record meant that you knew what you were doing, rather than being a liability.

Technology continued its explosion across the world, leaving little untouched. With this explosion came new security opportunities, and the field flourished. Security workers began to be able to learn the tricks of their trade without illegal activity. Once able-bodied workers sans criminal record were available, the industry turned to them, shunning most crackers.

Today, if anyone wants to enter the world of information security, they would do well to stay well within the confines of the law. It's incredibly cheap to set up a test system (thanks OSS and FSF!)

[0] https://twitter.com/kevinmitnick/status/293412795024801793

[1] http://www.newyorker.com/reporting/2013/01/07/130107fa_fact_green?currentPage=all&src=longreads

[2] http://en.wikipedia.org/wiki/Kevin_Poulsen

Beware: Limbo Dancers!

Graffiti's bad, right?  We can't have these hooligans spray-painting various obscene terms all over our beautiful city.  Something should be done!  We should create laws establishing strict penalties for destroying the inherent beauty of our stark concrete.  Police squads will be created, a community watch will be established and sanity and order will be restored.

At this point, society has successfully eliminated the graffiti problem.  Sadly, we've also eliminated the limbo dancers.  At the bottom of a bathroom stall door in our science building lies a warning: "BEWARE LIMBO DANCERS."  There's also a helpful arrow pointing to the bottom of the door indicating where said limbo dancers may enter.

The draconian laws earlier would eliminate this bit of graffiti alongside all of the "ugly" stuff.  Here, we'd only lose a bit of amusement.  Elsewhere, overbearing laws have much worse effects.  It's far too easy to say "this is bad" and outlaw it without contemplating the implications.  The heart-wrenching case of Aaron Swartz shows what happens when lawmakers pursue career over country.

We're a country of hackers and that's what has made the US what it is.  Sweeping legislation can only leave us surrounded by graffiti or devoid of limbo dancers.  We need to establish a middle ground, as hard as that may be, or perish.

This will be incredibly difficult for the politicians so long as the current system remains in place.  Who this won't be difficult for is us hackers. If we want to inspire others to challenge the binary status quo, we need to set an example.

What can you do to find that edge?  Explore compromise today.

Becoming teh awesome

One of the things that defines a good hacker is their drive to improve.  This often stymies young hackers as they desperately want to push forward and improve their skills but don't know how.  There are infinitely many wrong ways about it.  One path that seems to have met with some success is emulating "good" programmers by attempting to emulate their public attributes [0].

There are three different buckets that these attributes fall into.  First, there are things that will directly influence your coding skill through programming.   Then there are things that will help make you a better hacker but aren't necessarily "programming."  Finally, there are some things that famous programmers do that don't actually contribute to skill.  In rough order of importance:

First, never stop coding.  I mean it.  Make an effort to code every day.  There are a ton of different ways to accomplish this:

• Push yourself to develop something every month (Like these guys)[1]
• Run through Code Katas
• Learn new languages and frameworks, beyond the syntax

There's also something to be said for both reading code and teaching others how to code.  Reading code exposes you to other coding styles and formats for getting things done [1.5].

Teaching and blog writing forces you to be honest with yourself.  It's much easier to fake it if you never interact with others on an intellectual level.  Some of the most rewarding work I've done is with my co-founder, where we both were able to teach each other as we programmed [2]. 

Less direct (but no less important) are indirect methods.

Software engineering is about a lot more than just writing spiffy code.  Sure, you can "learn" about it by reading yet another book but there's nothing like getting actual experience.  There are tons of great communities that would love to have you on board (and you don't need to be an expert!).

Reading blogs expands your coding world view (and hey, you're reading one right now!).  Blogs (and their comment sections) can be excellent places to find new and innovative ideas, so long as you take them with a grain of salt.  It's easy to start reading blogs instead of moving up to the more important things on this list, which brings us to things famous developers do that don't really help at all:

One thing to remember when looking up to coding idols is that they are way smarter than you are.  It may seem cool, even edgy, that they argue about the languages they use.  Arrogantly arguing about languages and style won't make you Douglas Crockford, just Doug Crock-full-of-*ignored*.

Don't use libraries instead of languages.  This is a good shortcut for those rapidly putting together prototypes but will hinder your development as a developer.  It may seem like everyone's doing it but there is incredibly real value to learning the language, not the library.

Finally, don't claim that "Real X use Y" While I'm guilty of this myself (Heck, look at this entire post), there are exceptions to the rule.  Saying "real developers use Ruby" or "You'll never be a good developer until you learn lisp" only makes you look like an idiot.  You may be correct but it's better to not come off as a bigot.

BONUS: Write Read books.  You may not be up to the challenge of writing a book but reading one is much easier.  The "holy three" are Code Complete 2 (very close to the metal), The Pragmatic Programmer (Good advice for any coder) and The Clean Coder (How to write code that will work and be understood).

[0] C.S. Lewis said it best: "People have a habit of becoming who they are pretending to be."
[1] Amaan wants to remind you that he had the idea first.
[1.5] For the sake of your sanity, DON'T learn JavaScript by viewing the source of random webpages.
[2] I'm usually not in favor of pair programming except for teaching scenarios  as they allow both the student and the teacher to get the "meat" quicker.

Is your software too big to fail?

In my short career as a hacker, I've played with a lot of environments from Java with NetBeans and Swing, to Joomla running PHP and finally, Node + JavaScript.  All of the languages/frameworks I've worked in have their advantages and disadvantages (though I'd have to think harder about some to find advantages).  When it comes to application size, Node is unique.

This isn't about how many megabytes Node core is vs. PHP core.  Rather, let's investigate the average size of a supporting application.  Disclaimer: In each ecosystem, there are many different ways one could form a product.  I only have experience with a limited segment of them.  Read on at your own risk.

PHP and Java both have large, complex systems that try to do as much as possible.  Joomla in particular has a wide variety of functions and methods that'll "save you time."  (So long as you can understand their obtuse docs).  WordPress, ZendFramework, et. al. all try to provide the user with as much "stuff" as possible (and if they can't, the user can also get plugins etc for above).

Node doesn't.  Node has the philosophy of simple.  Each package in npm does one thing.  At first, this may bug you.  It seems inefficient to have such a decentralized system, ripe for error as some plugins don't connect with other packages and middleware.  Plus, you've got to learn how to work with all these systems.  There isn't a magical button to push to make everything work (yet).

Despite these downsides, I still think that Node has the advantage here if flexibility is your priority (and it should be).  If one were to build a website with Joomla, you'd be forced to either use their database object which still doesn't use prepared statements [0] or roll your own PDO system.  If you have to replicate work done by the system you're working in, there's something wrong with the system.

Node's decentralization prevents that sort of problem.  Even if I choose the most popular "framework" on node, Express, I still am free to choose other solutions (or roll my own) to my heart's content.  Even better, npm provides a one-stop-shop for organizing and updating all of the packages.  As you'll come to learn, decentralization doesn't mean we can't have standards.

Fortunately, the world of open source has virtually guaranteed that we won't be left adrift if the original authors leave the project.  This still doesn't mean that relying on a single software package for development is a good idea.  If something goes wrong or isn't available, you could be stuck high and dry.  Consider refactoring and reorganizing if you find you've been leaning on products too big to fail.  They probably will, at the worst moment.

This is all based on personal experience.  Want to hear more about it?  Ask me on Twitter, or in a comment below.

[0] They're fixing this in 3.0, but PDO's been around since 2005 for crying out loud!

CRUD with Mongo Helper

MongoDB is an excellent database solution that has it's quirks.  Node is a great server-side solution.  I'm using both in my latest project to revolutionize online education.  Unfortunately, the combination of the two can be verbose and prone to errors.  There are other solutions but those can be unnecessarily complex in their own way.

Let's say we wanted to add a new record to an existing collection.  Using the native mongodb driver, we'd need the following:

var mongo = require('mongodb')
  , server = new mongo.Server('localhost', mongo.Connection.DEFAULT_PORT, {auto_reconnect: true})
  , mdb = new mongo.Db('blog', server, {safe: true});

module.exports  = {
  insert = function(insertQuery) {
    mdb.open(function(err, db) {
      db.collection('recoding', function(err, collection) {
        collection.insert(insertQuery, function(err) {
          if(err) { /* handle errors */ }
          db.close();
      });
    });
  }
}

and that's only for a simple insert, without a callback.  Instead, I wrote up a simple CRUD app to help out, which reduces the above to the following (which is simple enough that one wouldn't need a whole function):

var mongoHelper = new (require('mongo-helper'))();
module.exports = {
  insert = function(insertQuery) {
    mongoHelper.insert('recoding', insertQuery);
  }
}

The one thing that's become more complicated is the declaration of mongoHelper.  Using the native driver allows for a much more flexible application with regard to settings.  I tried to keep it simple, while still allowing for customization.  The new method allows the user to pass settings to Mongo Helper, while letting defaults remain default.  For instance, if we wanted to use a different database:

var mongoHelper = new (require('mongo-helper')({dbName: 'users'});

Mongo Helper only supports the four basic CRUD operations for now. I plan on adding support for things like findOne and database storage of settings soon.

You can find the code/docs for Mongo Helper at my Github.  If you liked this, follow me on Twitter for more updates.

College? Heck yes

I'm back for another fun semester of college.  Now, I know that there's a wide variety of opinions on college in the hacker world.  I'm not surprised, given the average full-time programmer first started programming at 13.  If you've got 5 years of experience by the time you've got your high school degree, why spend lots of money to get yet another degree?

First and foremost, having a college degree will be good for your career.  You may not use what you learned in the process of acquiring that degree in the real world.  In fact, by the time the average CS major gets to their junior year, half of the stuff they learned in freshman year is obsolete.  Yikes.  For a very long time, virtually all professional jobs (Engineering, Business, etc) required the knowledge from college to work.  That's still somewhat true today (gravity hasn't changed significantly with regards to bridge building).  While you may be able to get by with independent experience in programming, many people will consider the lack of a bachelor's against you.  It may not make sense but that's the way the world is.  Think of it as hacking the hiring system.

That's not to say getting a degree will be pointless.  Four years of college can rack up a lot of debt.  One might be able to alleviate some or all of that financial burden by going to a community college instead.  However, you'll miss the most important reason to go to college.  MIT is incredibly costly at $57 thousand a year.  Ouch.  I understand that many of you probably can't afford that.  Loans, grants and scholarships will help.  Once you're there, you'll be surrounded by the type of people who go to MIT.  College is expensive because once you've arrived, you'll be with the type of people who are either smart enough to get scholarships or have rich (or financially savvy) parents.  Either way, these are the type of people you want to be around.

Secondly, if you're just about to graduate from high school, there's a good chance you really don't know how hard the real world is.  Let's be honest: If you're smart enough to be a competent programmer, high school academics were probably a joke.  College may be the first difficult thing you encounter.  Regardless of major, learning how to do difficult things you don't want to do just might be the most important thing you'll learn - ever.

You absolutely don't need to go to MIT (though I hear it's a very cool place).  Learning about more abstract things like data structures will be useful.  Try and shoot for the best college you can (remember more expensive !== best, do your research).

Reactions?  Comment!  I would love to hear what you've got to say on the topic.

Thoughts of the future in the wake of death

Before today, I had no idea who Aaron Swartz was.  Until today, I sat content with the ideal of an amazing life ahead of me.  Something in that ideal has broken.

I'm a certified genius with an IQ of 135.  I've also been identified as "special" thanks to my brain also running ADD and borderline Aspergers.  Most of my life has been attempting to use the former to conquer the latter.  Only recently have I come to realize what needed to be done to capitalize on my strengths to overcome my weaknesses.

It's been a lot of work.  Like Aaron, I had to battle against the demons of depression[0].  I've had to find and break habits that have been there for my entire lifetime, and then beat them back when they resurface.  I'm gaining ground against my own shortcomings slowly but surely.

One of the things that motivated me to begin this massive path was Paul Graham.  I'm attempting to start a company with the goal of being funded by YCombinator.  Aaron co-founded reddit and was funded in YC's first batch.

I wish today didn't happen.  I wish that Jan 12th could have a redo.  I want to change the world.  I want to stand at the walls of bureaucracy and academia itself armed with technology and innovation and charge until they are walls no more.

I'm trying to fight for change in a world solidly against it.  It's a lot of work, and I haven't even started.  I'm often tempted to give it up and get a simple, well-paying job and take it easy.  I haven't.

Aaron Swartz's suicide has provoked a strong reaction from the hacker community.  Suicides usually cause an intense emotional reaction.  In part, I think that this particular response is due to the fact that Aaron was in a position that we could all see ourselves in (save the pending litigation): Child genius who grew up to be a successful startup owner who didn't sell out and kept true to his hacker roots.

His death, like all deaths, tells a story.  It's an incredibly sad one that does not bode well for our future.  I know I'm not the only one who is striving to build and accomplish something with my life.  Now, I look at Aaron's choice and once again consider that desk job where I don't rock the boat.

I want to arrive at success.  What will be waiting for me?

[0] If you're struggling against depression, tell someone.  I don't care who, so long as you know them in real life.  Writing also helps enormously.  If it gets serious, see a professional.

Isn't this supposed to be fun?

I was unfortunately sick all day.  Bleh.  That's never fun.  What makes it unfortunately sick instead of just regular sick is that I had a bunch of fun stuff to tackle on my side project/startup/"internship"/what have you.  After about an hour of effort that only resulted in 10 lines of code [0], I was frustrated with my lack of progress and inability to focus.

Wait.  Isn't this supposed to be fun?  I'm building this out of my own free will.  Sure, there's the promise of a liquidity event but I'd go to Wall Street if all I cared about was money.  When we get down to it, I really enjoy programming.  Don't we all?  One of the best things about the programming field is that there's a bunch of people who genuinely enjoy the work they do.  We create amazing things and then give them away for free.  Heck, I even set a personal milestone when I released my first project that was built for more than personal edification.

Programming is incredible.  I get so much of a rush out of watching all my tests pass and seeing a project grow from idea to design to a fully-functioning application.

In the midst of all this back-patting, there's a lot of activity that just seems a lot like work.  I don't mean the depths of programming purgatory when nothing's working and you've got no clue why.  I'm also not talking about crunch time when all of your technical debt is called in.  These valleys are both par for the programming course and I hope to address them another time.  The "work" is rather the midpoint when there's 200 lines of code that need tests and someone's got to write them.  If you like writing tests, feel free to substitute the grind you don't like.

Work's fine if you're getting paid for it.  That's the whole point of work, doing things you don't want to for pay.  Us programmers are a different world.  It's easy to dismiss things like testing and refactoring as "work" and blow them off - that's how technical debt occurs.  If we do that, then we're ignoring the greater purpose, the entire reason we're writing code in the first place: To create!

The thing that unites us as hackers (rather than a loose conglomerate of "geeks") is the fact that we are all makers (of some form or another).  We enjoy creating stuff.  The goal isn't to maximize fun now, if it were, we'd all be in a giant chocolate orgy.  Our maker urge pushes us to both create and improve.  If we only focus on the now of boring test writing, we miss the wonderful big picture of making.

Of course, there's something to be said for taking a break if you're sick or to avoid burnout.  On the whole, don't be afraid to charge into boring for the end result of making something great.

[0] Yes, there are projects where 10 lines changing for only an hour of effort can be huge.  This was not one of them.

Group projects

Meetings, MEETINGS, MEETINGS!!!  I hate meetings.  Or rather, I hate the fact that I have to do meetings.  Or perhaps I only dislike the types of meetings I've encountered so far.  "Standing meetings" seem to be all the rage.  Perhaps I'll try those.  Gimme a sec.

Ok, now my legs are tired and I still hate meetings.

In truth, what are meetings for?  Writing an exhaustively-researched list completely off the top of my head results in:

• Announce stuff
• Get buy in from other employees
• Brainstorm

A quick Google search tells me that "the purpose of meetings is to coordinate action!"  Yeah, glad we got that one solved.  Meetings have a few key problems: People like to talk, there's usually little-to-no standard for structure or ending, and it's considered "impolite" to interrupt someone who's wasting everyone's time (especially if it's the CEO).

In fact, I'm starting to question if we need meetings at all.  Let's look at the four purposes above:
Announcements: Meetings might seem like a nice way to announce things until you consider the alternatives: Email (quick, easy, not distracting, difficult to ensure everyone reads it) and presentations [0] (Longer, can go into detail).
Buy in: If you (or your boss) feel(s) that you (they, ok, I'll stop now) need to discuss your decisions with your employees in order for them to feel included, you're an idiot.  Find a real way to include them.  Like letting them lead.  If you're looking for opposing viewpoints, people prefer to bring those up privately, instead of publicly in front of the staff.

Halfway through.  Phew.

Brainstorming: In the first draft of this article, I was going to posit that brainstorming was the one good reason for meeting.  Right?  Isn't that how it's supposed to be?  I mean, that's what they did all the way through school.
Then this article popped up on Hacker News.  Shoot.  As it turns out, we humans are better at coming up with creative ideas on our own than in groups.  So let's take a note from Rand's essay on The Twinge and say that meetings are good for taking those ideas and sanding off the rough edges.
Coordinate Action: Oh, give me a break.  There are many, many, ways to coordinate action in your particular organization other than meetings.  Half of this falls under "Announcements" and the other half under "superfluous planning."

I could be entirely wrong with this rant.  I'm still young, and have held only one real job in the industry (admittedly at a fairly bad company).  Tell me I'm wrong in the comments!

[0] Presentations differ in my opinion as they have a set goal/outline and are less prone to interruptions. Think Google's Friday presentation vs. your last staff meeting

Meetings for idea generation worthless because: http://www.theamericanconservative.com/jacobs/hey-extraverts-enough-is-enough/

Exporting a JavaScript "object" in node

It's simple to use module.exports if you want to distribute a few static functions.  It becomes an entirely different matter if you want to take some sort of input in a constructor.  In this case, you'd want to take advantage of JavaScript's Prototypical Object-Oriented system.  This isn't a tutorial on POO (heh), as MDN already has a good one.

Rather, we're going to tackle the node side of things.  Let's say we've got an incredibly simple system (in foo.js):

'use strict';
function Foo(bar) {
  this.baz = bar;
}
Foo.prototype = {
  foobar: function() {
    alert(this.baz);
  }
};
module.exports = Foo;

 If we then wanted to use it elsewhere, how would we require it?  Seeing other examples, we might be tempted to do something along the lines of:

var foo = require('./foo')('Kittens');

or

var foo = new require('./foo')('Kittens');

These will result in the rather odd error "TypeError: Cannot set property 'baz' of undefined." on the line "this.baz = bar;"  This is a side effect of using strict mode (which you should, for exactly this occasion) where the object is not being initialized properly.  While the above seem like they should work, there's one little kink that needs to be worked out.  While it's possible to get members of something required, like so:

var a = require('./b').a;

 This won't work for prototypical objects that depend on `this` like what we've got above.  Instead, you need to require, and then use new:

var fooProto = require('./foo')
  , foo = new fooProto('Kittens');

It's also possible to use a less clear shortcut:

var foo = new (require('./foo'))('Kittens');

While I am by no means an node expert, I hope this helps you.  Good luck!

Making software for me

After years of using open source code in many forms, I'm finally giving back to the community in mongo-helper, a simple wrapper module for MongoDB (which I mentioned in a previous article) under node.js.  mongo-helper won't be winning any awards for innovation or code awesomeness but it solves a problem I had, namely my code was cluttered with lots of database calls.  I tried out Mongoose and found it versatile and too advanced for my needs.

I doubt many other people will end up using mongo-helper (after the fact, I discovered that someone else had the same idea).  I don't really care.  I'll be using it to assist me in a few side projects.  There are some quirks that are due to my newness to node package design.  It's ok, I know them.  I also learned a LOT (and still am as I fix it up).

I didn't bring you all here so I could brag about mongo-helper.  I made it for me, it works for me, and if others want to try it out, great!  This "I made it for me" attitude becomes less great when you're actually making software for other people.  It's very easy to assume your target audience thinks pretty much like you.  This has plagued the open source community for eons.

As such, it's very important to identify who your audience is (yet another revelation from my groundbreaking "duh!" series).  This leads into a topic I've wanted to hit for a while: "Who is this blog for anyway?"

Let me start off by telling you that you should also write a blog.  It's not easy, keeping a schedule and coming up with ideas.  It's even worse when writer's block strikes.  However, I've found it invaluable for expanding my knowledge and discovering what I really enjoy writing about (instead of "yeah, that'd be nice to do something about").  Plus, Steve Yegge and Jeff Atwood [0] told you to.

I didn't think anyone would be interested in my writing, so the blog's original audience was me.  It helped me organize my thoughts and explore the realm of programming and business through a new avenue.  The blog's still mostly for me, consisting of my semi-organized thoughts about, well, stuff.

Recoding's published publicly so it isn't entirely for myself.  Originally, it was also for an open-minded teacher who was willing to let me write a blog for a class.  Now I'll get 100 readers on a good day (and 4k+ on a day I'm still trying to replicate).  I love the fact that people are reading my blog and I hope they get something out of it.  I know I did.

Just ask rlemon of Sour Coder or Amaan Cheval of What the Dude? how starting a blog worked for them.

If you do start a blog, send me a link on Twitter and I'll check it out.

[0] You should care because Yegge worked for Amazon and currently works for Google and Atwood co-founded StackOverflow.  Names and places aren't everything but these guys know their stuff.

Questions you should ask at the job interview

I stumbled into my first job without so much as a formal interview.  Had I bothered to ask a few key questions, I would have been much better prepared for the fiasco that was about to unfold.  Hindsight's 20/20, but I hope I can pass some of my vision onto you.

How much am I getting paid?
This seems like a no-brainer.  Most of the questions here are about getting the feel of the company you're about to work for and this is no exception.  Unlike all of the other questions, this helps determine how much the company values their workers.  There's no hard and fast rule to determine what dollar amount is best.

I didn't ask this (yes, slap me for that).  I was a poor college student who was just happy to be paid to code.  As it turned out, starting pay was $10 an hour which works out to around $20,000/year.  Big money to someone who never considered other options.  However, this put me in the second percentile with regard to entry-level coders.  Ouch.  I'm still not sure I would have realized this when I arrived.

A good followup to this question is "What's the raise/promotion structure like? [0]"  It's good to make sure that there's a path to progress upward as you spend time working.

What's your Joel test score?
It's surprising how well the Joel test has lasted against the fast-changing software world.  It was written in 2000, for heaven's sake!  While it was not intended to be comprehensive, it provides a good overview of practices that everyone should have.  Be prepared to provide a copy of the test (or at least a few questions), as the interviewer may not have heard of it.  I wouldn't consider not knowing the test to be a black mark, it's a wide world out there.  By asking, you're avoiding the cold water shock I had a month in when I realized that the company scored a 1.5.

If the company is missing a few points, you've now got a perfect example for the next question:

If I wanted to do <radical thing>, how hard would it be to implement?
The value of radical may vary depending on which way the corporate culture leans.  Still, it's incredibly important to know that change happens, regardless of how.  If there's an enormous process to changing anything, you may want to move on.

As scary as a DMV-like change process can be, be more afraid of a company that can't answer that question.  This means one of two things:

• There's no change at this company.  Unlikely, but possible.
• There's change at this company, but no one documents it.  ARG!  Documentation is power.  Change is good, but uncontrolled change can spell a death spiral.  If everyone can dive into the codebase and mess around, that's a problem.  Speaking of:

What's your workflow like, and why?
Ah, workflow.  This is the other half of "undocumented change."  What you're looking for here is evidence that the company supports collaboration while still allowing coders to get work done.  How does a team work together?  Who's in charge of setting requirements?  You should have a good idea of how your day-to-day coding life will look like before you start.

Naturally, it may be difficult for the interviewer to properly answer this question, especially in larger companies.  You may want to talk to someone in the position you'll be taking.

What will my training look like?
If you've made it this far, congratulations!  It looks like you've found the right place.  There's one last step to a wonderful job: training.  Programming is such an interesting field in that every job will be different, not only in language but in process, tools, goal, etc.

Training is important because it provides practical instruction in the tools you'll be using as well as an introduction to the corporate culture.  Make sure that the practical training is hands-on as well as actually relevant to your specific job.  I spent a full day watching videos on how to create articles with Joomla.  (SPOILER ALERT: You click the "New Article" button).  What I really needed was an introduction to the Joomla API.  The culture bit is tricky.  It's easy to overwhelm a new hire with buzzword-filled "values" and "missions."  What I really wished for was a go-to person who could answer the questions I had as a new hire.

This list isn't intended to be comprehensive or scholarly.  These are things that I wish I had known about before I started my last job.  I'd love to hear your stories either in the comments below or at Hacker News.

[0] You may think that discussing money through the interview/offer process is shameful.  HR would LOVE for you to assume that.  Read this excellent article for more negotiation techniques.

I hate mobile

The mobile "revolution" has been pretty cool.  We've seen a lot of innovative apps, a glut of games and flashlight apps galore.  It's been the biggest boon for open source since, well, ever.  It's made millionares and billionares and doesn't seem to be slowing down anytime soon.

I hate it.  Mobile never ceases to get on my nerves.

Remember Web 2.0?  That buzzword-filled era?  Yeah, I don't want to repeat it anytime either.  However, no one really knew what Web 2.0 meant.  There were plenty of definitions going around, but it seemed like everyone had their own spin.  While this had the disadvantage of never knowing what a company meant when they said they were "Web 2.0 compliant" or something like that, it meant that there wasn't a centralizing factor for all the hip startups to focus on.  They could add some element of interactivity and get back to creating awesome ideas.

Everyone knows what mobile is.  Everyone's trying to be the "next big thing" with mobile.  Unfortunately, this splits the market.  I could spend the next few paragraphs explaining the economics behind that, but I'd rather not bore you to death.

Bah, sorry.  I'm complaining about things again, aren't I?  Let's look at the positive.

Everyone focusing on mobile (or social media, or what have you) means that there's some incredibly under served markets out there.  It's New Years day (what am I doing blogging on New Years?  If only there were an appropriate time to think over my life and make significant changes in goal form...).  We've got a whole awesome year ahead of us.  Why don't we take some advice from Steve Yegge and build something that matters.

Don't try to be the next Temple Run.  Try to be the first whatever-the-heck-you-are.  I'm currently building a system that should make college easier and cheaper for the next cycle of college students.  Whose life will you change?