17 ms·

I've started using Friday as a "personal development" day at work. I do not write any code on Friday (unless it's a severe production level issue). Instead, I

I've started using Friday as a "personal development" day at work. I do not write any code on Friday (unless it's a severe production level issue). Instead, I spend the mornings reviewing PRs that I wasn't included on (to keep up with whats happening, but also to learn more about how other people write and review code) and the afternoons are spent reading/researching/online classes. This has really helped me avoid burn out. I go into the weekend less exhausted and more motivated to return on Monday and implement new stuff. It has also helped generate some inspiration for weekend/personal projects.

swiley 7y ago
This is a brilliant idea! Hopefully it becomes popular.
paracyst 7y ago
This sounds like a good idea that I would really like to try, for my own sanity if for nothing else. For me, the issue—imagined or not—would arise in the Friday morning daily stand-up. I’m not sure it would go over well if I said that I intend to spend part of the day doing PRs (this is fine and expected) and the other part learning/researching (likely not). Oh the joys of the JIRA sweatshop. We have JIRA pulled up on the big screen TV and the product guys cycle through the status of each dev team members’ items during each daily standup. This is my first development job, surely it’s not like this everywhere?
- vorpalhex 7y ago
  It's not like that everywhere > product guys cycle through the status of each dev team members’ items during each daily standup Something has gone horrible off the rails. Standup is supposed to be a quick time for every team member to raise any blockers primarily, with a quick "here's what I did, here's what I'm doing" type blurb. The benefit of standup is identifying blockers and if engineers are getting mired in problems (so you can fix those issues outside of standup).
  - organsnyder 7y ago
    Agreed. PMs (product or project) should rarely speak during standups; instead, they should be listening for blockers and other action items for them. I've worked in environments where the PMs micromanage like this. It's both hellish and extremely inefficient.
    - puPoh 7y ago
      It's almost like... gasp management always used agile to implement micromanagement all along.
      - alfiedotwtf 7y ago
        I logged in just to make this same comment but you beat me to it. Agile is micromanagement in disguise, and we fell for it hook, line, and sinker.
        Aeolun 7y ago
        To be fair, we were already micromanaged. Then Agile was posited as a solution, so of course we were enthusiastic. Unfortunately the only thing that appeared to change was the name. So we’re not really any worse off than before.
        sailfast 7y ago
        Are you sure you haven’t just always been micromanaged and this is another way for that to happen? All things can be abused for bad purposes. I haven’t heard too many examples of “oh man we used to be free and ship great features on time but now that we have a backlog and talk to each other every day it’s a hellscape death march”
        alfiedotwtf 7y ago
        I've done my stint in "large enterprise". It's a whole new world there where management believe that if projects aren't on track, then the solution is more meetings, more agile training and in-house "coaches", and even more micromanaging. I'm no longer in that world, and I'll never go back.
- protonimitate 7y ago
  The way we handle this is by padding our sprints enough so that there's always "extra time" at the end. E.g: If we as engs think we can do 12 tickets in a one-week sprint, we commit to 8. This leaves room to pick up any production issue related work, address tech debt, and have some breathing room so we're not rushing through jira tickets. It's also workplace specific, but imo product people shouldn't be engaging in daily standups other than passive observation. If they are drilling through the jira board and asking for status updates, they're taking on the role of a micro-manager, not a product owner/manager. Standups should be engineers talking to eachother and raising blockers/issues that would prevent them from meeting the sprint goal they committed to, not daily check ins with product (again, imo).
  - r00fus 7y ago
    How does this fly in an organization where your promotion is based on sprints and not sustainable coding/quality?
    - anon9001 7y ago
      If you want to contribute to the value of the organization because you're a substantial equity holder, then talk to the founders. A sweatshop with high turnover should be less valuable to an acquirer than a strong team. Your initiative may be well received as leadership and you can get your promotion that way. If you want to stay in the organization and get promoted by performance metrics, then figure out what numbers are being evaluated and work to maximize them, so that you appear as the model worker. It's not very hard to stay one step ahead of management if that's the game you're playing. If you have the best relationships and the best metrics, you should be able to get your promotions. If you want to stay in the organization and coast, then who cares, just do what you want and they're almost certainly not going to fire you without plenty of warning. If you do get put on a PIP, then go find a new job immediately, and repeat. From what I can tell, most of the workforce does something similar to this for 30-40 years. If you're not a leader, not a model worker, and not on autopilot, then you probably need to find a new organization where you can be one of those things.
- ddek 7y ago
  Yep, that's a way away from ideal. You're unlucky, there are a lot of software teams out there where the developers are pretty much autonomous. That's not to say they do absolutely whatever they want, but micromanagement is usually out of the question. A couple of months ago I spent about half my working hours in a week watching everything that happened at .Net Conf. I didn't ask anyone, I just said I was taking training time and since I don't take much no-one cared. If I was in your position, I'd take this as a sign that there are better places to work. Wait out your current job until it's adding value to your CV (few good projects and contributions you can talk about), then move out. You'll get more money, and you'll probably have a better idea of what to look for.
  - vagab0nd 7y ago
    Any idea what to look for when searching for such a job? I have asked about micromanagement in interviews before but I usually just get bullshit answers.
    - username90 7y ago
      I'm not sure about other places but the teams I've worked on and worked with at Google works like this.
    - jSully24 7y ago
      Brainstorming a bit on this. Curious for other ideas: Start with asking questions about how work is assigned/doled out. Where does all of their work come from, the Agile board? Someone stopping by and asking "can you do x" or "can you help Jill with Y". Follow that up by digging into how they then talk to others about their progress on that work. Ask if they're interrupted or allowed to progress independently? How often does someone ask them "Is that done yet?" Ask about how often they're asked about the status of the same piece of work by different people. Dig into how they keep everyone else apprised of what they're doing. Ask them about their relationship with their Scrum Master, Project Manager, Product Owner, Dev Manager, etc. Ask what they could change about it if they could. That line of questions may uncover the micromanagement pattern. Even if it doesn't, it will go a long ways in helping you get a feel for how a team works.
- itronitron 7y ago
  You may want to describe part of your work on a task as reviewing solutions (for a given PR) and then after the standup spend some time learning about related tech to whatever PRs you have assigned. If the product guys are any good they will care about having 'options' and will therefore welcome devs that are taking a broader look of the solution space.
- sidlls 7y ago
  It isn’t like that everywhere but it’s quite common, especially in companies where development is not the primary focus of the company. You’re more likely to end up in that kind of company than not unless you are in a place like the Bay Area or similar tech hub.
  - MrFoof 7y ago
    Replying purely for reinforcement of the parent. This is not just common, but the norm in most organizations. I think the only time in the past 12 years (working with probably 20 organizations) where this didn't occur is the one engagement when I was charged managing the team. There's far too many places where a team of even just four or five developers will spend 30 minutes (sometimes an hour!) every morning in "standup" being grilled on every single item committed to in the sprint.
    - celticmusic 7y ago
      I recently had my first experience with "agile" and "scrum", and this was my experience. I left after being there for 6 months for unrelated reasons, but one of things that made it an easy decision was the daily fucking standup. I convinced the team to do without the standup and just put the status updates in slack for a week. At the end I was the only one who thought it was better. To quote one developer "I don't read it when its in slack". That indicates to me that the information isn't necessary to do your goddamned job. I dislike agile now as a result of that experience.
- noelsusman 7y ago
  Where I work standups are for devs only. The product guys are involved in planning and reveals, but otherwise they stay out of our hair. We're expected to complete what we've committed to on time or promptly notify the product guys if that's not going to happen for whatever reason. About once a week (usually Friday) I tell my team I'm going to spend the day researching or exploring some new idea that doesn't have any stories yet. It's never a problem. A decent chunk of our big leaps forward for our projects have come from us working on random stuff nobody told us to work on.
  - Viliam1234 7y ago
    By the way, this is the official SCRUM way. Product people should be there for planning and for demo. If at the end of the sprint they got what they wanted to get, they should be happy and do their own work... or relax if they have nothing else to do. Micromanaging means you have nothing useful to do, and you are needlessly making other people angry. Such people should be fired first. (Yeah, I know, they are often the last ones to stay, because people who have better options leave first.)
- lonelappde 7y ago
  Stand up for what you believe in. Tell them you are spending the day on research. Better yet, cancel that standup because it's garbage. Only one representative needs to go to the product meeting.
- matz1 7y ago
  Well, you don't have to mentioned that you are doing your own research... Do they look over your shoulder every minute?
- Aeolun 7y ago
  It is like this in two out of 4 places that I’ve worked. Those two were both large corporations. It is my theory that it happens as soon as you have a separate scrum/project manager for the project you work on.
vorpalhex 7y ago
The company I'm at sets aside every other Friday for all engineers to learn, contribute to open source, hack on an idea they may have (that may or may not be related to work), etc. So far the only problems I've seen is that sometimes it's hard to convince engineers to actually use the time instead of still working on tickets.
- elpakal 7y ago
  very cool. does your company maintain the IP ownership to anything made during these periods?
  - tempestn 7y ago
    I would expect so. Doesn't it seem a bit much to expect the company to give you paid time to work on your own personal side projects? They don't own the knowledge and skills you gain doing it though.
docmars 7y ago
I love this, and that a major value in it is feeling refreshed. I think I'm going to try this a bit, time-permitted, and ask for forgiveness later if there's ever an issue. I'm constantly finding gaps in my knowledge that my smarter team members would certainly benefit from me being more on the same page on if I spent more time developing my skills.
spike021 7y ago
My team when I first joined had something like this; we called it a 'spike' day. Basically a full day of time where we could learn about something new, maybe hack on a non-necessary feature or even personal project for a few hours a week. But sadly over the past few years we've kind of just done away with it. We don't allot time for it specifically anymore. We think about it from time to time and wish we still had the bandwidth for it. But it just doesn't happen anymore. It's a tough thing to build into a team's structure, I think, and in such a way that it's sustainable.
- lonelappde 7y ago
  Go in tomorrow and tell everyone it's time to start doing spike again.
totalperspectiv 7y ago
'Great Thoughts Friday' from Richard Hamming https://youtu.be/a1zDuOPkMSw https://youtu.be/a1zDuOPkMSw
- teddyh 7y ago
  Slightly better video and sound (from the same source material): https://www.youtube.com/watch?v=e3msMuwqp-o&list=PLctkxgWNSR89bl7hTOS3F3wuoGj7id3Xy&index=32#t=22s https://www.youtube.com/watch?v=e3msMuwqp-o&list=PLctkxgWNSR...
ravenstine 7y ago
This is pretty much what I do at the company I work for. We also spend part of that time having roundtable discussions on different topics.
numbsafari 7y ago
This is what I encourage my staff to do. We have a company-wide bagel breakfast in the morning, and then no more meetings. We also skip our daily “async slack stand-up” on Fridays. My expectation for the day is that you prioritize personal development, long-term planning, or just “deck clearing” if you’ve had a long week or desire something less mentally demanding for the day. Obviously, thing happen that can interfere with the ideal, but it’s pretty rare and, when it happens, I make it a point to figure out if there’s a way to avoid it going forward. What we don’t do, is “no deploy Fridays”. We deploy all the time, and maybe somebody wants to do some minor bug or light UI cleanup. I’m certainly not going to stop them. Requiring an “off-day” for deployments is a major red flag for me.
- graphenus 7y ago
  Except when the Friday deployment breaks production and one of your employees needs to fix the issue on Saturday instead of relaxing with their family.
  - spongeb00b 7y ago
    You seem to be getting down voted but this is important. Unless the company is paying staff to be available and on call over the weekend people have lives to be getting on with and wouldn’t be able to respond to an issue as quickly than during the week.
  - xmprt 7y ago
    I understand this isn't a perfect world and problems happen but we also shouldn't live in constant fear that a deployment will break production. There should be processes in place that prevent broken code from even getting to the point where it's merged into master. The biggest extreme that I've faced was a team where there was a 36 hour window between Wednesday and Thursday where deployments to production were allowed and it was a nightmare getting any code out especially with most deployments involving 10-20 new commits so if something did break we had to rollback a lot and rack our heads to figure out what went wrong.
  - numbsafari 7y ago
PlasticTank 7y ago
I run a small consultancy and Development Friday's are almost mandatory for my developers. Everyone is given Friday afternoon to learn new skills or improve existing ones, I even tell my clients that this happens (we charge by the week) and in the last 4 years I've only had one complaint and we quickly cancelled the contract with them after.

swiley 7y ago

This is a brilliant idea! Hopefully it becomes popular.

paracyst 7y ago

This sounds like a good idea that I would really like to try, for my own sanity if for nothing else. For me, the issue—imagined or not—would arise in the Friday morning daily stand-up. I’m not sure it would go over well if I said that I intend to spend part of the day doing PRs (this is fine and expected) and the other part learning/researching (likely not). Oh the joys of the JIRA sweatshop. We have JIRA pulled up on the big screen TV and the product guys cycle through the status of each dev team members’ items during each daily standup. This is my first development job, surely it’s not like this everywhere?

vorpalhex 7y ago
It's not like that everywhere > product guys cycle through the status of each dev team members’ items during each daily standup Something has gone horrible off the rails. Standup is supposed to be a quick time for every team member to raise any blockers primarily, with a quick "here's what I did, here's what I'm doing" type blurb. The benefit of standup is identifying blockers and if engineers are getting mired in problems (so you can fix those issues outside of standup).
- organsnyder 7y ago
  Agreed. PMs (product or project) should rarely speak during standups; instead, they should be listening for blockers and other action items for them. I've worked in environments where the PMs micromanage like this. It's both hellish and extremely inefficient.
  - puPoh 7y ago
    It's almost like... gasp management always used agile to implement micromanagement all along.
    - alfiedotwtf 7y ago
      I logged in just to make this same comment but you beat me to it. Agile is micromanagement in disguise, and we fell for it hook, line, and sinker.
      - Aeolun 7y ago
        To be fair, we were already micromanaged. Then Agile was posited as a solution, so of course we were enthusiastic. Unfortunately the only thing that appeared to change was the name. So we’re not really any worse off than before.
      - sailfast 7y ago
        Are you sure you haven’t just always been micromanaged and this is another way for that to happen? All things can be abused for bad purposes. I haven’t heard too many examples of “oh man we used to be free and ship great features on time but now that we have a backlog and talk to each other every day it’s a hellscape death march”
        alfiedotwtf 7y ago
        I've done my stint in "large enterprise". It's a whole new world there where management believe that if projects aren't on track, then the solution is more meetings, more agile training and in-house "coaches", and even more micromanaging. I'm no longer in that world, and I'll never go back.
protonimitate 7y ago
The way we handle this is by padding our sprints enough so that there's always "extra time" at the end. E.g: If we as engs think we can do 12 tickets in a one-week sprint, we commit to 8. This leaves room to pick up any production issue related work, address tech debt, and have some breathing room so we're not rushing through jira tickets. It's also workplace specific, but imo product people shouldn't be engaging in daily standups other than passive observation. If they are drilling through the jira board and asking for status updates, they're taking on the role of a micro-manager, not a product owner/manager. Standups should be engineers talking to eachother and raising blockers/issues that would prevent them from meeting the sprint goal they committed to, not daily check ins with product (again, imo).
- r00fus 7y ago
  How does this fly in an organization where your promotion is based on sprints and not sustainable coding/quality?
  - anon9001 7y ago
    If you want to contribute to the value of the organization because you're a substantial equity holder, then talk to the founders. A sweatshop with high turnover should be less valuable to an acquirer than a strong team. Your initiative may be well received as leadership and you can get your promotion that way. If you want to stay in the organization and get promoted by performance metrics, then figure out what numbers are being evaluated and work to maximize them, so that you appear as the model worker. It's not very hard to stay one step ahead of management if that's the game you're playing. If you have the best relationships and the best metrics, you should be able to get your promotions. If you want to stay in the organization and coast, then who cares, just do what you want and they're almost certainly not going to fire you without plenty of warning. If you do get put on a PIP, then go find a new job immediately, and repeat. From what I can tell, most of the workforce does something similar to this for 30-40 years. If you're not a leader, not a model worker, and not on autopilot, then you probably need to find a new organization where you can be one of those things.
ddek 7y ago
Yep, that's a way away from ideal. You're unlucky, there are a lot of software teams out there where the developers are pretty much autonomous. That's not to say they do absolutely whatever they want, but micromanagement is usually out of the question. A couple of months ago I spent about half my working hours in a week watching everything that happened at .Net Conf. I didn't ask anyone, I just said I was taking training time and since I don't take much no-one cared. If I was in your position, I'd take this as a sign that there are better places to work. Wait out your current job until it's adding value to your CV (few good projects and contributions you can talk about), then move out. You'll get more money, and you'll probably have a better idea of what to look for.
- vagab0nd 7y ago
  Any idea what to look for when searching for such a job? I have asked about micromanagement in interviews before but I usually just get bullshit answers.
  - username90 7y ago
    I'm not sure about other places but the teams I've worked on and worked with at Google works like this.
  - jSully24 7y ago
    Brainstorming a bit on this. Curious for other ideas: Start with asking questions about how work is assigned/doled out. Where does all of their work come from, the Agile board? Someone stopping by and asking "can you do x" or "can you help Jill with Y". Follow that up by digging into how they then talk to others about their progress on that work. Ask if they're interrupted or allowed to progress independently? How often does someone ask them "Is that done yet?" Ask about how often they're asked about the status of the same piece of work by different people. Dig into how they keep everyone else apprised of what they're doing. Ask them about their relationship with their Scrum Master, Project Manager, Product Owner, Dev Manager, etc. Ask what they could change about it if they could. That line of questions may uncover the micromanagement pattern. Even if it doesn't, it will go a long ways in helping you get a feel for how a team works.
itronitron 7y ago
You may want to describe part of your work on a task as reviewing solutions (for a given PR) and then after the standup spend some time learning about related tech to whatever PRs you have assigned. If the product guys are any good they will care about having 'options' and will therefore welcome devs that are taking a broader look of the solution space.
sidlls 7y ago
It isn’t like that everywhere but it’s quite common, especially in companies where development is not the primary focus of the company. You’re more likely to end up in that kind of company than not unless you are in a place like the Bay Area or similar tech hub.
- MrFoof 7y ago
  Replying purely for reinforcement of the parent. This is not just common, but the norm in most organizations. I think the only time in the past 12 years (working with probably 20 organizations) where this didn't occur is the one engagement when I was charged managing the team. There's far too many places where a team of even just four or five developers will spend 30 minutes (sometimes an hour!) every morning in "standup" being grilled on every single item committed to in the sprint.
  - celticmusic 7y ago
    I recently had my first experience with "agile" and "scrum", and this was my experience. I left after being there for 6 months for unrelated reasons, but one of things that made it an easy decision was the daily fucking standup. I convinced the team to do without the standup and just put the status updates in slack for a week. At the end I was the only one who thought it was better. To quote one developer "I don't read it when its in slack". That indicates to me that the information isn't necessary to do your goddamned job. I dislike agile now as a result of that experience.
noelsusman 7y ago
Where I work standups are for devs only. The product guys are involved in planning and reveals, but otherwise they stay out of our hair. We're expected to complete what we've committed to on time or promptly notify the product guys if that's not going to happen for whatever reason. About once a week (usually Friday) I tell my team I'm going to spend the day researching or exploring some new idea that doesn't have any stories yet. It's never a problem. A decent chunk of our big leaps forward for our projects have come from us working on random stuff nobody told us to work on.
- Viliam1234 7y ago
  By the way, this is the official SCRUM way. Product people should be there for planning and for demo. If at the end of the sprint they got what they wanted to get, they should be happy and do their own work... or relax if they have nothing else to do. Micromanaging means you have nothing useful to do, and you are needlessly making other people angry. Such people should be fired first. (Yeah, I know, they are often the last ones to stay, because people who have better options leave first.)
lonelappde 7y ago
Stand up for what you believe in. Tell them you are spending the day on research. Better yet, cancel that standup because it's garbage. Only one representative needs to go to the product meeting.
matz1 7y ago
Well, you don't have to mentioned that you are doing your own research... Do they look over your shoulder every minute?
Aeolun 7y ago
It is like this in two out of 4 places that I’ve worked. Those two were both large corporations. It is my theory that it happens as soon as you have a separate scrum/project manager for the project you work on.

vorpalhex 7y ago

The company I'm at sets aside every other Friday for all engineers to learn, contribute to open source, hack on an idea they may have (that may or may not be related to work), etc. So far the only problems I've seen is that sometimes it's hard to convince engineers to actually use the time instead of still working on tickets.

elpakal 7y ago
very cool. does your company maintain the IP ownership to anything made during these periods?
- tempestn 7y ago
  I would expect so. Doesn't it seem a bit much to expect the company to give you paid time to work on your own personal side projects? They don't own the knowledge and skills you gain doing it though.

docmars 7y ago

I love this, and that a major value in it is feeling refreshed. I think I'm going to try this a bit, time-permitted, and ask for forgiveness later if there's ever an issue. I'm constantly finding gaps in my knowledge that my smarter team members would certainly benefit from me being more on the same page on if I spent more time developing my skills.

spike021 7y ago

My team when I first joined had something like this; we called it a 'spike' day. Basically a full day of time where we could learn about something new, maybe hack on a non-necessary feature or even personal project for a few hours a week. But sadly over the past few years we've kind of just done away with it. We don't allot time for it specifically anymore. We think about it from time to time and wish we still had the bandwidth for it. But it just doesn't happen anymore. It's a tough thing to build into a team's structure, I think, and in such a way that it's sustainable.

lonelappde 7y ago
Go in tomorrow and tell everyone it's time to start doing spike again.

totalperspectiv 7y ago

'Great Thoughts Friday' from Richard Hamming https://youtu.be/a1zDuOPkMSw https://youtu.be/a1zDuOPkMSw

teddyh 7y ago
Slightly better video and sound (from the same source material): https://www.youtube.com/watch?v=e3msMuwqp-o&list=PLctkxgWNSR89bl7hTOS3F3wuoGj7id3Xy&index=32#t=22s https://www.youtube.com/watch?v=e3msMuwqp-o&list=PLctkxgWNSR...

ravenstine 7y ago

This is pretty much what I do at the company I work for. We also spend part of that time having roundtable discussions on different topics.

numbsafari 7y ago

This is what I encourage my staff to do. We have a company-wide bagel breakfast in the morning, and then no more meetings. We also skip our daily “async slack stand-up” on Fridays. My expectation for the day is that you prioritize personal development, long-term planning, or just “deck clearing” if you’ve had a long week or desire something less mentally demanding for the day. Obviously, thing happen that can interfere with the ideal, but it’s pretty rare and, when it happens, I make it a point to figure out if there’s a way to avoid it going forward. What we don’t do, is “no deploy Fridays”. We deploy all the time, and maybe somebody wants to do some minor bug or light UI cleanup. I’m certainly not going to stop them. Requiring an “off-day” for deployments is a major red flag for me.

graphenus 7y ago
Except when the Friday deployment breaks production and one of your employees needs to fix the issue on Saturday instead of relaxing with their family.
- spongeb00b 7y ago
  You seem to be getting down voted but this is important. Unless the company is paying staff to be available and on call over the weekend people have lives to be getting on with and wouldn’t be able to respond to an issue as quickly than during the week.
- xmprt 7y ago
  I understand this isn't a perfect world and problems happen but we also shouldn't live in constant fear that a deployment will break production. There should be processes in place that prevent broken code from even getting to the point where it's merged into master. The biggest extreme that I've faced was a team where there was a 36 hour window between Wednesday and Thursday where deployments to production were allowed and it was a nightmare getting any code out especially with most deployments involving 10-20 new commits so if something did break we had to rollback a lot and rack our heads to figure out what went wrong.
- numbsafari 7y ago

PlasticTank 7y ago

I run a small consultancy and Development Friday's are almost mandatory for my developers. Everyone is given Friday afternoon to learn new skills or improve existing ones, I even tell my clients that this happens (we charge by the week) and in the last 4 years I've only had one complaint and we quickly cancelled the contract with them after.