Programming Rule #3

“Thou shalt always leave the code cleaner than when you found it.”

If you’ve ever had to work on a medium to large size code base you very quickly learn that the level of effort to maintain such a beast is indirectly proportional to the level of quality and cleanliness of the source code.

Every dirty hack, every one-off, every “chunk of ‘this-is-just-temporary’ code”, every badly named variable/method, every bit of sloppily formatted code makes maintaining it that much harder.

As a result you get into a mindset that you are dammed & determined that you will not let code rot on your watch and you start to do everything you reasonably can to prevent it.

If you’ve never worked in a wide-sweeping role that brings to light how the little issues become big problems… trust me they do. One badly named method becomes several hundred badly named methods in no time flat, and suddenly you now have a confusing and complicated API due to the lack of foresight.

The end result of learning about the “Broken Windows Theory” (the problem this rule is solving) is that you very quickly adjust your approach and work extra hard to ensure that you do your 110% to ensure it not only doesn’t get worse – but it has to get better… even if only just a little.

When you come across a file, no matter how you got there… if you see a problem you do something about it.

  • Bad spacing or indentation?…  you FIX it!
  • Inconsistent attribute quoting?… you FIX it!
  • Funky statement formatting?… you FIX it!
  • Risky error prone code?… you FIX it!
  • Dead, empty or commented out code blocks?… you DELETE them!
  • Useless comments?… you DELETE them!
  • Redundant line breaks?… you DELETE them!
  • Trailing whitespace?… you DELETE it!
  • Badly named local variables?… you RENAME them!
  • Unused variables?… you DELETE them!
  • Typos or grammatical errors?… you FIX them!

The 30-60 seconds of your time to attack these problems will save many minutes for every future developer that looks at this code and in time save aggregated hours or even days of time and frustration for future developers attempting to debug when something goes wrong.

You’ll notice that many of the above issues are resolved by deleting code.  This is a good thing! In fact you’ll find that there is very little in programming that is more satisfying than deleting code! Just ask Jeff Atwood (aka @CodingHorror)!

Related: Programming Rule #1, Programming Rule #7

Every Web User Deserves Usable Form Controls – Even in Internet Explorer!

As a Web App Developer – Internet Explorer is the browser we love to hate.  However end users that use Internet Explorer (by choice or by force) shouldn’t have to suffer poor usability when we can do something about it.

The usability item I want to mention today is with regards to <textarea> elements.  Conceptually the textarea field is dead simple, a multiline text field control… but it is the little details that really matter.

The 1st problem is that by default IE renders textarea controls with a disabled vertical scrollbar when it isn’t required. Visually it is just extra noise and consumes valuable space, but it is also potentially misleading as it implies that the field itself might be disabled.

However the 2nd problem is that IE didn’t keep up with the times as browsers advanced.  All other browsers have added a usability tweak enabling the user to stretch the textarea to their desired width/height so they can see more of the content in the textarea or shrink it to see more of the surrounding screen.

I’d love to see the stretchable textarea become a native feature in Project Spartan (the new browser from Microsoft (think IE12)) but even if it never makes it in – we can always apply a little JavaScript magic to bring the stretchable feature to Internet Explorer!

Presenting StretchableTextareas! a jQuery plugin I wrote (MIT license) that adds a simple overlay to mimic the gripper in other browsers (see screen capture below).

ieStretchableTextareas

Go ahead and download/fork the StretchableTextareas jQuery plugin code on Github.

Required Web Developer Toolbox Item Number 3

Opening the Toolbox

Every developer (and in particular) every Web Developer should have several tools in their toolbox.

I’ll reserve #1 for their assorted Web Browsers + devices, and accept #2 for their favorite text editor (Sublime, HippoEDIT, Notepad++, etc.) but that leaves us with the #3 slot open.

I think this is where every developers next tool depends more on their personal approach to development and what role they are filling that day etc.  If I’m doing graphics today then PhotoShop is my next weapon, Schema refactoring? then that will be my DB management tool… or based on how long it stays open when we are coding maybe its our console(s)?

However there is one tool I think is really important to developers that gets overlooked and that’s because you typically have to write this tool yourself – and its different for everyone!

Welcome to Searching your code base!

Search & Replace with our friend Regular Expressions

On the surface this is a super easy concept… you want to:

  1. Find all occurrences
  2. of ${someValue}
  3. in files of type ${theseFileTypes}

So you put your grep fu to work using whatever search tools you like, possibly with a funky regular expression to find that dynamic/variable value that you are looking for. It works great, you find everything you’re looking for… right?… wrong!

Sometimes you can’t find what you’re looking for because basic searching is quite limited and as powerful as they are, Regular Expressions have (IMHO) a severe limitation in that you can’t search for:  (find this)(but not this word)(followed by this)

You can abuse a RegEx to find matches that don’t contain a word… (great StackOverflow.com example answer) however you will always want to find stuff before/after it and thus it all starts to fall apart.

Other things that aren’t simple to find:

  • All files containing ${keywordA} but not ${keywordB}
  • All files containing ${keywordA} somewhere in the file after ${keywordB}
  • All files containing ${keywordA} without ${keywordB} directly following it

In the case of HTML files (regardless what language you use to generate them) there’s things you might want to be able to check for that go well beyond basic searching. How would you do some of these?

  • All files that define ID attributes (e.g. <div id=”foo”>) but only those that accidentally generate duplicate IDs… and if so list which IDs are duplicated
  • All files that include a specific JavaScript file but don’t contain any calls to the functions defined in it
  • All files that include 3 specific components in any order

The solution is both obvious and just painful enough that many developers give up and don’t attempt to solve the problem – heck I was one of them… for years!

The Solution:

The solution is to write code to do your dirty work ;-) the language you use doesn’t matter as long as you can fairly quickly script up what you need including:

  • Recursively search your project directory of files (and be able to cap/control iterations)
  • Filter by multiple file types
  • Search multiple keywords (simple & RegEx)
  • Track and compare result findings
  • Output some sort of a log of all the findings

Although you might be thinking… what about the ability to make code replacements? You’re right that would be a bonus but if you get too caught up trying to handle that part (which can double your overall effort) you’ll likely give up or risk causing damage to your code files due to a corner case condition you weren’t expecting.

The good news is that omitting the replacement part actually doesn’t matter because once you have a log of files matching your query its easy to load them in your favorite editor and then run search & replace across your open files as needed.

My Solution:

As I said the language you use doesn’t matter. I went with something easy, it works with the tools I already have at hand, & requires no compiling… PHP!

I’ve created several “base” scripts that are easy to extend/edit as needed for any task at hand and whenever I need one I just hit that file’s URL in my browser and let it do all the hard work ;-)

I’ve hosted the base files for this up on GitHub in  a project called ProjectQuery (under MIT License) feel free to grab them and start building your own collection of custom code searching tools!

 

Apple Store – Genius Bar Appointments

I’ve always found the process for getting a technician or technical support at Apple to be a fair pain in the butt.

When you need to get a problem resolved you want to get it resolved right away… yet you can’t – you need to go online and book an appointment.

 

Then you need to visit the actual Apple store, wait in line again in order to see a “Genius”.

Sadly while “in line” you witness everyone else with their problems… broken screens, home buttons jammed, power buttons that won’t work, dead speakers, won’t charge, etc.

It doesn’t give customers the best perspective on the “quality” of the products when everyone you’re forced to wait in line with is having tragic issues.

What can you do while you wait?

Well I decided to write a blog post! (so far my wait is 30min) – so glad I booked an appointment!

Ugh… maybe it will get faster when customers are bringing in their broken Beats By Dre headphones :-P

 

Update: So while I was waiting to get my unit replaced after finally getting to the Genius Bar… a classic case of a broken home button and they can’t just fix that, gotta replace the whole thing!.. oh and it is passed our 12mo warranty period… so… pay up :-(  the poor woman beside me was trying to get her iPhone replaced as there was no way it was going to be fixable.  Her issue was a bit more drastic… overnight while she was sleeping her iPhone was charging… that is until the middle of the night when the iPhone/battery short circuited and caught fire! Holy smokes! (pun intended) was she every lucky that she woke up as the parts she brought in in a Ziploc bag had clearly melted under intense internal heat. Luckily just the device melted and herself and her furniture/house were all fine.

I’m sure this was a fluke occurrence and not typical of iPhones but what scared me more was that the technician (once it was plainly obvious this was going to be a “no-point-in-arguing-this-will-be-a-free-replacement” situation)… ran the customer through a “standard” questionnaire to properly file the issue.  This “standard” questionnaire included references to “putting the fire out” and “fire truck”… yes “fire truck”!!! (obligatory Bobcat Goldthwait YouTube link) – How many times do fluke occurrences have to happen before they make it into the “standard” questionnaire? ;-)

Developers Hate QA Bug Reports That…

Developers Hate QA Bug Reports That…

…include screenshots that are wrapped up and pasted into Microsoft Word documents that are then uploaded as attachments to the bug tracker tool used.

There’s never any gain in doing this other than making it harder and more complicated for the developer to find and fix the issue.

You can’t zoom in on the image, Word often scales down the image, you can’t see 2 screenshots side by side like you could If they were separate files, you can’t take measurements, etc.

If your QA testers don’t have a tool for taking screenshots beyond the CTRL + PRINTSCREEN keyboard shortcut please invest 2 minutes and download one of the many great tools out there.

If you need a tool that costs a few bucks that’s fine too… it’s a totally justifiable expense.

Call Center Phone Systems Suck

I loathe having to call up any big company to get service.

Some parts of the process are just reality but many could be massively improved with a few small changes.

In no particular order here’s my beefs:

1.) Volume control – if your “your call is important to us” voice recording is so quiet that normal people can’t hear it… or so loud I can’t hold the phone to my ear – you’re annoying customers before they can even talk to you.

2.) If the Customer Service Rep (CSR) will be unable to do anything without my account number, name of first born, and the last 6 digits of my credit card – make sure you inform me up front and collect that data from me while I’m waiting for a representative.

3.) Those automated systems that ask callers to verbally state which option they want from a menu are officially the most annoying automated systems ever designed! Seriously if you can avoid ever installing one of these your customers will thank you. I don’t think they have ever correctly grasped my intentions. “How can I help you?“… “Tech Support“… “Did you say [Printer Ink Refills]?“… “No!“… “Let me try again – how can I help you?“… “I want to talk to a real person!“… “Did you say [Wifi Setup]?“…”WTF!? you stupid piece of ****!“… “Did you say [Install Anti-virus]?

4.) Most times when you are calling for some level of tech support the CSR has a script they want to run through to resolve your issue.  It would be soooooo much better if they would at the beginning of the call politely ask what your level of technical expertise you have (or listen when you try to tell them!) so that you could skip over some of the endless steps and explanations (e.g. I know how to bounce my router, get & release my IP address, my version of Windows, how to open Device Manager, etc.)

Behind the scenes of course I realize that not every company has a good system to take care of all the details… and that the staff that know the products/services very well are likely not working the phones but anything a company can do to improve this workflow would be really appreciated by customers and hopefully happy customers will improve your companies bottom line. :-)

Alarms Going Off

We’ve had some pretty rough weather recently – an ice storm, snow, and a cold snap that made the North Pole feel like a warm place to visit.
As a result trees snapped and fell causing power outages (some for days!), roads were blocked and some odd things occurred.
Anyway on my travels this weekend took me to an industrial area where I heard an alarm sounding. I didn’t have to investigate but I did.
There wasn’t any signage on the building so I drove around for a closer look… and here’s what I found.

I filmed the above expecting to send this to the local fire department or similar to investigate. I went back around the front of the unit to jot
down the address details and I ran into a guy that worked there. It turns out that the sprinkler pipes broke and the flooding inside was as bad
as expected… he called the sprinkler guy but there was likely another 20 minutes of flooding before they got there :-(.

I’ve still got no idea who the company is, what product they make but I can only imagine that no matter what it is the water damage was extensive and expensive.

What’s the moral of this story?

Well it all ties into programming and code. I saw an issue that was otherwise being ignored (the alarm was loud and could be heard from quite a distance by many people).  Rather than just ignoring it like others were I made an effort to investigate and resolve the issue – I couldn’t as a good citizen just let the alarm go unanswered.

The same goes for code and being a good citizen programmer. If I find an issue in code (bad logic, memory leak, just plain wrong code) I don’t have to be the programmer that fixes the issue (I doubt I would have been able to put out the fire (if there had been one) nor stop the flooding) but I did need to do something!
On the code level I could also just file a bug report or told someone else about it so that it could get the attention it needs.

If you are looking to be a better programmer, be a better citizen (or a combo of both) – the next time you see something ugly in code you’re looking at – don’t ignore it… either fix it or report it.