3 ms·

> AbstractBeanFactoryFactories I absolutely get what you mean and it sucks. I too love learning (and arguing, which doesn't help you that much on the job...)

> AbstractBeanFactoryFactories I absolutely get what you mean and it sucks. I too love learning (and arguing, which doesn't help you that much on the job...) I think these practices grow themselves out, but it takes quite some time. On the other hand, I can be defensive too if people just want to rewrite software to change the implementation language. It always sounds fun at first until you grasp the complexity of the project again. > Tickets, JIRA, daily standups, scrum masters, sprint planning, backlog grooming sessions. Why does nobody question any of this "best practice"? In my experience these are use to give people outside of software (and some developers) an illusion of control. If you can identify that want and can supply it with different means, you may be allowed to just skip it. I hate scrum, I like coffee breaks with colleagues. Of course that might not scale for the largest companies, don't know. > I know some of you may say I should go get checked out for depression On the contrary, depression stifles compassion for the craft. Like JIRA and daily standups or other formalities. As I said, if you can reduce the fears of management, they tend to give you the freedom you want. If other devs don't like that, go to management and make them your minions.

overitthrowaway 5y ago
Appreciate the comment. > On the other hand, I can be defensive too if people just want to rewrite software to change the implementation language. It always sounds fun at first until you grasp the complexity of the project again. Yep, I'd agree with you here, fun new things for fun new things sake is usually a mistake. The cases I'm talking about though are where a slightly less commonly used pattern could actually drastically simplify the problem, but the other party is so set in their own mindset and way of doing things that they're unwilling to do it differently. > In my experience these are use to give people outside of software (and some developers) an illusion of control. Yes, perhaps that's it. The challenge is that in the last few jobs I've been in, the team themselves have also been in favor of these processes. The teams I've worked with seem to love just picking off tickets, having someone chop up work, and sitting in backlog grooming etc.
thehappypm 5y ago
I'm a PM. I spend a lot of time managing the standup, sprint planning, etc. We have to do that stuff because otherwise the engineers wouldn't do things that the business needs. What engineers are interested in, passionate in -- don't often translate into what the business needs. So we have to do these processes to make it happen. I'm sorry that we do this to you.
- gfe8ygighjb7 5y ago
  Software development was fine without daily roll call. I honestly find it funny that grown adults have to tell their bosses what they did yesterday and what they will do today.
  - thehappypm 5y ago
    It’s sometimes important to have a little oversight to make sure people are working on the right things. Junior engineer spending 3 days on the same tiny bug? Maybe they need some help. Senior engineer clearly over-optimizing a system? Time for a new meaty project.
  - croo 5y ago
    The questions give a frame to the meeting but usually the important part is what is finished, who waits on what and who stuck on something. I know a few senior dev whom if I would lead daily standups would be unnecessary but that is called a dream team. Reality is littered with juniors, subpar programmers and devs only interested in tech not in business.

overitthrowaway 5y ago

Appreciate the comment. > On the other hand, I can be defensive too if people just want to rewrite software to change the implementation language. It always sounds fun at first until you grasp the complexity of the project again. Yep, I'd agree with you here, fun new things for fun new things sake is usually a mistake. The cases I'm talking about though are where a slightly less commonly used pattern could actually drastically simplify the problem, but the other party is so set in their own mindset and way of doing things that they're unwilling to do it differently. > In my experience these are use to give people outside of software (and some developers) an illusion of control. Yes, perhaps that's it. The challenge is that in the last few jobs I've been in, the team themselves have also been in favor of these processes. The teams I've worked with seem to love just picking off tickets, having someone chop up work, and sitting in backlog grooming etc.

thehappypm 5y ago

I'm a PM. I spend a lot of time managing the standup, sprint planning, etc. We have to do that stuff because otherwise the engineers wouldn't do things that the business needs. What engineers are interested in, passionate in -- don't often translate into what the business needs. So we have to do these processes to make it happen. I'm sorry that we do this to you.

gfe8ygighjb7 5y ago
Software development was fine without daily roll call. I honestly find it funny that grown adults have to tell their bosses what they did yesterday and what they will do today.
- thehappypm 5y ago
  It’s sometimes important to have a little oversight to make sure people are working on the right things. Junior engineer spending 3 days on the same tiny bug? Maybe they need some help. Senior engineer clearly over-optimizing a system? Time for a new meaty project.
- croo 5y ago
  The questions give a frame to the meeting but usually the important part is what is finished, who waits on what and who stuck on something. I know a few senior dev whom if I would lead daily standups would be unnecessary but that is called a dream team. Reality is littered with juniors, subpar programmers and devs only interested in tech not in business.