Process, People, and Tools - where do you place your trust?
-
Let me explain. Process: do you have processes that you trust? Are the processes there to compensate for mistakes people make, or to facilitate the work they do and facilitate coordinating work among people and across departments? People: do you trust your coworkers to do their work competently, to follow the processes, etc? Tools: Do you trust your tools, or are your tools causing problems? Are they causing problems because the process of using the tools is broken? The people using the tools don't use them appropriately or haven't configured them to actually be useful? So, where do you place your trust? Marc
It's quite shocking the number of people who only trust in themselves. This really doesn't do you any favors in the long run. For a start it kinda suggests you need to work a little your social skills! I once felt exactly the same. Then I realized that my dreams were far to big to become a reality relying only on myself! I came to the conclusion that unless I code up an intelligent being, I'm not going to get very far by myself. Trust is earned you don't have to trust everyone, be frank if they don't do it to standard then tell them. Processes above tools any day thats an easy one. AS for people, they should be trusted to develop the processes with you. The guys following the process should feel responsible for improving and maintaining them with support from their managers. The guys doing the work should also be working on how they do it! Managers should facilitate this, they should get their hands dirty and understand things from the bottom up. This rarely happens how many times have you had to follow a really dumb process? But don't moan too much the coding world is far more advanced in terms of processes and standards than many other industries. This comes with the job a good coder secretly get all excited by the idea of standards.
Steve O'Brien A successful person isn't necessarily better than her less successful peers at solving problems; her pattern-recognition facilities have just learned what problems are worth solving. - Ray Kurzweil www.newicon.net
-
Let me explain. Process: do you have processes that you trust? Are the processes there to compensate for mistakes people make, or to facilitate the work they do and facilitate coordinating work among people and across departments? People: do you trust your coworkers to do their work competently, to follow the processes, etc? Tools: Do you trust your tools, or are your tools causing problems? Are they causing problems because the process of using the tools is broken? The people using the tools don't use them appropriately or haven't configured them to actually be useful? So, where do you place your trust? Marc
Marvellous question! The first port of call is whether you trust the people. People have to earn trust and prove their competency not just to their employers, but also to their co-workers. I don’t have trouble trusting someone who has demonstrated their competency. If you are surrounded by people who have sufficiently proven their competency and are trustworthy, then you can look at the process. The processes are (in my humble opinion) both a way to catch and compensate for mistakes and a way to improve coordination and effectiveness in the team. Bad processes can ruin good developers and good teams, but I believe that good teams will naturally gravitate towards good processes. Processes are only as trustworthy and effective as the whole team. I always view a process with a little suspicion and I always question the processes’ effectiveness and the steps involved in it: is it as good as it can be? If the team is good I have less suspicion about the process but if the team is bad I have great trepidation about the process. This leaves tools... there are some good tools out there and some bad ones. If a good team with good process is using a bad tool then you will get bad results, but the good teams will again naturally gravitate towards good tools. Like processes, I always regard tools with suspicion: does this tool really help me in my work? If it doesn’t or I can find a better tool, then I use a better tool. Even if a tool is spectacular, it will not solve the problems of a bad team or a bad process. I've been doing some research about this area recently and thought I'd share a little of what I've learned. Ciarán
-
Gary R. Wheeler wrote:
So... why are you asking? Feeling betrayed lately? The System got you down?
Because my client has broken (or actually no) processes, people have proven to be untrustworthy, and the tools don't work, probably because of the lack of processes and the inept people. Marc
Marc Clifton wrote:
Because my client has broken (or actually no) processes, people have proven to be untrustworthy, and the tools don't work
SN-AFU.
Cheers, Vıkram.
Stand up to be seen. Speak up to be heard. Shut up to be appreciated.
-
Let me explain. Process: do you have processes that you trust? Are the processes there to compensate for mistakes people make, or to facilitate the work they do and facilitate coordinating work among people and across departments? People: do you trust your coworkers to do their work competently, to follow the processes, etc? Tools: Do you trust your tools, or are your tools causing problems? Are they causing problems because the process of using the tools is broken? The people using the tools don't use them appropriately or haven't configured them to actually be useful? So, where do you place your trust? Marc
I am equating trust with predictability - mainly. Least is People. As the circumstances change their commitment and performance becomes less predictable. I'm not a mind reader. Emotion, prejudice, greed, laziness, etc. clouds reason. Process, if you mean the broader sense, can be very predictable. There are always processes at work. Knowing how to discover and normalize them can result in a high degree of predictability. I was a process consultant for a large CPA firm at one point. I did forensic systems work mainly. There was always a predictor that the client missed that foretold the failure of the system they bought or built. I was hired to find it. The result of this was often messy. I learned lot about processes and systems project management doing this. Tools used the same way each time are very predictable, if viewed as implementations of algorithms. I certainly have doubted the ones I use daily when I keep getting a syntax or logic error. But its always me and not the tool in the end. Sometimes limitations in tools like interpreters and compilers are at the root. The messages are misleading but there is an error there. One bizarre one I had recently, when coding too late and should have stopped but stubbornly kept going. I had misspelled my JavaScript Array prototype statement. I kept getting a syntax error that I had an extra \n hidden somewhere (a nasty red herring). I thought I may have entered a control character or had a \n in position 200 on a line, or something similar. I was starting to doubt my VM, then finally after Firebug, Komodo, IE Dev Toolbar, etc., etc., my eyes cleared for a moment and there it was a dumb-s... typo. :)
"Coding for fun and profit ... mostly fun"
-
In my business, I trust process first, then people, then tools. If we make a mistake, people can die and property burns. Every action is preceded by writing a process, called a switching procedure, then all of our staff review it. It's called a "tailgate" meeting. The newest apprentice is entitled to object or question any step, and everything stops until that question is answered. I, myself, when I was two weeks on the job asked a question about a switching action, and everyone listened. It turned out that I'd caught a step missed by my boss, who has 30 years' experience doing what I'd never done at the time. They listened, corrected the procedure, and thanked me for catching the mistake. Tools can always fail, however simple. We use insulated hotsticks for switching, but we wear gloves rated for 30kV when using them, because sticks can fail and you don't live through it usually. There's nothing we can do about multiple failures, but we never fail to take every precaution available, just in case. I deviated from the intent of your question just to illustrate the wide range of possibilities. I know you're talking about other circumstances. In general situations, I trust the people who know how to get the job done. Policies and procedures are just shortcuts to avoid thinking, and having to evaluate all situations individually. All policies and procedures need exception mechanisms that allow people to make the final decision; things come up that the standards didn't anticipate. Both tools and procedures also become obsolete, and need to be re-evaluated once in a while. Those that no longer fit should be abandoned without remorse. One of the best books I've ever read is called "Sacred Cows Make The Best Burgers" and I commend it to your reading list. From it I learned ways to objectively view policies and procedures that have been in place forever and to unemotionally determine whether they really fit the way we do business today. Those that no longer work need to be dumped, and new ways defined. Similarly, people who will not give up doing things "the way we've always done it" need to be dumped. They only impede the progress of the rest of the organization. Overall, to function efficiently you must be able to trust all three - Processes, people, and tools. Any that don't function must be put to pasture or the company is doomed.
"A Journey of a Thousand Rest Stops Begins with a Single Movement"
Roger Wright wrote:
Sacred Cows Make The Best Burgers
The title alone is great :-D.
Software Zen:
delete this; -
Processes? We sort of have a process; you write the code, you test the code, somebody else tests your code. This generally finds coding mistakes. It doesn't really coordinate anything though. People? I don't really trust my coworkers. I've been given far too many of their projects that they screwed up and I have to fix. They all follow the process though. Tools? We have one tool that causes a lot of problems: SourceSafe. For most of our coding projects, we all have to edit the same project file. Thanks to SourceSafe we can't all edit the file at the same time so we end up doing a lot of check-out, edit a little, check-in so somebody else can check-out, edit a little, then check-in. We recently had a disaster where someone's changes got overwritten by somebody else and we lost a week of work that had to be made up in one night as we were doing a version release that night. Like several others before me have mentioned, I have learned to trust only myself.
My mind is like an aluminum trap. Some things get caught in the trap, and some things bend the trap and get away.
FyreWyrm wrote:
SourceSafe. For most of our coding projects, we all have to edit the same project file. Thanks to SourceSafe we can't all edit the file at the same time so we end up doing a lot of check-out, edit a little, check-in so somebody else can check-out, edit a little, then check-in.
This is a case where your process is defective, not your tools. There is no tool out there that would allow all of you to edit the same project file simultaneously and maintain its consistency and correctness. You need to break the project up into smaller, more manageable pieces.
Software Zen:
delete this; -
How are your processes reviewed and improved? That is the key problem I have with most process systems. They start well but do not evolve and people become dependent on antiquated process which ends up killing them (or the project if there is no 30kV supply involved. Crikey.)
cheers, Paul M. Watson.
Paul Watson wrote:
How are your processes reviewed and improved?
By any and all of us. One nice thing about working with something as tangible as electricity is that it always obeys the laws of physics - it's objective. It helps some that each action is unique, except for a few things we do fairly often. Each process is written for the specific action and reviewed by everyone involved. Once it is approved, we use it. If it works, we keep it. But anytime we make a system change we review the associated procedures again to ensure that they still make sense and are safe to use. We've had a few minor mishaps; once we opened a switch and started a 69kV arc that would not go out until the switch was slammed shut again. Checking with the manufacturer revealed that the switch was designed to open a line no more than 12 miles long, and our line was 22 miles long. Oops. More recently we asked our supplier to open a breaker to kill a line (the same line) before we tried switching. They did, one of our linemen started to open the switch, then the line suddenly came hot again. It turned out that the supplier's procedure was flawed, as well - it didn't include disabling the feature that automatically restores power when the voltage drops. Both procedures have since been fixed and tested. It has to be a continuous process - review, test, revise - for it to work. I think we're lucky that the danger factor is involved, as it makes everyone very conscious of the importance of having procedures that work. For more mundane issues - like a HR policy - the urgency isn't there, and bad procedures can sit and molder for years, far past the time when they may have been useful. Those are the organization killers. One such caused me to leave my first engineering job. There were two employee rating systems in use, one the employee could see, and the other a secret rating that only managers could access. While my ratings were excellent in the open file, I found out later that my secret file contained a "Z" rating - too valuable to promote out of the current position. That was a bad policy, and I'm not the only one who left because of it. I assume they never changed it, as they went out of business about three years after I left. Probably ran out of employees willing to work for them...
"A Journey of a Thousand Rest Stops Begins with a Single Movement"
-
Let me explain. Process: do you have processes that you trust? Are the processes there to compensate for mistakes people make, or to facilitate the work they do and facilitate coordinating work among people and across departments? People: do you trust your coworkers to do their work competently, to follow the processes, etc? Tools: Do you trust your tools, or are your tools causing problems? Are they causing problems because the process of using the tools is broken? The people using the tools don't use them appropriately or haven't configured them to actually be useful? So, where do you place your trust? Marc
Processes - very little trust (Since I work developing the processes I know how bad they can be ;) ) They are only as good as your people. Tools - again, only as good as the people who use them. A screw drivers no good if you can only use a hammer. People - more to the point, the RIGHT people. Some I trust some I know not to trust. If you get the right people using the right tools with a process that is flexible enough to accomodate the job then...BAM! the project is a success.
-
A little trust and a little doubt in all. I personally don't like fully automated completely because it takes the human out of the equation. I prefer semi-automated guns, I mean processes, because you can kill, I mean check, intermittently what's going on.
A little intermittent killing is a dangerous thing :laugh:
-
In my business, I trust process first, then people, then tools. If we make a mistake, people can die and property burns. Every action is preceded by writing a process, called a switching procedure, then all of our staff review it. It's called a "tailgate" meeting. The newest apprentice is entitled to object or question any step, and everything stops until that question is answered. I, myself, when I was two weeks on the job asked a question about a switching action, and everyone listened. It turned out that I'd caught a step missed by my boss, who has 30 years' experience doing what I'd never done at the time. They listened, corrected the procedure, and thanked me for catching the mistake. Tools can always fail, however simple. We use insulated hotsticks for switching, but we wear gloves rated for 30kV when using them, because sticks can fail and you don't live through it usually. There's nothing we can do about multiple failures, but we never fail to take every precaution available, just in case. I deviated from the intent of your question just to illustrate the wide range of possibilities. I know you're talking about other circumstances. In general situations, I trust the people who know how to get the job done. Policies and procedures are just shortcuts to avoid thinking, and having to evaluate all situations individually. All policies and procedures need exception mechanisms that allow people to make the final decision; things come up that the standards didn't anticipate. Both tools and procedures also become obsolete, and need to be re-evaluated once in a while. Those that no longer fit should be abandoned without remorse. One of the best books I've ever read is called "Sacred Cows Make The Best Burgers" and I commend it to your reading list. From it I learned ways to objectively view policies and procedures that have been in place forever and to unemotionally determine whether they really fit the way we do business today. Those that no longer work need to be dumped, and new ways defined. Similarly, people who will not give up doing things "the way we've always done it" need to be dumped. They only impede the progress of the rest of the organization. Overall, to function efficiently you must be able to trust all three - Processes, people, and tools. Any that don't function must be put to pasture or the company is doomed.
"A Journey of a Thousand Rest Stops Begins with a Single Movement"
Roger Wright wrote:
I deviated from the intent of your question just to illustrate the wide range of possibilities
Well, that made for a fascinating read, as usual. And thanks for the book recommendation too!
Roger Wright wrote:
Overall, to function efficiently you must be able to trust all three - Processes, people, and tools. Any that don't function must be put to pasture or the company is doomed.
Agreed. Hard to do though, when the process for evaluating the processes, people, and tools is frought with inaction, emotions, and politics. :) Marc
-
Let me explain. Process: do you have processes that you trust? Are the processes there to compensate for mistakes people make, or to facilitate the work they do and facilitate coordinating work among people and across departments? People: do you trust your coworkers to do their work competently, to follow the processes, etc? Tools: Do you trust your tools, or are your tools causing problems? Are they causing problems because the process of using the tools is broken? The people using the tools don't use them appropriately or haven't configured them to actually be useful? So, where do you place your trust? Marc
Trust NOTHING and NO ONE. Verify always. Get someone else to verify your verification, preferably two someones. Something may still slip by. God created the universe, but the Devil manages the details, and Murphy's Law is the First Law of action. Anecdote: I kept my first programming job because both the accountant and the new bookkeeper verified that, while the figures of my invoices entered into the new computing system weren't completely correct, they were much more correct than the old bookkeeper's manual figures. Anecdote: My father created a process for getting everything a new employee needed ordered and delivered to his desk by his start date, then my father hired a president while he moved to chairman of the board. Within three months, the process had broken down because no one believed that every point of the procedure the "hard ass chairman" had come up with was necessary, and the new president bought into that; my father, the chairman, didn't catch this until someone mentioned in passing how so-and-so (a programmer) didn't get their computer until they'd been at their desk for three weeks. Trust NOTHING and NO ONE. Verify always. Get someone else to verify your verification, preferably two someones. Something may still slip by.
-
I am equating trust with predictability - mainly. Least is People. As the circumstances change their commitment and performance becomes less predictable. I'm not a mind reader. Emotion, prejudice, greed, laziness, etc. clouds reason. Process, if you mean the broader sense, can be very predictable. There are always processes at work. Knowing how to discover and normalize them can result in a high degree of predictability. I was a process consultant for a large CPA firm at one point. I did forensic systems work mainly. There was always a predictor that the client missed that foretold the failure of the system they bought or built. I was hired to find it. The result of this was often messy. I learned lot about processes and systems project management doing this. Tools used the same way each time are very predictable, if viewed as implementations of algorithms. I certainly have doubted the ones I use daily when I keep getting a syntax or logic error. But its always me and not the tool in the end. Sometimes limitations in tools like interpreters and compilers are at the root. The messages are misleading but there is an error there. One bizarre one I had recently, when coding too late and should have stopped but stubbornly kept going. I had misspelled my JavaScript Array prototype statement. I kept getting a syntax error that I had an extra \n hidden somewhere (a nasty red herring). I thought I may have entered a control character or had a \n in position 200 on a line, or something similar. I was starting to doubt my VM, then finally after Firebug, Komodo, IE Dev Toolbar, etc., etc., my eyes cleared for a moment and there it was a dumb-s... typo. :)
"Coding for fun and profit ... mostly fun"
*nods* I had one boss who valued consistency above all, ESPECIALLY in the kind of mistakes you make. If the kind of mistakes you made were unpredictable, he got rid of you because your work was too dangerous to be trusted and/or verified reliably.
-
Trust NOTHING and NO ONE. Verify always. Get someone else to verify your verification, preferably two someones. Something may still slip by. God created the universe, but the Devil manages the details, and Murphy's Law is the First Law of action. Anecdote: I kept my first programming job because both the accountant and the new bookkeeper verified that, while the figures of my invoices entered into the new computing system weren't completely correct, they were much more correct than the old bookkeeper's manual figures. Anecdote: My father created a process for getting everything a new employee needed ordered and delivered to his desk by his start date, then my father hired a president while he moved to chairman of the board. Within three months, the process had broken down because no one believed that every point of the procedure the "hard ass chairman" had come up with was necessary, and the new president bought into that; my father, the chairman, didn't catch this until someone mentioned in passing how so-and-so (a programmer) didn't get their computer until they'd been at their desk for three weeks. Trust NOTHING and NO ONE. Verify always. Get someone else to verify your verification, preferably two someones. Something may still slip by.
cpkilekofp wrote:
how so-and-so (a programmer) didn't get their computer until they'd been at their desk for three weeks.
That is so common. It's happened to me, it's happened to coworkers... And even worse, the equipment I have at home is often better than the equipment the company provides, and I'm typically 1 to 2 years behind the technology curve! I cringe when I walk into a company and see developers still using CRT's at 800x600 resolution (yes, there are sometimes good reasons for that, but for pure programming, none that I can think of.) Marc
-
cpkilekofp wrote:
how so-and-so (a programmer) didn't get their computer until they'd been at their desk for three weeks.
That is so common. It's happened to me, it's happened to coworkers... And even worse, the equipment I have at home is often better than the equipment the company provides, and I'm typically 1 to 2 years behind the technology curve! I cringe when I walk into a company and see developers still using CRT's at 800x600 resolution (yes, there are sometimes good reasons for that, but for pure programming, none that I can think of.) Marc
It is common, which is why my father had instituted the procedure (which worked flawlessly as long as he was president and thus was at headquarters on a daily basis, instead of haring around to Tokyo, Sydney, New York, etc. promoting the company and building business relationships as chairman of the board). His replacement failed to be trustworthy in insuring that the processes that worked were actually used.
-
cpkilekofp wrote:
how so-and-so (a programmer) didn't get their computer until they'd been at their desk for three weeks.
That is so common. It's happened to me, it's happened to coworkers... And even worse, the equipment I have at home is often better than the equipment the company provides, and I'm typically 1 to 2 years behind the technology curve! I cringe when I walk into a company and see developers still using CRT's at 800x600 resolution (yes, there are sometimes good reasons for that, but for pure programming, none that I can think of.) Marc
Yeah. The only time I had a better machine at work was when I first started and had a 5yo built as a student box. desktop athlon 1400, 512mb(?) 60gb 1600x1200 17" crt vs laptop pm-1600, 1gb, 60gb, 1600x1200 19" crt and 1280x1024 19" lcd Currently it's somewhat close: desktop a64x2 2.5g, 2gb, 640gb 95 drive raid), 2x 20" 1600x1200 lcd vs laptop c2d 2.0, 2gb, 60 gb, 1600x1200 19" crt and 1280x1024 19" lcd but once I get my new desktop assembled over the weekend it's going to be a huge gap again core i7 920 quad core hyperthreaded 2.66g (stock speed, once I go h2o cooled in a few weeks* I'm aiming for ~4gig), 6gb, 640gb single HD, 2x 20" 1600x1200 * after market cooling makers really missed the ball for this release, the only i7 water blocks for sale now are from companies with poor performance histories, aftermarket air cooling is almost as badly off. :mad:
Today's lesson is brought to you by the word "niggardly". Remember kids, don't attribute to racism what can be explained by Scandinavian language roots. -- Robert Royall
-
Roger Wright wrote:
I deviated from the intent of your question just to illustrate the wide range of possibilities
Well, that made for a fascinating read, as usual. And thanks for the book recommendation too!
Roger Wright wrote:
Overall, to function efficiently you must be able to trust all three - Processes, people, and tools. Any that don't function must be put to pasture or the company is doomed.
Agreed. Hard to do though, when the process for evaluating the processes, people, and tools is frought with inaction, emotions, and politics. :) Marc
Marc Clifton wrote:
Hard to do though
Yes it is, and all the more necessary when the process for fixing processes is broken, and managed by people who are the problem. I recommend a Turkey Shoot, wherein random terminations strike without warning and target those who feels most comfy. That, or heavy medication.
"A Journey of a Thousand Rest Stops Begins with a Single Movement"
-
Paul Watson wrote:
How are your processes reviewed and improved?
By any and all of us. One nice thing about working with something as tangible as electricity is that it always obeys the laws of physics - it's objective. It helps some that each action is unique, except for a few things we do fairly often. Each process is written for the specific action and reviewed by everyone involved. Once it is approved, we use it. If it works, we keep it. But anytime we make a system change we review the associated procedures again to ensure that they still make sense and are safe to use. We've had a few minor mishaps; once we opened a switch and started a 69kV arc that would not go out until the switch was slammed shut again. Checking with the manufacturer revealed that the switch was designed to open a line no more than 12 miles long, and our line was 22 miles long. Oops. More recently we asked our supplier to open a breaker to kill a line (the same line) before we tried switching. They did, one of our linemen started to open the switch, then the line suddenly came hot again. It turned out that the supplier's procedure was flawed, as well - it didn't include disabling the feature that automatically restores power when the voltage drops. Both procedures have since been fixed and tested. It has to be a continuous process - review, test, revise - for it to work. I think we're lucky that the danger factor is involved, as it makes everyone very conscious of the importance of having procedures that work. For more mundane issues - like a HR policy - the urgency isn't there, and bad procedures can sit and molder for years, far past the time when they may have been useful. Those are the organization killers. One such caused me to leave my first engineering job. There were two employee rating systems in use, one the employee could see, and the other a secret rating that only managers could access. While my ratings were excellent in the open file, I found out later that my secret file contained a "Z" rating - too valuable to promote out of the current position. That was a bad policy, and I'm not the only one who left because of it. I assume they never changed it, as they went out of business about three years after I left. Probably ran out of employees willing to work for them...
"A Journey of a Thousand Rest Stops Begins with a Single Movement"
Roger Wright wrote:
I think we're lucky that the danger factor is involved, as it makes everyone very conscious of the importance of having procedures that work. For more mundane issues - like a HR policy - the urgency isn't there, and bad procedures can sit and molder for years
Good point about danger ensuring policies and process remain fresh. The odd thing is bad/outdated process is dangerous in every field of work. In your field it is immediate. In my field it is delayed and by the time you realise Process X is costing you Y the company is already three miles down in a debt hole. A shame we humans are not good at thinking beyond the immediate.
cheers, Paul M. Watson.
-
FyreWyrm wrote:
SourceSafe. For most of our coding projects, we all have to edit the same project file. Thanks to SourceSafe we can't all edit the file at the same time so we end up doing a lot of check-out, edit a little, check-in so somebody else can check-out, edit a little, then check-in.
This is a case where your process is defective, not your tools. There is no tool out there that would allow all of you to edit the same project file simultaneously and maintain its consistency and correctness. You need to break the project up into smaller, more manageable pieces.
Software Zen:
delete this;Gary Wheeler wrote:
There is no tool out there that would allow all of you to edit the same project file simultaneously and maintain its consistency and correctness.
I've found SVN+Tortoise manages this quite well actually. VS project files are text-based so merges happen seamlessly and even in the rare cases where two or more developers accidentally work on exactly the same chunk of code/project section, conflicts can be resolved manually.
T-Mac-Oz "When I'm ruler of the universe ... I'm working on it, I'm working on it. I'm just as frustrated as you are. It turns out to be a non-trivial problem." - Linus Torvalds
-
It's quite shocking the number of people who only trust in themselves. This really doesn't do you any favors in the long run. For a start it kinda suggests you need to work a little your social skills! I once felt exactly the same. Then I realized that my dreams were far to big to become a reality relying only on myself! I came to the conclusion that unless I code up an intelligent being, I'm not going to get very far by myself. Trust is earned you don't have to trust everyone, be frank if they don't do it to standard then tell them. Processes above tools any day thats an easy one. AS for people, they should be trusted to develop the processes with you. The guys following the process should feel responsible for improving and maintaining them with support from their managers. The guys doing the work should also be working on how they do it! Managers should facilitate this, they should get their hands dirty and understand things from the bottom up. This rarely happens how many times have you had to follow a really dumb process? But don't moan too much the coding world is far more advanced in terms of processes and standards than many other industries. This comes with the job a good coder secretly get all excited by the idea of standards.
Steve O'Brien A successful person isn't necessarily better than her less successful peers at solving problems; her pattern-recognition facilities have just learned what problems are worth solving. - Ray Kurzweil www.newicon.net
shubumpkin wrote:
the coding world is far more advanced in terms of processes and standards than many other industries
Yes! It has so many to choose from! :laugh:
T-Mac-Oz "When I'm ruler of the universe ... I'm working on it, I'm working on it. I'm just as frustrated as you are. It turns out to be a non-trivial problem." - Linus Torvalds
-
in god we trust
----------------------------------------------------------- "When I first saw it, I just thought that you really, really enjoyed programming in java." - Leslie Sanford