If you’ve spent any time at all developing software, you’ve – willingly or unwillingly – had to come to terms with the fact that a huge part of your job isn’t writing new code, but is instead about playing detective and recreating causes to problems so that you could fix them.

Here, your job as detective can be made much easier when the coder version of you – the criminal in this metaphor – has left behind obvious and useful clues as to what’s going on within your system. Future you, your current and future coworkers, and people you’ll never meet will some day thank you. When you have to go through systems trying to solve obscure issues that have brought your app to its knees – and the boss, standing over your slumped in distress shoulders with a scowl on his face, to your desk – these clues will be like water on the parched lips of a man lost in the desert.

One of the first places you’ll look to when faced with an unknown problem will be whatever logs you’ve thought to generate as the system is running. These logs contain a great deal of evidence, clues, eye witness accounts, and direction that can help you piece together exactly what’s going on. They can also become a source of frustration if they were created carelessly or if they generate so much information that they’re basically useless. Just as with any other tool, it’s important that you understand how to best use their unique features to your advantage to help you make your life easier.

Just like comments, logs help you understand what’s going on, and just as comments such as:

//adding one to the variable x
x += 1;


Tell you basically…nothing, a log like:

2013-04-18--[3] - ERROR - Something bad happened with the input.


Is equally useless. While grep will be your savior in pinpointing errors, keeping your logs clear will allow you to find these errors more quickly and generally keep your system more maintainable, just as writing clean code keeps your code base clearer.

Generally, the following guidelines work well for me, but as always it’s important that you figure out what will work for you and your team:

DEBUG: Here I log everything that I’ll want to know as I’m developing and debugging my code. This is stuff that’s helpful when I’m first building my system and helps me get a very detailed idea of what’s going on, but stuff that I wouldn’t miss when it comes time to solve production problems.

INFO: General business logic messages, progress, etc.

WARN: Recoverable issues, typically things like missing configuration values where the code reverts to some sane default value.

ERROR: Serious and unrecoverable issues. These will be what you grep through your logs looking for and logging non errors at this level will make your life Very Difficult when trouble comes knocking. Your database is down, your caching server isn’t responding, etc.

Again, these are just my general guidelines – the point is that I want to log as much information as I’ll need when something bad happens – and nothing more. There are a lot more detailed and great logging tips out there, if you want do a deeper dive.

One of the principles I live by both in my professional as well as personal life is to appreciate what’s come before me. Recognizing that while there are often opportunities for improvement, decisions made before you were around are what allowed you the opportunity you have today to make things better.

I again thought about this as I read a great interview with Ricky James that the New Yorker published back in 1993. Ricky is held in extremely high regard by all those familiar with him – from fans to most importantly his own peers – for his considerable technical and social skills, style, wit, and charm. What elevates Ricky above the rest, I’d argue however, is his deep held respect for the past and for those that came before him, paving the road he walks today.

He’s appalled that they haven’t read this stuff

Though it’s given him the reputation as being aloof, Ricky’s inability to comprehend his supposed peers disinterest in their craft and their lack of education and commitment to it is precisely what allows him to reintroduce techniques and tricks that nobody else is capable of, let alone aware of.

We can all learn a valuable lesson from Ricky James’ commitment to history and to learning, even if we aren’t necessarily in his league (yet!) as far as our relative expertise in our chosen fields goes. Ricky’s refusal to participate in their self congratulatory social gatherings and their disconnection from the point of what magic should provide – a sense of wonder – and their focus on tricks and stealing them from others without originality mirrors some of the disillusionment I feel from so many people posturing for a slice of the internet pie that must seem so easy to grab a piece of. The mobile and web has created yet another gold rush and has inundated us with poseurs and smug wave after wave of founders, co-founders, presidents, CEOs, and whatever other title of the day people are giving themselves in company after company that they continually spin off, pivot, bootstrap, aquihire – blogging, tweeting, speaking at conferences, and generally spewing the image they want of themselves out into the world incessantly, trying to reach for those streetlights, so they can bow out, cash out and…what then, exactly? Wait for the next gold rush? I’d venture to guess that many of these people are in the game of feeding their ego, and if a new wave of financial opportunity came raining down in the form of new widgets, they’d line up right next to all the other widget makers, selling their services, offering to teach you how to make new and better widgets, and promising to change the world of widgets in a way nobody has ever done before – that they know of, at least…

If people gave 1% of the effort they’ve spent on marketing and imagemaking and applied it to learning and applying the craft they’d like the world to think them a part of, where could we be today instead? So much time and potential is flushed away in these falsities.

Granted, there are always vocal minorities which paint an ugly picture of the hardworking and dedicated masses, and this case is no different than any other. Still, in Ricky James’ honor, I feel that separating from and calling out the fakers when we see them should be the responsibility of everyone who wants to keep some of the art in what we do for a living –  back when it wasn’t about investors and monetization schemes and ad revenue – back in our mother’s basements as children, hunched over keyboards in the dark, pecking through history and finding the wonder and magic behind the screen.

It’s well known that a major component to a successful user experience is absolute consistency. Apple does this better than almost anyone, and as their desktop and mobile OS quickly merge it will become even more consistent than it already is today.  For the most part Microsoft is a close second, and I say this even after factoring in the fact that the new Metro UI has a certain disjointed feel to it of something new bolted onto something old. In fact, their consistency has opened them up to criticism: Windows 7 wasn’t so different from Win95, after all.

While listening to a great interview over at This Developer’s Life, I started thinking about how I personally deal with stress and pressure. We’ve had our share of catastrophes at WAM, like everyone in the game of software development it comes with the territory whether it’s working on client projects or your own products. The scenarios are the same: something isn’t working the way it’s supposed to work, there’s a problem you never saw before, and someone is upset – worse: they’re looking at you to fix it.

Like so many times in life, you have two paths you can choose to follow in these situations, the way I see it. You can Panic or you can Relax.

I, being a child of the 80s, will always and forever listen to Frankie, and Frankie says “Relax”. In addition to being an amazing dance song, it’s also sound advice in almost any situation where it is an option.

In the South Seas there is a cargo cult of people. During the war they saw
airplanes land with lots of good materials, and they want the same
thing to happen now. So they’ve arranged to imitate things like
runways, to put fires along the sides of the runways, to make a
wooden hut for a man to sit in, with two wooden pieces on his head
like headphones and bars of bamboo sticking out like antennas–he’s
the controller–and they wait for the airplanes to land. They’re
doing everything right. The form is perfect. It looks exactly the
way it looked before. But it doesn’t work. No airplanes land. So
I call these things cargo cult science, because they follow all the
apparent precepts and forms of scientific investigation, but
they’re missing something essential, because the planes don’t land.

As of late, there’s a lot of great stuff I like about what Microsoft has been up to. They’re more open, more transparent, and more connected than they’ve ever been – and I think the result of all this is a more relevant company than they’ve been in a long time. Today, Microsoft announced TypeScript as one more attempt to reach out to developers, make their lives easier, and make the web a more open place and a platform that’s easier than ever to develop for.

It’s common in technical fields to attract the more introverted personalities. Often, they’ve honed their skills over a period of years, working alone in their bedrooms and offices, absorbing content from manuals and documentation that nobody else reads. Even in today’s hyper-connected world where there’s a forum of likeminded individuals studying the same fields you’re interested in, it’s still very much mostly a solo endeavor. At the end of the day, you still need to sit down and create and implement a design, write code, test, deploy, and any number of other tasks related to today’s tech world – and do it alone.

Because of this, there’s a tendency for these personalities to retain a go at it alone attitude, even when working side by side with others in an organization on a complex project with many moving parts. This is true in a large organizations as well as small: In our company, which is still tiny at under 20 people, attempting to work in a vacuum often creates problems.

A couple of days ago, DoneDone - the issue tracking tool (for humans) that I help work on at WAM - experienced some downtime due to a server update which inadvertently rebooted our servers. While the fact that DoneDone was down for a short period wasn’t anyone’s idea of ideal, I can’t help but get excited when we make mistakes because mistakes are the only currency I can create, and I can spend that currency on lessons that help make our organization better.

We have a framed picture at our office that says “Work Hard and Be Nice to People”. Simple and pithy? Yes, of course – all good mantras need to be.

As my years in the industry have inched past a decade, I’ve been exposed to more and more types of projects, unique (sometimes great, sometimes not so great) personalities, and various hot new tech fads that will Solve Everything. The more things change, though, the more I keep coming back to this idea as the single most important point in my personal Code Of Ethics. Work Hard. Be Nice to people.