No, this is just being slopy. Developers who "hate" code will always push to deal with the smallest amount of it, so they think twice before they touch the keyboard.
I guess it depends on how you define "hate". The amount of effort you put into your job tends to some function of how much you enjoy it and how much money you are paid. At a certain point the money tends to tailor off in effectiveness too.
If you hate your job then your main motivator is "how soon can I go home today?" or "how little brain power can I invest in this?" you will not be interested in the LOC count of the project at all.
If you enjoy programming then you are more likely to want to expend more effort thinking about how you could write the same thing using less/more maintainable code. There are of course programmers who will over architect solutions but this is usually because they believe that they are creating a structure that will keep LOC count lower over the long run.
After all code saving things like MVC/ORM frameworks were originally used by the early adopter more enthusiastic programmers.
I would say it's better to hate large bloated codebases, but I can't think there are many programmers who create these on purpose, it is usually a by product of flawed assumptions made in earlier stages or less skilled programmers.
If he doesn't understand the aspects of the business and doesn't have any stake on the final product he's not a developer, he's just a programmer doing repetitive work at a software factory - "code monkey" on jargon - and is not in a position to provide the kind of disruptive, ten-fold improvement software is able to produce.
Again this is sort of semantics, most companies will advertise positions that are repetitive "factory" jobs as "developer" positions. In fact some of the better programmers I know refer to themselves as "code monkeys" so I guess this is really a cultural thing.
It's an interesting point about automation and how much stake a developer should have in a business.
Most businesses now depend fundamentally on software in one way or another, for a glaring example of this see the UK banks that have had to cease pretty close all activity for the best part of a week because of a software problem. Also pretty much also businesses above a certain size have some custom code running somewhere.
Does this mean that all businesses should have a developer present at board level? Also should that board level person simply be someone with development experience or should they be involved in the day to day code production so that they can understand all of the decisions made?
This also ties into the debate about who should learn to program, for example do you get that experience at board level by teaching executives to write programs or instead do you promote programmers to board level and teach them about "business stuff"?
You don't have to love the ride to enjoy the trip. Programming is just a means to an end. We love the end, not the mean. He's not talking about worrying "how soon can I go home today". You do have a powerful motivator, which is the awesome software you're gonna build. You wanna write code because you wanna see your own thing built and working. Not because you love writing text on the editor.
If I could build great software without writing code I would. Unfortunately we're not there yet. As you said it yourself, most businesses now depend fundamentally on software. So being inside and working to make your code base as good and maintainable as possible, and understand those processes is important. So we do care about writing good software. But not because we love writing code, but because we hate that.
Right, but that's not an especially incitefull distinction to make. I imagine there are very few programmers around who
love programming because it means they get to type lots of characters into a text editor in the same way that nobody enjoys sex because it means they get to exercise their hips.
In fact this is probably a big motivator in the number of open source libraries available now, they were developed by somebody who wanted to achieve thing X but they needed to create byproduct Y in order to do that.
So it makes sense to share by byproduct Y with the people who need to make thing Z.
I guess it depends on how you define "hate". The amount of effort you put into your job tends to some function of how much you enjoy it and how much money you are paid. At a certain point the money tends to tailor off in effectiveness too.
If you hate your job then your main motivator is "how soon can I go home today?" or "how little brain power can I invest in this?" you will not be interested in the LOC count of the project at all. If you enjoy programming then you are more likely to want to expend more effort thinking about how you could write the same thing using less/more maintainable code. There are of course programmers who will over architect solutions but this is usually because they believe that they are creating a structure that will keep LOC count lower over the long run.
After all code saving things like MVC/ORM frameworks were originally used by the early adopter more enthusiastic programmers.
I would say it's better to hate large bloated codebases, but I can't think there are many programmers who create these on purpose, it is usually a by product of flawed assumptions made in earlier stages or less skilled programmers.
If he doesn't understand the aspects of the business and doesn't have any stake on the final product he's not a developer, he's just a programmer doing repetitive work at a software factory - "code monkey" on jargon - and is not in a position to provide the kind of disruptive, ten-fold improvement software is able to produce.
Again this is sort of semantics, most companies will advertise positions that are repetitive "factory" jobs as "developer" positions. In fact some of the better programmers I know refer to themselves as "code monkeys" so I guess this is really a cultural thing.
It's an interesting point about automation and how much stake a developer should have in a business. Most businesses now depend fundamentally on software in one way or another, for a glaring example of this see the UK banks that have had to cease pretty close all activity for the best part of a week because of a software problem. Also pretty much also businesses above a certain size have some custom code running somewhere.
Does this mean that all businesses should have a developer present at board level? Also should that board level person simply be someone with development experience or should they be involved in the day to day code production so that they can understand all of the decisions made?
This also ties into the debate about who should learn to program, for example do you get that experience at board level by teaching executives to write programs or instead do you promote programmers to board level and teach them about "business stuff"?