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.