4 ms·

The problem I have now is; How can I get the manager to read, understand, and respect Maker Schedule? Should I send them this link and then try to explain to t

by jbob2000 9y ago

The problem I have now is; How can I get the manager to read, understand, and respect Maker Schedule? Should I send them this link and then try to explain to them who Paul Graham is and why they should care about him? Should I send them the wikipedia article about Flow[1]? Should I show them the clip from The Social Network about "being in the zone"? [1] https://en.wikipedia.org/wiki/Flow_(psychology) https://en.wikipedia.org/wiki/Flow_(psychology)

codingdave 9y ago
Maybe you should treat both schedules as equally valuable, while acknowledging the different purposes they serve, and respectfully discuss the problem with your manager to collaborate on a solution together. It could be as simple as "Please don't schedule meeting mid-day." When I was a 50% manager / 50% dev, I blocked off 10-2 forever on my calendar for my coding. Whatever you end up with, talk, don't send links -- sending links to articles comes off about as well as sending your fellow devs to LMGTFY.
- brazzledazzle 9y ago
  They’ll agree because it’s reasonable and makes sense but the real test will be if they ask if they can book over that big maker block, just this once. And this once. And this project is really important so just this once. It’s like technical debt. No manager is going to disagree that it’s important. But the test is if they ever make time for it or drop the story for something else.
rumpope 9y ago
Yes, all these things do help and you can also speak their language - they understand having multiple "back to back" meetings, so you if you schedule meetings with yourself, that you can't miss, and open up your schedule for other times, then you can allow them to book you then.
- jermaustin1 9y ago
  This is exactly what I learned after years of developing around meetings. Block your time first. And block your time based on your tasks you have to complete. Sure you can't completely rewrite the billing system from scratch in an hour, but you CAN stub out the new architecture. Then each hour after that you fill in a method. I feel needing 4-9 hour blocks of time means you AREN'T focusing, not that you are "IN THE ZONE"
  - maxxxxx 9y ago
    I can't do anything with some complexity in one hour increments. I need days (or weeks) to immerse myself into the issue to develop a mental model. In my view working in short increments leads to very superficial work.
    - deleted 9y ago
      [deleted]
    - annywhey 9y ago
      I think I know what parent is getting at. I am increasingly able to bypass the "load problem into brain" stage by reducing the problem scope to a subset. When the problem seems potentially quite large, like "greenfield a new system", I look for "seven plus/minus two coherent concepts": while I can't know the whole scope until development begins, I can pick a set of concepts that I can commit to memory(hence, about 7) and search for an optimization of which concepts I'm using that makes each one cohere better with the others, contingent on whatever belief is driving the need for a software solution. This process typically only takes a few hours at most and usually illuminates something really unexpected about the problem space. Selecting for coherence is effective at reducing problem scope since it cuts through unquestioned practices: in a more coherent solution all the answers feed into each other. In my previous methods I would just sit and stare at the problem and sit and stare at techniques until a match of technique to problem came to mind. That's why it took so long - there wasn't a philosophy there, so my thinking could drift in an undirected way for long periods and even get deep into writing code without doing anything effective.
reggieband 9y ago
I find this comic is helpful: https://heeris.id.au/2013/this-is-why-you-shouldnt-interrupt-a-programmer/ https://heeris.id.au/2013/this-is-why-you-shouldnt-interrupt...
- andyidsinga 9y ago
  I'm sending this to my wife!
- codemac 9y ago
  Taking notes in a digital lab notebook (i.e. text file) while I'm thinking has sped up the re-inflation period significantly from ~1/2 hour to ~1-5 minutes. I can highly recommend it for folks in very noisy/distracting environments. It also points out how much you struggle to stay focused if you are not continually writing in your notebook.
- wool_gather 9y ago
  Unfortunately I'm not sure that explains it in any way that a non-maker would get. It's basically missing the last panel, where the dev writes a _new_ bug that costs millions of dollars because of the distraction.

codingdave 9y ago

Maybe you should treat both schedules as equally valuable, while acknowledging the different purposes they serve, and respectfully discuss the problem with your manager to collaborate on a solution together. It could be as simple as "Please don't schedule meeting mid-day." When I was a 50% manager / 50% dev, I blocked off 10-2 forever on my calendar for my coding. Whatever you end up with, talk, don't send links -- sending links to articles comes off about as well as sending your fellow devs to LMGTFY.

brazzledazzle 9y ago
They’ll agree because it’s reasonable and makes sense but the real test will be if they ask if they can book over that big maker block, just this once. And this once. And this project is really important so just this once. It’s like technical debt. No manager is going to disagree that it’s important. But the test is if they ever make time for it or drop the story for something else.

rumpope 9y ago

Yes, all these things do help and you can also speak their language - they understand having multiple "back to back" meetings, so you if you schedule meetings with yourself, that you can't miss, and open up your schedule for other times, then you can allow them to book you then.

jermaustin1 9y ago
This is exactly what I learned after years of developing around meetings. Block your time first. And block your time based on your tasks you have to complete. Sure you can't completely rewrite the billing system from scratch in an hour, but you CAN stub out the new architecture. Then each hour after that you fill in a method. I feel needing 4-9 hour blocks of time means you AREN'T focusing, not that you are "IN THE ZONE"
- maxxxxx 9y ago
  I can't do anything with some complexity in one hour increments. I need days (or weeks) to immerse myself into the issue to develop a mental model. In my view working in short increments leads to very superficial work.
  - deleted 9y ago
    [deleted]
  - annywhey 9y ago
    I think I know what parent is getting at. I am increasingly able to bypass the "load problem into brain" stage by reducing the problem scope to a subset. When the problem seems potentially quite large, like "greenfield a new system", I look for "seven plus/minus two coherent concepts": while I can't know the whole scope until development begins, I can pick a set of concepts that I can commit to memory(hence, about 7) and search for an optimization of which concepts I'm using that makes each one cohere better with the others, contingent on whatever belief is driving the need for a software solution. This process typically only takes a few hours at most and usually illuminates something really unexpected about the problem space. Selecting for coherence is effective at reducing problem scope since it cuts through unquestioned practices: in a more coherent solution all the answers feed into each other. In my previous methods I would just sit and stare at the problem and sit and stare at techniques until a match of technique to problem came to mind. That's why it took so long - there wasn't a philosophy there, so my thinking could drift in an undirected way for long periods and even get deep into writing code without doing anything effective.

reggieband 9y ago

I find this comic is helpful: https://heeris.id.au/2013/this-is-why-you-shouldnt-interrupt-a-programmer/ https://heeris.id.au/2013/this-is-why-you-shouldnt-interrupt...

andyidsinga 9y ago
I'm sending this to my wife!
codemac 9y ago
Taking notes in a digital lab notebook (i.e. text file) while I'm thinking has sped up the re-inflation period significantly from ~1/2 hour to ~1-5 minutes. I can highly recommend it for folks in very noisy/distracting environments. It also points out how much you struggle to stay focused if you are not continually writing in your notebook.
wool_gather 9y ago
Unfortunately I'm not sure that explains it in any way that a non-maker would get. It's basically missing the last panel, where the dev writes a _new_ bug that costs millions of dollars because of the distraction.