Should you reinvent the wheel?

One important concept we've all heard a billion times is Don't Repeat Yourself.  Simply put, this means that we shouldn't copy/paste code all over our code.  That's what functions were created for in the first place.  There's another side to this.  Obviously, re-using the same code again and again is a recipe for disaster (you need to change something in 40 places?  Too bad).

There's another angle we can look at this.  If there's already an email framework or database abstraction out there, why write your own?  My absolute favorite part of the open source movement is that we now have access to thousands of libraries, frameworks and plugins not only for free but we can view the source code as well.

The reason viewing the source code is so important is that we can learn from a product instead of just using it.  Anytime I want, I can load up GitHub and learn how to find Waldo, learn (and help develop!) an entirely new language, or crank out some poetry.

Full disclosure: The Haiku one's mine.  And I made it despite the fact that many other generators exist.  Am I "reinventing the wheel"?  Absolutely.  Did I learn a lot about Python and the English language while I did?  Also absolutely.

Reinventing the wheel isn't a bad thing.  It may be tedious in some scenarios, but it's a valuable tool in your utility belt.  It's a key step along the way to increasing your knowledge.

Richard Feynman said it best: "What I cannot create, I do not understand."

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.