Developer productivity: The art of saying no(localizejs.com)
localizejs.com
Developer productivity: The art of saying no
https://localizejs.com/blog/startup/developer-productivity-saying-no
20 comments
Coworker of the OP here. To elaborate a bit:
> How do I tell my clients that I only do meetings on Thursdays?
I generally do 10-15 customer meetings per week. When I get a meeting request, I ask if they're available on the following Tuesday or Thursday with a 90% hit rate. Meetings are almost always not urgent, so fitting them into Tues and Thurs, instead of spreading them randomly througout the week, has worked really well for me.
> How in the world does [doing 1 thing per day] work? [...] surely your goal should be actually doing a reasonable amount of things
In the context of software development, doing a large number of things usually doesn't push the product forward as much as doing 1 big 2-4 hour project.
Personally I still have 30+ things on my TODO list at any given time, but I try to center my days around getting one "big" thing done, and fill the rest of the day with smaller day-to-day tasks.
> How do I tell my clients that I only do meetings on Thursdays?
I generally do 10-15 customer meetings per week. When I get a meeting request, I ask if they're available on the following Tuesday or Thursday with a 90% hit rate. Meetings are almost always not urgent, so fitting them into Tues and Thurs, instead of spreading them randomly througout the week, has worked really well for me.
> How in the world does [doing 1 thing per day] work? [...] surely your goal should be actually doing a reasonable amount of things
In the context of software development, doing a large number of things usually doesn't push the product forward as much as doing 1 big 2-4 hour project.
Personally I still have 30+ things on my TODO list at any given time, but I try to center my days around getting one "big" thing done, and fill the rest of the day with smaller day-to-day tasks.
So you do meetings on Tuesday or Thursdays, and rather than doing one thing a day, in fact you do one big task a day and many small tasks. That's all fine and good, but 1) it's not really what the OP's post says, and 2) it's not really very revolutionary at all.
I'm glad it works for you guys, but I'm often irritated by these preachy posts which seem to say that developers should be treated as delicate flowers and suggest all manner of strategies to preserve their preferred ways of working, many of which, if you actually applied them to the real world, would result in clients saying, "Wow, these guys are hard to work with, can we please find someone else?"
I'm glad it works for you guys, but I'm often irritated by these preachy posts which seem to say that developers should be treated as delicate flowers and suggest all manner of strategies to preserve their preferred ways of working, many of which, if you actually applied them to the real world, would result in clients saying, "Wow, these guys are hard to work with, can we please find someone else?"
> So you do meetings on Tuesday or Thursdays, and rather than doing one thing a day, in fact you do one big task a day and many small tasks. That's all fine and good, but 1) it's not really what the OP's post says, and 2) it's not really very revolutionary at all.
I would go further than saying this isn't really very revolutionary, rather it describes a fairly normal working environment.
I would go further than saying this isn't really very revolutionary, rather it describes a fairly normal working environment.
Unfortunately, there are a lot of dysfunctional working environments out there, where this wouldn't be considered "normal".
Of course, in those environments, developers cannot say "no", they can either keep working under whatever unreasonable constraints they have, or quit. (I've found this a lot more common in companies where the main focus isn't software development)
I agree it's not very revolutionary, but I still find it useful to read about how other people organize their teams and how it works, and very especially what tools they use (Slack and a few others are on my to-try list).
Of course, in those environments, developers cannot say "no", they can either keep working under whatever unreasonable constraints they have, or quit. (I've found this a lot more common in companies where the main focus isn't software development)
I agree it's not very revolutionary, but I still find it useful to read about how other people organize their teams and how it works, and very especially what tools they use (Slack and a few others are on my to-try list).
Appreciate your thoughts! Definitely agree the article doesn't apply to everyone in all cases.
As a company we really want to spend time sharing what we learn.
This is one of the first posts we've written, so we'll try to improve in the future :)
As a company we really want to spend time sharing what we learn.
This is one of the first posts we've written, so we'll try to improve in the future :)
Here's some more feedback, I cracked open the article, quickly identified it as one of the preachy posts he was referring to, and closed it without reading.
I too am tired of people discovering this "blog" thing.
I too am tired of people discovering this "blog" thing.
I've been told that customers actually respect companies that say "no" to them more than the ones that always say "yes" to everything (as long as the rationale is explained and reasonable).
Just like you respect a romantic partner who is firm with you and has boundaries, more than you respect one who's a total doormat and lets you trample all over them.
While this sounds nice to hear, I would actually like to see some hard evidence proving this. If you have any sources backing this comment up I would love to see it. I work in advertising and I would love to tell account execs this because they are notorious for not being able to say no.
My only strategy to working is just to sit there and fucking work. It's not very difficult. You sort of just tell yourself you're going to do something and then you do it. Boom, saved this entire community a blog post.
" many of which, if you actually applied them to the real world, would result in clients saying, "Wow, these guys are hard to work with, can we please find someone else?"
Exactly. Totally flies in the face of saying "how high" when someone says "jump".
Not only that but a similar attitude of some old timers in a business that I was in (right out of college) was what allowed me to get their clients.
We live in a world where people want instant gratification and answers to their questions. While there may be cases where timing doesn't matter when you are dealing with sales and closing deals and keeping away the competition I have always found the early bird gets the worm. And sometimes you get the deal just by showing up because the other party is to busy to service the account.
Exactly. Totally flies in the face of saying "how high" when someone says "jump".
Not only that but a similar attitude of some old timers in a business that I was in (right out of college) was what allowed me to get their clients.
We live in a world where people want instant gratification and answers to their questions. While there may be cases where timing doesn't matter when you are dealing with sales and closing deals and keeping away the competition I have always found the early bird gets the worm. And sometimes you get the deal just by showing up because the other party is to busy to service the account.
So really, you don't just do meetings on Thursday, and you don't just do one thing a day.
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.
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.
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.
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.
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.
There's no downvote function for stories, so even controversial stories will appear on the front page. The only reason something shouldn't be on the front page is when it's off topic or spam. As long as someone cares about something, it can be on the front page.
There is no "off topic" on HN since the topic is "anything that interests hackers" and us hackers are not going to up vote anything that isn't interesting.
It need to be reiterated until it becomes the norm.
I happen to use one-goal-a-day in my own career. It's amazing. There's so many things you could do, but would not really move any needles. If you pick the one thing you know will move the needle, and focus just on that, and be happy if you can accomplish it, you'll ultimately be so much more productive, even if it doesn't really feel like it. You can decouple the feeling of being productive from your activities without losing real productivity, if you can do that, you can be amazing.
I had only one thing to do this entire week, and I didn't even get it done. So from where I sit one thing a day is pretty optimistic. Granted I did a lot of useful things for people, I just didn't get my own priority completed. Hopefully all this other stuff will die down over time.
I don't think he is really saying to do just one thing, just that we should hang the success of the day on only one priority. It is somewhat similar to the 'today is the deadline' motto from scrum.
I don't think he is really saying to do just one thing, just that we should hang the success of the day on only one priority. It is somewhat similar to the 'today is the deadline' motto from scrum.
You probably made progress on that task, though. Added unit tests, clarified requirements, etc.
I did. I actually sent everyone a note one morning that I was planning to avoid email, and they should hit me up directly if they needed anything. I was going to suggest that in the comments here, but I feel like I need to see how well that works if it becomes a regular thing.
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!
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!
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.
- 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.
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.
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.
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.
Another pattern I've seen is the dreaded "artificial deadline" from on high. A project is structured to meet a tight deadline, resources are reallocated, nights and weekends are worked, stress ripples through the team. At great emotional expense the deadline is met, and the team submits the project, victorious.
And then nothing is heard for several days. No feedback from the heavens. Inquiries are made, and it's discovered that, well, no, in fact there was no particular reason this project had to be finished by that particular date. Managers have moved on, checkboxes have been checked. Because the project was nominally successful, the episode is used to further confirm the management theory that "the dev team needs deadlines, even arbitrary ones, or things don't get done." The project size and time frame is now baked into management's institutional memory as the new baseline.
Another pattern I've seen is the dreaded "artificial deadline" from on high. A project is structured to meet a tight deadline, resources are reallocated, nights and weekends are worked, stress ripples through the team. At great emotional expense the deadline is met, and the team submits the project, victorious.
And then nothing is heard for several days. No feedback from the heavens. Inquiries are made, and it's discovered that, well, no, in fact there was no particular reason this project had to be finished by that particular date. Managers have moved on, checkboxes have been checked. Because the project was nominally successful, the episode is used to further confirm the management theory that "the dev team needs deadlines, even arbitrary ones, or things don't get done." The project size and time frame is now baked into management's institutional memory as the new baseline.
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?)
On the other hand is the manager with no grasp of the technical challenges who asks the expert with the intention of getting a rubber stamp and acts all shocked and offended at the slightest push-back.
Not that I've been the developer in that scenario...
Not that I've been the developer in that scenario...
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.
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.
Having meetings every Thursday is exactly "periodically come out of our hidey-holes and talk to people".
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.
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.
Unfortunately so.
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.
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.
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.
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.
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.
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.
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.
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."
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.
-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.
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-...
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.
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-...
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.
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.
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.
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.
> 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.
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.
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.
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.
>> 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
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
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).
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 :)
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 :)
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.
My favorite developer productivity trick is office hours. Post times you are available on your door/cube and most people will respect it.
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.
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.
I the whole world read Ury's "Getting to Yes" trilogy, the whole world would be a much nicer place to be.
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...
> 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.
The post is titled "Developer Productivity..." - most developers (regardless of startup or megacorp) aren't having meetings with clients.
[deleted]
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.
The reality is that the meeting is about communication, and that's almost-as-important-as coding for bigger teams.
Love it, great read
sounds awfully boring.
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.