As a Software Engineer, what's our job?
As a Software Engineer, what's our responsibility?
As a Software Engineer, what do we do for the company?
I assume we all have a job description - Is that what we do? Design, Write, Test, and Debug software?
At a high, generic level, sure. Why though?
Why do we do these things?
What's is our responsibility in doing these things?
Is our job to "write code"?
Definitely not. That's what we do in the early stages of the career - that's the manual process of part of our job. It'd be like assuming the assembly line is where cars are built. ... Technically yes - but there's so much more behind the scene.
What do we really do? That's not the question I want to actually ask - What SHOULD we really do?
The biggest thing I SEE from software engineers as our job is by what they do. From that - our responsibility and what we do for the company is - Deliver functional software.
Of course that's part of it - deliver working software. Which isn't what anyone cares about. If we never deliver we may have never written it so deliver is important. The working software many not help anyone.
Let's constrain it to delivery of working software the business has asked for. Otherwise, boy do I have a lot of random things to go off an write. :)
Why do we want to deliver software for the business? In the end - to provide value to customer.
A software engineer co-worker of mine is fantastically customer focused. It's what drives him to do the best work in his role - being able to provide value to the customer.
I am not as customer focused - I tend to be focused on the code. Quality, maintainability, testability - and that's what drives me. Building the software as best as I can (cosntraints, time, blah blah) and the side effect is that we deliver value to the customer.
My co-worker focuses on delivering value to the customer as best as possible, and the side effect is quality, maintainable, testable code.
Is our job delivering value to the customer?
Part of it.
There's way too much focus on deliver of features. The maintenance of the features tends to be an afterthought. Something that's done because it has to be. I haven't seen this as core to what the business expects from software engineers. It's not core to what the business expects from it's software.
I look at the main responsibility of software engineers as the maintainers of the value of digital assets.
Code is an asset.
Untouched code depreciates. Tech debt is not debt - and as much as I love the zombie analogy, this looks at 'tech debt' as a decrease of value in the asset. 'Tech Debt' is a digital expense - It will be paid.
Bugs cost money, the asset is worth less. Money in both developer time, and customer satisfaction. It's why we fix big bugs before little bugs - big bugs cost more. They cost more because the digital asset had an unknown expense.
Unmaintainable code is expensive code. It takes longer to be able to deliver value to the customer - Taking longer costs more, in dev time, and customer satisfaction. We want to be able to deliver quickly - and easily fix issues that come up.
Our industry doesn't look at code as a digital asset - if it did we wouldn't throw it away because it's become unmaintainable. I've worked in multiple of these rewrites. One was a prototype into production, the other was years of cruft that no one maintained. It was so invasive, it hit the point it was cheaper to re-write the entire site than iteratively update it.
When we have to re-write, we've failed as software engineers. We've failed to maintain the digital asset under our care. It became so worthless that it's being thrown away - How's that for doing your job? What you did is being thrown away.
Now - I'm a huge proponent of throwing away code, because code you don't have doesn't have any bugs. This is within a project though. When the value the code provides is no longer needed, hell yeah chuck it. If the value is still needed, and you have to throw it away because it can't be worked to provide the value the business needs... You've failed as a software engineer.
Having to re-write a system is a declaration that the software engineers responsible for it have failed to do their job - the digital asset was allowed to become too costly to be worth keeping.
And yet - its so common. Its easier to rewrite the same shit in new tech and let that decay and get rewritten again than put the time in to maintain the existing digital asset.
I look at my job as a Software Engineer to maintain and increase the value of the digital asset I'm responsible for.
More features isn't increasing the value of the digital asset. It might be providing more value to the business, but that's not the asset we are maintaining. We're creating value in a digital asset that the business utilizes to provide value to the customer.
More features, done quick and dirty, decrease the value of the digital asset we're responsibile for.
There's plenty of reasons to get something done quick and dirty. If we move on, we're being irresponsible in our role as software engineers towards the digital asset we're responsbile for.