Most important side of coding
-
Since when? Cost influences everything we do: if it costs too much, it won't get done; it is comes in under budget we might get new toys. Or a pay rise.
The only instant messaging I do involves my middle finger.
OriginalGriff wrote:
Or a pay rise.
Wait,...you lost me there. Did you mean the bonus the execs give themselves?
Psychosis at 10 Film at 11 Those who do not remember the past, are doomed to repeat it. Those who do not remember the past, cannot build upon it.
-
Getting paid... I wouldn't do it otherwise. Don't get me wrong I enjoy coding but after 8 hours a day I don't look at any code after hours. I see Griff already had payment on his list. That's how important it is to coding.
It was broke, so I fixed it.
-
Suvabrata Roy wrote:
Which part is the most important part in prospect of a coding.
What's most important to you when undergoing surgery?
- Anesthetic?
- Disinfecting?
- Sewing the body when done?
- Checking if you still have both your gloves?
- Survival?
Please, assign priorities :) They're all priorities. When someone repairs a car, do you ask whether checking the brakes is a priority? What you're asking is where you can cut corners. The plain answer is that you can't, the quality will always suffer. That doesn't mean that the client would notice. Security isn't a problem (and doesn't get any budget), until it's proven to be broken. A completely secure program that doesn't perform, will not be used, no matter what it will promise the user. The most important aspect of any trade, is learning the trade.
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^]
Eddy Vluggen wrote:
When someone repairs a car, do you ask whether checking the brakes is a priority?
I see we are of the same mind. I used to counter with a similar question when a management fad was "Time boxing". Work on the module for a certain amount of time and then move on. I'd ask, "Do you want the mechanic working on your brakes to time box or would you rather he finish the job?" Yes, I was one of the usual suspects when it came to asking questions at the end of a presentation.
Psychosis at 10 Film at 11 Those who do not remember the past, are doomed to repeat it. Those who do not remember the past, cannot build upon it.
-
Reliability encompasses all the others except maybe performance, but I would think think a product without acceptable performance would be consider unreliable by most.
Hmm....:thumbsup:
Life is all about share and care... public class Life : ICareable,IShareable { // implements yours... }
-
Getting S%!& done. Seriously all that you mention is great and extremely important. But don't ever lose the final goal of putting product out the door. If you cannot get information into the customers hands you won't have a job for very long. It bugs me when people spend 3 weeks in analysis paralysis on Error/Exception handling when the project should have taken 1 day. But going from your list Availability Reliability Security Performance Errors/Exceptions
To err is human to really mess up you need a computer
Well Explained... :)
Life is all about share and care... public class Life : ICareable,IShareable { // implements yours... }
-
I don't know, software isn't very functional if no attention is paid to the members of that list.
"If you don't fail at least 90 percent of the time, you're not aiming high enough." Alan Kay.
That is the basic requirement....
Life is all about share and care... public class Life : ICareable,IShareable { // implements yours... }
-
S Houghtelin wrote:
I don't look at any code after hours.
So you are not a true believer. ???
Psychosis at 10 Film at 11 Those who do not remember the past, are doomed to repeat it. Those who do not remember the past, cannot build upon it.
BrainiacV wrote:
So you are not a true believer. ???
Not in the least, I truly believe I've had enough coding by the end of the day. I also have my family and my hobbies that I enjoy. ;)
It was broke, so I fixed it.
-
Hi Geeks, Which part is the most important part in prospect of a coding. 1. Exception Handling 2. Reliability 3. Availability 4. Performance 5. Security You can chose multiple but you should assign them as priority.
Life is all about share and care... public class Life : ICareable,IShareable { // implements yours... }
1. Reliability 2. Performance 3. Exception Handling 4. Security 5. Availability (not sure what your definition is here: platform support?) If its buggy I don't care about most of the other stuff. If it is tight I am concerned about how fast it is and how well it handles typical exceptions. If it runs well I am concerned about security and platform availability. If it is buggy how secure can it be anyway.
"Courtesy is the product of a mature, disciplined mind ... ridicule is lack of the same - DPM"
-
I'd have to quote your entire post, assuming I did... My experience has been... THEM: Can you do A? ME: Yes, here it is. THEM: Oh, can you do B? ME: Yes, here it is. THEM: OK, can you do C? ME: Yes, here it is. THEM: How about D? ME: Getting harder, but yes, here it is. THEM: I really need E. ME: Why didn't you ask for it first? I can do it, but it is much harder now. THEM: I didn't know you could do it until you managed to do A, B, C,and D, but E is what I really wanted all along. ME: You know, I could have given you E, much faster and easier if you had asked for it first. THEM: I didn't know what you could do (as in product, not my abilities). ME: Grrrr!
Psychosis at 10 Film at 11 Those who do not remember the past, are doomed to repeat it. Those who do not remember the past, cannot build upon it.
Yes I have seen that as well. What's worse is often when they ask for A, you respond with a hestiant But this seems unusable. Why not just build some like this: E No, no no. We can't afford to do that. We need A. Then as you wrote it happens. Which then when they ask for E and say that is what they always want.... You dang near go postal. Maybe some day they will refer to it as going Developer :omg:
Computers have been intelligent for a long time now. It just so happens that the program writers are about as effective as a room full of monkeys trying to crank out a copy of Hamlet. The interesting thing about software is it can not reproduce, until it can.
-
Hi Geeks, Which part is the most important part in prospect of a coding. 1. Exception Handling 2. Reliability 3. Availability 4. Performance 5. Security You can chose multiple but you should assign them as priority.
Life is all about share and care... public class Life : ICareable,IShareable { // implements yours... }
They will be: 1. Exception Handling 1. Reliability 1. Availability 1. Performance 1. Security Oh, did you mean real code? then: 1. Usability (that's that it works and does what it supposed to do) Everything else is a bonus.
CEO at: - Rafaga Systems - Para Facturas - Modern Components for the moment...
-
Hi Geeks, Which part is the most important part in prospect of a coding. 1. Exception Handling 2. Reliability 3. Availability 4. Performance 5. Security You can chose multiple but you should assign them as priority.
Life is all about share and care... public class Life : ICareable,IShareable { // implements yours... }
None of the above. IMHO the most important aspect of coding is CLARITY! Clarity makes all the others possible. Without it, you can't implement any of the others. Clarity is why we create subroutines and classes: To break up the code into manageable chunks mere humans can understand. Clarity is why we have comments and expressive variable/method names. Clarity is why a method of three subroutine calls in a loop is superior to a 200-line mess that no one can understand or reliably modify. Clarity is key to writing maintainable, reliable code. Good programmers strive for clarity.
-
Yes I have seen that as well. What's worse is often when they ask for A, you respond with a hestiant But this seems unusable. Why not just build some like this: E No, no no. We can't afford to do that. We need A. Then as you wrote it happens. Which then when they ask for E and say that is what they always want.... You dang near go postal. Maybe some day they will refer to it as going Developer :omg:
Computers have been intelligent for a long time now. It just so happens that the program writers are about as effective as a room full of monkeys trying to crank out a copy of Hamlet. The interesting thing about software is it can not reproduce, until it can.
Collin Jasnoch wrote:
Maybe some day they will refer to it as going Developer
I'd send you a t-shirt, but I think you already have one. What always galls me is their insistence on paving the cowpath by electronically replicating their manual (paper) methods. I understand that they don't know my job, but they blink at you uncomprehending when you explain that the computer can transcend their manual methods and do something that is a quantum leap over what they've been doing. I always think of it as that it is part of my job to become an expert at theirs, if only for a day, so I can separate what they are doing from what they want done. A side rant is how they fail to realize how you can fold the process into individual steps and then wave their hand and say, "You don't have to worry about X, because it only happens every once in a while." For example at one job, the hardware manager freaked when I explained to him I did not have 60 separate modules to handle the 60 diverters on the conveyor, I had only 1, but in regards to those occasional events, if they happened even once, I had to have code to deal with it. It didn't matter that it was only needed once every million cartons, I still needed to take the time to deal with it. What really caused him to lose it was when it was revealed it didn't matter where a photoeye was located, I just had to change a parameter number to set it's location. He was too used to building rails to place the photoeyes on so their location could be fine tuned. But then it was truly amusing when we had a bug, he suggested we run the computer slower so it wouldn't happen. His other bright suggestion was to print out all the instructions that were executed so we could find out where it failed. :wtf: You are free to make varoom sounds as you pass your hand over your head repeatedly.
Psychosis at 10 Film at 11 Those who do not remember the past, are doomed to repeat it. Those who do not remember the past, cannot build upon it.
-
Yes we should solve the problem and we also care about speed at the same time
Life is all about share and care... public class Life : ICareable,IShareable { // implements yours... }
Yes, but that's changing the argument from "what is the most important thing" to "what are important things to do". For example, code maintainability is an extremely important thing and often has the convenient side-effect of stability, security and speed, but it isn't the most important thing.
-
None of the above. IMHO the most important aspect of coding is CLARITY! Clarity makes all the others possible. Without it, you can't implement any of the others. Clarity is why we create subroutines and classes: To break up the code into manageable chunks mere humans can understand. Clarity is why we have comments and expressive variable/method names. Clarity is why a method of three subroutine calls in a loop is superior to a 200-line mess that no one can understand or reliably modify. Clarity is key to writing maintainable, reliable code. Good programmers strive for clarity.
I'm with you although I'd call it: Maintainability Of course, for small throwaway apps, this doesn't matter. But for apps that will need to be maintained and enhanced and modified over time, it is important to have it coded properly, not just have it working. It is important to be able to make changes to it without breaking everything (or having to spend a week, six months down the road, trying to figure out how the code is actually working so that I can enhance it), etc. My two cents, -D
-
Collin Jasnoch wrote:
Maybe some day they will refer to it as going Developer
I'd send you a t-shirt, but I think you already have one. What always galls me is their insistence on paving the cowpath by electronically replicating their manual (paper) methods. I understand that they don't know my job, but they blink at you uncomprehending when you explain that the computer can transcend their manual methods and do something that is a quantum leap over what they've been doing. I always think of it as that it is part of my job to become an expert at theirs, if only for a day, so I can separate what they are doing from what they want done. A side rant is how they fail to realize how you can fold the process into individual steps and then wave their hand and say, "You don't have to worry about X, because it only happens every once in a while." For example at one job, the hardware manager freaked when I explained to him I did not have 60 separate modules to handle the 60 diverters on the conveyor, I had only 1, but in regards to those occasional events, if they happened even once, I had to have code to deal with it. It didn't matter that it was only needed once every million cartons, I still needed to take the time to deal with it. What really caused him to lose it was when it was revealed it didn't matter where a photoeye was located, I just had to change a parameter number to set it's location. He was too used to building rails to place the photoeyes on so their location could be fine tuned. But then it was truly amusing when we had a bug, he suggested we run the computer slower so it wouldn't happen. His other bright suggestion was to print out all the instructions that were executed so we could find out where it failed. :wtf: You are free to make varoom sounds as you pass your hand over your head repeatedly.
Psychosis at 10 Film at 11 Those who do not remember the past, are doomed to repeat it. Those who do not remember the past, cannot build upon it.
BrainiacV wrote:
His other bright suggestion was to print out all the instructions that were executed so we could find out where it failed. :WTF:
I probably would have lost my job at that point! I am usually good at holding my tongue with the right (er wrong) people, but that would be difficult.
BrainiacV wrote:
You are free to make varoom sounds as you pass your hand over your head repeatedly.
:) I followed, but reading what you wrote makes my brain go varoom. Would be hard to follow such lead. ;)
Computers have been intelligent for a long time now. It just so happens that the program writers are about as effective as a room full of monkeys trying to crank out a copy of Hamlet. The interesting thing about software is it can not reproduce, until it can.
-
Hi Geeks, Which part is the most important part in prospect of a coding. 1. Exception Handling 2. Reliability 3. Availability 4. Performance 5. Security You can chose multiple but you should assign them as priority.
Life is all about share and care... public class Life : ICareable,IShareable { // implements yours... }
-
Hi Geeks, Which part is the most important part in prospect of a coding. 1. Exception Handling 2. Reliability 3. Availability 4. Performance 5. Security You can chose multiple but you should assign them as priority.
Life is all about share and care... public class Life : ICareable,IShareable { // implements yours... }
6: Something no other software has done. 5 down to 1: it's called a Try Catch.
-
Hi Geeks, Which part is the most important part in prospect of a coding. 1. Exception Handling 2. Reliability 3. Availability 4. Performance 5. Security You can chose multiple but you should assign them as priority.
Life is all about share and care... public class Life : ICareable,IShareable { // implements yours... }
-
:java:
The difficult we do right away... ...the impossible takes slightly longer.
Agreed!!! There is nothing better than a fresh pot of coffee to help write code!
-
Hi Geeks, Which part is the most important part in prospect of a coding. 1. Exception Handling 2. Reliability 3. Availability 4. Performance 5. Security You can chose multiple but you should assign them as priority.
Life is all about share and care... public class Life : ICareable,IShareable { // implements yours... }
Accuracy. Everything else can get stuffed.
