Experienced software and UX guy. Over 20 years making professional software. Lots of tech/tools/languages. Father of 7. Armchair philosopher. Currently focused on full stack dev with React, Node..
Thanks. I appreciate the thoughtful response. I'll stay away from the analogy because that can lead to rabbit holes that aren't applicable.
I wouldn't argue that knowing algorithms and judging computational complexity aren't useful. My contention is that they are, in the larger scheme of things, not very important during normal development. When you consider comparatively how little time you have with a candidate, I think it's wise to optimize that time for the issues that really make a bigger impact on a day-to-day basis.
I've worked with very smart devs who know lower-level things inside and out, but that can actually work against them. These are often the same devs who pride themselves on things like brevity and cleverness of code, which tends to accumulate to difficult to maintain code. They also can tend to focus on less important details and premature optimization that inhibits forward momentum on projects.
I personally value someone who cares more about code readability and clarity, who might need to spend an extra four hours to solve the occasional performance problem, more than the algorithmic genius. Again, this is speaking of general business software development. I absolutely acknowledge that different types of dev problems/domains call for different types of skilled devs.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Thanks. I appreciate the thoughtful response. I'll stay away from the analogy because that can lead to rabbit holes that aren't applicable.
I wouldn't argue that knowing algorithms and judging computational complexity aren't useful. My contention is that they are, in the larger scheme of things, not very important during normal development. When you consider comparatively how little time you have with a candidate, I think it's wise to optimize that time for the issues that really make a bigger impact on a day-to-day basis.
I've worked with very smart devs who know lower-level things inside and out, but that can actually work against them. These are often the same devs who pride themselves on things like brevity and cleverness of code, which tends to accumulate to difficult to maintain code. They also can tend to focus on less important details and premature optimization that inhibits forward momentum on projects.
I personally value someone who cares more about code readability and clarity, who might need to spend an extra four hours to solve the occasional performance problem, more than the algorithmic genius. Again, this is speaking of general business software development. I absolutely acknowledge that different types of dev problems/domains call for different types of skilled devs.