"I would rather have a novice interviewer use a good process than have an experienced interviewer use a bad or mediocre process."
This provokes me to ask, is that also true of software development? Would we rather have a novice programmer using a good process than an experienced programmer using a bad or mediocre process?
My first thought is that the experienced programmer produces good results despite the bad process because they write a lot of tests, and so forth, but that suggest that they are using their own good process inside a bad process.
An experienced person using a bad or mediocre software development process really ought to be understood to be eschewing source code control and tests. They are patching production directly. They aren't putting thought into their names or software organization.
And yet they get some good results. But given this false dichotomy of novice with good process versus experienced with bad process... Which do we really prefer, and why?
I would say each developer also has their own process, which may be more or less or different than the organizational process. I find that good devs have a good personal process.
I think being an expert sometimes means you know which rules should be followed, and which rules can be bent for certain circumstances, possibly even producing a better result. Novice programmers may not know all the consequences of their actions, so it is better for them to follow a strong rigorous process.
Good results is also subjective. Does good results mean fast? Or that you can look at the code while not having to clean the vomit off your keyboard? Bug count? Getting it right the first time? Good UX?
Knowing what you're going for and what counts is where the process should be pointing, but sometimes they are just rules for rules sake.
A lot of programming has low stakes and immediate feedback. If a "bad" process means you have to fix a bug and recompile it's no biggie. And since there's rapid feedback, a "bad" programmer will usually be doing stuff that actually works.
Exceptions would be things like security, backups, major data / source code loss where things don't really go wrong until they go spectacularly wrong.
This provokes me to ask, is that also true of software development? Would we rather have a novice programmer using a good process than an experienced programmer using a bad or mediocre process?
My first thought is that the experienced programmer produces good results despite the bad process because they write a lot of tests, and so forth, but that suggest that they are using their own good process inside a bad process.
An experienced person using a bad or mediocre software development process really ought to be understood to be eschewing source code control and tests. They are patching production directly. They aren't putting thought into their names or software organization.
And yet they get some good results. But given this false dichotomy of novice with good process versus experienced with bad process... Which do we really prefer, and why?