At the end of the day, the business solution is always the most important part of the equation, but it’s not the only part. While I’m working on a solution, I’m also looking at tools, scaffolding, and framework. This is especially true if others are going to be working on the project, and that accounts for nearly every non-trivial project.
How easy is it to set up? How easy is it to work with? Do the expressions make sense? Can I hand it off to my least experienced teammate, get them to pick this up, and expect reasonable results? (For that matter, can I hand it off to my most experienced teammate and expect them to respect the design decisions I made? )
Keeping my head in the code is critical. Loosing touch with tools means shooting in the dark on the above questions. It doesn’t matter what their experience is, if you ask someone to push a tack into a corkboard, hand them the wrong tools for the job, they won’t be able to push the thumbtack into the corkboard… or you’ll nuke your budget paying for tools that are overpowered for the job. (But that thumbtack will be SO IN THERE!)
In any case, in most projects, after the architecture & technical designs have been sorted out, frameworks, built, automations put in place, I’ll take on the coding, too.
Of course, I’ve said this before… if you can really simplify the work, what’s to stop you from taking the extra step and automating it? I’m always eyeing code, especially “formulaic”, repetititive stuff, looking for opportunities to simplify, abstract, and/or automate.
