6 ms·

Developer productivity: The art of saying no

189 points by cj 12y ago

bbody 12y ago
Very interesting article, something every manager who manages developers should read. However I think a lot of developers (Particularly startup ones) have multiple roles, so interruptions and changing flow is a part of the job. How do you suggest to get around that? My only solution would be to split your day up into chunks for the different roles, minimizing context switching.
- bluedino 12y ago
  >> However I think a lot of developers (Particularly startup ones) have multiple roles, so interruptions and changing flow is a part of the job. That's how my last job was. Tasks varied as followed: * Work on upcoming project X (release date in the future) * Feature request on project Y (need done somewhat soon for a client on an already operating project) * Bugfix needs done NOW on existing project Z * Ops issue with servers, database, etc
tschellenbach 12y ago
Love it, great read
dpcan 12y ago
Their key points here were: -Inbox Pause -Thursday Meetings -and Do 1 Thing a Day. I personally use: -Archive Everything -Never have meetings... ever. -and Prioritize My email is like Chat unfortunately, so much back and forth on projects I really can't afford to only chime in once a day or nothing would ever get done. But everything gets archived unless I'm working on it actively, or I still need to reply. Meetings... I never meet in person now. The time suck is just horrible awful miserable. I will occasionally have a phone meeting, but they aren't much better, but at least I don't have to take time to shave and drive. 1 thing a day would be nice unless your world consists of 200 little tiny things. So, I prioritize and block out hours to get things done. Then I DO apply 1-thing-a-day to my side-projects so they stay fresh. To each their own.
- karinnielsen 12y ago
  Not having meetings or conf calls might work for you but I would be very surprised if it works for your customers and/or peers (assuming you have any). If there is one thing I have learned it's that the quality of communication in a team usually makes or breaks the project. The quality of communication with a customer makes or breaks the relationship. It's important to remember that humans have been communicating for thousands of years without email, chat servers or telephones. Our brains are hard-wired to respond to facial expression, tone of voice and body language. All of this is lost with computer-mediated communication channels. Your post prompted me to look at this study which you may also find interesting: http://www.academia.edu/538403/Face-to-face_Versus_Computer-mediated_Communication_Exploring_Employees_Preference_of_Effective_Employee_Communication_Channel http://www.academia.edu/538403/Face-to-face_Versus_Computer-... Don't get me wrong, meetings for the sake of meetings are a waste of time but that's not to say that they do not have their place.
  - 1123581321 12y ago
    I find maker-vs-manager a bit brittle as well. A company I'm very familiar with has people going into and out of immersive "modes" that involve creative work as well as communication about that work. So, someone might spend all week in "ABC mode" and have 4-8 meetings about ABC as well as shipping a few features or solutions. Others might advance a few large features and be interrupted by 2-3 meetings, but because they are connected, the immersion is not broken.
ryandrake 12y ago
A strategy of communication avoidance might work if you're a one-person company with no managers and no customers, but in the real world, it's necessary to periodically come out of our hidey-holes and talk to people. The need to communicate regularly grows as the project's size and complexity grows, as deadlines approach, as requirements change. The idea of the Lone Wolf Developer sitting uninterrupted in his office 24/7, building the software in a vacuum, gloriously emerging after three months, on time, with software that perfectly conforms to the requirements, that miraculously works exactly according to the customer's needs, is a myth--incompatible with the reality of professional software development.
- nerdy 12y ago
  Unfortunately so.
- BurningFrog 12y ago
  Having meetings every Thursday is exactly "periodically come out of our hidey-holes and talk to people".
  - cssmoo 12y ago
    I operate a "if you can't be bothered to structure your thoughts in a well-written email, you can bugger off" process. Meetings Thursday is a no go area for me. This works well once everyone understands it. Unfortunately for it to work, you tend to have to serve as an internal consultant to a company, write good replies and maintain a lot of documentation and technical standards.
bshimmin 12y ago
This post is almost comically ridiculous if you try and apply any of it outside of the context of (I imagine) a small team that doesn't really do anything externally. How do I tell my clients that I only do meetings on Thursdays? If they happen to be unavailable one Thursday, do they have to wait a fortnight before I deign to speak to them again? Is this guy seriously suggesting that the way to stop being overwhelmed by inbox zero is by using Slack? And honestly, doing one thing a day - really? How in the world does that work? Sure, doing one thing well is better than doing nothing or half-doing a bunch of things, but surely your goal should be actually doing a reasonable amount of things that reflect a solid day's work - and figuring out a strategy for reliably making that happen. Perhaps I'm just a grouch today, but it feels like this post is either satire or written from a completely different universe, utterly unrelated to the one I inhabit and work in.
- mathgeek 12y ago
  Not just you. I feel like this post just regurgitates a bunch of other "every few days" posts. Doesn't really add much to the conversation. That's not to say that it shouldn't be written, as getting your thoughts out there is always a good exercise. It being on the front page of HN is of questionable use, though. Might be of some utility to anyone who has never read HN before.
  - spotridge 12y ago
    I've just canned a very similar post to yours. Is there any explanation as to why this should be on the front page? This seems rather like Reddit - posts there often seem to rise up while most of the comment section is fairly negative.
    - mathgeek 12y ago
      Well there are people voting it up, which I can understand as the concepts are always popular. Not sure on the algorithm that's used.
    - striking 12y ago
corysama 12y ago
Anyone here who has not read "The Power of a Positive No" really should get to it. It's about how to say No constantly without being an ass. It's practically tailored around devs negotiating with customers. I the whole world read Ury's "Getting to Yes" trilogy, the whole world would be a much nicer place to be.
unoti 12y ago
This reminds me of a type of professional that I see far too often. The professional who specializes in not doing their job. It happens with programmers, as well as many other specialties. You've probably seen them: - Software developers who as soon as you tell them what you need, they tell you why it's impossible. - Network administrators who apparently specialize in making machines not talk to each other, because things worked better before their first day - DBA's whose first priority is keeping you from accessing the data - Engineers who think it's their job to make things more difficult Saying NO to all the things is better than getting nothing done, sure. But having the skill to say yes to the things that are needed is better.
- mistermann 12y ago
  I agree, this is extremely common, and it completely baffles me....you are in charge of a resource, would it not be in your best interest if more people use that resource rather than less? For whatever reason, I find DBA's to commonly have this type of attitude, as well as having extremely unimaginative minds (Why would you want to do that?)
- Bahamut 12y ago
  It's all about what you say no to. For example, if it is something that will cause a lot of technical debt, as a developer, I push back until I get a concession where I have the opportunity to undo the damage afterwards. Otherwise the debt will increase stress, lower developer happiness, and potentially prevent the business from growing in the long term as developer retention becomes more difficult the longer it lasts. If you're going to ask for something unreasonable from someone with domain expertise, expect to make a concession if you want it done since that person has a high likelihood of understanding the true costs of the request. It is all too common to see developers experience burnout from 60+ hour weeks in order to attempt to meet a deadline because managers were awful at planning. I often take a more neutral stance through explaining that it would take [X] amount of time to build solid & tested pieces of functionality as designed, and then let the product managers assess the information to come to a decision to either scale back or if it is still pushed for, then push back for a concession. It doesn't have to be a Yes or No proposition, it is like bartering - you want to get to a mutual agreement so all parties are satisfied.
YorkianTones 12y ago
I like the idea of holding personal email and then bulk delivering to my inbox at specific times during the day. However, the tool recommended by the linked post, "Inbox Pause", seems to just use a toggle button and doesn't have a scheduling mechanism. Anyone know of a tool that does? Maybe the folks over at SaneBox should add this.
- mkopinsky 12y ago
  How about Ctrl-W to just close the Gmail tab?
  - jonathanpeterwu 12y ago
    That's actually a great point.
droopyEyelids 12y ago
We all make fun of "One weird trick to lose belly fat" but how many articles have you read about pomodoroing, closed offices, meeting refusal, and the like? The market is ripe for The Secret to Developer Productivity, a product that talks about all the common strategies in a happy but "we all know they don't work" style, while promising to let you in to the True Secret after you break out the credit card.
- tbrake 12y ago
  > We all make fun of "One weird trick to lose belly fat" but how many articles have you read about pomodoroing, closed offices, meeting refusal, and the like? I've been reading them for years. I'm sure there are vets who have been reading them for longer. I'm also sure a good portion of management - at all levels - have read it, or heard about it, or attended a conference etc. So then why does it persist? I'm sure it's not down to just one reason. There are three that instantly spring to mind - One slightly cynical one could be that management simply views the eroded productivity as an acceptable cost of getting things their way in regards to meetings, agendas, stopping by to bother you and so on. Another, more self-critical one, is that we as developers just aren't assertive enough in demanding change in the workplace. Maybe we do need unions. I don't know. A third is that for every one company that "gets it" there are hundreds (if not more) of companies that don't. Most of them not even in your field/industry, but if you want them as clients then external pressure to conform to their way overrides the ability to operate how we want. I'm sure there's lots of other good reasons it happens and probably plenty of bad ones. I haven't _completely_ given up hope things could change throughout the industry but it's not something I'd cling to.
S4M 12y ago
Am I the only person who hates daily morning stand ups here? Not everybody on the team arrives at the same time, so if you arrive early it will become aninterruption in your workflow. Sometimes I can't do what I planned to do and most of the time I don't care about what others are plamning to do. Also in my previous companies members of my team had the tendency to talk a lot in the daily standup, making it last sometimes 20 minutes.
- samspot 12y ago
  It's not my favorite thing, but I do believe it removes the need for a lot of other meetings. I also find that I am almost never 'statused' on this team, which is a huge improvement. Talking too much is a discipline thing that you have to push against hard & often. Some people get it really easily, while others take a lot of coaching before they learn to give the right amount of information.
- mavdi 12y ago
  20 minutes? We have a technical architect who alone babbles nonsense for half hour in each standup. Some people confuse stand ups with their counselling sessions.
  - S4M 12y ago
    Dude, I am sorry to hear that.
  - dakotaben 12y ago
    Then whoever is running the stand up.... sucks. This is not a stand up.
fein 12y ago
The pendulum always swings to one extreme; it never seems to find a resting place in the middle. Productivity is all about balance, which is a word that never appears in this article. A blog providing polarizing advice won't be any sort of silver bullet, as the definition of "productive" will, quite often, change completely. One day it may be fielding calls, having meetings, and talking to clients. Another day it may mean sitting in a dark room for ten hours with a coffeemaker, a laptop, and yourself, just banging out bugfixes and feature requests. This is the kind of concept that should be felt out on a project by project / week by week basis, not with a rigid "WE NEVER DEVIATE!" attitude.
callesgg 12y ago
sounds awfully boring.
itsbits 12y ago
Meetings only on thursdays!!...Working in a startup I can say that those kind of enforcements is quite tough to keep on Clients...You know there is lot of competition every where...if your client is unhappy, they will find another one...
- frostmatthew 12y ago
  > Working in a startup I can say that those kind of enforcements is quite tough to keep on Clients The post is titled "Developer Productivity..." - most developers (regardless of startup or megacorp) aren't having meetings with clients.
AstroChimpHam 12y ago
A lot of the commenters are understanding this post as the author putting down unbreakable commandments and then demonstrating that there are exceptions to the rules, and thus the author is wrong, or bad at his job, or whatever. We programmers have really got to learn to take stuff less rigidly. OP can correct me if I'm wrong, but I read this more as "here's the ideal I'm working towards, and I follow it as much as I can unless there's a good reason to break it." Read it that way, and there's actually a lot of good advice in there. I've never met a programmer that didn't need to be in the zone to get big projects done well, and everything mentioned here is good advice towards finding time to get into the zone more often. As a start-up founder, I have a ton of little things I constantly need to do, and following advice like this to get those little things into manageable clusters that allow for less context-switching has been incredibly helpful in getting stuff done. I'd never heard of some of the tools the author mentioned, and I sometimes forget some of the strategies, and a refresher is always nice. Thanks for the post!
EliRivers 12y ago
Weekly sprint planning. 30 min over Monday lunch. I'm happy to eat on company time if you like, but if I'm working it doesn't come out of my lunch break :)
- mattxxx 12y ago
  Also, I don't get how you can plan a sprint while eating. Sprint planning is like the most important time to be actively in discussion.
Flemlord 12y ago
My favorite developer productivity trick is office hours. Post times you are available on your door/cube and most people will respect it.
lettergram 12y ago
It's kind of strange, but I came up with the same (more-or-less) rules while I worked. Especially interesting, was that I worked at a place that "required" meetings pretty much every day. I just decided to start skipping them, all of them. Absurdly, nothing happened. I was able to complete all of my work by Tuesday afternoon (skipping the 3 monday meetings). Then I would meet one-on-one with my boss (who agreed that I could try this out), show him what I did, and by wednesday I started something new. Within a month I convinced three of the teams (3 - 8 people) to start doing this. It was pretty awesome it was to improve productivity by just trying to skip meetings I didn't want to attend anyways.
- civilian 12y ago
  Yup :) I also get a morale boost from feeling rebellious and anti-bureaucratic when I skip meetings. "Fuck y'all, I've got code to write, your words don't mean anything to me. If it's important my project manager will give me the lowdown."
kull 12y ago
I disagree with many haters in the comments. Of course, it works differently for different people and different businesses. But the ideas in the article make me willing to try some tweaks to my workflow. I will just try less hardcore implementation of those things (eg. limit meetings and calls to 3 days a week and see how it goes).
deleted 12y ago
[deleted]
mattxxx 12y ago
It'd be nice, but the article comes off like a small-sized engineering team, telling much bigger businesses how to be efficient. The reality is that the meeting is about communication, and that's almost-as-important-as coding for bigger teams.

189 points by cj 12y ago

bbody 12y ago

Very interesting article, something every manager who manages developers should read. However I think a lot of developers (Particularly startup ones) have multiple roles, so interruptions and changing flow is a part of the job. How do you suggest to get around that? My only solution would be to split your day up into chunks for the different roles, minimizing context switching.

bluedino 12y ago
>> However I think a lot of developers (Particularly startup ones) have multiple roles, so interruptions and changing flow is a part of the job. That's how my last job was. Tasks varied as followed: * Work on upcoming project X (release date in the future) * Feature request on project Y (need done somewhat soon for a client on an already operating project) * Bugfix needs done NOW on existing project Z * Ops issue with servers, database, etc

tschellenbach 12y ago

Love it, great read

dpcan 12y ago

Their key points here were: -Inbox Pause -Thursday Meetings -and Do 1 Thing a Day. I personally use: -Archive Everything -Never have meetings... ever. -and Prioritize My email is like Chat unfortunately, so much back and forth on projects I really can't afford to only chime in once a day or nothing would ever get done. But everything gets archived unless I'm working on it actively, or I still need to reply. Meetings... I never meet in person now. The time suck is just horrible awful miserable. I will occasionally have a phone meeting, but they aren't much better, but at least I don't have to take time to shave and drive. 1 thing a day would be nice unless your world consists of 200 little tiny things. So, I prioritize and block out hours to get things done. Then I DO apply 1-thing-a-day to my side-projects so they stay fresh. To each their own.

karinnielsen 12y ago
Not having meetings or conf calls might work for you but I would be very surprised if it works for your customers and/or peers (assuming you have any). If there is one thing I have learned it's that the quality of communication in a team usually makes or breaks the project. The quality of communication with a customer makes or breaks the relationship. It's important to remember that humans have been communicating for thousands of years without email, chat servers or telephones. Our brains are hard-wired to respond to facial expression, tone of voice and body language. All of this is lost with computer-mediated communication channels. Your post prompted me to look at this study which you may also find interesting: http://www.academia.edu/538403/Face-to-face_Versus_Computer-mediated_Communication_Exploring_Employees_Preference_of_Effective_Employee_Communication_Channel http://www.academia.edu/538403/Face-to-face_Versus_Computer-... Don't get me wrong, meetings for the sake of meetings are a waste of time but that's not to say that they do not have their place.
- 1123581321 12y ago
  I find maker-vs-manager a bit brittle as well. A company I'm very familiar with has people going into and out of immersive "modes" that involve creative work as well as communication about that work. So, someone might spend all week in "ABC mode" and have 4-8 meetings about ABC as well as shipping a few features or solutions. Others might advance a few large features and be interrupted by 2-3 meetings, but because they are connected, the immersion is not broken.

ryandrake 12y ago

A strategy of communication avoidance might work if you're a one-person company with no managers and no customers, but in the real world, it's necessary to periodically come out of our hidey-holes and talk to people. The need to communicate regularly grows as the project's size and complexity grows, as deadlines approach, as requirements change. The idea of the Lone Wolf Developer sitting uninterrupted in his office 24/7, building the software in a vacuum, gloriously emerging after three months, on time, with software that perfectly conforms to the requirements, that miraculously works exactly according to the customer's needs, is a myth--incompatible with the reality of professional software development.

nerdy 12y ago
Unfortunately so.
BurningFrog 12y ago
Having meetings every Thursday is exactly "periodically come out of our hidey-holes and talk to people".
- cssmoo 12y ago
  I operate a "if you can't be bothered to structure your thoughts in a well-written email, you can bugger off" process. Meetings Thursday is a no go area for me. This works well once everyone understands it. Unfortunately for it to work, you tend to have to serve as an internal consultant to a company, write good replies and maintain a lot of documentation and technical standards.

bshimmin 12y ago

This post is almost comically ridiculous if you try and apply any of it outside of the context of (I imagine) a small team that doesn't really do anything externally. How do I tell my clients that I only do meetings on Thursdays? If they happen to be unavailable one Thursday, do they have to wait a fortnight before I deign to speak to them again? Is this guy seriously suggesting that the way to stop being overwhelmed by inbox zero is by using Slack? And honestly, doing one thing a day - really? How in the world does that work? Sure, doing one thing well is better than doing nothing or half-doing a bunch of things, but surely your goal should be actually doing a reasonable amount of things that reflect a solid day's work - and figuring out a strategy for reliably making that happen. Perhaps I'm just a grouch today, but it feels like this post is either satire or written from a completely different universe, utterly unrelated to the one I inhabit and work in.

mathgeek 12y ago
Not just you. I feel like this post just regurgitates a bunch of other "every few days" posts. Doesn't really add much to the conversation. That's not to say that it shouldn't be written, as getting your thoughts out there is always a good exercise. It being on the front page of HN is of questionable use, though. Might be of some utility to anyone who has never read HN before.
- spotridge 12y ago
  I've just canned a very similar post to yours. Is there any explanation as to why this should be on the front page? This seems rather like Reddit - posts there often seem to rise up while most of the comment section is fairly negative.
  - mathgeek 12y ago
    Well there are people voting it up, which I can understand as the concepts are always popular. Not sure on the algorithm that's used.
  - striking 12y ago

corysama 12y ago

Anyone here who has not read "The Power of a Positive No" really should get to it. It's about how to say No constantly without being an ass. It's practically tailored around devs negotiating with customers. I the whole world read Ury's "Getting to Yes" trilogy, the whole world would be a much nicer place to be.

unoti 12y ago

This reminds me of a type of professional that I see far too often. The professional who specializes in not doing their job. It happens with programmers, as well as many other specialties. You've probably seen them: - Software developers who as soon as you tell them what you need, they tell you why it's impossible. - Network administrators who apparently specialize in making machines not talk to each other, because things worked better before their first day - DBA's whose first priority is keeping you from accessing the data - Engineers who think it's their job to make things more difficult Saying NO to all the things is better than getting nothing done, sure. But having the skill to say yes to the things that are needed is better.

mistermann 12y ago
I agree, this is extremely common, and it completely baffles me....you are in charge of a resource, would it not be in your best interest if more people use that resource rather than less? For whatever reason, I find DBA's to commonly have this type of attitude, as well as having extremely unimaginative minds (Why would you want to do that?)
Bahamut 12y ago
It's all about what you say no to. For example, if it is something that will cause a lot of technical debt, as a developer, I push back until I get a concession where I have the opportunity to undo the damage afterwards. Otherwise the debt will increase stress, lower developer happiness, and potentially prevent the business from growing in the long term as developer retention becomes more difficult the longer it lasts. If you're going to ask for something unreasonable from someone with domain expertise, expect to make a concession if you want it done since that person has a high likelihood of understanding the true costs of the request. It is all too common to see developers experience burnout from 60+ hour weeks in order to attempt to meet a deadline because managers were awful at planning. I often take a more neutral stance through explaining that it would take [X] amount of time to build solid & tested pieces of functionality as designed, and then let the product managers assess the information to come to a decision to either scale back or if it is still pushed for, then push back for a concession. It doesn't have to be a Yes or No proposition, it is like bartering - you want to get to a mutual agreement so all parties are satisfied.

YorkianTones 12y ago

I like the idea of holding personal email and then bulk delivering to my inbox at specific times during the day. However, the tool recommended by the linked post, "Inbox Pause", seems to just use a toggle button and doesn't have a scheduling mechanism. Anyone know of a tool that does? Maybe the folks over at SaneBox should add this.

mkopinsky 12y ago
How about Ctrl-W to just close the Gmail tab?
- jonathanpeterwu 12y ago
  That's actually a great point.

droopyEyelids 12y ago

We all make fun of "One weird trick to lose belly fat" but how many articles have you read about pomodoroing, closed offices, meeting refusal, and the like? The market is ripe for The Secret to Developer Productivity, a product that talks about all the common strategies in a happy but "we all know they don't work" style, while promising to let you in to the True Secret after you break out the credit card.

tbrake 12y ago
> We all make fun of "One weird trick to lose belly fat" but how many articles have you read about pomodoroing, closed offices, meeting refusal, and the like? I've been reading them for years. I'm sure there are vets who have been reading them for longer. I'm also sure a good portion of management - at all levels - have read it, or heard about it, or attended a conference etc. So then why does it persist? I'm sure it's not down to just one reason. There are three that instantly spring to mind - One slightly cynical one could be that management simply views the eroded productivity as an acceptable cost of getting things their way in regards to meetings, agendas, stopping by to bother you and so on. Another, more self-critical one, is that we as developers just aren't assertive enough in demanding change in the workplace. Maybe we do need unions. I don't know. A third is that for every one company that "gets it" there are hundreds (if not more) of companies that don't. Most of them not even in your field/industry, but if you want them as clients then external pressure to conform to their way overrides the ability to operate how we want. I'm sure there's lots of other good reasons it happens and probably plenty of bad ones. I haven't _completely_ given up hope things could change throughout the industry but it's not something I'd cling to.

S4M 12y ago

Am I the only person who hates daily morning stand ups here? Not everybody on the team arrives at the same time, so if you arrive early it will become aninterruption in your workflow. Sometimes I can't do what I planned to do and most of the time I don't care about what others are plamning to do. Also in my previous companies members of my team had the tendency to talk a lot in the daily standup, making it last sometimes 20 minutes.

samspot 12y ago
It's not my favorite thing, but I do believe it removes the need for a lot of other meetings. I also find that I am almost never 'statused' on this team, which is a huge improvement. Talking too much is a discipline thing that you have to push against hard & often. Some people get it really easily, while others take a lot of coaching before they learn to give the right amount of information.
mavdi 12y ago
20 minutes? We have a technical architect who alone babbles nonsense for half hour in each standup. Some people confuse stand ups with their counselling sessions.
- S4M 12y ago
  Dude, I am sorry to hear that.
- dakotaben 12y ago
  Then whoever is running the stand up.... sucks. This is not a stand up.

fein 12y ago

The pendulum always swings to one extreme; it never seems to find a resting place in the middle. Productivity is all about balance, which is a word that never appears in this article. A blog providing polarizing advice won't be any sort of silver bullet, as the definition of "productive" will, quite often, change completely. One day it may be fielding calls, having meetings, and talking to clients. Another day it may mean sitting in a dark room for ten hours with a coffeemaker, a laptop, and yourself, just banging out bugfixes and feature requests. This is the kind of concept that should be felt out on a project by project / week by week basis, not with a rigid "WE NEVER DEVIATE!" attitude.

callesgg 12y ago

sounds awfully boring.

itsbits 12y ago

Meetings only on thursdays!!...Working in a startup I can say that those kind of enforcements is quite tough to keep on Clients...You know there is lot of competition every where...if your client is unhappy, they will find another one...

frostmatthew 12y ago
> Working in a startup I can say that those kind of enforcements is quite tough to keep on Clients The post is titled "Developer Productivity..." - most developers (regardless of startup or megacorp) aren't having meetings with clients.

AstroChimpHam 12y ago

A lot of the commenters are understanding this post as the author putting down unbreakable commandments and then demonstrating that there are exceptions to the rules, and thus the author is wrong, or bad at his job, or whatever. We programmers have really got to learn to take stuff less rigidly. OP can correct me if I'm wrong, but I read this more as "here's the ideal I'm working towards, and I follow it as much as I can unless there's a good reason to break it." Read it that way, and there's actually a lot of good advice in there. I've never met a programmer that didn't need to be in the zone to get big projects done well, and everything mentioned here is good advice towards finding time to get into the zone more often. As a start-up founder, I have a ton of little things I constantly need to do, and following advice like this to get those little things into manageable clusters that allow for less context-switching has been incredibly helpful in getting stuff done. I'd never heard of some of the tools the author mentioned, and I sometimes forget some of the strategies, and a refresher is always nice. Thanks for the post!

EliRivers 12y ago

Weekly sprint planning. 30 min over Monday lunch. I'm happy to eat on company time if you like, but if I'm working it doesn't come out of my lunch break :)

mattxxx 12y ago
Also, I don't get how you can plan a sprint while eating. Sprint planning is like the most important time to be actively in discussion.

Flemlord 12y ago

My favorite developer productivity trick is office hours. Post times you are available on your door/cube and most people will respect it.

lettergram 12y ago

It's kind of strange, but I came up with the same (more-or-less) rules while I worked. Especially interesting, was that I worked at a place that "required" meetings pretty much every day. I just decided to start skipping them, all of them. Absurdly, nothing happened. I was able to complete all of my work by Tuesday afternoon (skipping the 3 monday meetings). Then I would meet one-on-one with my boss (who agreed that I could try this out), show him what I did, and by wednesday I started something new. Within a month I convinced three of the teams (3 - 8 people) to start doing this. It was pretty awesome it was to improve productivity by just trying to skip meetings I didn't want to attend anyways.

civilian 12y ago
Yup :) I also get a morale boost from feeling rebellious and anti-bureaucratic when I skip meetings. "Fuck y'all, I've got code to write, your words don't mean anything to me. If it's important my project manager will give me the lowdown."

kull 12y ago

I disagree with many haters in the comments. Of course, it works differently for different people and different businesses. But the ideas in the article make me willing to try some tweaks to my workflow. I will just try less hardcore implementation of those things (eg. limit meetings and calls to 3 days a week and see how it goes).

deleted 12y ago

[deleted]

mattxxx 12y ago

It'd be nice, but the article comes off like a small-sized engineering team, telling much bigger businesses how to be efficient. The reality is that the meeting is about communication, and that's almost-as-important-as coding for bigger teams.