3 ms·

I think they are just being posers. When we compare the efficiency of debugging (p. ex.) it is clear who can find the problem fast. Today if I'm conducting an

I think they are just being posers. When we compare the efficiency of debugging (p. ex.) it is clear who can find the problem fast. Today if I'm conducting an interview and the someone tries to convince me he/she is a good programmer and just use vi/vim, I need to rethink my decision because it can compromise the whole project. I'm not saying they are not good, but having the capability of fast debugging and solving problems fast is crucial sometimes and is part of the whole package. I was that kind of person someday and I understand the feeling. But for devops, vim or emacs are the all-in-hands tool and everyday editor, just because they are available in everywhere and work very well on terminal mode.

1_player 6y ago
I don't get it. Are you saying vim users are bad programmers and bad at debugging?
- catach 6y ago
  I believe the assumption is that IDEs are dramatically superior tools for debugging.
- nice_byte 6y ago
  he's saying vim users are hampering themselves.
flippinburgers 6y ago
Spoken like someone who has never gotten accustomed to the power of vim :) Do you know who would likely "compromise a project"? The junior dev that is unable to stray outside their IDE when getting things done.
xtracto 6y ago
Interesting comment. I've been programming for more than 25 years. Have used stuff like GWBASIC, TurboPascal/C , fancy ide like VisualStudio, Eclipse, Netbeans and the new kids like atom or vscode. I even used DDD at some point. Line debugging becomes less and less valuable as you become more mature in you dev career. Sometimes you have a race condition bug, some times the target architecture just doesn't provide it (devkitpro/devkitarm or embedded) and sometimes bugs that are evident in production just cannot be replicated in your debugging environment. In my experience it is more valuable to improve skills of building mental models of the system at hand, get effective with console logging for key info and troubleshoot issues that way.
- ohgodplsno 6y ago
  >some times the target architecture just doesn't provide it (devkitpro/devkitarm or embedded) and sometimes bugs that are evident in production just cannot be replicated in your debugging environment. It happens, yeah. What mostly happens is that 99% of software development has debuggers available and that they are infinitely better and more useful when resolving issues. Printing, then realizing you don't have enough info, chaning your code, recompiling, printing, etc, is just not good software development practices. Live with your constraints when you have no other choice. Use the tools that have been a standard in the industry when they are available to you.
jgwil2 6y ago
I think you should evaluate candidates based on the skill/knowledge they show in the interview and trust that if that is up to par, then they will be competent to choose the tools that work best for them.
oalae5niMiel7qu 6y ago
IDEs are great for the early stages of a project, but once it hits production, this is the only debugging flow that has ever worked for me: 1. Read the logs. 2. Read the code that produced the logs.

1_player 6y ago

I don't get it. Are you saying vim users are bad programmers and bad at debugging?

catach 6y ago
I believe the assumption is that IDEs are dramatically superior tools for debugging.
nice_byte 6y ago
he's saying vim users are hampering themselves.

flippinburgers 6y ago

Spoken like someone who has never gotten accustomed to the power of vim :) Do you know who would likely "compromise a project"? The junior dev that is unable to stray outside their IDE when getting things done.

xtracto 6y ago

Interesting comment. I've been programming for more than 25 years. Have used stuff like GWBASIC, TurboPascal/C , fancy ide like VisualStudio, Eclipse, Netbeans and the new kids like atom or vscode. I even used DDD at some point. Line debugging becomes less and less valuable as you become more mature in you dev career. Sometimes you have a race condition bug, some times the target architecture just doesn't provide it (devkitpro/devkitarm or embedded) and sometimes bugs that are evident in production just cannot be replicated in your debugging environment. In my experience it is more valuable to improve skills of building mental models of the system at hand, get effective with console logging for key info and troubleshoot issues that way.

ohgodplsno 6y ago
>some times the target architecture just doesn't provide it (devkitpro/devkitarm or embedded) and sometimes bugs that are evident in production just cannot be replicated in your debugging environment. It happens, yeah. What mostly happens is that 99% of software development has debuggers available and that they are infinitely better and more useful when resolving issues. Printing, then realizing you don't have enough info, chaning your code, recompiling, printing, etc, is just not good software development practices. Live with your constraints when you have no other choice. Use the tools that have been a standard in the industry when they are available to you.

jgwil2 6y ago

I think you should evaluate candidates based on the skill/knowledge they show in the interview and trust that if that is up to par, then they will be competent to choose the tools that work best for them.

oalae5niMiel7qu 6y ago

IDEs are great for the early stages of a project, but once it hits production, this is the only debugging flow that has ever worked for me: 1. Read the logs. 2. Read the code that produced the logs.