Motivation

Stop.  What are you doing right now?  You're reading a blog.  (mine!)

Forget that.  My blog isn't even that good.

A better question would be "What should you be working on right now?"  Think about that for a moment.  Better yet, eliminate all the "should do" things.  These are things like mowing the lawn and doing laundry.  Sure, they need to be done but they won't have a lasting impact.

Find something major to do.  Think big.  What's a giant problem facing your field?  How could you make a measurable impact on that*?

Plan out your first few steps.  Don't be afraid to let your imagination run free.  Create a trickle list of activities that'll let you move closer to that goal.

Do the laundry but work on the big stuff now.  If you don't, when will you?

*Yes, the average CS guy probably won't make headway on P=NP.  There are plenty of problems.  Be creative.

Building towers of code

If I wished to build a tower four feet tall, I'd need about ten cans and some decent balancing skills.  If I was assigned to build a tower four hundred feet tall, I'd need a bit more than 1,000 cans.  Scaling software, like towers, isn't easy.

Code complexity increases much faster than a simple line count.  There are a myriad of tools and techniques that one can use to provide structure to code to ease growing pains.  The most popular of these is Object Oriented Programming.  OOP gives structure to code and allows a programmer to easily conceptualize the pile of code in front of them.  It's also really easy to make it look like you're working when you're dealing with an object oriented language.

Therein lies the bigger problem.  If we can make it look like we're working, why do actual work?  The pay is the same.  Lazy programming leads to even more complexity than you started with as endless lists of classes, factories, and helper functions spawn because it's much easier to write out the frame than it is to fill it in.  Like anything else, these lazy programmers are bad but cheap.

Hiring cheap programmers is like building a massive tower out of plywood.  Sure, the construction material allows for a budget that impresses your boss but who'll be responsible when the whole thing goes tumbling down?

Source Saturday: Prolog and Lists

Welcome to a new feature of Recoding!  On Source Saturdays, I'll be going through some code I've written that week and exploring design decisions that lead to the code.  This week, we look into my experimentation with Prolog.

I'm taking an Artificial Intelligence class at my college.  So far, I've learned that real life is nothing like Hollywood movies make it out to be.  One of our assignments is to create a virtual adviser that suggests what courses a CS student needs to take next semester.  You can find the full (incomplete) project here.

One of the things we need to check for is that the student has completed (or is taking) all of the prerequisites to a course.  If they haven't, we can't suggest it.  At first glance, this seems simple enough. Just slam out something like:

prereq(csc140, csc145).
hasPrereqs(Student, Class) :-
    prereq(Pre, Class),
    creditFor(Student, Class).

This solves two problems: When one class is required and when one or another class is required.  One glaring problem is that it'll return false if the class doesn't have any requirements.  That too, is simply solved with Prolog's if-then-else.

hasPrereqs(Student, Class) :-
    (prereq(Pre, Class) ->
    creditFor(Student, Class);
    true).

We've solved everything but one problem - multiple required classes.  You can see my struggle with the problem in my first StackOverflow Prolog question.  My main issue was csc201, which had the prereqs of either (csc130 AND csc140) OR (csc145).  Thus, it'd return a set that included a list and an atom.  I eventually came up with rules that allowed for all cases.  While my answer worked, it was messy.  Fortunately, mndrix was there to help and proposed an alternate solution.

prereq(csc140, []).
prereq(csc145, [csc140]).
hasPrereqs(Student, Class) :-
  prereq(Class, Pres),
  forall(member(Pre, Pres), hasClass(Student, Pre)).

Awesome.  There's one thing I'd like to focus on here. I spent a lot of time trying to figure out how to iterate over a list in Prolog.  forall/2 was suggested, but I couldn't figure out how to use it given a raw list, rather than something that results in a list.  My "aha" moment was member/2.  It "returns" all the data in a list through a variable, rather than a list.  forall/2 can then take that data and check it against hasClass/2 to determine the truthiness of the items.  This has the disadvantage of requiring me to reformat all of the prereqs as well as creating entries for classes that don't have prereqs but I think it lends the code to be more self-documenting.  Every class is accounted for.

State of Tech Industry

I'd like to follow up on my last post, where we looked at a specific segment of code libraries and the negative effect it has on the coding industry as a whole.  Anyone who's dealt with a bad interface or incoherent errors can tell that we programmers aren't perfect.  I like to go to Larry Niven when this topic comes up

That's the thing about people who think they hate computers. What they really hate is lousy programmers.

There's an almost unlimited supply of lousy programmers.  Most managers don't want to hire lousy workers.   So where's the disconnect?  What's wrong?

Despite decades of research and understanding, programming is still hard.  Heck, understanding programmers is still hard.  Thus, a lot of companies that want programming done don't hire their own programmers.  Instead, they outsource to another company.  Any hacker can tell you that good code takes effort.

A lot of outsourcers are actually quite good.  However, there are far too many out there where the only goal is profit.  Managers who don't understand programming only see the same end product (a pile 'o code) but cheaper.  Back in reality, we see a huge discrepancy in quality of code.

One would think that companies would catch on and start hiring firms that create quality code.  Sadly, this isn't the case.

Why jQuery Doesn't Work

jQuery is popular.  It's used in half of all sites on the web.  And I hate it.

Why?

It works, that's for sure.  However, even a simple selector is 93% slower with jQuery.  Speed isn't the issue either.  There's a lot of things that slow the web down.  Sure, I'd like all of my webpages to load perfectly, but that isn't going to happen.

The problem is that it's become more than a library.  Some people actually mistake it for a full language (see the first revision of this question).  There's no such thing as "coding" in jQuery.  It's only slapping on plugin after plugin.  Building websites in jQuery is like constructing spaceships in Spore: You take prerendered parts and put them together, with no respect for purpose or location.  Sure, you don't need an advanced degree in astrophysics but you can't call yourself an astronaut either.

I'm spending thousands of dollars and years of my life to learn how to be a programmer.  One who builds things and knows the system that they built.  Relying on jQuery to build websites isn't real programming.

I'll leave you with this

Reverse Eagle

Imagine the following scenario:

You're happily hacking away at your latest project.  Things are coming together and you're slamming out some awesome features in a caffeine-fueled haze.  Suddenly, your boss appears with a deadly statement: "I was thinking...."

I don't even need to finish that statement.  We've all been there.  Alarm bells are going off in your head before he even finishes the first sentence.  Best-case, it'll be a false alarm and won't result in extra work.  Worst-case (and much more likely), you'll be up late for a week rebuilding the structure to add a feature that does nothing but stroke the boss' ego.

I like to call this the reverse eagle.  The programmer has all their ducks in a row until an edict arrives from "on high."  The edict is akin to an eagle swooping down and depositing an enormous duck (rather than stealing one).  The rowed-up ducks are lost.  The programmer now has to deal with both the scattered ducks (the now-lost project) and the new, out-of-place duck.

Unfortunately, there's no real way to prevent the reverse eagle.  Once it's happened, the damage is done.  You may be able to talk your boss out of it but the idea will still be there.  Your best solution is to be proactive in ensuring that projects don't go out of scope, and that your boss is familiar with the intricacies of software development.

Learning for now and later

Once again, Jeff Atwood hits the nail right on the head:

Do you ever feel like you're buried under umpteen zillion backlogged emails, feeds, books, articles, journals, magazines, and printouts? Do you ever feel that you're hopelessly behind, with so much new stuff created every day that you can never possibly hope to keep up?

Absolutely.  So much so that I started developing a Chrome Extension to solve my blog addiction.  I'll read a new blog and take one look at their archives, and want to devour everything there.

Problem is, I've also got a job.  In that job, I'm continually handling projects that are beyond the scope of my knowledge.  I need to keep expanding my knowledge if I want to produce the best work I possibly can.

It's very easy to get overwhelmed by the immense amount of data out there.  Currently, I have 28 29 30 tabs open, the majority of which are blogs to read "later."  The guys in the StackOverflow chat rooms don't help, as they're constantly recommending me new things to look into.

Well what do you do?  Jeff says to learn things "just in time," which I agree with most of the time.  There's something to be said for abstract learning, so long as it doesn't get in the way of what you need to do now.  When I sit down to work for the day, I spend 10-15 minutes reading blogs and news before  settling down to work.  It allows me to hack away at my huge backlog (though I often find myself opening more tabs than closing) as well as create a buffer between the stresses of the day and my coding.

Managing Humans

Michael "Rands" Lopp has an excellent collection of management tips in Managing Humans.  In it, he describes the ins and outs of being a manager of nerds.  Some of what he has to say can be applied to any management job, but most of it is specific to programmers because nerds are *gasp* different.  While the book is essentially a "best of" of his blog, I still enjoyed it because I'm one of those horrible tree-killers who likes real books.

In reading through this blog book, five lessons stood out to me.  One lesson stood out to me enough that I've already written about it.  However, there's a second component to asking dumb questions, and it has to do with the second half of your interview.  After we're hired, we want to prove that we're competent and our boss made a good choice.  Sadly, that won't happen.  It's better to approach your first 90 days at a company with humility.  Learn as much as you can.  Feel your way around by being brash and making mistakes.

Another thing that Rands hits on a lot in his book is talking without action.  It's best summed up in Fred Hates It.  This is something I experience a lot in my current job.  It is irritating!  We're nerds, we want to get things done.  Bosses won't disagree with this - it's our job to do things.  And yet, it's practically impossible to get anything done.  We spend ages in meetings trying to figure out why nothing's getting done.

Alright, so meetings don't work so well.  How does one get things accomplished?  You build a cave.  A nerd's cave is a place that they're familiar with and is secured from distraction.  This is one of the reasons I have such trouble getting anything done at college (homework and funny pictures on the internet being the other two).

After college, I'll need to procure a job.  Various programs that have attempted to teach me how to get one have taught me two lessons: "Having a resume is good" and "wear a tie."  Despite hearing the same lectures telling us "What Employers Want", I never actually heard anything from an employer.  Managing Humans has two chapters that filled in a lot of holes for me, A Glimpse and a Hook which is about resumes and A Sanity Check which covers the phone screen.

Finally, there's the inevitable - something goes horribly wrong.  There are many ways to react to this scenario, most of them wrong.  In When the Sky Falls, Rands lays out a simple process to weather the storm.  The nice thing about this plan is that it scales well.  It can cover anything from a major security hole on a minor one-man project to major someone's-getting-fired-for-this disasters.

This barely scratches the surface of what's contained in Managing Humans.  While it's more of a reference book than an afternoon read, Rands communicates the lessons that he's learned very well.

Action Items and other buzzwords

Alright.  You've asked the dumb questions and now know what you've got to do.  The holes in the plan have been filled in and you're feeeeeling good.  You whistle a happy tune as you head back to wherever it is you code.

And then, just like that, you're lost.  You frantically scramble over the meeting minutes and discover that what you consider the "Important Bit" is only written as "Joe talked about working on the FooBar project."

Fortunately, Scott Belesky (author of the excellent Making Ideas Happen) has also encountered this problem.  He recommends capturing these notes as "Action Items."

The format of an Action Item is really simple.  Every time something you'll need to do comes up in a meeting, write it down on a small piece of paper.  Personally, I use a pocket notebook, but you can use Post It notes or anything small that works for you.

These don't have to be exclusively used in a meeting.  Carry your notebook around with you.  Capture them when you have a good idea to follow up on.  Write down complaints other people have (any great product solves a problem).  Action Items are a great alternative to the ubiquitous "To Do" list.

Making Meetings Matter

I had a meeting with my boss earlier this week.  In it, we discussed three separate projects, each at different stages.  Each project had different requirements and impacted different parts of the company.  Ultimately, the meeting didn't help much for all the time we spent on it.  It wasn't the fault of the diverse array of discussion topics but rather how we managed the meeting.  I left with a distinct sense of "wait, what?" (especially for our new project).

I'm sure I'm not alone in dealing with such things.  Over the next week, I'll investigate some things that anyone can do to salvage a meeting.  For today:

Ask Dumb Questions.  

This culture of head-nodding we've cultivated is hurting us.  Too often we pretend we heard or understood the past five minutes when in reality we were all off in dreamland accepting our third Nobel.  Asking for clarification helps glean details that may otherwise slip through the cracks and cause a Malcom event.

If you don't understand something, ask.  If you're confused, perhaps others in the meeting are as well.  Chances are, you'll avoid costly communication errors later on.  These dumb questions can also bring up flaws that others might not have heard of.  If I had thought ahead to ask specifics, I'd understand the scope of our new project a lot more and would be much more effective in my research.  Unfortunately, I'm now forced to ask them via email.

If you're the boss, create opportunities during a meeting for people to ask clarifying questions.  Make sure to cultivate a non-critical atmosphere (but bring a Nerf gun in case anyone dozes off!)

NASA sounds....boring

NASA sends rocket-powered jetpack-using robots to Mars.  They developed the technology to bring men to the moon and back.

As I was reading through their software development process, it all sounding so...boring.  There usually aren't any overtime hours.  Everything is written out in reams of paper before any code is written.  Don't get me wrong, it's wonderful to see that somewhere out there is a coding team that uses proper code techniques but their methods seem like all the fun of creation is gone.

A large part of the reason I like to write code is the creation process.  My absolute favorite part is writing proof-of-concept code that works, showing that my idea has validity.  Dear NASA.  As much as I love your work, pleas don't hire me (unless you need another astronaut).

Getting it less wrong

I'll be honest.  I'm looking at some of my posts from the past few weeks and wondering just what I was thinking when I decided to start a blog.  Who am I kidding?  I'm not that great of an author.  Heck, I don't have anywhere near enough real-life experience to write about.

A friend of mine commented today that he wished he could go back and redo large portions of the component we'd just finished.  He had gone through a few advanced tutorials as he began framing our next project and learned a lot that we wished we could have known earlier.

This isn't a new story.  We learn throughout a project and want to start over before we're even finished. Even top programmers will discover new secrets as they explore the edges of the known.

Programming is about getting it less wrong, every time.

I guess that's why I'm still writing this blog.  You can't learn how not to do it if you don't start somewhere.

When your code supports billions

Obviously, some testing of code needs to be done before it's released.  This can be anywhere from "it compiles, ship it!" to the extensive rigor NASA software goes through.  Some of this stuff seems over the top, even to the strictest of developers:

Take the upgrade of the software to permit the shuttle to navigate with Global Positioning Satellites, a change that involves just 1.5% of the program, or 6,366 lines of code. The specs for that one change run 2,500 pages, a volume thicker than a phone book. The specs for the current program fill 30 volumes and run 40,000 pages.

Yikes.  And I thought the the fact that I had to deal with code that was released without testing was bad.  Can you imagine writing just under a page of details for every line of code?  Obviously, this isn't the standard.  In fact, NASA's shuttle team is only one of four teams in the world that live up to the Software Engineering Institute's Level 5 standards.

We'd all love to write bug-free code.  The problem is, we all don't have the time or patience to write code like the NASA team.  They do exemplify some best practices for us (source control/bug tracking) but their overboard attitude toward bugs just doesn't work for a small feature on a deadline.

Anthony Ferrara brings up an interesting point.  While your software may not have actual lives riding on it, some of it is pretty important.  The key is to divide up your features and test them according to your importance.  Some things are mission-critical and others are just icing.  Sort those out and test accordingly.

Numbers part 10

In my last blog post about numbers, I talked about the issues programmers can encounter when dealing with whole numbers.  Just like elementary school, things get a lot more complicated when we add fractions.

Most decimal numbers on computers are stored using the IEEE floating point specifications.  To greatly summarize the standard, binary digits after the decimal point are no longer stored as double the digit before them, but rather 1/n where n is double the previous digit.  This can cause some peculiarities, as most numbers result in a repeating decimal (much like 1/3 does in base 10).  In this system, any fraction that does not have a denominator that is not Dyadic will be repeating and will likely result in rounding errors.

This raises the question: Why on earth are we storing numbers like this?  Can't we just store the number after the decimal as another whole number and ditch all the rounding errors?  As it turns out, I was wondering the same thing and asked the kind folks at programmers.SE.  As it turns out, most calculators do use an alternate storage method that avoids these errors (at least in base two).  The problem is that doing it this way takes up a lot more space than above.

Almost all of the time, the only people worrying about these errors will be mathematicians.  Outside of research, the place you're most likely to encounter this is when you a coding an application that handles money.  Fortunately, this has a simple answer: Multiply the money by 100 (making it a whole number) do all the math/taxes/etc

Getting your ideas heard

We all have ideas.  Sometimes, they're actually good.  Problem is, not all of us are decision makers where we work.  Often, our ideas are shot down before we can even fully express them.  How can we get our ideas to be implemented despite our position on the corporate ladder?

First, let's look at why this happens.  In a typical scenario, I've found out about a new thing that'll work twice as fast as the doohickey we've got now.  I go and talk to my boss about the wonders of The New Thing.  My boss (hopefully) thinks about this for 10 seconds and then interrupts.  "Doesn't this new thing have caching issues?"  Sure, it does, but they're working on it.  However, it's already too late.  I'll be fighting an uphill battle, defending New Thing.  Even if I do manage to push it through, all future caching issues (and anything else that's related) will be pinned on me.

See what happened?  We tend to be critical of any new idea and for good reason.  Most new ideas are terrible.  Thus, when the new idea is yours, people will seek to find the flaws in it.  Instead of bringing up the solution for the problem, bring up the problem you intend to solve.

Instead of seeing something that could go wrong, they'll see something that is wrong - and needs to be fixed.  Explain the details of the problem and wait for others to come up with solutions.  Once a few ideas have floated (and been criticized), bring up yours.  Instead of being put on the spotlight to be judged, it is now part of an idea slurry that will hopefully result in a solution.  The solution will have buy-in from others so you're not the single point of blame.

Bringing up the problem first helps people focus on what really needs fixing, rather than the how.  Creating an idea slurry ensures that the focus is on fixing the problem, rather than fixing your solution.