How can I not take bugs found in software I work on personally?

The name of the pictureThe name of the pictureThe name of the pictureClash 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.










share|improve this question









New contributor




Exiltaran is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.



















  • 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
















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.










share|improve this question









New contributor




Exiltaran is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.



















  • 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












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.










share|improve this question









New contributor




Exiltaran is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.











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






share|improve this question









New contributor




Exiltaran is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.











share|improve this question









New contributor




Exiltaran is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.









share|improve this question




share|improve this question








edited 5 mins ago









Ben Mz

3,2471524




3,2471524






New contributor




Exiltaran is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.









asked 53 mins ago









Exiltaran

1




1




New contributor




Exiltaran is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.





New contributor





Exiltaran is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.






Exiltaran is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.











  • 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




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










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.






share|improve this answer




















  • 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

















up vote
0
down vote













I would not say "someone is sabotaging me" unless you have indisputable proof that is happening.






share|improve this answer








New contributor




Eric J is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.

















  • 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

















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.






share|improve this answer




















  • 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










Your Answer







StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "423"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);

else
createEditor();

);

function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
convertImagesToLinks: false,
noModals: false,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
noCode: true, onDemand: false,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);



);






Exiltaran is a new contributor. Be nice, and check out our Code of Conduct.









 

draft saved


draft discarded


















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

























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.






share|improve this answer




















  • 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














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.






share|improve this answer




















  • 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












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.






share|improve this answer













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.







share|improve this answer












share|improve this answer



share|improve this answer










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
















  • 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












up vote
0
down vote













I would not say "someone is sabotaging me" unless you have indisputable proof that is happening.






share|improve this answer








New contributor




Eric J is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.

















  • 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














up vote
0
down vote













I would not say "someone is sabotaging me" unless you have indisputable proof that is happening.






share|improve this answer








New contributor




Eric J is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.

















  • 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












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.






share|improve this answer








New contributor




Eric J is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.









I would not say "someone is sabotaging me" unless you have indisputable proof that is happening.







share|improve this answer








New contributor




Eric J is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.









share|improve this answer



share|improve this answer






New contributor




Eric J is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.









answered 32 mins ago









Eric J

92




92




New contributor




Eric J is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.





New contributor





Eric J is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.






Eric J is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.











  • 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




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










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.






share|improve this answer




















  • 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














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.






share|improve this answer




















  • 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












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.






share|improve this answer












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.







share|improve this answer












share|improve this answer



share|improve this answer










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
















  • 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










Exiltaran is a new contributor. Be nice, and check out our Code of Conduct.









 

draft saved


draft discarded


















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.













 


draft saved


draft discarded














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

















































































Comments

Popular posts from this blog

Long meetings (6-7 hours a day): Being “babysat” by supervisor

What does second last employer means? [closed]

One-line joke