Mixing
Should I emphasize quality or quantity when in a contract to hire position? [closed]
Clash Royale CLAN TAG#URR8PPP
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;
up vote
2
down vote
favorite
I am on a contract to hire and I was wondering what work attitude I should adopt.
As a software engineer, I can code really fast if I put my mind to it, but chances of mistakes, such as missed requirements or glitches go up.
If I take extra time to checked that all requirements are addressed and that my application is glitch-free, then my production level goes down dramatically.
Since I am in a contract to hire, which attitude is best to emphasize? Quality or quantity?
Considering the fact that I apply myself to meeting the goals that are expected of me regarding workplace etiquette and attitude, obviously.
I don't want to take any risk of delivering bad applications but I also don't want to be told "Sorry, you code well, but at the speed of a snail and we need someone a bit faster on the keyboard".
contracts
asked Nov 24 '15 at 23:35
Charlie Mike No Shoot
171
closed as off-topic by Jim G., Dawny33, gnat, The Wandering Dev Manager, mcknz Nov 29 '15 at 17:52
This question appears to be off-topic. The users who voted to close gave this specific reason:
- "Questions asking for advice on what to do are not practical answerable questions (e.g. "what job should I take?", or "what skills should I learn?"). Questions should get answers explaining why and how to make a decision, not advice on what to do. For more information, click here." – Jim G., Dawny33, gnat, The Wandering Dev Manager, mcknz
suggest improvements |Â
up vote
2
down vote
favorite
I am on a contract to hire and I was wondering what work attitude I should adopt.
As a software engineer, I can code really fast if I put my mind to it, but chances of mistakes, such as missed requirements or glitches go up.
If I take extra time to checked that all requirements are addressed and that my application is glitch-free, then my production level goes down dramatically.
Since I am in a contract to hire, which attitude is best to emphasize? Quality or quantity?
Considering the fact that I apply myself to meeting the goals that are expected of me regarding workplace etiquette and attitude, obviously.
I don't want to take any risk of delivering bad applications but I also don't want to be told "Sorry, you code well, but at the speed of a snail and we need someone a bit faster on the keyboard".
contracts
asked Nov 24 '15 at 23:35
Charlie Mike No Shoot
171
closed as off-topic by Jim G., Dawny33, gnat, The Wandering Dev Manager, mcknz Nov 29 '15 at 17:52
This question appears to be off-topic. The users who voted to close gave this specific reason:
- "Questions asking for advice on what to do are not practical answerable questions (e.g. "what job should I take?", or "what skills should I learn?"). Questions should get answers explaining why and how to make a decision, not advice on what to do. For more information, click here." – Jim G., Dawny33, gnat, The Wandering Dev Manager, mcknz
"I also don't want to be told 'Sorry, you code well, but at the speed of a snail.'" - No one cares how fast you code. They care about whether or not you deliver the required results on time. Let the required results alone be your focus.
– Brandin
Nov 25 '15 at 9:21
suggest improvements |Â
up vote
2
down vote
favorite
up vote
2
down vote
favorite
I am on a contract to hire and I was wondering what work attitude I should adopt.
As a software engineer, I can code really fast if I put my mind to it, but chances of mistakes, such as missed requirements or glitches go up.
If I take extra time to checked that all requirements are addressed and that my application is glitch-free, then my production level goes down dramatically.
Since I am in a contract to hire, which attitude is best to emphasize? Quality or quantity?
Considering the fact that I apply myself to meeting the goals that are expected of me regarding workplace etiquette and attitude, obviously.
I don't want to take any risk of delivering bad applications but I also don't want to be told "Sorry, you code well, but at the speed of a snail and we need someone a bit faster on the keyboard".
contracts
asked Nov 24 '15 at 23:35
Charlie Mike No Shoot
171
I am on a contract to hire and I was wondering what work attitude I should adopt.
As a software engineer, I can code really fast if I put my mind to it, but chances of mistakes, such as missed requirements or glitches go up.
If I take extra time to checked that all requirements are addressed and that my application is glitch-free, then my production level goes down dramatically.
Since I am in a contract to hire, which attitude is best to emphasize? Quality or quantity?
Considering the fact that I apply myself to meeting the goals that are expected of me regarding workplace etiquette and attitude, obviously.
I don't want to take any risk of delivering bad applications but I also don't want to be told "Sorry, you code well, but at the speed of a snail and we need someone a bit faster on the keyboard".
contracts
asked Nov 24 '15 at 23:35
Charlie Mike No Shoot
171
asked Nov 24 '15 at 23:35
Charlie Mike No Shoot
171
asked Nov 24 '15 at 23:35
Charlie Mike No Shoot
171
asked Nov 24 '15 at 23:35
Charlie Mike No Shoot
171
171
closed as off-topic by Jim G., Dawny33, gnat, The Wandering Dev Manager, mcknz Nov 29 '15 at 17:52
This question appears to be off-topic. The users who voted to close gave this specific reason:
- "Questions asking for advice on what to do are not practical answerable questions (e.g. "what job should I take?", or "what skills should I learn?"). Questions should get answers explaining why and how to make a decision, not advice on what to do. For more information, click here." – Jim G., Dawny33, gnat, The Wandering Dev Manager, mcknz
closed as off-topic by Jim G., Dawny33, gnat, The Wandering Dev Manager, mcknz Nov 29 '15 at 17:52
This question appears to be off-topic. The users who voted to close gave this specific reason:
- "Questions asking for advice on what to do are not practical answerable questions (e.g. "what job should I take?", or "what skills should I learn?"). Questions should get answers explaining why and how to make a decision, not advice on what to do. For more information, click here." – Jim G., Dawny33, gnat, The Wandering Dev Manager, mcknz
"I also don't want to be told 'Sorry, you code well, but at the speed of a snail.'" - No one cares how fast you code. They care about whether or not you deliver the required results on time. Let the required results alone be your focus.
– Brandin
Nov 25 '15 at 9:21
suggest improvements |Â
"I also don't want to be told 'Sorry, you code well, but at the speed of a snail.'" - No one cares how fast you code. They care about whether or not you deliver the required results on time. Let the required results alone be your focus.
– Brandin
Nov 25 '15 at 9:21
"I also don't want to be told 'Sorry, you code well, but at the speed of a snail.'" - No one cares how fast you code. They care about whether or not you deliver the required results on time. Let the required results alone be your focus.
– Brandin
Nov 25 '15 at 9:21
"I also don't want to be told 'Sorry, you code well, but at the speed of a snail.'" - No one cares how fast you code. They care about whether or not you deliver the required results on time. Let the required results alone be your focus.
– Brandin
Nov 25 '15 at 9:21
suggest improvements |Â
1 Answer
1
active
oldest
votes
up vote
6
down vote
Talk with your manager. Or your colleagues. Or look around and see what the company tends to reward.
Every company has a different trade-off between quantity and quality. If you're writing code to control rocket launches, no one is likely to care how quickly you delivered if your code causes the launch to fail. If you're coding a library to send messages testing what happens after it has passed 4.2 billion messages (potentially overflowing a 32-bit integer) probably isn't going to win you too many friends unless you have a plausible reason to believe that's something that would ever happen. Different companies will undoubtedly have different trade-offs. You don't want to be known as someone that takes an eternity to deliver code and wastes time considering and designing for cases that are unlikely to ever be needed. But you also don't want to be known as someone that rushes to implement something without bothering to ask some obvious questions to understand the requirements and delivers something that is too buggy to be useful.
It is probably also useful to consider what sort of feedback you've been given previously and to adjust to that. When you've made mistakes in the past, have they generally been because you rushed and delivered something buggy and unusable? Or because you over-engineered something that should have been much simpler? Most people tend to have their failures cluster to one side or the other at least at a particular point in time. I was definitely more likely to have problems from over-engineering early in my career, for example, so it would make sense for me to have focused more on quantity. At other points, I've written code that wasn't as robust as it should have been so I adjusted my approach to improve quality.
answered Nov 24 '15 at 23:48
Justin Cave
34.8k9112136
excellent advice, the only thing I'd like to expand on is that it also depends on workload, if you are in a fast paced team facing deadlines, then obviously you need to up the speed. But working with a slower paced team you can actually make some enemies by being too productive and they will nit pick over your code.
– Kilisi
Nov 25 '15 at 2:25
suggest improvements |Â
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
6
down vote
Talk with your manager. Or your colleagues. Or look around and see what the company tends to reward.
Every company has a different trade-off between quantity and quality. If you're writing code to control rocket launches, no one is likely to care how quickly you delivered if your code causes the launch to fail. If you're coding a library to send messages testing what happens after it has passed 4.2 billion messages (potentially overflowing a 32-bit integer) probably isn't going to win you too many friends unless you have a plausible reason to believe that's something that would ever happen. Different companies will undoubtedly have different trade-offs. You don't want to be known as someone that takes an eternity to deliver code and wastes time considering and designing for cases that are unlikely to ever be needed. But you also don't want to be known as someone that rushes to implement something without bothering to ask some obvious questions to understand the requirements and delivers something that is too buggy to be useful.
It is probably also useful to consider what sort of feedback you've been given previously and to adjust to that. When you've made mistakes in the past, have they generally been because you rushed and delivered something buggy and unusable? Or because you over-engineered something that should have been much simpler? Most people tend to have their failures cluster to one side or the other at least at a particular point in time. I was definitely more likely to have problems from over-engineering early in my career, for example, so it would make sense for me to have focused more on quantity. At other points, I've written code that wasn't as robust as it should have been so I adjusted my approach to improve quality.
answered Nov 24 '15 at 23:48
Justin Cave
34.8k9112136
excellent advice, the only thing I'd like to expand on is that it also depends on workload, if you are in a fast paced team facing deadlines, then obviously you need to up the speed. But working with a slower paced team you can actually make some enemies by being too productive and they will nit pick over your code.
– Kilisi
Nov 25 '15 at 2:25
suggest improvements |Â
up vote
6
down vote
Talk with your manager. Or your colleagues. Or look around and see what the company tends to reward.
Every company has a different trade-off between quantity and quality. If you're writing code to control rocket launches, no one is likely to care how quickly you delivered if your code causes the launch to fail. If you're coding a library to send messages testing what happens after it has passed 4.2 billion messages (potentially overflowing a 32-bit integer) probably isn't going to win you too many friends unless you have a plausible reason to believe that's something that would ever happen. Different companies will undoubtedly have different trade-offs. You don't want to be known as someone that takes an eternity to deliver code and wastes time considering and designing for cases that are unlikely to ever be needed. But you also don't want to be known as someone that rushes to implement something without bothering to ask some obvious questions to understand the requirements and delivers something that is too buggy to be useful.
It is probably also useful to consider what sort of feedback you've been given previously and to adjust to that. When you've made mistakes in the past, have they generally been because you rushed and delivered something buggy and unusable? Or because you over-engineered something that should have been much simpler? Most people tend to have their failures cluster to one side or the other at least at a particular point in time. I was definitely more likely to have problems from over-engineering early in my career, for example, so it would make sense for me to have focused more on quantity. At other points, I've written code that wasn't as robust as it should have been so I adjusted my approach to improve quality.
answered Nov 24 '15 at 23:48
Justin Cave
34.8k9112136
excellent advice, the only thing I'd like to expand on is that it also depends on workload, if you are in a fast paced team facing deadlines, then obviously you need to up the speed. But working with a slower paced team you can actually make some enemies by being too productive and they will nit pick over your code.
– Kilisi
Nov 25 '15 at 2:25
suggest improvements |Â
up vote
6
down vote
up vote
6
down vote
Talk with your manager. Or your colleagues. Or look around and see what the company tends to reward.
Every company has a different trade-off between quantity and quality. If you're writing code to control rocket launches, no one is likely to care how quickly you delivered if your code causes the launch to fail. If you're coding a library to send messages testing what happens after it has passed 4.2 billion messages (potentially overflowing a 32-bit integer) probably isn't going to win you too many friends unless you have a plausible reason to believe that's something that would ever happen. Different companies will undoubtedly have different trade-offs. You don't want to be known as someone that takes an eternity to deliver code and wastes time considering and designing for cases that are unlikely to ever be needed. But you also don't want to be known as someone that rushes to implement something without bothering to ask some obvious questions to understand the requirements and delivers something that is too buggy to be useful.
It is probably also useful to consider what sort of feedback you've been given previously and to adjust to that. When you've made mistakes in the past, have they generally been because you rushed and delivered something buggy and unusable? Or because you over-engineered something that should have been much simpler? Most people tend to have their failures cluster to one side or the other at least at a particular point in time. I was definitely more likely to have problems from over-engineering early in my career, for example, so it would make sense for me to have focused more on quantity. At other points, I've written code that wasn't as robust as it should have been so I adjusted my approach to improve quality.
answered Nov 24 '15 at 23:48
Justin Cave
34.8k9112136
Talk with your manager. Or your colleagues. Or look around and see what the company tends to reward.
Every company has a different trade-off between quantity and quality. If you're writing code to control rocket launches, no one is likely to care how quickly you delivered if your code causes the launch to fail. If you're coding a library to send messages testing what happens after it has passed 4.2 billion messages (potentially overflowing a 32-bit integer) probably isn't going to win you too many friends unless you have a plausible reason to believe that's something that would ever happen. Different companies will undoubtedly have different trade-offs. You don't want to be known as someone that takes an eternity to deliver code and wastes time considering and designing for cases that are unlikely to ever be needed. But you also don't want to be known as someone that rushes to implement something without bothering to ask some obvious questions to understand the requirements and delivers something that is too buggy to be useful.
It is probably also useful to consider what sort of feedback you've been given previously and to adjust to that. When you've made mistakes in the past, have they generally been because you rushed and delivered something buggy and unusable? Or because you over-engineered something that should have been much simpler? Most people tend to have their failures cluster to one side or the other at least at a particular point in time. I was definitely more likely to have problems from over-engineering early in my career, for example, so it would make sense for me to have focused more on quantity. At other points, I've written code that wasn't as robust as it should have been so I adjusted my approach to improve quality.
answered Nov 24 '15 at 23:48
Justin Cave
34.8k9112136
edited Nov 25 '15 at 0:36
answered Nov 24 '15 at 23:48
Justin Cave
34.8k9112136
answered Nov 24 '15 at 23:48
Justin Cave
34.8k9112136
answered Nov 24 '15 at 23:48
Justin Cave
34.8k9112136
34.8k9112136
excellent advice, the only thing I'd like to expand on is that it also depends on workload, if you are in a fast paced team facing deadlines, then obviously you need to up the speed. But working with a slower paced team you can actually make some enemies by being too productive and they will nit pick over your code.
– Kilisi
Nov 25 '15 at 2:25
suggest improvements |Â
excellent advice, the only thing I'd like to expand on is that it also depends on workload, if you are in a fast paced team facing deadlines, then obviously you need to up the speed. But working with a slower paced team you can actually make some enemies by being too productive and they will nit pick over your code.
– Kilisi
Nov 25 '15 at 2:25
excellent advice, the only thing I'd like to expand on is that it also depends on workload, if you are in a fast paced team facing deadlines, then obviously you need to up the speed. But working with a slower paced team you can actually make some enemies by being too productive and they will nit pick over your code.
– Kilisi
Nov 25 '15 at 2:25
excellent advice, the only thing I'd like to expand on is that it also depends on workload, if you are in a fast paced team facing deadlines, then obviously you need to up the speed. But working with a slower paced team you can actually make some enemies by being too productive and they will nit pick over your code.
– Kilisi
Nov 25 '15 at 2:25
suggest improvements |Â
"I also don't want to be told 'Sorry, you code well, but at the speed of a snail.'" - No one cares how fast you code. They care about whether or not you deliver the required results on time. Let the required results alone be your focus.
– Brandin
Nov 25 '15 at 9:21