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.
It can be rewarding. For me, this has a lot to do with team culture. Am I supported and given the time needed to make improvements as I go or am I constantly rushing to make a deadline?
So much. When I’m trusted to find the right balance of productivity and quality, I enjoy the work more. When I enjoy the work, I’m more productive and write better code. It’s a positive feedback loop.
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: !programming@programming.dev
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person’s post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
Follow the programming.dev instance rules
Keep content related to programming in some way
If you’re posting long videos try to add in some form of tldr for those who don’t want to watch videos
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.
It can be rewarding. For me, this has a lot to do with team culture. Am I supported and given the time needed to make improvements as I go or am I constantly rushing to make a deadline?
So much. When I’m trusted to find the right balance of productivity and quality, I enjoy the work more. When I enjoy the work, I’m more productive and write better code. It’s a positive feedback loop.