Saturday, August 11, 2012

The Two Ways of Doing a Job

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.
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.



Comments:
That's a very useful post.
Too many situations (artificially set unrealistic commercial deadlines) pressurise developers to follow tactical patchwork rather than develop well engineered solutions.

Sometimes solutions are created as proofs of concept and need work to get them production ready - but 'business' and even non technical PM's can get tempted to get 'cheaper resources' to copy-paste and 'get things done' , to their own long term detriment.
 
(h/t Karen Morton) How would you like your graphic design
 
HI!

You post help me rebuild my brain.
I re-read you post several times.
I start understand what mean - Professional!!!

Thank's for the Article!!!
 
Thanks for your article, it is arrive just in time in my professional life!!!

Peter
 
Hey Robert,
I have found your blog, which I really like it. Enjoyed to read your posts. Hopefully, you will continue it.
I was wondering if you would be interested in sharing your posts and ideas on Glipho? It's a quite new social publishing platform for bloggers, where you can connect to every social network accounts.
 
Path Infotech is in the field of oracle training program from past several years.

For more info : Ocp Certification
 
That's nice, thanks for sharing.
 
non quality work is fast and dirt. but is short term and will haunt you in the long run
 
SAP by definition is also name of the ERP (Enterprise Resource Planing) software as well the name of the company. SAP system comprises of a number of fully integrated modules, which covers virtually every aspect of the business management. Visit Us,
Sap training in chennai | Success factor training in chennai
| Workday training in chennai | SAP ABAP Training in chennai


 
Very informative feature indeed, i have come across a similar solution at an ERP Job Board
 
SAP is one of the customer relationship management software and it support all end to end customer related process. To know more details about SAP modules please refer the following site.
Regards..
SAP Training in Chennai
 
Oracle customers features
Performance and scalability
Deployment fexibility
Availability and Reliability
Support for very large databases
security
Management and self management
Reduced and cost.
http://www.thinkittraining.in/oralce-apps-dba
 
An Oracle database is a collection of data treated as a unit. The purpose of a database is to store and retrieve related information. A database server is the key to solving the problems of information management. In general, a server reliably manages a large amount of data in a multiuser environment so that many users can concurrently access the same data. All this is accomplished while delivering high performance. A database server also prevents unauthorized access and provides efficient solutions for failure recovery.Get more ideas :http://www.thinkittraining.in/dba-training
 
Latest version of Oracle 12c is a version of the Oracle Database. The "c" stands for "cloud" to indicate that 12c is "cloud enabled". It features a new multi-tenant option that will help companies to consolidate databases into private or public clouds.
Get more upgrade knowledge for http://www.thinkittraining.in/oralce-apps-dba
 
Features of oracle latest version:
ASM in Oracle Database 12c continues an evolution of superior storage management for the Oracle
database that began with Oracle 10g. In Oracle 10g ASM was designed to address one goal really well;
to improve the automation and manageability of storage for Oracle databases. The next phase for
ASM’s evolution was in Oracle Release 11.2 with the introduction of ACFS providing complete
manageability for all customer data. ASM in Oracle 12c continues this tradition by addressing storage
management requirements for cloud computing in the enterprise. New features in ASM for Oracle 12c
enable storage management to seamlessly adapt to changing requirements and configurations. Part and
parcel of this phase brings several new features enhancing management for Oracle’s engineered
systems, such as Exadata and the Oracle Database Appliance.
http://www.thinkittraining.in/oralce-apps-dba
 
By posting the details based on the Oracle will enable the user to know more about the relevant ideas about that. Thank you for updating this type of posts.
SAP Training in Chennai
 
The Oracle content is easy to understandable way.It is good article.We also provide the abap training in our institute.It is fully concentrates on basic level to advanced level training.
abap-training in chennai

 
The information about the oracle is good.It is easy to understandable way.Our abap course is enough for anyone who wants the certified training.It is used to get excellent job offers.It is used to improve your career.
abap-training in chennai

 
I got some valid information from this article. It is very happy to know about Oracle.

SAP Training in Chennai
 
Post a Comment

<< Home

This page is powered by Blogger. Isn't yours?