My philosophy in regards to my work boils down to one sentence: “That’s why we have a dev environment.”

When you have a team working towards a common goal, you get to have lots of meetings, make spiffy flowcharts in Visio, delegate tasks, all that great stuff. When it’s just you with an inbox full of “I need this” emails, and you’re literally the only one in the organization who knows how to do what you do, you get to play things a bit more fast and loose. And that’s how I like it. Don’t get me wrong, processes and collaboration are important things. I simply consider myself fortunate in not having to bother with either of them.

Working more or less solo means I get to establish my own best practices, which can be both good and bad, and often is. Maybe you’ll have something to say about how I do things. In the course of my day, there are a number of bullet points I come back to over and over.

  • Google is your friend. In the course of your career, you will never encounter a problem that no one else has encountered before. And not only will someone else have encountered it, but many of them have proudly bragged about the solution online. People in our industry love to know more than everyone else, so take advantage of that. Half of what I know about my job I learned on Google. There’s no shame in this. You have the knowledge of the planet at your fingertips, embrace it.
  • Steal other people’s work. That may be putting it a bit indelicately, granted.  This is an extension of the first point. Whatever you’re trying to do, lots of other people have tried to do in the past. And when they figured it out, they probably posted it somewhere. Figure out who did it best, and grab that code. It’s okay – if they didn’t want anyone else to use it, they wouldn’t have posted it. This is a big ego thing for a lot of techies; I dream of the day someone actually uses some code I post on this blog. Just be sure to credit the author in your code, include the URL where you found it, and thank the author in the comments thread. And most importantly, take the time to figure out what they did and why it works. Saving time is an important part of this, but you’ll save even more time in aggregate if you can manage to pick up a new concept for future use while you’re at it. I’ll admit I have one bit of stolen code I still don’t understand, but I keep coming back to it.
  • Repurpose like your life depends on it. If you find yourself with the same block of code in three stored procedures, that should be your tipping point. Get it out of there and put it into its own procedure, view, function, whatever’s appropriate. Now when it comes time to alter it, you only have to change it in one place.
  • Don’t do anything but the most basic table joins and formulas in Crystal Reports. Maybe a SQL Expression here and there if absolutely necessary. If you need to do anything more intense, write a stored procedure and base the report on that. Stored procedures are more powerful, they’re repurposable, and they’re easier to use and maintain once you get the hang of them. Sure, I could do it in Crystal, and those are important skills to have. But it’s more important to know how to do things the smart way. If you’ve got three hidden subreports in there calculating shared variables, you’re doing it wrong.
  • Keep a “tricks” file. For me, this is literally a file called “tricks.sql.” It contains every shortcut, every workaround, every bit of sleight of hand I’ve gathered over years of working with SQL. I refer to it almost every day for one reason or another.
  • Don’t be afraid to break the dev environment. That’s what it’s for. You’ll want an escape plan of some kind – in my case I know how to reinstall the entire environment if I need to, though a worst-case scenario is usually just a db restore from production. No biggie. With that in hand, I’m free to tinker to my heart’s content. If a query takes twenty minutes to run because I don’t have the indexes I need and the system slows to a crawl, who cares? Or a cleanup routine I just wrote wipes out all of the patient data… good! I want terrible things to happen when I’m working in dev. Because if they happen there, that’s one less potential nightmare I have to fret over when it comes time to apply my work to production. Nothing is more unnerving to me than writing a long, complicated, potentially dangerous script and having it run perfectly on the first execution.
  • You had better have a damn good mission-critical reason for adding that trigger, mister. I used to be of the naive opinion that triggers were really nifty. Well sure, every time A happens, I want B to happen. Set it and forget it, right? It’s the ultimate in task automation! And then three months from now when you get a flood of support calls the day after an upgrade, from users complaining about mysterious error messages they’re getting and nobody including GE can figure out where they’re coming from, you start running Profiler traces and you see that red error event. And then you copy the command that caused the error and paste it into a new query window and you find the error is being thrown by cus_trThisWasABadIdea. And now you get to deliver the classic “good news/bad news” speech to your boss: The good news is I fixed it – the bad news is I broke it in the first place because I thought I was being clever. Triggers aren’t automatically evil, but they are risky and they’re comparitvely hidden among the more visible database objects. Bottom line: If you can’t name every trigger you’ve added to your database off the top of your head, you have too many.
  • Think of every task as a game. If you’re not the kind of person who loves puzzles, you don’t belong in the database world. Because it’s all about creative solutions. The same mindset that lets you disassemble those twisted nail games and then put them back together again, that’s the same mindset that’s going to find a creative way to provide the data your users are looking for. Have fun with it! Why do it otherwise? For the paycheck? You can get one of those anywhere.
  • When frustration sets in, walk away. Even give up entirely if that helps. It helps me. My process is typically that I work on a problem until I can’t see straight. Now, I know I should have walked away before now but sometimes that just doesn’t happen. I finally throw my hands up in frustration and declare that this simply can’t be done. I begin to write up exactly why it can’t be done. The reasons are often sound; but eventually, I hit a point where I realize I’ve missed something. And five minutes later I have my solution. This doesn’t exactly support my point about walking away when frustration sets in, I realize that. But in a way, declaring defeat is a form of walking away, at least for me. It’s all about getting outside of the problem for as long as it takes for the picture to come into focus.

These are the basic points that get me through my day. What can you use from this list? What would you add? What sounds incredibly stupid to you? Bring it on.

Leave a Reply