Having fun when programming should be much more important than having correct or fast code when you’re a programmer and should be what we should aim for first.
Having fun when programming should be much more important than having correct or fast code (…)
That’s only remotely reasonable if you’re a weekend warrior that messes with coding as a pastime. Even so, I’m not sure what fun you can extract from dealing with slow, broken code.
Of course those concepts are intertwined in some way.
But as a full time lead dev of a relatively big project, I find that a lot of people, often junior devs, concentrate a lot on what they think is “good code” and not a lot on whether they and other devs are having fun. It may make sense when you’re junior and you have to learn a lot at once, but when you’re experienced enough I feel that focusing on having fun, both for you and your team, should be much more important to us than focusing on precepts you read on having fast code and theoretically clean code, as long as it doesn’t lead the code to be less fun to work with in the long run.
For example, doing R&D re-implementing things from scratch, in most cases just to throw away the great majority of it, could be considered as fun by most programmers, even when it makes not much sense because what you did before also worked. As with switching some architecture around (perhaps wrongly, but it’s hard to know sometimes before you tried it).
I’ve come to very much dislike scrum or agile management as well due to all its protocols and the ways it enforces a certain way of progressing (with tickets, progress reporting, mostly short-term work) which focuses on the project’s goal (which really is what the company wants), sometimes at the expense of devs experimenting and just having fun (what I advocate we should aim for).
Though it all depends on your project and company I guess.
Having fun when programming should be much more important than having correct or fast code when you’re a programmer and should be what we should aim for first.
That’s only remotely reasonable if you’re a weekend warrior that messes with coding as a pastime. Even so, I’m not sure what fun you can extract from dealing with slow, broken code.
Of course those concepts are intertwined in some way.
But as a full time lead dev of a relatively big project, I find that a lot of people, often junior devs, concentrate a lot on what they think is “good code” and not a lot on whether they and other devs are having fun. It may make sense when you’re junior and you have to learn a lot at once, but when you’re experienced enough I feel that focusing on having fun, both for you and your team, should be much more important to us than focusing on precepts you read on having fast code and theoretically clean code, as long as it doesn’t lead the code to be less fun to work with in the long run.
For example, doing R&D re-implementing things from scratch, in most cases just to throw away the great majority of it, could be considered as fun by most programmers, even when it makes not much sense because what you did before also worked. As with switching some architecture around (perhaps wrongly, but it’s hard to know sometimes before you tried it).
I’ve come to very much dislike scrum or agile management as well due to all its protocols and the ways it enforces a certain way of progressing (with tickets, progress reporting, mostly short-term work) which focuses on the project’s goal (which really is what the company wants), sometimes at the expense of devs experimenting and just having fun (what I advocate we should aim for). Though it all depends on your project and company I guess.