OracleBlog

Whether it's deployment, development, performance tuning, troubleshooting or something else, there are two fundamentally different ways of doing your job: doing it fast and doing it completely.

Doing it Fast

Sometimes you can make a case for doing something fast.  If you're dealing with something you're only going to do once, in a problem space you're either already deeply familiar with or couldn't care less about, and have a number of other competing priorities for your time, that's usually when a case for doing something fast can be made.

Doing something fast usually means trying a few quick ideas, either from your own toolbelt or something you saw on this site or somewhere else, and hacking away until it works, whether you understand what you're doing or not. 

It's certainly the most time-efficient way of doing your job, at least in the short-term, and at some risk.  Unfortunately there are some long-term consequences to this approach.

• Your solution may have introduced a problem somewhere else
• The problem could potentially be a more severe one that blows up in your face
• If you broke something there's no record of what you did exactly
• If the problem re-appears at some other place or time you're no better equipped to deal with it. 
• As a corollary, you're no better at your job tomorrow than you were today
• Furthermore the system is no faster and no more stable tomorrow than it was today
• Nobody else knows what you did, how to maintain it, nor how to fix it should it break
• You're at risk of developing a reputation for shoddy work with your client, boss or peers
• At the very least, you certainly didn't do anything to develop a good reputation
• You probably didn't enjoy it

For these and other reasons I've always tried to do the job the other way: completely.  There are times when the client or manager wants the job done quickly, but if the job is important enough to be done quickly, then it's certainly important enough to be done properly.  If it's not important enough to do properly, then it's probably not important enough to do at all.

Doing it Completely

What exactly does it mean to do a job completely?  Even when someone knows what they're doing and does an excellent job, the failure to properly document it, test it, communicate it and cross-train the team generally eliminates most of the advantages of doing the job in the first place.  Given that completing the task is generally harder and more time-consuming than those other tasks, it's tragic how someone is doing 80% of the work for 20% of the benefit.

A frequent mantra we've always shared among us is "the job is never done unless it's tested and documented."  There's no better way to describe the fundamental difference between doing a job fast and doing it completely.  For instance, we don't allow a customer ticket to be closed, nor a project task to be marked off until it has been appropriately tested and the work has been appropriately recorded in the appropriate place.

It may sound like common sense, especially for someone who is sufficiently dedicated to their profession to read sites like this, but it's alarming how many we come across who simply don't properly research the technology with which they're working, document what they're doing, fully test their solution (with the users), all the while communication their work with those involved. 

Consequently these people generally can't do their jobs any better in year five than they could in year two, support systems no easier to maintain in year five than in year two, spend a lot of their time fighting avoidable fires (though some of them actually like this), generally dislike their jobs, but don't have the reputation or knowledge to get other opportunities.

Doing a job completely involves five primary differences to doing a job fast: investing the time to understand the technology, taking the steps to completely the job properly, documenting the work, testing it thoroughly, and communicating with others.

1. Understand the Technology

Doing a job completely means looking at every task as an opportunity to improve your knowledge in the relevant technology.  For example, coming to a site like this is an excellent way to get a deeper understanding not only of how to solve a problem, but how the particular component in question works. 

Get a few books, talk to a few experts, work with the technology yourself (in a private development environment, initially) and develop a thorough understanding.  You originally paid thousands of dollars for your education, here's your chance to get it on the job for free (or sometimes even get paid for it).

You chose this profession for a reason - you love it.  You should really love the deeper understanding of the technology this investment in time and effort will give you.  Did you really get into this field to hack blindly at quick fixes?  To apply other people's solutions that you don't even understand?

A thorough understanding will also help you do your job faster and better in the future, finding even better solutions to even tougher challenges, all the while reducing the chances of making mistakes.

2. Do the Job Properly

Every time you do a job the goal has to be to leave the system more robust, maintainable, faster and more error-free than when you found it, and by the largest degree possible.

For example, when writing code, including good exception-handling, inline documentation, and instrumentation (debug messages).  Write your code so that it is reusable in other systems.  Furthermore, load the code into source control, and put good comments when you check it in.  Conduct a code review with your team when you're done.  There are any number of ways to improve the code, these are just suggestions (and here are a few more tricks to improve your PL/SQL code).

Speaking of suggestions, when tracking down a performance issue, set up automated performance test procedures.  Evaluate performance-testing software and get one set up in your development environment, which pre-loaded tests that can run at the touch of a button.  Work with other teams or customers that support similar technologies and create a shared standard.

When designing or deploying a system, think about security and scalability, not just the checklist of functionality requirements.  Make sure your system is appropriately designed and sized for future growth, and maintenance - build a development, testing and production environment.

When troubleshooting, doing the job properly means getting to the root cause of the problem, not just the quick fix.  There are even ways to add value when writing SQL queries.  These are the types of value-added activities that make everything you do in your career progressively easier, and your systems progressively more robust and maintainable.

There are lots of possibilities (here are a few more).  These are the various differences between doing a job properly and just doing a job fast.  It's the difference between professionals who love their job and do it well, and those who just do their time and wonder why they don't get anywhere.

At least have the conversation with yourself.  Have you found the root cause, is there something you can do to make future development easier, are there other performance issues you can track down while you're in there, or ways to help find them in the future?

3. Document

Part of doing a job properly is documenting your work.  Document the requirements before you begin, document your designs, deployment plans, tests, how to maintain it - whatever is appropriate.

They secret to writing good documentation is pretending you're someone else, and you're reading this in the future.  Maybe you're someone maintaining the work, or someone doing something similar somewhere else, or maybe it broke and you're someone fixing it.

Anticipate what this individual is looking for.  If they're doing something similar, what are the exact steps needed to do it from scratch, including explanations behind each step?  If something broke, what do you think it would be, what tests would prove it, and how would they fix it?

Be as thorough as that future individual (which might be you!) would need you to be, including the requirements of the job, names and dates, the tests and their results.

4. Test

If the three rules of real estate are location, location, location then the three rules of our profession is test, test, test.

Years ago we termed the phrase deprayment to refer to any deployment that wasn't tested.  Rather than deploy-and-test, we had one individual on our team that would unfortunately deploy-and-pray (thus "deprayment").  Don't do this, because it generally hurts others more than it does you, especially since there are many effective ways to test practically anything.

Test it yourself, have someone on your team test, have the vendor test it, have those who support systems that touch yours test it, and have the user test it.  Everyone is testing it from their own perspective.

Record your tests, include steps, results, dates, and names.  If something breaks later, even something unrelated to what you're doing, knowing what tests yielded which results on which day can be very useful troubleshooting information indeed.

It also shows a tremendous amount of respect for your system, the people that use it, and those systems that depend on it, or upon which it depends.  It reinforces the message that your system is important, and will generally result in high level of cooperation with all of them.  A level of commitment that will help you do your job more successfully, and at much lower risk since so many people have knowledge about what's going on and who's involved.

Testing is also a great way to deal with any issues that come up.  Despite your best efforts sometimes things happen, but if you have evidence that your solution was properly tested it will not only help you fix this new problem but also demonstrate to your customers and managers that it wasn't likely caused by incompetence or neglect.

That may sound harsh, but how else do customers and managers know if you're doing your job properly or not?  Good documentation, testing and above all the communication it entails is the best way for them to know that there's a difference between you and a non-professional.

5. Communicate

I've very rarely ran into a situation where someone was accused of over-communication.  Miscommunication, sure, but not over-communication.  If in doubt simply ask those with whom you have relationships what level of communication they would like (and document it).

One important type of communication is within your team.  Get your peers to review your requirements, your deployment plan, your tests, your results, and so on.  Not only can they find your mistakes, or give you ideas to improve, but it will also give them the knowledge they need to quickly hop in and help if something goes wrong - even in your absence.

It also makes your job more fun being reminded that people actually care what you did and how you did it.

Bottom Line

Though it's not always easy for customer and managers to identify the difference between quality work and non-quality work, it's real, and it's big.

The difference between professionals who love their job, do it well, and get better and better every year while their systems become more and more stable, is that they're more interested in doing their job completely than in doing it fast.

They work to understanding the technology thoroughly, do the job properly to leave a system better off every time they touch it, document everything they do thoroughly, test it completely, and communicate regularly with users, peers, vendors and other technology groups.

A lot of this may indeed sound like common sense for someone who's already looking at a site like this, but if someone forwarded you this link perhaps they're trying to tell you something.  In the long run you'll enjoy your work a lot more and get further ahead if you understand the difference between doing a job completely and doing it fast.