
Developer productivity: The art of saying no - cj
https://localizejs.com/blog/startup/developer-productivity-saying-no
======
bshimmin
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.

~~~
cj
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.

~~~
bshimmin
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?"

~~~
GFischer
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).

~~~
kyllo
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.

------
AstroChimpHam
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!

------
unoti
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.

~~~
Bahamut
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.

~~~
redler
_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.

------
ryandrake
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.

~~~
BurningFrog
Having meetings every Thursday is exactly "periodically come out of our hidey-
holes and talk to people".

~~~
cssmoo
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.

------
S4M
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.

~~~
mavdi
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.

~~~
dakotaben
Then whoever is running the stand up.... sucks. This is not a stand up.

------
fein
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.

------
lettergram
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
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."

------
dpcan
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
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-...](http://www.academia.edu/538403/Face-to-
face_Versus_Computer-
mediated_Communication_Exploring_Employees_Preference_of_Effective_Employee_Communication_Channel)

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
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.

------
droopyEyelids
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
> 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.

------
bbody
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
>> 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

------
kull
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).

------
EliRivers
_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
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
My favorite developer productivity trick is office hours. Post times you are
available on your door/cube and most people will respect it.

------
YorkianTones
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
How about Ctrl-W to just close the Gmail tab?

~~~
jonathanpeterwu
That's actually a great point.

------
corysama
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.

------
itsbits
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
> 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.

------
mattxxx
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.

------
tschellenbach
Love it, great read

------
callesgg
sounds awfully boring.

