How can I not take bugs found in software I work on personally?
Clash Royale CLAN TAG#URR8PPP
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;
up vote
-1
down vote
favorite
For a while, I'm being reported of strange bugs that are related to my code but once I investigate, I find those could not be eventually bugs.
Example: some data is NULL in the database, but the only query I have written to write a row in that particular table would fail with a null input.
There is only one explanation: 1 of the X people with database credentials have set that value to null, and usually those null values are in places that are surely to cause problems visibly in my parts of the code.
I have been having such problems for 3 months. I cannot say "Hi, someone is sabotaging me". So how do I handle that in the most professional way to reduce damage to my image. While at same time, avoiding damages to my company?
I'm very bored investigating non-bugs and that hurts my productivity.
communication unprofessional-behavior
New contributor
add a comment |Â
up vote
-1
down vote
favorite
For a while, I'm being reported of strange bugs that are related to my code but once I investigate, I find those could not be eventually bugs.
Example: some data is NULL in the database, but the only query I have written to write a row in that particular table would fail with a null input.
There is only one explanation: 1 of the X people with database credentials have set that value to null, and usually those null values are in places that are surely to cause problems visibly in my parts of the code.
I have been having such problems for 3 months. I cannot say "Hi, someone is sabotaging me". So how do I handle that in the most professional way to reduce damage to my image. While at same time, avoiding damages to my company?
I'm very bored investigating non-bugs and that hurts my productivity.
communication unprofessional-behavior
New contributor
Have you talked to the person who is setting the values to NULL in the database to find out why? Have you updated your code to handle the null values? If not, why not?
â Seth R
31 mins ago
add a comment |Â
up vote
-1
down vote
favorite
up vote
-1
down vote
favorite
For a while, I'm being reported of strange bugs that are related to my code but once I investigate, I find those could not be eventually bugs.
Example: some data is NULL in the database, but the only query I have written to write a row in that particular table would fail with a null input.
There is only one explanation: 1 of the X people with database credentials have set that value to null, and usually those null values are in places that are surely to cause problems visibly in my parts of the code.
I have been having such problems for 3 months. I cannot say "Hi, someone is sabotaging me". So how do I handle that in the most professional way to reduce damage to my image. While at same time, avoiding damages to my company?
I'm very bored investigating non-bugs and that hurts my productivity.
communication unprofessional-behavior
New contributor
For a while, I'm being reported of strange bugs that are related to my code but once I investigate, I find those could not be eventually bugs.
Example: some data is NULL in the database, but the only query I have written to write a row in that particular table would fail with a null input.
There is only one explanation: 1 of the X people with database credentials have set that value to null, and usually those null values are in places that are surely to cause problems visibly in my parts of the code.
I have been having such problems for 3 months. I cannot say "Hi, someone is sabotaging me". So how do I handle that in the most professional way to reduce damage to my image. While at same time, avoiding damages to my company?
I'm very bored investigating non-bugs and that hurts my productivity.
communication unprofessional-behavior
communication unprofessional-behavior
New contributor
New contributor
edited 5 mins ago
Ben Mz
3,2471524
3,2471524
New contributor
asked 53 mins ago
Exiltaran
1
1
New contributor
New contributor
Have you talked to the person who is setting the values to NULL in the database to find out why? Have you updated your code to handle the null values? If not, why not?
â Seth R
31 mins ago
add a comment |Â
Have you talked to the person who is setting the values to NULL in the database to find out why? Have you updated your code to handle the null values? If not, why not?
â Seth R
31 mins ago
Have you talked to the person who is setting the values to NULL in the database to find out why? Have you updated your code to handle the null values? If not, why not?
â Seth R
31 mins ago
Have you talked to the person who is setting the values to NULL in the database to find out why? Have you updated your code to handle the null values? If not, why not?
â Seth R
31 mins ago
add a comment |Â
3 Answers
3
active
oldest
votes
up vote
4
down vote
There is only one explanation: 1 of the X people with database credentials have set that value to null, and usually those null values are in places that are surely to cause problems visibly in my parts of the code.
That means you write really fragile code that's easy to break.
Treat this as a technical challenge and start validating your inputs.
I'm very bored investigating non-bugs and that hurts my productivity.
But these are bugs - the code is clearly not working. When the code encounters an unexpected NULL, it should do something - probably report a data corruption error to the user.
Chasing down bugs is as much a part of the job as writing new code. In mature code, it's most of the job. If you're fixing bugs, you're being productive.
By the way, the answer to your title question
How can I not take bugs personally?
is to remember that it's not your code. The code belongs to the company or to the development team. Who wrote what is not important and shouldn't matter.
Input are always validated indeed. At application level. Theresa are always loro of constraints at db level. But
â Exiltaran
18 mins ago
If someone decides to introduce a bug in a db there is not much I can do
â Exiltaran
13 mins ago
2
@Exiltaran If your DB allows null values and your application is using the data in the DB as input, then you should handle those null values. If you don't want people putting null values in your DB then you should not make those columns nullable. If you can't, then you must be prepared for them.
â Jeff Lambert
12 mins ago
You are perfectly right, but this is happened hundred times so far. While there are things I can prevent with constraints, some are not preventable (like swapping 2 id in 2 rows of a relation). And moving to NO-SQL will prevent a lot of Security checks to be gone preventing me to avoid data manipulations.
â Exiltaran
2 mins ago
add a comment |Â
up vote
0
down vote
I would not say "someone is sabotaging me" unless you have indisputable proof that is happening.
New contributor
Along these same lines, sabotage is a strong word. It's possible that this data is being updated for many reasons.
â Dan Delany
3 mins ago
add a comment |Â
up vote
0
down vote
Any code should take into account of erroneous input. It's unclear from your question how someone is "sabotaging" you by entering null data in the database. Null rows are common database data and your code should never assume all input is valid. Someone entering invalid data into your code is not "sabotaging" it especially if they are expecting some sort of output from it.
Now someone on the outside might sabotage your application. They could surmise that if you are not validating input, then it is entirely possible they could access the database through your broken code. Now if that is found to be from your code, it's a sure bet you might not have a job depending on your level.
It was for cutting short. In short if only the application is allowed to access the db, there would be' no bug. Someone is editing db tables directly. Im not speaking od null values only of course
â Exiltaran
47 secs ago
add a comment |Â
StackExchange.ready(function ()
$("#show-editor-button input, #show-editor-button button").click(function ()
var showEditor = function()
$("#show-editor-button").hide();
$("#post-form").removeClass("dno");
StackExchange.editor.finallyInit();
;
var useFancy = $(this).data('confirm-use-fancy');
if(useFancy == 'True')
var popupTitle = $(this).data('confirm-fancy-title');
var popupBody = $(this).data('confirm-fancy-body');
var popupAccept = $(this).data('confirm-fancy-accept-button');
$(this).loadPopup(
url: '/post/self-answer-popup',
loaded: function(popup)
var pTitle = $(popup).find('h2');
var pBody = $(popup).find('.popup-body');
var pSubmit = $(popup).find('.popup-submit');
pTitle.text(popupTitle);
pBody.html(popupBody);
pSubmit.val(popupAccept).click(showEditor);
)
else
var confirmText = $(this).data('confirm-text');
if (confirmText ? confirm(confirmText) : true)
showEditor();
);
);
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
4
down vote
There is only one explanation: 1 of the X people with database credentials have set that value to null, and usually those null values are in places that are surely to cause problems visibly in my parts of the code.
That means you write really fragile code that's easy to break.
Treat this as a technical challenge and start validating your inputs.
I'm very bored investigating non-bugs and that hurts my productivity.
But these are bugs - the code is clearly not working. When the code encounters an unexpected NULL, it should do something - probably report a data corruption error to the user.
Chasing down bugs is as much a part of the job as writing new code. In mature code, it's most of the job. If you're fixing bugs, you're being productive.
By the way, the answer to your title question
How can I not take bugs personally?
is to remember that it's not your code. The code belongs to the company or to the development team. Who wrote what is not important and shouldn't matter.
Input are always validated indeed. At application level. Theresa are always loro of constraints at db level. But
â Exiltaran
18 mins ago
If someone decides to introduce a bug in a db there is not much I can do
â Exiltaran
13 mins ago
2
@Exiltaran If your DB allows null values and your application is using the data in the DB as input, then you should handle those null values. If you don't want people putting null values in your DB then you should not make those columns nullable. If you can't, then you must be prepared for them.
â Jeff Lambert
12 mins ago
You are perfectly right, but this is happened hundred times so far. While there are things I can prevent with constraints, some are not preventable (like swapping 2 id in 2 rows of a relation). And moving to NO-SQL will prevent a lot of Security checks to be gone preventing me to avoid data manipulations.
â Exiltaran
2 mins ago
add a comment |Â
up vote
4
down vote
There is only one explanation: 1 of the X people with database credentials have set that value to null, and usually those null values are in places that are surely to cause problems visibly in my parts of the code.
That means you write really fragile code that's easy to break.
Treat this as a technical challenge and start validating your inputs.
I'm very bored investigating non-bugs and that hurts my productivity.
But these are bugs - the code is clearly not working. When the code encounters an unexpected NULL, it should do something - probably report a data corruption error to the user.
Chasing down bugs is as much a part of the job as writing new code. In mature code, it's most of the job. If you're fixing bugs, you're being productive.
By the way, the answer to your title question
How can I not take bugs personally?
is to remember that it's not your code. The code belongs to the company or to the development team. Who wrote what is not important and shouldn't matter.
Input are always validated indeed. At application level. Theresa are always loro of constraints at db level. But
â Exiltaran
18 mins ago
If someone decides to introduce a bug in a db there is not much I can do
â Exiltaran
13 mins ago
2
@Exiltaran If your DB allows null values and your application is using the data in the DB as input, then you should handle those null values. If you don't want people putting null values in your DB then you should not make those columns nullable. If you can't, then you must be prepared for them.
â Jeff Lambert
12 mins ago
You are perfectly right, but this is happened hundred times so far. While there are things I can prevent with constraints, some are not preventable (like swapping 2 id in 2 rows of a relation). And moving to NO-SQL will prevent a lot of Security checks to be gone preventing me to avoid data manipulations.
â Exiltaran
2 mins ago
add a comment |Â
up vote
4
down vote
up vote
4
down vote
There is only one explanation: 1 of the X people with database credentials have set that value to null, and usually those null values are in places that are surely to cause problems visibly in my parts of the code.
That means you write really fragile code that's easy to break.
Treat this as a technical challenge and start validating your inputs.
I'm very bored investigating non-bugs and that hurts my productivity.
But these are bugs - the code is clearly not working. When the code encounters an unexpected NULL, it should do something - probably report a data corruption error to the user.
Chasing down bugs is as much a part of the job as writing new code. In mature code, it's most of the job. If you're fixing bugs, you're being productive.
By the way, the answer to your title question
How can I not take bugs personally?
is to remember that it's not your code. The code belongs to the company or to the development team. Who wrote what is not important and shouldn't matter.
There is only one explanation: 1 of the X people with database credentials have set that value to null, and usually those null values are in places that are surely to cause problems visibly in my parts of the code.
That means you write really fragile code that's easy to break.
Treat this as a technical challenge and start validating your inputs.
I'm very bored investigating non-bugs and that hurts my productivity.
But these are bugs - the code is clearly not working. When the code encounters an unexpected NULL, it should do something - probably report a data corruption error to the user.
Chasing down bugs is as much a part of the job as writing new code. In mature code, it's most of the job. If you're fixing bugs, you're being productive.
By the way, the answer to your title question
How can I not take bugs personally?
is to remember that it's not your code. The code belongs to the company or to the development team. Who wrote what is not important and shouldn't matter.
answered 25 mins ago
Dan Pichelman
25.2k116983
25.2k116983
Input are always validated indeed. At application level. Theresa are always loro of constraints at db level. But
â Exiltaran
18 mins ago
If someone decides to introduce a bug in a db there is not much I can do
â Exiltaran
13 mins ago
2
@Exiltaran If your DB allows null values and your application is using the data in the DB as input, then you should handle those null values. If you don't want people putting null values in your DB then you should not make those columns nullable. If you can't, then you must be prepared for them.
â Jeff Lambert
12 mins ago
You are perfectly right, but this is happened hundred times so far. While there are things I can prevent with constraints, some are not preventable (like swapping 2 id in 2 rows of a relation). And moving to NO-SQL will prevent a lot of Security checks to be gone preventing me to avoid data manipulations.
â Exiltaran
2 mins ago
add a comment |Â
Input are always validated indeed. At application level. Theresa are always loro of constraints at db level. But
â Exiltaran
18 mins ago
If someone decides to introduce a bug in a db there is not much I can do
â Exiltaran
13 mins ago
2
@Exiltaran If your DB allows null values and your application is using the data in the DB as input, then you should handle those null values. If you don't want people putting null values in your DB then you should not make those columns nullable. If you can't, then you must be prepared for them.
â Jeff Lambert
12 mins ago
You are perfectly right, but this is happened hundred times so far. While there are things I can prevent with constraints, some are not preventable (like swapping 2 id in 2 rows of a relation). And moving to NO-SQL will prevent a lot of Security checks to be gone preventing me to avoid data manipulations.
â Exiltaran
2 mins ago
Input are always validated indeed. At application level. Theresa are always loro of constraints at db level. But
â Exiltaran
18 mins ago
Input are always validated indeed. At application level. Theresa are always loro of constraints at db level. But
â Exiltaran
18 mins ago
If someone decides to introduce a bug in a db there is not much I can do
â Exiltaran
13 mins ago
If someone decides to introduce a bug in a db there is not much I can do
â Exiltaran
13 mins ago
2
2
@Exiltaran If your DB allows null values and your application is using the data in the DB as input, then you should handle those null values. If you don't want people putting null values in your DB then you should not make those columns nullable. If you can't, then you must be prepared for them.
â Jeff Lambert
12 mins ago
@Exiltaran If your DB allows null values and your application is using the data in the DB as input, then you should handle those null values. If you don't want people putting null values in your DB then you should not make those columns nullable. If you can't, then you must be prepared for them.
â Jeff Lambert
12 mins ago
You are perfectly right, but this is happened hundred times so far. While there are things I can prevent with constraints, some are not preventable (like swapping 2 id in 2 rows of a relation). And moving to NO-SQL will prevent a lot of Security checks to be gone preventing me to avoid data manipulations.
â Exiltaran
2 mins ago
You are perfectly right, but this is happened hundred times so far. While there are things I can prevent with constraints, some are not preventable (like swapping 2 id in 2 rows of a relation). And moving to NO-SQL will prevent a lot of Security checks to be gone preventing me to avoid data manipulations.
â Exiltaran
2 mins ago
add a comment |Â
up vote
0
down vote
I would not say "someone is sabotaging me" unless you have indisputable proof that is happening.
New contributor
Along these same lines, sabotage is a strong word. It's possible that this data is being updated for many reasons.
â Dan Delany
3 mins ago
add a comment |Â
up vote
0
down vote
I would not say "someone is sabotaging me" unless you have indisputable proof that is happening.
New contributor
Along these same lines, sabotage is a strong word. It's possible that this data is being updated for many reasons.
â Dan Delany
3 mins ago
add a comment |Â
up vote
0
down vote
up vote
0
down vote
I would not say "someone is sabotaging me" unless you have indisputable proof that is happening.
New contributor
I would not say "someone is sabotaging me" unless you have indisputable proof that is happening.
New contributor
New contributor
answered 32 mins ago
Eric J
92
92
New contributor
New contributor
Along these same lines, sabotage is a strong word. It's possible that this data is being updated for many reasons.
â Dan Delany
3 mins ago
add a comment |Â
Along these same lines, sabotage is a strong word. It's possible that this data is being updated for many reasons.
â Dan Delany
3 mins ago
Along these same lines, sabotage is a strong word. It's possible that this data is being updated for many reasons.
â Dan Delany
3 mins ago
Along these same lines, sabotage is a strong word. It's possible that this data is being updated for many reasons.
â Dan Delany
3 mins ago
add a comment |Â
up vote
0
down vote
Any code should take into account of erroneous input. It's unclear from your question how someone is "sabotaging" you by entering null data in the database. Null rows are common database data and your code should never assume all input is valid. Someone entering invalid data into your code is not "sabotaging" it especially if they are expecting some sort of output from it.
Now someone on the outside might sabotage your application. They could surmise that if you are not validating input, then it is entirely possible they could access the database through your broken code. Now if that is found to be from your code, it's a sure bet you might not have a job depending on your level.
It was for cutting short. In short if only the application is allowed to access the db, there would be' no bug. Someone is editing db tables directly. Im not speaking od null values only of course
â Exiltaran
47 secs ago
add a comment |Â
up vote
0
down vote
Any code should take into account of erroneous input. It's unclear from your question how someone is "sabotaging" you by entering null data in the database. Null rows are common database data and your code should never assume all input is valid. Someone entering invalid data into your code is not "sabotaging" it especially if they are expecting some sort of output from it.
Now someone on the outside might sabotage your application. They could surmise that if you are not validating input, then it is entirely possible they could access the database through your broken code. Now if that is found to be from your code, it's a sure bet you might not have a job depending on your level.
It was for cutting short. In short if only the application is allowed to access the db, there would be' no bug. Someone is editing db tables directly. Im not speaking od null values only of course
â Exiltaran
47 secs ago
add a comment |Â
up vote
0
down vote
up vote
0
down vote
Any code should take into account of erroneous input. It's unclear from your question how someone is "sabotaging" you by entering null data in the database. Null rows are common database data and your code should never assume all input is valid. Someone entering invalid data into your code is not "sabotaging" it especially if they are expecting some sort of output from it.
Now someone on the outside might sabotage your application. They could surmise that if you are not validating input, then it is entirely possible they could access the database through your broken code. Now if that is found to be from your code, it's a sure bet you might not have a job depending on your level.
Any code should take into account of erroneous input. It's unclear from your question how someone is "sabotaging" you by entering null data in the database. Null rows are common database data and your code should never assume all input is valid. Someone entering invalid data into your code is not "sabotaging" it especially if they are expecting some sort of output from it.
Now someone on the outside might sabotage your application. They could surmise that if you are not validating input, then it is entirely possible they could access the database through your broken code. Now if that is found to be from your code, it's a sure bet you might not have a job depending on your level.
answered 13 mins ago
Dan
4,0971719
4,0971719
It was for cutting short. In short if only the application is allowed to access the db, there would be' no bug. Someone is editing db tables directly. Im not speaking od null values only of course
â Exiltaran
47 secs ago
add a comment |Â
It was for cutting short. In short if only the application is allowed to access the db, there would be' no bug. Someone is editing db tables directly. Im not speaking od null values only of course
â Exiltaran
47 secs ago
It was for cutting short. In short if only the application is allowed to access the db, there would be' no bug. Someone is editing db tables directly. Im not speaking od null values only of course
â Exiltaran
47 secs ago
It was for cutting short. In short if only the application is allowed to access the db, there would be' no bug. Someone is editing db tables directly. Im not speaking od null values only of course
â Exiltaran
47 secs ago
add a comment |Â
Exiltaran is a new contributor. Be nice, and check out our Code of Conduct.
Exiltaran is a new contributor. Be nice, and check out our Code of Conduct.
Exiltaran is a new contributor. Be nice, and check out our Code of Conduct.
Exiltaran is a new contributor. Be nice, and check out our Code of Conduct.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fworkplace.stackexchange.com%2fquestions%2f119356%2fhow-can-i-not-take-bugs-found-in-software-i-work-on-personally%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Have you talked to the person who is setting the values to NULL in the database to find out why? Have you updated your code to handle the null values? If not, why not?
â Seth R
31 mins ago