Mixing
![Is a client identifying my device (which caused high network traffic) possibly in violation of privacy regulations? [closed]](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgjbpfN9tAutmK93bJRC3ZoROZzi2TJDms5n8_qJuhgE0a9b52OOHayv3NGT8igAdFL7byXNst-_1DZK5SjrIJ28_6RQPUpBROqMs5s6jo-ZsjX8kjDwfxJufIitH3TaQRXWaGSQKRQib-f/s72-c/1.jpg)
As a software developer, how do I ask an employer about internal support when handing production errors?
Clash Royale CLAN TAG#URR8PPP
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;
up vote
3
down vote
favorite
I've worked as a software developer for 4 years and find that there is a specific scenario I dislike very much.
The scenario is that I am "thrown" at a problem with no internal support. I will be tasked by my manager to fix something that went wrong and will have no useful access to how anything is done, how the software works, no documentation, all the test code I dig up are out-dated and do not work.
The problem is that I am literally "stuck" with this type of cases until it is fixed or I leave the company, then whatever I don't fix goes to someone else. When I started I inherited some of these, and well, I still had them when I left. I don't think the manager breathed down my neck to fix these, but having these "unfixable" cases with me bothered me quite a bit, and felt it was pointless to give them to me.
Just recalling from my last role, there was a case dealing with FTP connections. It took me 2 days of talking with people around the office (100 people office) to get a definitive answer on whether our internal FTP connections to the outside are passive or active. My manager obviously didn't know, so he pointed me to different people, then I had to track down false leads, bad leads, people who aren't sure, etc.
I'm not sure how to ask an interviewer about this type of scenario. How can I ask a potential employer about internal facing resources to assist developers? I am thinking of either some sort of documentation practices, or mentoring role for new hires, or something... but I have no idea how to frame the question.
interviewing software-industry
asked Oct 17 '15 at 6:43
Nelson
3,21921225
suggest improvements |Â
up vote
3
down vote
favorite
I've worked as a software developer for 4 years and find that there is a specific scenario I dislike very much.
The scenario is that I am "thrown" at a problem with no internal support. I will be tasked by my manager to fix something that went wrong and will have no useful access to how anything is done, how the software works, no documentation, all the test code I dig up are out-dated and do not work.
The problem is that I am literally "stuck" with this type of cases until it is fixed or I leave the company, then whatever I don't fix goes to someone else. When I started I inherited some of these, and well, I still had them when I left. I don't think the manager breathed down my neck to fix these, but having these "unfixable" cases with me bothered me quite a bit, and felt it was pointless to give them to me.
Just recalling from my last role, there was a case dealing with FTP connections. It took me 2 days of talking with people around the office (100 people office) to get a definitive answer on whether our internal FTP connections to the outside are passive or active. My manager obviously didn't know, so he pointed me to different people, then I had to track down false leads, bad leads, people who aren't sure, etc.
I'm not sure how to ask an interviewer about this type of scenario. How can I ask a potential employer about internal facing resources to assist developers? I am thinking of either some sort of documentation practices, or mentoring role for new hires, or something... but I have no idea how to frame the question.
interviewing software-industry
asked Oct 17 '15 at 6:43
Nelson
3,21921225
"What's your approach to keeping down technical debt?"
– A E
Oct 17 '15 at 14:40
There are many types of software developers. I think a great software developer would--in the FTP scenario you described--NOT rely upon everyone else to solve a problem. A great software developer would 1) review the code that initiates the FTP connection, 2) start up a fake FTP server with a known PASV configuration and then point the client to it, 3) initiate the FTP connection and then use other software or commands to review the open connections to infer the answer. You didn't need anyone else to solve this mystery for you.
– Michael Blankenship
Oct 17 '15 at 21:43
suggest improvements |Â
up vote
3
down vote
favorite
up vote
3
down vote
favorite
I've worked as a software developer for 4 years and find that there is a specific scenario I dislike very much.
The scenario is that I am "thrown" at a problem with no internal support. I will be tasked by my manager to fix something that went wrong and will have no useful access to how anything is done, how the software works, no documentation, all the test code I dig up are out-dated and do not work.
The problem is that I am literally "stuck" with this type of cases until it is fixed or I leave the company, then whatever I don't fix goes to someone else. When I started I inherited some of these, and well, I still had them when I left. I don't think the manager breathed down my neck to fix these, but having these "unfixable" cases with me bothered me quite a bit, and felt it was pointless to give them to me.
Just recalling from my last role, there was a case dealing with FTP connections. It took me 2 days of talking with people around the office (100 people office) to get a definitive answer on whether our internal FTP connections to the outside are passive or active. My manager obviously didn't know, so he pointed me to different people, then I had to track down false leads, bad leads, people who aren't sure, etc.
I'm not sure how to ask an interviewer about this type of scenario. How can I ask a potential employer about internal facing resources to assist developers? I am thinking of either some sort of documentation practices, or mentoring role for new hires, or something... but I have no idea how to frame the question.
interviewing software-industry
asked Oct 17 '15 at 6:43
Nelson
3,21921225
I've worked as a software developer for 4 years and find that there is a specific scenario I dislike very much.
The scenario is that I am "thrown" at a problem with no internal support. I will be tasked by my manager to fix something that went wrong and will have no useful access to how anything is done, how the software works, no documentation, all the test code I dig up are out-dated and do not work.
The problem is that I am literally "stuck" with this type of cases until it is fixed or I leave the company, then whatever I don't fix goes to someone else. When I started I inherited some of these, and well, I still had them when I left. I don't think the manager breathed down my neck to fix these, but having these "unfixable" cases with me bothered me quite a bit, and felt it was pointless to give them to me.
Just recalling from my last role, there was a case dealing with FTP connections. It took me 2 days of talking with people around the office (100 people office) to get a definitive answer on whether our internal FTP connections to the outside are passive or active. My manager obviously didn't know, so he pointed me to different people, then I had to track down false leads, bad leads, people who aren't sure, etc.
I'm not sure how to ask an interviewer about this type of scenario. How can I ask a potential employer about internal facing resources to assist developers? I am thinking of either some sort of documentation practices, or mentoring role for new hires, or something... but I have no idea how to frame the question.
interviewing software-industry
asked Oct 17 '15 at 6:43
Nelson
3,21921225
asked Oct 17 '15 at 6:43
Nelson
3,21921225
asked Oct 17 '15 at 6:43
Nelson
3,21921225
asked Oct 17 '15 at 6:43
Nelson
3,21921225
3,21921225
"What's your approach to keeping down technical debt?"
– A E
Oct 17 '15 at 14:40
There are many types of software developers. I think a great software developer would--in the FTP scenario you described--NOT rely upon everyone else to solve a problem. A great software developer would 1) review the code that initiates the FTP connection, 2) start up a fake FTP server with a known PASV configuration and then point the client to it, 3) initiate the FTP connection and then use other software or commands to review the open connections to infer the answer. You didn't need anyone else to solve this mystery for you.
– Michael Blankenship
Oct 17 '15 at 21:43
suggest improvements |Â
"What's your approach to keeping down technical debt?"
– A E
Oct 17 '15 at 14:40
There are many types of software developers. I think a great software developer would--in the FTP scenario you described--NOT rely upon everyone else to solve a problem. A great software developer would 1) review the code that initiates the FTP connection, 2) start up a fake FTP server with a known PASV configuration and then point the client to it, 3) initiate the FTP connection and then use other software or commands to review the open connections to infer the answer. You didn't need anyone else to solve this mystery for you.
– Michael Blankenship
Oct 17 '15 at 21:43
"What's your approach to keeping down technical debt?"
– A E
Oct 17 '15 at 14:40
"What's your approach to keeping down technical debt?"
– A E
Oct 17 '15 at 14:40
There are many types of software developers. I think a great software developer would--in the FTP scenario you described--NOT rely upon everyone else to solve a problem. A great software developer would 1) review the code that initiates the FTP connection, 2) start up a fake FTP server with a known PASV configuration and then point the client to it, 3) initiate the FTP connection and then use other software or commands to review the open connections to infer the answer. You didn't need anyone else to solve this mystery for you.
– Michael Blankenship
Oct 17 '15 at 21:43
There are many types of software developers. I think a great software developer would--in the FTP scenario you described--NOT rely upon everyone else to solve a problem. A great software developer would 1) review the code that initiates the FTP connection, 2) start up a fake FTP server with a known PASV configuration and then point the client to it, 3) initiate the FTP connection and then use other software or commands to review the open connections to infer the answer. You didn't need anyone else to solve this mystery for you.
– Michael Blankenship
Oct 17 '15 at 21:43
suggest improvements |Â
3 Answers
3
active
oldest
votes
up vote
2
down vote
Asking about documentation protocols would be the best way I would think. A perfectly legit question to ask in an interview. It's always a good idea to get an idea of what you will be tasked with before you start. But sometimes no one admits there's documentation issues, or they just don't know, so even then you can be thrown in the deep end.
There's not a great deal else you can do unfortunately.
I've never come across anything unfixable though, I have had to re-write things from scratch, but always found a solution eventually. It's what I was tasked to do. Developing methodology to troubleshoot and deal with these situations is more productive in the long run.
answered Oct 17 '15 at 7:17
Kilisi
94.7k50216377
suggest improvements |Â
up vote
2
down vote
Pay attention during the interview process especially if you get a chance to visit the office. I've had interviews where attendees had to "put out fires" during my interview. Others showed up late, rescheduled and basically showed how chaotic their world was. Some will tell you this is normal. Everyone is busy and working 80 hours a week, blah, blah, blah - nonsense.
Good managers run the interference and create an environment where things can get done. If they don't show they're organized especially during the hiring process, other areas are probably a mess. Amazed at how over-worked teams don't make time to hire people and wonder why they're over-worked.
Ask about how requirements are gathered and documented. Where do they track requests and projects? Do they have any established methodology or are they "kind-of-sort-of-agile/waterfall."
Those aren't necessarily indicators of a bad work environment. My group works on critical highly-available systems. There are issues that will prevent some of the folks signed up to interview a candidate from being able to do it at the last minute. One of those popped up during my interview and if I had let that dissuade me, I would have missed out working on the best team of my decades long career. It's much more important to notice how stressed the folks are, not whether they have an urgent matter come up. The big red flag is how many people you pass in the hall that look miserable.
– ColleenV
Oct 17 '15 at 19:52
suggest improvements |Â
up vote
2
down vote
I find that often in organizations like that, you can find comments in the code that have people's names in them. Go to your project manager and say, "I need to have some time with 'msmith' or whoever is doing his job now.
answered Oct 17 '15 at 18:10
dwoz
1,283510
1
It won't have their name in the code, necessarily. But if you review the change management system it will show who's checked out/in the parts of it.
– Michael Blankenship
Oct 17 '15 at 21:46
@MichaelBlankenship, I fully agree...but the kinds of problems that the OP is describing are typical of the kinds of orgs where devs put their names in the code...and leave commented code, etc. i.e. "spaghetti" that forgets you still have the previous version in your repository.
– dwoz
Oct 18 '15 at 17:22
suggest improvements |Â
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
2
down vote
Asking about documentation protocols would be the best way I would think. A perfectly legit question to ask in an interview. It's always a good idea to get an idea of what you will be tasked with before you start. But sometimes no one admits there's documentation issues, or they just don't know, so even then you can be thrown in the deep end.
There's not a great deal else you can do unfortunately.
I've never come across anything unfixable though, I have had to re-write things from scratch, but always found a solution eventually. It's what I was tasked to do. Developing methodology to troubleshoot and deal with these situations is more productive in the long run.
answered Oct 17 '15 at 7:17
Kilisi
94.7k50216377
suggest improvements |Â
up vote
2
down vote
Asking about documentation protocols would be the best way I would think. A perfectly legit question to ask in an interview. It's always a good idea to get an idea of what you will be tasked with before you start. But sometimes no one admits there's documentation issues, or they just don't know, so even then you can be thrown in the deep end.
There's not a great deal else you can do unfortunately.
I've never come across anything unfixable though, I have had to re-write things from scratch, but always found a solution eventually. It's what I was tasked to do. Developing methodology to troubleshoot and deal with these situations is more productive in the long run.
answered Oct 17 '15 at 7:17
Kilisi
94.7k50216377
suggest improvements |Â
up vote
2
down vote
up vote
2
down vote
Asking about documentation protocols would be the best way I would think. A perfectly legit question to ask in an interview. It's always a good idea to get an idea of what you will be tasked with before you start. But sometimes no one admits there's documentation issues, or they just don't know, so even then you can be thrown in the deep end.
There's not a great deal else you can do unfortunately.
I've never come across anything unfixable though, I have had to re-write things from scratch, but always found a solution eventually. It's what I was tasked to do. Developing methodology to troubleshoot and deal with these situations is more productive in the long run.
answered Oct 17 '15 at 7:17
Kilisi
94.7k50216377
Asking about documentation protocols would be the best way I would think. A perfectly legit question to ask in an interview. It's always a good idea to get an idea of what you will be tasked with before you start. But sometimes no one admits there's documentation issues, or they just don't know, so even then you can be thrown in the deep end.
There's not a great deal else you can do unfortunately.
I've never come across anything unfixable though, I have had to re-write things from scratch, but always found a solution eventually. It's what I was tasked to do. Developing methodology to troubleshoot and deal with these situations is more productive in the long run.
answered Oct 17 '15 at 7:17
Kilisi
94.7k50216377
edited Oct 17 '15 at 7:25
answered Oct 17 '15 at 7:17
Kilisi
94.7k50216377
answered Oct 17 '15 at 7:17
Kilisi
94.7k50216377
answered Oct 17 '15 at 7:17
Kilisi
94.7k50216377
94.7k50216377
suggest improvements |Â
suggest improvements |Â
up vote
2
down vote
Pay attention during the interview process especially if you get a chance to visit the office. I've had interviews where attendees had to "put out fires" during my interview. Others showed up late, rescheduled and basically showed how chaotic their world was. Some will tell you this is normal. Everyone is busy and working 80 hours a week, blah, blah, blah - nonsense.
Good managers run the interference and create an environment where things can get done. If they don't show they're organized especially during the hiring process, other areas are probably a mess. Amazed at how over-worked teams don't make time to hire people and wonder why they're over-worked.
Ask about how requirements are gathered and documented. Where do they track requests and projects? Do they have any established methodology or are they "kind-of-sort-of-agile/waterfall."
Those aren't necessarily indicators of a bad work environment. My group works on critical highly-available systems. There are issues that will prevent some of the folks signed up to interview a candidate from being able to do it at the last minute. One of those popped up during my interview and if I had let that dissuade me, I would have missed out working on the best team of my decades long career. It's much more important to notice how stressed the folks are, not whether they have an urgent matter come up. The big red flag is how many people you pass in the hall that look miserable.
– ColleenV
Oct 17 '15 at 19:52
suggest improvements |Â
up vote
2
down vote
Pay attention during the interview process especially if you get a chance to visit the office. I've had interviews where attendees had to "put out fires" during my interview. Others showed up late, rescheduled and basically showed how chaotic their world was. Some will tell you this is normal. Everyone is busy and working 80 hours a week, blah, blah, blah - nonsense.
Good managers run the interference and create an environment where things can get done. If they don't show they're organized especially during the hiring process, other areas are probably a mess. Amazed at how over-worked teams don't make time to hire people and wonder why they're over-worked.
Ask about how requirements are gathered and documented. Where do they track requests and projects? Do they have any established methodology or are they "kind-of-sort-of-agile/waterfall."
Those aren't necessarily indicators of a bad work environment. My group works on critical highly-available systems. There are issues that will prevent some of the folks signed up to interview a candidate from being able to do it at the last minute. One of those popped up during my interview and if I had let that dissuade me, I would have missed out working on the best team of my decades long career. It's much more important to notice how stressed the folks are, not whether they have an urgent matter come up. The big red flag is how many people you pass in the hall that look miserable.
– ColleenV
Oct 17 '15 at 19:52
suggest improvements |Â
up vote
2
down vote
up vote
2
down vote
Pay attention during the interview process especially if you get a chance to visit the office. I've had interviews where attendees had to "put out fires" during my interview. Others showed up late, rescheduled and basically showed how chaotic their world was. Some will tell you this is normal. Everyone is busy and working 80 hours a week, blah, blah, blah - nonsense.
Good managers run the interference and create an environment where things can get done. If they don't show they're organized especially during the hiring process, other areas are probably a mess. Amazed at how over-worked teams don't make time to hire people and wonder why they're over-worked.
Ask about how requirements are gathered and documented. Where do they track requests and projects? Do they have any established methodology or are they "kind-of-sort-of-agile/waterfall."
Pay attention during the interview process especially if you get a chance to visit the office. I've had interviews where attendees had to "put out fires" during my interview. Others showed up late, rescheduled and basically showed how chaotic their world was. Some will tell you this is normal. Everyone is busy and working 80 hours a week, blah, blah, blah - nonsense.
Good managers run the interference and create an environment where things can get done. If they don't show they're organized especially during the hiring process, other areas are probably a mess. Amazed at how over-worked teams don't make time to hire people and wonder why they're over-worked.
Ask about how requirements are gathered and documented. Where do they track requests and projects? Do they have any established methodology or are they "kind-of-sort-of-agile/waterfall."
answered Oct 17 '15 at 13:37
user8365
Those aren't necessarily indicators of a bad work environment. My group works on critical highly-available systems. There are issues that will prevent some of the folks signed up to interview a candidate from being able to do it at the last minute. One of those popped up during my interview and if I had let that dissuade me, I would have missed out working on the best team of my decades long career. It's much more important to notice how stressed the folks are, not whether they have an urgent matter come up. The big red flag is how many people you pass in the hall that look miserable.
– ColleenV
Oct 17 '15 at 19:52
suggest improvements |Â
Those aren't necessarily indicators of a bad work environment. My group works on critical highly-available systems. There are issues that will prevent some of the folks signed up to interview a candidate from being able to do it at the last minute. One of those popped up during my interview and if I had let that dissuade me, I would have missed out working on the best team of my decades long career. It's much more important to notice how stressed the folks are, not whether they have an urgent matter come up. The big red flag is how many people you pass in the hall that look miserable.
– ColleenV
Oct 17 '15 at 19:52
Those aren't necessarily indicators of a bad work environment. My group works on critical highly-available systems. There are issues that will prevent some of the folks signed up to interview a candidate from being able to do it at the last minute. One of those popped up during my interview and if I had let that dissuade me, I would have missed out working on the best team of my decades long career. It's much more important to notice how stressed the folks are, not whether they have an urgent matter come up. The big red flag is how many people you pass in the hall that look miserable.
– ColleenV
Oct 17 '15 at 19:52
Those aren't necessarily indicators of a bad work environment. My group works on critical highly-available systems. There are issues that will prevent some of the folks signed up to interview a candidate from being able to do it at the last minute. One of those popped up during my interview and if I had let that dissuade me, I would have missed out working on the best team of my decades long career. It's much more important to notice how stressed the folks are, not whether they have an urgent matter come up. The big red flag is how many people you pass in the hall that look miserable.
– ColleenV
Oct 17 '15 at 19:52
suggest improvements |Â
up vote
2
down vote
I find that often in organizations like that, you can find comments in the code that have people's names in them. Go to your project manager and say, "I need to have some time with 'msmith' or whoever is doing his job now.
answered Oct 17 '15 at 18:10
dwoz
1,283510
1
It won't have their name in the code, necessarily. But if you review the change management system it will show who's checked out/in the parts of it.
– Michael Blankenship
Oct 17 '15 at 21:46
@MichaelBlankenship, I fully agree...but the kinds of problems that the OP is describing are typical of the kinds of orgs where devs put their names in the code...and leave commented code, etc. i.e. "spaghetti" that forgets you still have the previous version in your repository.
– dwoz
Oct 18 '15 at 17:22
suggest improvements |Â
up vote
2
down vote
I find that often in organizations like that, you can find comments in the code that have people's names in them. Go to your project manager and say, "I need to have some time with 'msmith' or whoever is doing his job now.
answered Oct 17 '15 at 18:10
dwoz
1,283510
1
It won't have their name in the code, necessarily. But if you review the change management system it will show who's checked out/in the parts of it.
– Michael Blankenship
Oct 17 '15 at 21:46
@MichaelBlankenship, I fully agree...but the kinds of problems that the OP is describing are typical of the kinds of orgs where devs put their names in the code...and leave commented code, etc. i.e. "spaghetti" that forgets you still have the previous version in your repository.
– dwoz
Oct 18 '15 at 17:22
suggest improvements |Â
up vote
2
down vote
up vote
2
down vote
I find that often in organizations like that, you can find comments in the code that have people's names in them. Go to your project manager and say, "I need to have some time with 'msmith' or whoever is doing his job now.
answered Oct 17 '15 at 18:10
dwoz
1,283510
I find that often in organizations like that, you can find comments in the code that have people's names in them. Go to your project manager and say, "I need to have some time with 'msmith' or whoever is doing his job now.
answered Oct 17 '15 at 18:10
dwoz
1,283510
answered Oct 17 '15 at 18:10
dwoz
1,283510
answered Oct 17 '15 at 18:10
dwoz
1,283510
answered Oct 17 '15 at 18:10
dwoz
1,283510
1,283510
1
It won't have their name in the code, necessarily. But if you review the change management system it will show who's checked out/in the parts of it.
– Michael Blankenship
Oct 17 '15 at 21:46
@MichaelBlankenship, I fully agree...but the kinds of problems that the OP is describing are typical of the kinds of orgs where devs put their names in the code...and leave commented code, etc. i.e. "spaghetti" that forgets you still have the previous version in your repository.
– dwoz
Oct 18 '15 at 17:22
suggest improvements |Â
1
It won't have their name in the code, necessarily. But if you review the change management system it will show who's checked out/in the parts of it.
– Michael Blankenship
Oct 17 '15 at 21:46
@MichaelBlankenship, I fully agree...but the kinds of problems that the OP is describing are typical of the kinds of orgs where devs put their names in the code...and leave commented code, etc. i.e. "spaghetti" that forgets you still have the previous version in your repository.
– dwoz
Oct 18 '15 at 17:22
1
1
It won't have their name in the code, necessarily. But if you review the change management system it will show who's checked out/in the parts of it.
– Michael Blankenship
Oct 17 '15 at 21:46
It won't have their name in the code, necessarily. But if you review the change management system it will show who's checked out/in the parts of it.
– Michael Blankenship
Oct 17 '15 at 21:46
@MichaelBlankenship, I fully agree...but the kinds of problems that the OP is describing are typical of the kinds of orgs where devs put their names in the code...and leave commented code, etc. i.e. "spaghetti" that forgets you still have the previous version in your repository.
– dwoz
Oct 18 '15 at 17:22
@MichaelBlankenship, I fully agree...but the kinds of problems that the OP is describing are typical of the kinds of orgs where devs put their names in the code...and leave commented code, etc. i.e. "spaghetti" that forgets you still have the previous version in your repository.
– dwoz
Oct 18 '15 at 17:22
suggest improvements |Â
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%2f56087%2fas-a-software-developer-how-do-i-ask-an-employer-about-internal-support-when-ha%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
"What's your approach to keeping down technical debt?"
– A E
Oct 17 '15 at 14:40
There are many types of software developers. I think a great software developer would--in the FTP scenario you described--NOT rely upon everyone else to solve a problem. A great software developer would 1) review the code that initiates the FTP connection, 2) start up a fake FTP server with a known PASV configuration and then point the client to it, 3) initiate the FTP connection and then use other software or commands to review the open connections to infer the answer. You didn't need anyone else to solve this mystery for you.
– Michael Blankenship
Oct 17 '15 at 21:43