11 ms·

> For example, I once joined a team maintaining a system that was drowning in bugs. There were something like two thousand open bug reports. Nothing was tagged,

> For example, I once joined a team maintaining a system that was drowning in bugs. There were something like two thousand open bug reports. Nothing was tagged, categorized, or prioritized. The team couldn’t agree on which issues to tackle > I spent almost three weeks in that room, and emerged with every bug report reviewed, tagged, categorized, and prioritized. Honestly, this is one of those traps a team can fall into, where nobody feels empowered to ignore the rest of the business for 3 weeks to put the bell on the cat. The only person without deliverables and due dates is the new hire. And it takes a special kind of new hire to have the expertise to parachute in, recognize that work needs to be done, and then do it with little supervision. But he's right in general, that you can get some surprising things done by just putting in the time and focus. Which is why it's so utterly toxic that corporate America runs on an interrupt driven system, with meetings sprinkled carelessly across engineer calendars.

pbourke 6y ago
> Which is why it's so utterly toxic that corporate America runs on an interrupt driven system, with meetings sprinkled carelessly across engineer calendars. I agree with this statement and your other points. I’ve noticed a more insidious variant of this behavior: the expectation of interruptions. Some groups have such frequent priority shifts and/or a culture of fire fighting or door knocking such that even with a relatively open schedule, one is dissuaded from engaging in longer stretches of work for fear of having it all go to waste when the next meteor strike arrives.
- dnautics 6y ago
  I agree but I wouldn't call it toxic, rather "foolish".
- milesvp 6y ago
  I've experienced this professionally. It's super debilitating. At some point, the only thing that you are willing to spend energy on is preventing the last fire you're exhausted from just fighting from happening again. I don't know what I'd have done if I didn't have good support from my manager at the time. He cleared a lot of expectations of other deliverables out of the way, so I could stabilize the infrastructure. Now, I know enough to work the politics to give myself room to do this work, but junior me couldn't have done it alone without cracking.
- jokethrowaway 6y ago
  I think you can blame "agile thinking" for that and the general laziness in product planning which is so typical of the last 10 years. We went from recognising that requirements may change after planning to zero planning and telling developers what's the next priority for the day, day by day. This lack of planning and product definition is also what drives the lack of documentation, which is another big problem in 2021. I don't expect going back to waterfall but also not what's going on nowadays. Hopefully we'll bounce back in the middle at some point.
  - heterodoxxed 6y ago
    I don't understand why software architect isn't a position in any of the new startup culture tech businesses. The advantage of having an older, very wise and very experienced engineer whose job it is to document, plan and understand all the moving parts of your project would have been invaluable instead of expecting all the engineers who are stressed about hitting deadlines and chasing down memory leaks to do that work on top of their daily requirements.
    - titanomachy 6y ago
      The people who do this job at large companies are called Staff or Principal engineers. One reason startups might be less likely to have them is that they are extraordinarily expensive.
      - charrondev 6y ago
        And you can’t cheap out on the role. It’s also really hard to recognize the right kind of person for this without a somewhat Mature engineering team. The wrong person in this type of role at a smaller company can things back significantly.
        titanomachy 6y ago
        Yeah I saw that early in my career at a small company. Smart and charismatic guy in an architect role, impressed technical and non-technical people alike with his knowledge. Now that I have more experience I realize he was more excited about cargo-culting big tech practices than about making sure our software was well-architected. We wasted so much time enthusiastically implementing his low-impact but technically exciting ideas.
- nullsense 6y ago
  "meteor strike" what a brilliant way to put it. Been struck by a few of those in my time.
hyperpape 6y ago
Interruptions are definitely harmful, but if you look at what he did, he could have done it in spite of meetings. What would be bad would be starting it and being told (implicitly or explicitly) not to finish it. Better to have meetings than to have what you’re doing cancelled several weeks in.
habitue 6y ago
One of the most important things I think Kanban[1] emphasizes is that once you eliminate unnecessary bottlenecks, you're left with unavoidable bottlenecks, and this naturally means there will be slack. Explicitly expecting slack time is super useful to allow developers at all levels of seniority to do surprising and necessary things like this that would otherwise never be scheduled. [1] not the project board shape, but the original process it's named after where you set a hard cap on work in progress in each stage to find out where bottlenecks are.
- emodendroket 6y ago
  I think the reason people don't like Kanban is there are a bunch of tasks that suck to get stuff over the line and without the "deadline" there's little incentive to help with them instead of just pulling something else off the backlog.
  - habitue 6y ago
    Take this with a grain of salt, because I haven't done Kanban personally, but I think the theory is that if you hard cap work in progress, and everyone is sitting around on their hands, it puts a lot of pressure to eliminate bottlenecks to progress.
aspaceman 6y ago
> And it takes a special kind of new hire to have the expertise to parachute in, recognize that work needs to be done, and then do it with little supervision. About 6 months into a job I realized this was what I needed to do and totally cracked. Didn’t know the questions to ask or the way to learn what I needed to so I burnt out quick and quit. My fault for sure, but there was a ton of pressure to identify issues and fix them because senior people were “just too busy”.
- cgriswald 6y ago
  I had the opposite problem. I took to it like a duck to water and then was told to stop because I had “better things to do.” When I asked what they suggested things I had already done. I become so bored it really affected my work ethic. I didn’t like that and eventually quit.
rufius 6y ago
Honestly, I’d have approached it differently. Close everything older than 2 weeks. If it’s important/relevant, it will crop back up. If it’s not, then it stays unfixed. This can be really uncomfortable to do. But it’s how I’ve rescued a couple of teams that I’ve led as either an EM or Tech Lead. Put another way - if everything is important or “must fix”, nothing is. So to the author: that seemed like a waste of time. I would not have done it because I’m not convinced the outcome would have been meaningfully different from my tactic.
- fossuser 6y ago
  The author's tactic gives them a good sense of the project, common requests, and bugs over a long time period. This context is really valuable when reasoning about the product or determining what's important to prioritize. The issue with the "declare bankruptcy and important stuff will come back" is that you don't actually solve the underlying ruthless prioritization issue and very quickly end up in the exact same position. You also irritate people that spent time writing up product issues for potentially important bugs by auto closing them (so many important things may not come back), but the bigger loss is that going through all of them gives you solid product historical context. For what it's worth, the best PMs I know go through the backlog and understand what they're killing when they approach a project that's currently fucked. I think it has a positive side effect of giving them a lot of credibility too (as well as helping them ramp up).
  - EmptyMoon 6y ago
    I have to agree. There is nothing more demotivating for me than documenting a bug thoroughly, only to have it returned to me two months later as part of a bulk 'we didn't get to this in time' cleanup. Issues for those teams usually 'best effort' isolation going forward, which compounds the issue.
    - pixl97 6y ago
      A bug left alone long enough grows from an child bug to an adult bug. You're still caring, feeding, and maintaining that bug the entire time.
sdenton4 6y ago
Just had a meeting with some students looking to outsource some dataset validation work. I had them time themselves for a couple hours doing it themselves, and we found that seeing aside am hour a day for a couple weeks will get them through everything... And they'll end up with higher quality data than they'll get from outsourced validation, with a better idea of the pitfalls of the dataset.
- disgruntledphd2 6y ago
  Those students are in the wrong career. You can't make good things from data without (metaphorically) getting your hands dirty.
  - dan-robertson 6y ago
    Or maybe they have just learned something—these are students, not seasoned professionals.
    - disgruntledphd2 6y ago
      Yeah definitely. To be fair, I was kinda harsh, but it's incredibly frustrating to see people ignore core parts of the DS workflow because it doesn't map neatly to cool technologies. Especially when that part is the base for pretty much everything you'll do with data.
morty_s 6y ago
> it takes a special kind of new hire Yeah, it does. I’ve had a good amount of experience doing this. You need to have tact and a kind of humbleness that can be difficult to maintain (tbh, it was for me at least). In my most recent experience with this, many of the bugs were unknown. During my ramp up, I read through nearly all of the code I’d be working on and got a good sense of what needed to be done, but the code changes were the easy part. The issue that required more work IMO was navigating the social waters as a new hire. I found that you can use being a new hire to your advantage, eg “hey I was reading through this piece of code and I had a question about XYZ.” Sometimes I’ve felt certain bugs are, for one reason or another, difficult to discuss. One thing I’ve done in cases like this is to refactor a bit of code in a way that makes a subtle bug painfully obvious; then in review, where the reviewers were the original author and reviewer, it’s easier for them to see the bug and say “this looks weird,” to which I respond “ah, yeah, this seems like a bug, I’ll fix this.” The rough part of this is that you can get so good at being the fixer that this becomes all you (ie. maybe you’re not working on new features, etc) which can suck. The bright side is that you can strengthen the team—-everyone gets a chance to build/rebuild context and mental models, design docs can be updated, and the teams foundation gets stronger as a result. Of course, ymmv. As a new hire, I find it important to build trust and relationships.
- joshuamorton 6y ago
  The best advice I was given (when I was a new hire, by my manager) was something along the lines of "You're smart, and you aren't burdened by tradition or seniority. If you see something that looks weird or confusing, ask about it! No one will hold it against you, and your point of view may keep us from committing to something more complex than it needs to be." I've tried to keep that level of intentional naïveté.
  - ErrantX 6y ago
    intentional naivete is such a great way to put it, definitely going to use that going forward :)
- cbushko 6y ago
  This resonates with me so much as I was in this position 3 years ago. My boss came to me and said "we want to move from AWS to GCP, using kubernetes and not have it be a mess like we have now" I was new, senior, free from ownership. I chose to stay as a team of 1 so that I wasn't burdened with fires and meetings. It freed me up to put my head down and get the work done. The grind was learning GCP, kubernetes, terraform, the platform/product, gathering requirements from several teams and mentoring people that would pop into the project as their time allowed. I won't lie as learning new things was great. The project was partially greenfield as it was a platform migration and not a product rewrite. There were a lot of constraints & debt to deal with. Maybe the new employee churn is one of the reasons that most startups get so much done... the new people are not burdened by ownership and being the subject matter experts. They are free to do things, good or bad. :)
djmetzle 6y ago
Truth! Deep work and focus is difficult, expensive with continuous meetings and notifications. So the OP is extra right! Cutting through the noise looks like magic now.
emodendroket 6y ago
If the meeting is on a calendar ahead of time it's not really an interruption.
- nullsense 6y ago
  Certainly feels like one when I know the context switch is coming and it's scheduled in such a mid morning or mid afternoon slot that the time either side of it isn't long enough to do deep work, particularly when the rest of the team will interrupt me ad hoc to get unblocked on their work. If there were no meeting I can deal with their interruptions and context switch back to my work and get a long enough stretch to concentrate. With frequent meetings in certain timeslots I get virtually nothing done some weeks. It likely affects some people more than others depending on the demands placed on you. Think I'm going request meetings never fall mid morning or mid afternoon.
  - emodendroket 6y ago
    Personally my least favorite time for a meeting is one that interrupts my usual lunch. They should put you on trial at the Hague for scheduling a meeting from 11:00-1:00.
    - nullsense 6y ago
      Yeah I don't want lunch interrupted either. But from 11:00 to 12:00. Or preferably 11:30 to 12:00. Or even 4pm to 5pm.
- Aeolun 6y ago
  I don’t know how you work, but my schedule of meeting, work, meeting, work definitely feels like the meetings are interruptions. Especially since they don’t add any value, but that’s arguably a different problem.
- dragonwriter 6y ago
  > If the meeting is on a calendar ahead of time it's not really an interruption. Knowing about it doesn’t make it interrupt flow any less, unless you just avoid the kind of work that would require flow around it, which still imposes the same kind of productivity impact on intellectual “making” workers. [0] [0] related: http://www.paulgraham.com/makersschedule.html http://www.paulgraham.com/makersschedule.html
outime 6y ago
>Which is why it's so utterly toxic that corporate America runs on an interrupt driven system, with meetings sprinkled carelessly across engineer calendars. As a person who’s worked in both american and european big companies... I can tell it’s not an american illness only and I have heard the same from asian friends. Best I got was one or two meeting-free days (at least on paper, in reality these would be ignored as well). I just got used to these things.
zebraflask 6y ago
I can both see the value in that approach and, having run across things like this situation before, I can also see an unaddressed question in this post (already brought up by the replies, but worth repeating): how is that scenario not a fundamental failure of management, or some kind of dysfunctional organizational dynamic, to not prevent that kind of thing from happening in the first place? Bug reports aren't exactly sui generis, they don't just mysteriously appear.
Daynil 6y ago
I feel like by far the biggest impediment to my productivity is the knowledge that I have a meeting any time in the next two hours. Unfortunately, that's usually the case.
SkyPuncher 6y ago
I tend to be verbose in tracking bugs, but poor in tagging, categorizing, and prioritizing them. Ultimately, I've found the important bugs prioritize themselves no matter how sloppy your system is. The rest of the bugs are simply there to (1) provide context, reference (2) serve as fallback if product work tends to lag.
lolthishuman 6y ago
Imagine how the kernel and operating system feels...
- vmladenov 6y ago
  I just recently walked past a hotel advertisement display that had blue-screened, so not well
mikepurvis 6y ago
I did an internal transfer and took over from a team that I think had been in this state for some time— it was really the ideal scenario because in many ways I wasn't having to ramp on everything the way a true new hire would, but I still had the clean slate and clean calendar to immediately get a bunch of stale systems upgraded, processes cleaned up, start into writing some documentation, research new tools to deploy, etc. Very invigorating and a lot of progress possible in a short period of time.
Animats 6y ago
I did that when I first came to Silicon Valley. I went to work for a company which operated a large, for its day, mainframe data center. (Not IBM, UNIVAC). Each time the operating system crashed, which it did several times a day, a "panic dump" was produced, a stack of paper about an inch thick, with a summary and stack backtrace at the top, and a full listing of the contents of memory. There were two stacks of these, six feet high, waiting for me. It took me most of a year to work through the pile, finding out why the crash had occurred, by tracking pointers through memory with pencil and colored marker and comparing this with paper listings of the operating system. Then I'd code a fix for that problem, test it (usually around 2 AM when I could take over a mainframe), and nervously put it into production on one mainframe. Slowly, the piles of crash dumps got shorter and the mean time to failure went from hours to weeks. There were very few meetings, and nobody interfered. They were just happy to see the crash dump pile shrink and the uptime increase. After a few years of this, by which time the systems would stay up for months, I got a job in R&D at another company and got out of maintenance programming and into theory.
- peterb 6y ago
  Respect!
- jebeng 6y ago
  Neat. For some reason I find it satisfying to read an example like that where there's actual real tangible work being done with immediate and obvious benefits.
  - lulzury 6y ago
    The weird thing about tackling these seemingly Goliath type problems is that at the start it requires a lot of patience to get going and can be demotivating to see no progress or trickle-slow progress, but once you visibly see that the gears are starting to crank, it is very rewarding.
wombatmobile 6y ago
Mark Ruffalo dramatised the lawyer who did exactly this in Dark Waters to foil DuPont. Thanks to this grind, we know what DuPont did to pristine West Virginia waterways with Teflon toxic waste. https://youtube.com/watch?v=yBGi3SzxkKk https://youtube.com/watch?v=yBGi3SzxkKk
deleted 6y ago
[deleted]

pbourke 6y ago

> Which is why it's so utterly toxic that corporate America runs on an interrupt driven system, with meetings sprinkled carelessly across engineer calendars. I agree with this statement and your other points. I’ve noticed a more insidious variant of this behavior: the expectation of interruptions. Some groups have such frequent priority shifts and/or a culture of fire fighting or door knocking such that even with a relatively open schedule, one is dissuaded from engaging in longer stretches of work for fear of having it all go to waste when the next meteor strike arrives.

dnautics 6y ago
I agree but I wouldn't call it toxic, rather "foolish".
milesvp 6y ago
I've experienced this professionally. It's super debilitating. At some point, the only thing that you are willing to spend energy on is preventing the last fire you're exhausted from just fighting from happening again. I don't know what I'd have done if I didn't have good support from my manager at the time. He cleared a lot of expectations of other deliverables out of the way, so I could stabilize the infrastructure. Now, I know enough to work the politics to give myself room to do this work, but junior me couldn't have done it alone without cracking.
jokethrowaway 6y ago
I think you can blame "agile thinking" for that and the general laziness in product planning which is so typical of the last 10 years. We went from recognising that requirements may change after planning to zero planning and telling developers what's the next priority for the day, day by day. This lack of planning and product definition is also what drives the lack of documentation, which is another big problem in 2021. I don't expect going back to waterfall but also not what's going on nowadays. Hopefully we'll bounce back in the middle at some point.
- heterodoxxed 6y ago
  I don't understand why software architect isn't a position in any of the new startup culture tech businesses. The advantage of having an older, very wise and very experienced engineer whose job it is to document, plan and understand all the moving parts of your project would have been invaluable instead of expecting all the engineers who are stressed about hitting deadlines and chasing down memory leaks to do that work on top of their daily requirements.
  - titanomachy 6y ago
    The people who do this job at large companies are called Staff or Principal engineers. One reason startups might be less likely to have them is that they are extraordinarily expensive.
    - charrondev 6y ago
      And you can’t cheap out on the role. It’s also really hard to recognize the right kind of person for this without a somewhat Mature engineering team. The wrong person in this type of role at a smaller company can things back significantly.
      - titanomachy 6y ago
        Yeah I saw that early in my career at a small company. Smart and charismatic guy in an architect role, impressed technical and non-technical people alike with his knowledge. Now that I have more experience I realize he was more excited about cargo-culting big tech practices than about making sure our software was well-architected. We wasted so much time enthusiastically implementing his low-impact but technically exciting ideas.
nullsense 6y ago
"meteor strike" what a brilliant way to put it. Been struck by a few of those in my time.

hyperpape 6y ago

Interruptions are definitely harmful, but if you look at what he did, he could have done it in spite of meetings. What would be bad would be starting it and being told (implicitly or explicitly) not to finish it. Better to have meetings than to have what you’re doing cancelled several weeks in.

habitue 6y ago

One of the most important things I think Kanban[1] emphasizes is that once you eliminate unnecessary bottlenecks, you're left with unavoidable bottlenecks, and this naturally means there will be slack. Explicitly expecting slack time is super useful to allow developers at all levels of seniority to do surprising and necessary things like this that would otherwise never be scheduled. [1] not the project board shape, but the original process it's named after where you set a hard cap on work in progress in each stage to find out where bottlenecks are.

emodendroket 6y ago
I think the reason people don't like Kanban is there are a bunch of tasks that suck to get stuff over the line and without the "deadline" there's little incentive to help with them instead of just pulling something else off the backlog.
- habitue 6y ago
  Take this with a grain of salt, because I haven't done Kanban personally, but I think the theory is that if you hard cap work in progress, and everyone is sitting around on their hands, it puts a lot of pressure to eliminate bottlenecks to progress.

aspaceman 6y ago

> And it takes a special kind of new hire to have the expertise to parachute in, recognize that work needs to be done, and then do it with little supervision. About 6 months into a job I realized this was what I needed to do and totally cracked. Didn’t know the questions to ask or the way to learn what I needed to so I burnt out quick and quit. My fault for sure, but there was a ton of pressure to identify issues and fix them because senior people were “just too busy”.

cgriswald 6y ago
I had the opposite problem. I took to it like a duck to water and then was told to stop because I had “better things to do.” When I asked what they suggested things I had already done. I become so bored it really affected my work ethic. I didn’t like that and eventually quit.

rufius 6y ago

Honestly, I’d have approached it differently. Close everything older than 2 weeks. If it’s important/relevant, it will crop back up. If it’s not, then it stays unfixed. This can be really uncomfortable to do. But it’s how I’ve rescued a couple of teams that I’ve led as either an EM or Tech Lead. Put another way - if everything is important or “must fix”, nothing is. So to the author: that seemed like a waste of time. I would not have done it because I’m not convinced the outcome would have been meaningfully different from my tactic.

fossuser 6y ago
The author's tactic gives them a good sense of the project, common requests, and bugs over a long time period. This context is really valuable when reasoning about the product or determining what's important to prioritize. The issue with the "declare bankruptcy and important stuff will come back" is that you don't actually solve the underlying ruthless prioritization issue and very quickly end up in the exact same position. You also irritate people that spent time writing up product issues for potentially important bugs by auto closing them (so many important things may not come back), but the bigger loss is that going through all of them gives you solid product historical context. For what it's worth, the best PMs I know go through the backlog and understand what they're killing when they approach a project that's currently fucked. I think it has a positive side effect of giving them a lot of credibility too (as well as helping them ramp up).
- EmptyMoon 6y ago
  I have to agree. There is nothing more demotivating for me than documenting a bug thoroughly, only to have it returned to me two months later as part of a bulk 'we didn't get to this in time' cleanup. Issues for those teams usually 'best effort' isolation going forward, which compounds the issue.
  - pixl97 6y ago
    A bug left alone long enough grows from an child bug to an adult bug. You're still caring, feeding, and maintaining that bug the entire time.

sdenton4 6y ago

Just had a meeting with some students looking to outsource some dataset validation work. I had them time themselves for a couple hours doing it themselves, and we found that seeing aside am hour a day for a couple weeks will get them through everything... And they'll end up with higher quality data than they'll get from outsourced validation, with a better idea of the pitfalls of the dataset.

disgruntledphd2 6y ago
Those students are in the wrong career. You can't make good things from data without (metaphorically) getting your hands dirty.
- dan-robertson 6y ago
  Or maybe they have just learned something—these are students, not seasoned professionals.
  - disgruntledphd2 6y ago
    Yeah definitely. To be fair, I was kinda harsh, but it's incredibly frustrating to see people ignore core parts of the DS workflow because it doesn't map neatly to cool technologies. Especially when that part is the base for pretty much everything you'll do with data.

morty_s 6y ago

> it takes a special kind of new hire Yeah, it does. I’ve had a good amount of experience doing this. You need to have tact and a kind of humbleness that can be difficult to maintain (tbh, it was for me at least). In my most recent experience with this, many of the bugs were unknown. During my ramp up, I read through nearly all of the code I’d be working on and got a good sense of what needed to be done, but the code changes were the easy part. The issue that required more work IMO was navigating the social waters as a new hire. I found that you can use being a new hire to your advantage, eg “hey I was reading through this piece of code and I had a question about XYZ.” Sometimes I’ve felt certain bugs are, for one reason or another, difficult to discuss. One thing I’ve done in cases like this is to refactor a bit of code in a way that makes a subtle bug painfully obvious; then in review, where the reviewers were the original author and reviewer, it’s easier for them to see the bug and say “this looks weird,” to which I respond “ah, yeah, this seems like a bug, I’ll fix this.” The rough part of this is that you can get so good at being the fixer that this becomes all you (ie. maybe you’re not working on new features, etc) which can suck. The bright side is that you can strengthen the team—-everyone gets a chance to build/rebuild context and mental models, design docs can be updated, and the teams foundation gets stronger as a result. Of course, ymmv. As a new hire, I find it important to build trust and relationships.

joshuamorton 6y ago
The best advice I was given (when I was a new hire, by my manager) was something along the lines of "You're smart, and you aren't burdened by tradition or seniority. If you see something that looks weird or confusing, ask about it! No one will hold it against you, and your point of view may keep us from committing to something more complex than it needs to be." I've tried to keep that level of intentional naïveté.
- ErrantX 6y ago
  intentional naivete is such a great way to put it, definitely going to use that going forward :)
cbushko 6y ago
This resonates with me so much as I was in this position 3 years ago. My boss came to me and said "we want to move from AWS to GCP, using kubernetes and not have it be a mess like we have now" I was new, senior, free from ownership. I chose to stay as a team of 1 so that I wasn't burdened with fires and meetings. It freed me up to put my head down and get the work done. The grind was learning GCP, kubernetes, terraform, the platform/product, gathering requirements from several teams and mentoring people that would pop into the project as their time allowed. I won't lie as learning new things was great. The project was partially greenfield as it was a platform migration and not a product rewrite. There were a lot of constraints & debt to deal with. Maybe the new employee churn is one of the reasons that most startups get so much done... the new people are not burdened by ownership and being the subject matter experts. They are free to do things, good or bad. :)

djmetzle 6y ago

Truth! Deep work and focus is difficult, expensive with continuous meetings and notifications. So the OP is extra right! Cutting through the noise looks like magic now.

emodendroket 6y ago

If the meeting is on a calendar ahead of time it's not really an interruption.

nullsense 6y ago
Certainly feels like one when I know the context switch is coming and it's scheduled in such a mid morning or mid afternoon slot that the time either side of it isn't long enough to do deep work, particularly when the rest of the team will interrupt me ad hoc to get unblocked on their work. If there were no meeting I can deal with their interruptions and context switch back to my work and get a long enough stretch to concentrate. With frequent meetings in certain timeslots I get virtually nothing done some weeks. It likely affects some people more than others depending on the demands placed on you. Think I'm going request meetings never fall mid morning or mid afternoon.
- emodendroket 6y ago
  Personally my least favorite time for a meeting is one that interrupts my usual lunch. They should put you on trial at the Hague for scheduling a meeting from 11:00-1:00.
  - nullsense 6y ago
    Yeah I don't want lunch interrupted either. But from 11:00 to 12:00. Or preferably 11:30 to 12:00. Or even 4pm to 5pm.
Aeolun 6y ago
I don’t know how you work, but my schedule of meeting, work, meeting, work definitely feels like the meetings are interruptions. Especially since they don’t add any value, but that’s arguably a different problem.
dragonwriter 6y ago
> If the meeting is on a calendar ahead of time it's not really an interruption. Knowing about it doesn’t make it interrupt flow any less, unless you just avoid the kind of work that would require flow around it, which still imposes the same kind of productivity impact on intellectual “making” workers. [0] [0] related: http://www.paulgraham.com/makersschedule.html http://www.paulgraham.com/makersschedule.html

outime 6y ago

>Which is why it's so utterly toxic that corporate America runs on an interrupt driven system, with meetings sprinkled carelessly across engineer calendars. As a person who’s worked in both american and european big companies... I can tell it’s not an american illness only and I have heard the same from asian friends. Best I got was one or two meeting-free days (at least on paper, in reality these would be ignored as well). I just got used to these things.

zebraflask 6y ago

I can both see the value in that approach and, having run across things like this situation before, I can also see an unaddressed question in this post (already brought up by the replies, but worth repeating): how is that scenario not a fundamental failure of management, or some kind of dysfunctional organizational dynamic, to not prevent that kind of thing from happening in the first place? Bug reports aren't exactly sui generis, they don't just mysteriously appear.

Daynil 6y ago

I feel like by far the biggest impediment to my productivity is the knowledge that I have a meeting any time in the next two hours. Unfortunately, that's usually the case.

SkyPuncher 6y ago

I tend to be verbose in tracking bugs, but poor in tagging, categorizing, and prioritizing them. Ultimately, I've found the important bugs prioritize themselves no matter how sloppy your system is. The rest of the bugs are simply there to (1) provide context, reference (2) serve as fallback if product work tends to lag.

lolthishuman 6y ago

Imagine how the kernel and operating system feels...

vmladenov 6y ago
I just recently walked past a hotel advertisement display that had blue-screened, so not well

mikepurvis 6y ago

I did an internal transfer and took over from a team that I think had been in this state for some time— it was really the ideal scenario because in many ways I wasn't having to ramp on everything the way a true new hire would, but I still had the clean slate and clean calendar to immediately get a bunch of stale systems upgraded, processes cleaned up, start into writing some documentation, research new tools to deploy, etc. Very invigorating and a lot of progress possible in a short period of time.

Animats 6y ago

I did that when I first came to Silicon Valley. I went to work for a company which operated a large, for its day, mainframe data center. (Not IBM, UNIVAC). Each time the operating system crashed, which it did several times a day, a "panic dump" was produced, a stack of paper about an inch thick, with a summary and stack backtrace at the top, and a full listing of the contents of memory. There were two stacks of these, six feet high, waiting for me. It took me most of a year to work through the pile, finding out why the crash had occurred, by tracking pointers through memory with pencil and colored marker and comparing this with paper listings of the operating system. Then I'd code a fix for that problem, test it (usually around 2 AM when I could take over a mainframe), and nervously put it into production on one mainframe. Slowly, the piles of crash dumps got shorter and the mean time to failure went from hours to weeks. There were very few meetings, and nobody interfered. They were just happy to see the crash dump pile shrink and the uptime increase. After a few years of this, by which time the systems would stay up for months, I got a job in R&D at another company and got out of maintenance programming and into theory.

peterb 6y ago
Respect!
jebeng 6y ago
Neat. For some reason I find it satisfying to read an example like that where there's actual real tangible work being done with immediate and obvious benefits.
- lulzury 6y ago
  The weird thing about tackling these seemingly Goliath type problems is that at the start it requires a lot of patience to get going and can be demotivating to see no progress or trickle-slow progress, but once you visibly see that the gears are starting to crank, it is very rewarding.

wombatmobile 6y ago

Mark Ruffalo dramatised the lawyer who did exactly this in Dark Waters to foil DuPont. Thanks to this grind, we know what DuPont did to pristine West Virginia waterways with Teflon toxic waste. https://youtube.com/watch?v=yBGi3SzxkKk https://youtube.com/watch?v=yBGi3SzxkKk

deleted 6y ago

[deleted]