Are You a Pragmatic Programmer?

Do you find yourself debating about specs and architecture more than you actually write code? Do you find yourself trying to force colleagues to use the Unified Modeling Language (UML) even when you’re not a manager? Do you blog about functional programming whereas you used to blog about OO? Do you love patterns and long discussions about architecture (even with your wife or girlfriend who couldn’t care less)?

Now functional is the boooomb — you say to yourself. You say, “Scala will kill Java. Just wait.” Or you say, “Haskell is ready for prime time and should replace C very soon.” Do you find yourself quoting fancy, slick east coast software management consultants?

If some of those ring true about you, then you might not be a pragmatic programmer. First, about the consultants…a lot of these consultants come out of Carnegie Mellon University (CMU) and the Carnegie Mellon Institute think tank — sponsored, in large part, by Uncle Sam.

My MS degree was modeled after the Carnegie Mellon University (CMU) MS program in software engineering. In fact, I’m certified in something called Personal Software Process (PSP) from CMU (and a former employer/sponsor). Most of these consultants spend their time darting around the world presenting at conferences and staying at five-star hotels. They enjoy telling us peons how it is and how stupid we are.

They want us to believe without their guidance we would be like a ship without a rudder. Yeah right. They come armed with their fancy slide deck. The truth is they are giving upper management the opium fix they need. See upper management pays these big wigs to come in and solve all their problems — they hope.

The software industry went from no process hardly to speak of (ad hoc or little more) to the very rigorous processes (think Capability Maturity Model Integration — CMMI).

The CMMI is popular in regulated industries such as defense, aerospace, bio-med, etc.

A pragmatic programmer is trying to delight customers and please his boss. He doesn’t have time to fill out 20 checklists and have an audit every other week. He needs to focus on adding features and supporting the paying customer base.

OK. Listen, like I said, I have a master’s in software engineering, so I know what I’m talking about — just trust me (ha ha)! Most of these consultants come out of such programs and think they know something. You learn how to write software and manage teams by spending years in the trenches, not just getting some sheepskin.

They get published and speak at conferences because they have the creds and have something to say. Both generally good things. However, it is a one-sided debate.  I recall one such conference I attended where the speaker described how to use the Kalman filter to improve on your software process (become more optimal) by using your software metrics data. Are you kidding me?  Too impractical.  Give me a break.

Let’s switch gears and talk books. I highly recommend Steve McConnell’s writings. His book Code Complete is a must for practitioners. I studied from it at a lunchtime study group at a former employer.

I recommend you or your team do the same. Each week, someone would lead the discussion, and we would all interject our thoughts — while eating our chimichangas that we got from the chow line. See, our manager gave everyone a free cafeteria lunch pass if we attended. We also got the book for free, too.

So consider reading Code Complete if you haven’t. Form a lunchtime study group. That would be a great way to take some leadership on your team. You don’t need a leadership title to start leading.

Most leaders start leading before the title even came about. Another book to consider is the book titled The Pragmatic Programmer. It’s also a bit old but well respected. So don’t stop reading about architectures, software processes and learning the newfangled languages, but keep it real. Be a pragmatic programmer. (For those wondering, it’s called an alliteration — the word choice, that is.)

Lastly, just to be clear, I consider Code Complete to be the most seminal book on software engineering for real practitioners — no over-the-top academic silliness.  It’s all about the nuts and bolts of being a pragmatic programmer.


Stop Bashing PHP (Unless You Want To)

First let me say I’m no PHP fanboy. I do consider PHP a very viable, powerful language, especially for smaller webapps. I think that PHP apps that get very big often become rather unwieldy — perhaps even if using an MVC framework. Can a project or team write great PHP code?

Yes, I think so, but I think PHP programmers are often flying by the seat of their pants, getting code out, and making it clean isn’t as high on their priority list — how is that for a generalization? It’s just, in general, not a big cultural objective in the PHP community.  At the same time, someone can code in Python or Ruby, and it can be not so clean too.  Yet the culture in the Python/Ruby community places more value on clean code.

See, one morning you got this high school kid writing on his blog how much he loves his Grandma’s apple pies, then in the afternoon he’s kicking open Notepad++ and doing some PHP code for his new WordPress plugin.  Did he do any requirements, design, or test?  Perhaps on the fly.  Test?  What’s that.  Guess what?  His plugin goes viral and now everyone is adding features and it turns into an even bigger mess.  See what I mean.

Again, I think there is a stronger culture in the Python/Ruby community to write cleaner code. Frameworks are more commonly used in those cultures (like Django and Rails). I know there are many PHP frameworks and they are great too, but let’s face it, Rails — in particular — is awesome.

It is not unusual for some PHP projects to not use an MVC framework — the horror. In Python and Ruby, that would be less likely, especially in Ruby-land where again they have the infamous Rails MVC framework. Besides, isn’t Ruby a “cuter” name for a language than PHP — cute like watching kittens and puppies play together on YouTube. Have I just accidentally started bashing PHP? So sorry. Not.

However, with that said, I think bashing on PHP is silly. PHP was never designed to be a language used for large web applications. Although it currently runs some of the biggest ones like even Facebook. It was originally designed to be used by just one person for his webpage — that’s it.

It mushroomed into something much more, of course. I don’t think anyone can deny that PHP is also a very powerful language containing tons of code and libraries to boot.

Even Microsoft developed the ASP language with strong similarities to PHP. They have since moved to a more MVC-based language with ASP.NET MVC. Yes, again, with PHP one can be all MVC-like, but it is more common to stray from that paradigm — even if using an MVC framework. (I blame that on the historical PHP culture more than the language itself though.)

I do think PHP morphed over the years into a rather ugly language (C++ also shares some of this morphing problem — trying to be too many things to too many people). Everyone loves to bash on PHP though — way more than C++.

I admit the dollar signs can get old (influenced from the Bash shell), but don’t the “handle bars” or “mustaches” in Ruby get kind of tiring too — at least when doing template and web stuff (like when using the Ruby liquid templating library) — of course, when Jekylling? (Am I allowed so say that?)  By the way, Ruby is one of my favorite languages so don’t go throw mud at me, please.

I’m a WordPress to Jekyll convert — who wouldn’t be. Well truth is I’m back to WordPress — at least for this blog. Lots of reasons but that’s another post. So PHP can be very powerful. I once wrote a static site generator in only about 100 lines of code.

I called it Cheetah. It was my little introduction to PHP project I made. It is a testament to the power of PHP as it only took, again, about 100 lines of code to make a basic static blog site generator.  Obviously I didn’t make it generic or powerful like Jekyll though. One of my favorite things about PHP is that templating is baked in — besides having a huge library too.

Anyway, if you want to do serious web stuff, you probably would use one of the many other options out there. For example, Ruby, and to some extent Python, sure are eating away at the PHP market.

If only more shared hosting platforms would adopt Python (and especially Ruby), we would see the PHP slice get even smaller. Let’s face it. Does anyone really WANT to code in PHP? Isn’t it often just because we are trying to extend WordPress (Joomla, Drupal … yada yada) or host our app on a run-of-the-mill shared hosting platform that only carries PHP — maybe the host is even just running an old version of PHP?

You know, that low-cost LAMP stack that you brag to your mother you got for $8.99/month. I think it’s all about the right tool for the right job. For most serious web development, graduating from PHP to Ruby/Python or to Java/.NET is the way to go. Are there any banks that do transactional e-commerce stuff in PHP? Thought not.  No, most likely they are using Java or .NET — faster, more secure and not PHP.

The Five Computer Languages You Must Know for Marketability

There are probably more than five, but let’s start there.

  1. C/C++ — Despite being a really old language, I consider C to be a must— it is the Latin of computer languages (although still very much used compared to Latin). I threw in C++ as I consider C++ mostly an extension of C, albeit a big extension (a C schism). Sure, C++ is all OO friendly, but so is Java and many other languages. Hence, you can learn OO elsewhere. In fact, learning OO and C++ at the same time could lead you to go insane — seriously. C++ is a monstrosity (multiple personality language — I mean multi-paradigm) and very complex. The Stroustrup book on C++ is probably 4 times thicker than the K&R book (even compared to the 2nd edition of K&R, which was thicker than the 1st edition). It probably would take someone ten years to truly master the language. And by the time you master it, they — I mean HE, and we all know to whom I am referring — will add 100 more things to it. Often when one needs to write code in C, C++ wouldn’t be a good substitute anyway. C++ has its strengths though, in particular, it is well suited for GUI and game development and, as such, Microsoft has strongly adopted it. C/C++ is one of the approved languages at Google as well.
  2. Java — Java, despite also being a rather old language, keeps getting reborn — it must have done something good in a former life. Thanks in part to Scala and Clojure (a dialect of Lisp) — both functional-friendly languages — and other functional languages on the JVM, Java gets the benefit. Java might be the new COBOL of business programming, as it is so dominant in the enterprise, but it is a great language despite being a bit noun-heavy and verbose. I suspect Scala won’t replace Java, rather Java will continue to develop more Scala-like features (i.e., functional stuff) — as is currently happening. Java is also one of the approved languages at Google. Java is loved in the enterprise. It is a rather fast language as the JVM has got a lot of researchers working on it. It’s used extensively on the server for larger enterprises as it is very fast and secure. It’s also hard to break code on it. The Java code you write will be very well managed by the JVM — like that nanny who took great care of you while your mother was off jet-setting the world with Rico Suave. Since the JVM has garbage collection, no need to stress about malloc/new and free/delete and pointer issues. Of course with Android adopting Java, you will be able to break into the mobile app world if you so desire. Maybe you will be put in charge of sending those annoying push notifications.
  3. C# — Backed by Microsoft, it is the most used language on the CLR (usurping VB.NET). I believe knowing this language will certainly make you more marketable. The good news if you know Java, you are pretty close to C# (excluding the .NET specifics, oh, and there are many). C#, in my opinion, is a little “nicer” of a language over Java, but they are very similar — I like to personify languages, sue me. Also the good news is if you know C#, you can more easily program on the CLR in any language because you will be comfortable with .NET — as comfortable as a stripper at a nude beach in France.
  4. Swift — It is the new language from Apple and can replace Objective-C. It is a pretty language and includes automatic reference counting (think of it like garbage collection lite). That’s when the garbageman picks up “most” of your garbage. It is Apple’s answer to C#. I really like the direction that Apple has gone with this. I think this is a much better approach than Microsoft’s with the CLR. If code portability isn’t your goal (as it often is in Java), why have a CLR? Apple realized that the code their developers write is designed to run on their machines, and their machines only, so why have a “CLR-type” middleman slowing things down? CLRs/JVMs are the used car salesmen of computer science, aren’t they? Ouch! I can only assume Microsoft thought having garbage collection was worth the expense of slowing down your code with a CLR. I think Apple’s approach with automatic reference counting is a better option — ultimately resulting in faster code and a better user experience. Starting PowerShell (a .NET/CLR app) on Windows, for example, is slow — as compared to the Command Prompt, which is pure native code as there is no CLR middleman. Have you tried the GitHub for Windows shell? It is as slow as molasses. I blame this on the Windows CLR (.NET) assemblies that have to load, not Git/MSYS or GitHub. Similarly, run any Java program, like Eclipse, and tell me you don’t notice that it is slower than a “pure” native app (i.e. not running on a JVM)?
  5. Python — Python remains to be a significant language. Many universities are no longer teaching programming and OO using Java instead are using Python. Python, being in large part, developed at Google is also one of the languages approved at Google. Note there is a bit of a schism between version 2 and 3 of Python. Many projects have not upgraded to version 3 yet. For fear I am labeled a Python fanboy, I should add that I actually find Ruby more pure and beautiful (kind of like Smalltalk). I have to be a realist though. Python still has a big user-base, especially in academia, and it has a fairly good presence on the server too. Python is also great for algorithm prototyping as well as numerical computation (using NumPy and SciPy, etc.). This is the only scripting language on the list. It is important to be very proficient in at least one such language. Python has mostly displaced Perl and is starting, along with Ruby, to eat into the PHP server space too.

Honorable mention: Ruby

What about JavaScript?  JavaScript although like Node.js is more than a niche language (far from it of course), it still doesn’t have the reach of the languages listed above — outside of the browser space. Go (by Google) was a candidate for honorable mention, as well, but it is a bit too early to tell and currently is more of an experimental language.

I was also thinking about adding F# as an honorable mention, a somewhat new language from Microsoft, but I have to admit it mostly remains to be an experimental language too. You might think I missed Scala or Clojure, but I haven’t. I think Java will just adopt the best from those languages and remain to be king on the JVM. I’m sure others are saying you missed Haskell too.

This post was about marketable language skills. I consider Haskell, and other languages like it, to be very important to know, but not necessarily the best language that HR and hiring managers care about. In fact, many probably haven’t even heard of Haskell.

Keep in mind, pointy-headed managers don’t love code the way you do, and they aren’t reading blogs and coding on nights and weekends either. They are golfing and hanging out with their spouse at farmer’s markets and antique shops — ya know, living life.

Do You Love Vim and Native Apps, Too?

One thing that I used to hate was Vim. Back in the day, in undergraduate school, I was introduced to this on Unix. Yes, I said Unix, not Linux. I hated it, Vim that is. I won’t say that I switched to electrical engineering as a major to avoid having to use this editor as I WAS an EE major. Yes, my brain is pretty big. And, yes, I’m really good at math, too.

Well, for most programmers, that’s nothing new. But, oh did I pity the comsci majors. Suckers! Few girls AND they had to use Vim on a daily basis. See, in my program, we had to take C and Fortran. (There was even a girl in one of my EE classes once. I hope things have improved since then!)

That’s it. That’s right, Fortran. Don’t giggle. You’re now hurting my feelings, and I may have to block your IP. Anyway, academicians the world over still often use Fortran for their research codes, especially in scientific computation or high performance computing — number crunching! I would know as I spent some time in a PhD program in scientific computation.

So, in academia, they often refer to their software as codes. I know it’s a bit weird. Anyway, Fortran, like many languages, has evolved to be a rather nice language. You don’t have to align stuff like you did with Fortran 77. That was the version I learned. Yuck.

That is in part why some hate Fortran. The history of it with the fixed indentation requirement. Why do some languages do this you ask? Because you don’t need opening and closing braces like in C. Python uses something similar. This is in part why Python is so clean looking to read. Almost as clean as reading a book. BASIC does this too. No braces means a cleaner look and even fewer bytes, which used to matter.

So let me get back to the premise of this post. Oh, I didn’t tell you that yet did I? It must be rambling Monday — sorry it’s not an alliteration. The premise is that editing text or source code in the cloud still isn’t in prime time. (For the kids out there, prime time is when intact nuclear families would all sit around the television after having dinner together — usually from 7-9PM in the evening. Now kids are free range … oh, and it takes a village.)

OK maybe that’s an extreme. I haven’t used the big vendors’ IDEs like MS Visual Studio on the cloud as of yet. Well, actually I have no plans to either. I presume their code editor in the cloud is amazing! Bill is no fool.

Microsoft (M$) makes amazing dev tools. Visual Studio, the native program, is the best IDE ever made. Yet, play around with the free online editor on OneDrive, and you will see what I mean. Lots of stuff lacking. Like spell checking of markdown files. Gads. By the way, this is a common problem among many — if not most — cloud-based editors.

What to do? It’s all about marketing baby. What? Don’t say that word. Yep. If I told you I have this amazing editor that is native, super fast, and runs on every platform available, what would you say? Not possible, perhaps? Besides you would say the cloud is where it’s at.

My answer is Vim. Vim runs on everything. I still prefer Vim on Mac and Linux, but the Windows version is nice too. But you still want something cloud-based? Don’t you?

Why? The cloud still kind of sucks, so why do you salivate over this so much? Hum? I’m waiting. Native stuff just works. You do realize that, right? OK, you’re on a Chromebook? Toss it. Get a MacBook Air like the rest of civilization. If you’re short on cash, just ask your mom. That’s what they’re for — piggy banks for us devs.

Just don’t be so tight. Hand over your cash to Apple like the rest of us. I’ve had two Chromebooks. One wasn’t too bad. The last one I bought actually uses the Haswell processor. Yeah, great battery life and pretty fast. But I simply don’t care. Give me a MacBook Air and get out of my way, asshat (French for I don’t like you).

My point is not to fight about computers though. We can save that for another day. Rather that the cloud just isn’t that great. Before “natives” were the norm, it was all about time-sharing. IBM, DEC, Control Data, etc., were the bad boys. Add Cray if you’re an academic.

(Short aside: I studied from the same math department that Seymour Cray earned his master’s in math.)

Anyway, now it’s all about cheap clusters and the cloud. Blah. I think the cloud bites. It’s over-hyped. I still prefer native apps. They just work and they’re so fast — and fewer bugs. No browser inconsistencies either. I tried many of the cloud markdown and source code text editors (aside from Visual Studio online). Most are buggy and slow. And if you want them to work with GitHub or Google Docs, you have to grant the app Google authentication. No thanks.

Besides, if the third-party app isn’t first-party, then why? I can tell you why? Often it’s because they aren’t ready for prime time. If GitHub thought a better web app existed for editing content on GitHub, wouldn’t you think they would’ve just integrated it into their core?

Just like plugins for WordPress. Plugins that are any good usually get adopted into the WordPress core. I’m referring to open source code or apps. Of course there will always be value in third-party apps, but if the app was open source — and most bleeding edge stuff is — why won’t the bigwigs at GitHub just make it part of the core?

Like I said, they probably don’t because they aren’t high quality — at least yet. On GitHub, Gist and GitHub pages are called apps. They are part of GitHub. Hence, they are first-class apps. All the rest are third party.

When I first got my MacBook Air, a few months ago, I loaded TextMate. It’s so pretty — and powerful, too. So Vim is great, but so are others like Notepad++, too. My point is just get out of the cloud and go native. The cloud isn’t ready for us devs yet. (Again MS probably has got it down, but the rest haven’t).

(Back to Vim…)

Am I cheating on Vim? Yes, but don’t tell. I can’t help it. Sometimes you just got to do it. I mean try a different editor that actually loves GUIs and doesn’t fight them. Never forget how to use Vim though.

You never know when you’ll be at a terminal in some space station in twenty years, in a Linux shell, and need to remote in to your server and edit your code remotely — using Vim. Don’t be lazy and use Nano. Anyway it might happen!

What about Atom, made by GitHub, you say. It’s basically a native app, too. I admit so far I don’t use Atom as it seems to load slow on Windows. Crap, I just admitted I use Windows. I must go in hiding now. I use all operating systems. My main desktop just happens to be Windows.

OK, Atom kind of reminds me of Eclipse or NetBeans. The Java bloatware systems. Sorry, but if you have to use them, I get it. But if you don’t need to do Java, why the heck would you use them? Same with MS Visual Studio. Why use it if you don’t need to do C#? Or VB.NET if you’re in the last decade. Just say no!

Next time you need to write some code, open up a native code-based text editor and then go commando with PowerShell or Bash. Fudge the cloud stuff.


Sent from my Windows PC!

Break the Code to Set Yourself Free

Have you ever been assigned to work on someone else’s code? Isn’t this kind of like an artist to be given the Mona Lisa and asked to improve on it.  Well that’s assuming you’ve been given some sweet code.  More often what we are given is just typical code — some good, some bad.

Yet, writing code from a blank canvas is much more fun isn’t it.  You can use whatever “brushes” you want and the fun pastel color paints, too. If you want to paint a nude, you’re free to do so. Oh wait. I thought I was talking about code. I let my mind wander when I mentioned nudes … ex-squeeze me.

But when we code, that blank file MyNewFile.c is heaven. And seeing someone else’s code is a complete bummer — kind of like seeing your plumber’s plumber’s crack.  First you have to make something of the mess of code you’ve been given, because at some level all code is just a big mess when you first look at it.

Maybe it’s even written in a crappy language, too — in other words, anything other than C, right?  (I’m a bit of a C purist, sue me.) So here you are, PHP (barf), and your gun has no bullets.

Besides you couldn’t leave your manager with this mess. Or have to have the emergency first responders need to take your fat dead body out on a stretcher — huge mess, too. Too much work… We can spare them.   Let’s figure this out because at some level we have our eyes set on a rock star lifestyle.  And rock stars don’t quit — they just OD!

But we are artists, right? You’ve coded naked at home on the weekend, right? Maybe even thought of slicing off your ear when you couldn’t find that one bug. But, how can that bloody manager ask us to work on some else’s art? How rude. Oh, I guess if you want to keep getting that darn paycheck, we better fix our attitude. I imagine Linus Torvalds even gets patch requests that look like sh*t and makes him want to swallow a gun muzzle, too.

But he managed to push through the pain and so can we. I’ll slip into my big boy pants now, but I’m going commando when I get back home, OK.  (Right now my gay male readership — if I have any — is doing backflips.) Let me drop some quisi-senior citizen wisdom on you.

There are two major approaches to working on someone else’s code: first approach, you change only what you absolutely have to and then run for the hills, and, second approach, you make it yours, own it, and change it to your heart’s content.  The latter often involves going on your blog and slandering the piss out of the original author as well. (Ha ha.)

First, many times the former is the way to go. Sure, sometimes you would be a fool to do anymore. Yet if you expect to have to make a lot of changes to the code going forward, I say own it. Make it yours.  Put a ring on it.

So often we don’t do this though.  Instead, we tread lightly, not wanting to break the code … or make any noise as we approach the deer in the woods.  The slightest noise and they flee.  (Where my tribe is from deer hunting is popular among “real” men (and women, too).  I tried it but flopped.  Too much of a sensitive intellectual perhaps.)

If you own it, you will care about the code. Caring about the code is the most important thing there is. If you care about the code, you will make sure your customers are delighted; you will make sure to produce high quality software. It will now be your art — your masterpiece.

The fear of breaking a codebase can cause concern though.  If the codebase is large or poorly written, it gets even more scary.  And if your boss is a jerk, you might be less inclined to take chances.  Other issues might be the codebase is poorly documented.  We all know how common that problem is.  Or the codebase has docs but they haven’t been kept up to date — another common problem.

So sometimes you need to just spend time documenting the code before you jump in.  Do a high-level flowchart of the code.  You could use Visio or just do it in a notebook for starters.  By charting out the software and various interactions, you will have a great head start.

Next make sure you understand all use-cases.  Do your homework.  Figure out what the heck the code does and how it does it.  Be patient.  This can take some time depending on the size of the code, your familiarity with the language and your knowledge of the problem domain.

But get in there and don’t be afraid to break the code.  You will learn by breaking code.  Of course, try to break the code without it going live and messing up your customers.  But definitely get in there and mess around, discover, break, and create your genius.  Leave your mark.  Own it.

Your confidence will grow as a developer.  When you face fears, you will inevitably conquer them.  You will quickly become the go-to person for the codebase.  Your manager will see you’ve got gumption and are self-led.  Both traits highly valued in any profession.

The worst case scenario is you’ll break the code really bad and spend a few hours reversing changes from your source control tool until you get back to a working version.  Now, if you don’t use version control software, you’ll have a bigger problem!

So the next time you are assigned to work on someone else’s code, own it. Make it yours. The best code is that which is produced by someone who really owns it and takes pride in their code. Sign every header file with your name like it’s your art. Because it now is!

The 7 Habits of Highly Effective Programmers

If you’re like me, I’m sure you’ve had someone do some construction work on your house or maybe you just hired a painter.  Well, there’s that painter who gets paint all over everything as they don’t put down drop cloths.  And there is the painter who leaves drips on the wall or misses spots.  The whole time the painter is painting your house he tells you how his real passion is to be a writer.  Painting is just how he pays the bills.  And guess what, it shows!

After you give that painter his walking papers, you find that rare painter craftsman.  He believes his destiny was to be a painter.  He loves the craft and is always working to perfect it.  He doesn’t accept payment unless his customer is completely satisfied with his work.  Every morning before he starts painting, he meditates or prayers for a higher power to work through him.  He is humble with his gifts and generous with his time and talent.

Programmers are as varied as they come.  Some love to jump headfirst into coding on a new project while others like to plan out every move before writing a line of code.  From working with many programmers over the years, I’ve gleaned some common traits to highly effective programmers.

Highly Effective Programmers …

  1. They code for love, not money, fame or power.  The only reason they live is to code and share their gifts.  They are pushed to code via a deep force or power, a muse.  They discovered a need or problem to be solved, found a challenge, or have something to say through their code and its impact.  They take great pride in their code and are compelled to make their code both beautiful and powerful as well as leave a mark on the world.
  2. They code without abandon.  They know they are gifted and must use their time on Earth wisely.  They don’t waste time debating about computer languages or software processes.  They code ’til it hurts.
  3. They take requirements gathering seriously but aren’t anal about it either.  Too many programmers jump head first into coding.  They get virtually half done and then realize there design is untenable for scaling up, or has left the project overly complex or difficult to maintain.  Worst yet, they render their code a resource hog perhaps with many bugs, too.  On the flip side, programmers can get into analysis paralysis and never hardly get off the ground.  Or take two years for a project that should have only taken 6 months.  I think we’ve all see too many times projects like the latter.  Highly effective programmers need to find a balance.  Do a sound job of gathering requirements but then get coding and create their genius for the world.
  4. They put their name and reputation behind their code.  They sign all of their code files in the same way an artist would sign a painting.  They do this by typing their name (and cell phone number) and other comments in the header of each source file they make.  They remain accountable to the program even if they no longer are on the project or even at the company.  If someone has a question two years later, they are more than available to field it.  They know their reputation demands it and that it’s the right thing to do.
  5. They test their code with passion.  They review their code and spend about a third of their time on the project testing the code.  They test at the unit level, mid-level, and systems level.  They test against the requirements and when time permits, ensure test automation exists, such as automated unit testing.
  6. They continue to sharpen the saw and master the craft.  They see learning and teaching (and even research) as one of the highest virtues and spend much time reading and learning about the craft.
  7. They’re humble and a servant to others.  They know that they are pre-destined for greatness.  They also know that although they possess the gift to code, they know they are not entitled to the fruits of their labor and instead give back to the community.  That is, they open-source all their code they reasonably can.  Although they don’t take a vow of poverty, they believe that the fruits of their art will benefit the world and ultimately later be reflected back to them as well.

8 Tips for Debugging using Top-Down Techniques and Divide and Conquer

Here we go.  Debug.  People love to write about software methodologies but rarely about debug.  Yet, it’s one of the most important skills any developer needs to have.  I was once asked about my typical debug strategy in an interview, so we know it’s important and says a lot about where we are on our programming journey.

First let me say, before you get involved with doing debug, make sure you’ve reviewed your code.  I don’t know how many times I’ve taken a shortcut and jumped right into debug only to find out that the error would have popped out at me if only I would’ve reviewed my code first.

So, now, assuming you’ve reviewed your code.  What then are some good tactics to employ when doing debug.

Well, of course, a lot of that depends, right?  I mean, what kind of software are we talking about?  Is there a server or database involved?  Are we dealing with a mobile app, or are we talking about an old-fashioned desktop program?

Let’s speak in generalities since we won’t define anything too particular in order to keep this post fairly general and high level.

Do you remember when you first learned to program?  Maybe it was in BASIC or C?  Probably Python, nowadays.  Anyway, my first language was BASIC in high school.  My first “real” language (compiled language) was C in college.  I remember my great dependence on the printf statement when problems occurred, and they will.

Of course, we were told that more sophisticated methods of debug would later be taught.  Turns out the old print statement still is very useful though, and I have no shame in admitting it or using it.

Well, of course, now you can put in fancy try/catches in many languages, which can be helpful too.  Did your teachers ever really explain how to use a debugger?  The tool that often is integrated within the IDE or in the case of GNU comes in the form of GDB (to support GCC).  That little tool, albeit a bit cryptic, is so powerful especially for finding memory-leak related stuff and pointer issues.

Let’s first review some of the more common errors that we might find before we get to some debug tips.

  1. Segmentation fault (memory or pointer issues).  This usually occurs when you step on memory that doesn’t belong to you (a misuse of pointers), or you run out of memory all together — i.e., you haven’t released unused memory or tried to acquire more memory than exists.
  2. Stack overflow.  This usually results when your function calls go too deep.  For example, when you call a function recursively and it takes too many recursive calls before the exit criterion is met.
  3. Overflow, underflow related errors.  Overflow usually means you divided by zero — or a number close to zero — or you are trying to represent a number bigger than your data type allows.  Underflow is the opposite of overflow.  Imagine dividing a number by something close to infinity.  The result is an extremely small number that can’t be represented by your data type.
  4. Allowing your algorithm to blow up.  Common issues are underflow and overflow, and stack overflow.  Exceeding array bounds, etc. (Related to 1 above.)
  5. Precision errors.  Say you use floats instead of doubles.  The accuracy of your answer will be compromised, or the algorithm may become unstable and cause an underflow or overflow error.  This tends to be more of a problem in math and numerical-type programs.
  6. Input related faults.  Faults related to not checking for the proper input data types or bounds on the data, etc.  These can cause all sorts of different kind of errors or faults.
  7. Logic errors in your program.  You implemented an algorithm incorrectly, for example.
  8. Communication errors.  Say you are trying to communicate with a server that is offline and didn’t write code to deal with this condition.
  9. Errors in a library, plugin or API, etc.  These can be hard because you often aren’t expecting it.  OK, if it’s a WordPress plugin, you probably expect it.
  10. Less likely, but sometimes the OS or browser can even cause problems.  Say a systems call has a bug in it, or a bug exists in the browser where you run your webapp.  These are even harder because you aren’t expecting it.  This can happen more so on custom operating systems or an OS that doesn’t have a large market share (same with browsers).
  11. Output error.  Say you are trying to print or control something that is experiencing an error. (This is similar to 8 but it can communicate.  Instead, it just doesn’t know what to do when a fault occurs.)

Of course, with some languages, like Java and C#, you’ll never have pointer issue as you don’t have that kind of control.  Same with memory on the heap.  You can’t acquire memory from the heap, so you never have to worry about releasing the memory back to the heap (garbage collection does it for you).

Java and C# has some nice abilities using the try/catch related constructs as well.  These can often allow a programmer to catch underflow or overflow issues, as well as deal better with unexpected or “bad” input, etc.

Well, that’s a nice review of some of the common errors one might have to deal with.  So what can we do if we have one of these errors.  Sometimes the program (and/or operating system) will tell us which error occurred, but often we don’t really know.  Say it’s a bug in a library, the browser or even the operating system itself?

So here are the options I usually employ — first assuming I’ve reviewed my code and don’t see anything wrong with it.  And when I say review my code, I use a two-step approach.

First, I do a quick review, and then, if that doesn’t help, I scrutinized every line as if I’m back in grad school and analyzing a math proof for correctness.  (I had a rule of thumb that if the professor was over 70, I would assume he had one or more bugs in his proof —  actually, usually just omissions.)

  1. I revert back to dropping a couple of print statements in areas of the program where I have some suspicion.  Here, I use the divide and conquer approach.  The essence of divide and conquer is to continue to break down the problem into smaller pieces unless you find the root cause.  If you are familiar with binary search, you are familiar with divide and conquer.  In binary search the data set is continually cut into half until you find your search item or determine it’s not in your data set.  I’ll write more about this general approach in another post.  What do I print?  Sometimes just statements that say I am on line 333.  At other times, I print out variables that I suspect are related to the problem.
  2. If the language has try/catch constructs, I add a few in areas where I think the problem may reside.  Again using divide and conquer.
  3. If step 1-2 didn’t work, I pull out the bigger guns and invoke the debugger.  I set break points and inspect variables where I think the problem may be occurring.
  4. In this step, I may create several print statements that print to a file.  Hence, print a log file while the program is running.  Often the bug was discovered using earlier steps and I never even have to use this approach.
  5. I decouple the program as much as possible.  I test each module/class/file as much as possible outside of the program using a small test-suite driver program.
  6. I further decouple the program by doing unit tests on each method or function outside of the program using a small test-suite driver program.
  7. I ask a coworker to review my code and the issue I’m having.
  8. I set up a code inspection with the team.  I consider this an all-hands approach.  Sometimes this can work when you have a really tough one that you and your code buddy can’t figure out.

Generally the tips come down to top-down strategies and employing divide and conquer, decoupling the problem, and putting your ego on the back burner and asking for help.

Other things to consider before enlisting help.

  • Take a break from the problem or bug.  If you can, work on something else for a while.  Give your brain a break.
  • Maybe even tackle it the next day after you’re more rested and have cleared your head.

Of course, a no-brainer is to Google any error message(s) you get.  I figured that was too simple to add to the list, but let’s face it, it’s often a smart idea before going too far down other paths.

We’ll there you have it.  These are my usual go-to strategies I employ.  Of course, these are meant to be rather generic.  If I was doing embedded software, for example, I would probably set up an emulator. And if I was doing some web stuff, MUCH different — like hanging out in the browser, forever. But, nonetheless, many of these debug principles should carryover across various areas of programming.