3 ms·

True. The one thing that corporations are extremely good at is destroying all the initiative and add so much bureaucracy to the development that you loose inte

by stiray 6y ago

True. The one thing that corporations are extremely good at is destroying all the initiative and add so much bureaucracy to the development that you loose interest to improve / inovate as you are paifully aware that this will bring in more documents, jira tickets, endless "bicycle shed" discussions, endless covincing of managers that only care about their schedule (which you will corupt by "unknowns"), endless politics as there is always some architect/team lead that "must be the smartest" (and typically those comming to those positions are excelent in navigating buereaucracy and politics and are rarly inovators as those endanger manager schedules, adding risks, ...) and so on. Too many cooks spoil the broth. At the end you just figure out it is not worth it , do what you are paid for and you inovate at home. If those inovations become a startup you just leave.

dwd 6y ago
I used to infuriate one development manager by going on a streak of productivity where I'd generate a mass of code over a matter of days, and then go quiet while I was thinking, trialing and tinkering with the next project - this was in a role where I had some latitude to do that. I'm not sure if other's thought I was slacking off at those times and complained, or it just messed with him because his burn-down charts would always look like a cliff face.
- qes 6y ago
  I struggle with the same pattern and worries myself, though mostly internally. My position affords a lot of latitude for it (I replaced the previous lead dev 10 years ago when the company was 5 people). It seems to be (and is said to be) okay with others as long as I communicate even as little as, "I'm deep in the weeds on this and probably will be for the next 2-3 weeks." I worry about the optics of it, but at least have confidence that other developers can see the end result is solid for the total amount of time invested. Smooth workflow for everyone is the other major concern, but again we're lucky to be working on our own system and not beholden to external deadlines.. and I guess lucky to have enough want-to-dos in the backlog that no one is ever without something useful to work on. We do create a bit of expectation of every developer having at least some tasks each week that are picked up and some that are completed, and it's tempting to just game that a bit to put up some numbers on the weeks where I'm figuring out how to do what I'm about to do.
  - dwd 6y ago
    When it comes to smoothing out a burn-down chart, the trick is the break up the tasks in a way that allows for each to be completed in full according to how you work on them. It may go against the logical or functional division of the project but it helps you mark stuff as done. For JIRA in particular, also avoid creating sub-tasks if you're burn-down is tracking at the task level - as you have to complete all subs for the main task to be complete.

by stiray 6y ago

dwd 6y ago

I used to infuriate one development manager by going on a streak of productivity where I'd generate a mass of code over a matter of days, and then go quiet while I was thinking, trialing and tinkering with the next project - this was in a role where I had some latitude to do that. I'm not sure if other's thought I was slacking off at those times and complained, or it just messed with him because his burn-down charts would always look like a cliff face.

qes 6y ago
I struggle with the same pattern and worries myself, though mostly internally. My position affords a lot of latitude for it (I replaced the previous lead dev 10 years ago when the company was 5 people). It seems to be (and is said to be) okay with others as long as I communicate even as little as, "I'm deep in the weeds on this and probably will be for the next 2-3 weeks." I worry about the optics of it, but at least have confidence that other developers can see the end result is solid for the total amount of time invested. Smooth workflow for everyone is the other major concern, but again we're lucky to be working on our own system and not beholden to external deadlines.. and I guess lucky to have enough want-to-dos in the backlog that no one is ever without something useful to work on. We do create a bit of expectation of every developer having at least some tasks each week that are picked up and some that are completed, and it's tempting to just game that a bit to put up some numbers on the weeks where I'm figuring out how to do what I'm about to do.
- dwd 6y ago
  When it comes to smoothing out a burn-down chart, the trick is the break up the tasks in a way that allows for each to be completed in full according to how you work on them. It may go against the logical or functional division of the project but it helps you mark stuff as done. For JIRA in particular, also avoid creating sub-tasks if you're burn-down is tracking at the task level - as you have to complete all subs for the main task to be complete.