He/Him; Senior Software Developer, IT Swiss-army-knife, 3 programming blades, 1 hardware, 1 networking and infrastructure and a corkscrew. The tweezers have long since been lost. (Recent ADHD diag.)
I would also add, knowing when to NOT write code to try to solve a problem.
As people trained to, and love to, solve problems with technology: its easy to forget that a new, or modified piece of software may not be the best tool to solve the problem.
Often in my career I've come across problems that the business clients have thought needed to be solved with a new software tool. However after some real analysis, the root problem was a business process problem or people problem. Often these are solved by a) removing legacy business processes that no longer served a purpose (It's how we've always done it), training people on the correct way to do things, or often simply having people talk to each other.
Any bit of code that is NOT written is another bit of code that doesn't need maintenance, doesn't incur technical debt, and doesn't hide implementation (and eventually becomes part of the organizational magic.)
I'm often asked to help automate business processes. The clients bring a flow diagram many feet across describing the process they currently follow. They usually believe they need to automate it exactly as it is. My first job is to help them walk through and evaluate the utility of each box, line, and all other items in the process. We can usually, after a few rounds, cut out about 1/4 to 1/2 of the process as followed while maintaining the same utility, well before any code has been written.
I would also add, knowing when to NOT write code to try to solve a problem.
As people trained to, and love to, solve problems with technology: its easy to forget that a new, or modified piece of software may not be the best tool to solve the problem.
Often in my career I've come across problems that the business clients have thought needed to be solved with a new software tool. However after some real analysis, the root problem was a business process problem or people problem. Often these are solved by a) removing legacy business processes that no longer served a purpose (It's how we've always done it), training people on the correct way to do things, or often simply having people talk to each other.
Any bit of code that is NOT written is another bit of code that doesn't need maintenance, doesn't incur technical debt, and doesn't hide implementation (and eventually becomes part of the organizational magic.)
I'm often asked to help automate business processes. The clients bring a flow diagram many feet across describing the process they currently follow. They usually believe they need to automate it exactly as it is. My first job is to help them walk through and evaluate the utility of each box, line, and all other items in the process. We can usually, after a few rounds, cut out about 1/4 to 1/2 of the process as followed while maintaining the same utility, well before any code has been written.
Valid point but I think that is really high level and something for a great developer. We still need room for improvement. 😉