10 Ways To Suck At Programming | Finalint

I recently inherited a web app from a dirty, nasty, stinking contractor that claimed to be a competent enough
programmer to be left alone to get things done. Unfortunately, we took him at his word. Functionally, most of the web
app seemed to work at first glance. However, once the client took over the reigns and actually started using it things
went downhill fast. The contractor disappeared after payment (die reputation DIE!) and I was left to try and get things
working properly and performing up to snuff while the client limped along with what they had been given.

I decided to document a few of the things that I found wrong along the way. These are really just things that every
good programmer should already know to avoid… but obviouslysome people need to be reminded (or taught).

#10 – Don’t store settings in a configuration file

When you’re writing a sizable application, things like database connections and SMTP server information will be
used throughout the app. The best way to make sure your app is entirely immune to maintenance is to redefine those
little bits of information every time you need them. So instead of putting them in the configuration file (Web.config or
whatever) just leave them in your compiled code. Whoever inherits the app will thank you for sending them on a hunt
through thousands of lines of code to change which SMTP server is being used. What’s even more fun is when the
next programmer only finds 14 of the 15 places where you’ve used this code and a single instance somewhere deep in
the app silently breaks hundreds of times without anyone knowing. Sometimes it’s helpful to build the variables
in inconsistently concatenated strings. The repeated and more frequent interaction between the new developer and the
disgruntled client will help strengthen their relationship. And if you don’t hook up that love connection, who will?

#9 – Don’t store variables in [any] memory scope

One of the great things about databases is they store your bits of information and allow you to access them whenever
you need them. To make sure your app is as terrible as possible, you’ll want to be sure and access the database every
time you need a bit of that information. The more common the information is that’s needed, the bigger win you’ll
have by making a new database connection to get that information. Non-sensitive user information is a great use of
this prinicple. Don’t worry about defining a user’s information, such as “isAdmin” to a variable and using it
throughout the current request. Just query the database each time you need to know anything about the user. After all,
the client paid for that database, we’d better get as much spin out of it as possible!

#8 – Use arcane plugins

If the client has a non-standard request, such as formatting a table in a way that is outside the abilities of your
WYSIWYG editor (colspan are hard). You should definitely hit up the interwebs and search for random unsupported
closed source plugins to do the work for you. If you would spend almost an entire hour writing it yourself, you should
spend at least 3 hours searching for and getting a plugin that does roughly but not exactly the same thing. Bonus
points if you can get a plugin that doesn’t do what you need, but offers 15MB+ of functionality you have no use for
and include it without getting caught. Bonus bonus points if the documentation for that plugin is in a language not
native to your market (for example, if you’re working in an English speaking shop look for plugins that are
documented only in Spanish or German).

#7 – Never, ever remove functionality

Over the course of developing a large application there are bound to be times when functionality you were working on
proves itself to not be needed. Now, to be sure to leave plenty of dead ends for those who come behind you to get lost
in, never delete that functionality. Maybe even comment out random parts of it, or even hundreds of lines of it at a
time, but don’t delete it. Imagine the hours of fun the future-crew for this app will have while they trace through this
functionality only to find that it isn’t needed! If you can make it seem needed, without actually needing it, it will even
keep them from deleting it themselves… This way the fun is exponential! Oh, a bonus on this one… if your project
uses source control and multiple server environments, be sure to have a different version of your files (both code and
compiled) on each server and source control. This way no one will know which one is live in production and who
doesn’t love a good round of Code Russian Roulette?

#6 – Screw performance
Large applications, you know, the ones that pay the bills, are generally needed because they deal with large amounts of
data. Sure, during your development process you’ll create 20 or so test records. Take my word for it, there’s no need
to even worry about what happens once you get to 25 records, or even 1,000! Obviously, all pagination will work just
fine and performance will never take a hit. So if it compiles, ship it!

#5 – Nest major logic/functionality in loops

Now obviously, we’ve already covered #6 so we know that we’re working with large amounts of data. And
inevitably, there will be plenty of looping through that data to do work with it. If you want to make sure your
application is really difficult to maintain and completely unusable to the client, you should embed major functionality
and/or logic inside of these loops. For example, instead of running a query against the database to get ALL the data
you need, storing the data in memory and working with the variables in memory during your loop, just get all the data
except one field up front and loop through it… then on each loop you should get all the data again, and now include
your extra field. This will guarantee that your app will never survive more than 5 concurrent users (re: #6). So for
review: Get data > create loop > get data > work with data. I’m sure you see some room for added idiocy in that
process, so feel free to nest this idea as many times as you want.

#4 – Document NOTHING

Look, documentation is for morons. I mean either you can read the code or you can’t, right (this was actually said to
me at one point)? Of COURSE the next programmer will be able to read the code. What’s really fun though, is when
you document absolutely nothing, especially not your intent. It pays to keep them guessing. You’re mysterious, like
a ninja. No need to let someone get all up in your grill, knowing everything about what you were trying to do.
Because if you document what you’re trying to do and then don’t end up doing it… well… that’s just embarrassing.

#3 – Use and reuse illogical variable names

There’s going to be a LOT of variables needed to work on this app, so you’d better choose a movie or television show
with enough characters to use all the names. Lord of The Rings, Star Wars and Family Guy are all good choices for
this. Maybe you can even form relationships with the variables. That way, you never have to kill them! You can have
variables that are chameleons, changing their usage and values throughout processing and you can recycle them for
something new each time you need a variable for new functionality. It’s like they’re growing up, evolving, right
before your eyes! After all, you’re trying to be green and reduce your carbon footprint so recycling variables just
seems like the responsible thing to do!

#2 – Catch all errors — and do nothing with them

Most languages / platforms nowadays have really good error handling built in. They’ll die somewhat gracefully and
give enough details through the default error output to be helpful. You must not allow this to happen! Start off by
wrapping nearly every tiny piece of functionality in a try / catch phrase. Then… inside the catch… put a comment, like
“// It borked lawl.” This will ensure that if anyone wants to work on this app, they’d better spend the time getting to
know the app and it’s adorable character variables before they start wrecking the app altogether.

#1 – Duplicate functionality

If the client tells you that they need two pages: One for an administrator that has all of the details on an item along
with a button to delete it; and one for a regular user which has all of the details on an item without a button, you should
create multiple pages to accomplish this. In fact, if you can make pages for each user group that would even be better.
Making a separate page for each user is the ultimate success. So ninja up and get serious on this one, because it’s
your last line of defense against the teeming hordes of qualified individuals who will inevitably be bewildered while
trying to update your carefully constructed Pandora’s box of an app.

This is by no means a comprehensive list. On this project alone I could name 10 more things that could make you
suck. But I’ll leave it at 10 for now. Anyone have more to add?