
Ask HN: "I'm sure that'll be really easy" - babyduck
How do you convey the ease/difficulty of your work to a non-technical co-founder? Mine has a habit of saying that this or that task "looks really easy", to me and to our designer. "I can't see how X would take long/be difficult", etc.<p>I don't want to keep explaining the difficulty of stuff, because it makes me seem incompetent. And lots of stuff isn't actually hard, it's just time-consuming. More than that though, the easy stuff may be easy for me, but it's not necessarily "easy", and I feel undervalued to hear it being described that way.<p>I usually just go off and do it, but then I think I'm making it look too easy. When you've spent hours working on a feature, and you finally get it right, and you're really excited, but your co-founder stares at it blankly and then wants to change everything, it can get a little discouraging.<p>How do you explain this stuff to someone who's never coded?
======
zedshaw
First, learn to say no. You can do it politely and still say it, and it's not
rude or aggressive to just say no.

Second, get a task list, put all of his/her suggestions on them. Use something
like trac or redmine or whatever. Even better, have him/her put them in
themselves.

Third, after you complete whacks of work, get together and prioritize the
list, then pick a chunk of it to work on next. Keep your priorities to "Need
It Now", "Could Be Cool", and "Not Worth It", or similar. The idea is
eventually things should just fall off the list as not worth it.

Last but not least, you can reduce the amount of "no" you say by keeping to
this little list. It puts their wild optimism into perspective by showing how
their proposed feature fits in with all the other features currently waiting
to be done and then they'll start to understand how long things take.

Now, the warning, do _not_ keep track of how long each thing takes. This will
give him/her control over how long things should take, and will be seen as a
contract/promise rather than a guess. This is where you use "no". You are not
a factory worker. Lists of things to do are fine. Fine grain hourly tracking
is for time card punchers with no education working in a 3rd world country.

~~~
starkfist
actually one of the nice things about 3rd world countries is that they don't
do fine grained hourly tracking and time card punching.

------
elbenshira
I start with a "that takes like 3 seconds easy" sub-feature on the "it looks
really easy" feature such as entering a user's name into a text box. Then I
ask the "looks really easy" person questions:

\- What is a "name" exactly? \- What about names in other languages? \- How do
we search for names in other languages? \- What if the user puts something
that is clearly not a name e.g. bob@example.com. But what if it _is_ someone's
name? \- What about cultures with no last name? \- What about security? How do
we make sure that someone doesn't try destroy our data with the name text box?

And on and on. Basically, I make them think like me. Usually, they either (1)
realize it's hard or (2) say "fine!" (meaning they realize it's hard).

~~~
detst
I've also had the experience that they take this as just being difficult and
making things seem more complicated than they need to be.

They'll try to simplify or eliminate the problems that you present not
understanding the implications or stubbornly believe that what you need to do
is simple.

I love dealing with people that think that what I do is as far above their
head as brain surgery; much easier to deal with.

~~~
babyduck
I really like this idea, though I've done a lesser version of it and I did get
the feeling that she thought I was overcomplicating things.

I'm also starting to realize that the focus required to work through problems
like this is pretty extreme. It feels normal to us because we do it all the
time, but for many people it's almost impossible. They just kind of bounce off
the problem. They solve one or two parts, then as it gets harder they either
gloss over the rest, or they come up with a completely different idea so that
they can go back into high-level brainstorming mode.

------
albertsun
You say this is your co-founder but the way you describe the situation makes
it sound like your dealing with a manager.

They have no business making comments like that about something they don't
understand.

~~~
babyduck
How do they sound like a manager?

We frequently sit down together to brainstorm about features, or figure out
what we can get done in the next few days, what needs to be working before my
partner can show a prototype to potential customers for feedback, that kind of
thing - this is where the "easy" comment usually comes up.

~~~
dejb
> How do they sound like a manager?

In short Yes. It sounds like

\- They tell you what to do way more than the reverse. I'm guessing they have
more autonomy in their area.

\- You are a lot more worried about what they think of your performance than
the reverse.

\- You don't feel comfortable simply contradicting them directly.

They certainly seem to be 'wearing the pants' in your organisation. I'm not
saying this a necessarily bad thing. If you are working with a Steve Jobs then
being a Steve Wozniak is a pretty good move. But make sure to pay critical
attention to their performance as well. The danger is that if you are working
to impress them you won't notice if their performance is substandard.
Salesy/Businessy types are good at tricks like that.

------
zackola
I think the best thing to do is to sit down and come up with a list of parts
of the app that need to be touched to complete what they are asking for. When
you lay it all out, even at a skeletal level, clearly there are a lot of
moving parts right? We sometimes get the taunt that "oh come on, it's only
another if statement", but besides the shit code and maintenance nightmare
that kind of thinking/implementation causes, when we lay it out for a few
minutes the complexity becomes apparent - add a column to the database here -
oh crap that migration will take 20 minutes to run - oh crap, we need to make
sure that field is going to be indexed properly, create the frontend to modify
it - oh crap, it has to work for the clients still using IE6?, oh crap! they
need it to print nicely too? etc...

There's no need for anger or to become irate - it's a matter of education. I'm
sure there's many a HN reader who has poo-pooed non-technical business types
for the perceived easiness of their jobs, and for some posers it's deserved,
but you don't really know that until you take the time to understand the other
person's reality.

~~~
dkarl
_I think the best thing to do is to sit down and come up with a list of parts
of the app that need to be touched to complete what they are asking for._

It's really hard to do this, because it feels like cataloging and advertising
all the ways I failed as a designer.

~~~
stcredzero
_It's really hard to do this, because it feels like cataloging and advertising
all the ways I failed as a designer._

How do you think you become a better designer?

~~~
dkarl
Yeah, but it doesn't help in a situation where you're trying to stand up for
yourself and defend your judgment to a boss or client. You're using an example
of your past failed judgment and foresight to argue for the accuracy of your
current judgment and foresight.

------
inerte
I can understand a business oriented (I'm assuming) co-founder pushing for
quality/release/cost, but in no way I would let them say whatever I'm doing is
"easy". It's disrespectful!

If this was being said by a customer, my treatment would be totally different.
But to a co-founder, honestly I would tell him to fuck off. I would be irate.
I wouldn't let him downplay my work. Ever.

C'mon. What kind of work environment is your company going to have? Imagine
hiring some employee and telling him "Your work is easy. I'm now wondering if
I'm paying you too much."

Or maybe I'm too bitter and stressed today and someone else will give you a
more diplomatic route.

~~~
hga
Agreed; I see babyduck having three or so options:

Change his co-founder's attitude, obtain his respect.

Admit that he's just hired help and is not himself really a co-founder.
Remember that one of the subtexts of "that's easy" is "I can replace you
easily".

Leave for a better startup or someplace where you'll be treated no better but
will get market compensation for the privilege.

~~~
babyduck
My co-founder is very aware that she'd have trouble replacing me. She was
looking for a partner with very specific characteristics, and I'm one of the
few who fit. She's just blunt, and if something looks easy to her, she says
it.

She's never worked with a programmer before, so she has no idea how good I am.
When I get things done quickly, she can take it for granted; she honestly
thinks it must be easy. This shouldn't matter, but I do have an ego, so it's
getting to me.

People are right, I have to talk with her.

~~~
hga
Anyone who has no knowledge of the field and who says " _I can't see how X
would take long/be difficult_ " is being more than "blunt". At best they're
very impolite, they're lacking the mental filters that prevent many people
from saying such. If that's the case, you have to wonder how she's interacting
with your company's customers....

When you say " _She was looking for a partner with very specific
characteristics, and I'm one of the few who fit._ " I _really_ have to wonder
if she truly sees you as a partner or co-founder. If she's capable of being
polite, then you have to wonder why she doesn't bother with you.

Especially since treating people with disrespect is not going to have a happy
ending. It's already getting to you, and when you hire a new technical person
she's going to treat them with disrespect, continuing the problem, but the
worse alternative for you is that she won't.

It's hard for me to see how this venture will be successful _for you_ without
getting some good results when you talk to her, and that means real change,
not promises. Be aware that despite the fact that she " _is very aware that
she'd have trouble replacing_ " you, that doesn't mean she won't try, even if
it kills the company (been there, done that).

------
jolie
Have him sit and watch you do it for an hour. Try to explain what you're doing
as you go along.

The best thing you can do for him is show, not tell, exactly what your job
entails. Otherwise, he's not only inconsiderate but also ignorant when it
comes to developers... and that'll make it harder for him to work with other
technical staff down the road.

------
Ixiaus
I distinguish between the concepts _easy_ and _straight forward_. I _never
ever ever_ say "that is easy" when talking to a non-technical person about
feature xyz or a project; I always say "that is straight forward". I then
proceed to lay out the fact that feature x is not technically complicated (a
problem already solved) but it does require _foot work_.

For example, building websites (your standard eCommerce Sally-wants-to-sell-
sweaters kind of website) is not innovating _anything_ on a technical level;
but there is footwork involved in building the website and integrating a
shopping cart and designing/slicing.

That's where many customers and non-technical people go wrong in their
understanding (it's mostly the programmer's fault for constantly saying
"that's easy") they will assume that if it is "easy" it is going to be simple
_and_ quick. Whereas, if the programmer makes a concerted effort to
distinguish what they mean; saying it is "straight forward" implies it is
simple but will take time.

~~~
hga
Very good point. I don't remember when I learned this, but I did learn to
_never_ say "this is easy" unless it truly was both easy and quick and I use
"this is straight forward" instead. It's very good at getting across the idea
of it being low risk without implying it'll be quick.

------
itgoon
Pick some aspect of his job, and say the same of it ("Accounting? That's just
addition and subtraction!" "Sales? That's just going out drinking").

If he gets offended, just smile.

~~~
jsean
Fun indeed. Unfortunately he'll probably only get offended and completely miss
the part about you subtly trying to prove a point.

If only we could _counter_ their "that's easy" with a similar statement of our
own thrown back at them...

Something like;

-Hey Mr. Developer we need to implement feature X. I think it's a 5 minute thing really. You only need to Y and then we're set. Should take an hour or less. Probably less if you just insert and if statement in module Z.

-Sure thing Mr. Manager/Sales/What-the-heck-do-u-really-do-around-here-anyways-guy. But may I ask... Do they [the customer] really need this feature?

-What do you mean? They asked for it specifically and besides they're paying us in gold.

-Well instead of implementing this feature can't we just convince 'em [the customer] that they really don't need this feature and would actually be better of paying us 10x what they do today? That's just simple sales and accounting! I bet all you need is a phone call. That way we could play Pong all day AND make more money.

~~~
itgoon
If he gets offended so much that he doesn't see the point, then he doesn't
view himself as a partner. He thinks he's the boss.

The most important thing to convey is that you are both bringing value to the
table, and neither of you can do it without the other. If that is a problem,
find someone else.

------
aheilbut
I have trouble explaining the difficulty of stuff to myself.

~~~
dunstad
I'm not sure why this was downvoted; there are tons of things I think will be
easy _before_ I start doing them.

------
spydertennis
One of the most important things in any start up is to have open lines of
communication. I think it's the number one thing that kills start ups. I would
tell your co-founder exactly what you wrote here.

It always feels really good when you explain to your co-founder why he's
making you upset, he understands and you guys work together to fix it.

------
tjpick
"easy" is if you can sit at a desk, peer style, and you can implement it
before he gets bored.

------
techiferous
One phrase I use is "going with the grain". Some software changes go with the
grain of the architecture and are easy, others are difficult.

Your non-technical co-founder needs to dip their toes into programming, if
even just a fibonacci algorithm. They need to get their feet wet enough to
realize that things easy for the human mind to conceive aren't necessarily
easy to translate to a silicon mind.

------
chaosmachine
The way I explain it is pretty simple. I tell the person:

"There's this thing called The Programmer's Law of Project Estimation. You
take your best guess, double it, and add a zero. That's how long it will take.
And it's always right."

You have to be dead serious when you say it, though.

~~~
carbocation
Also, see Hofstadter's law: <http://en.wikipedia.org/wiki/Hofstadters_law>

------
andymism
Assuming your cofounder is also involved in the design of the product, the
easiest way to show him the rest of the iceberg is to sit down and write a
functional spec of the feature together.

As a non-technical founder, he's likely just thinking about the end result of
feature X, not the implementation of it, whereas you see the technical details
at a much higher resolution.

You don't need to do this every time with him (although it's not a bad
idea)--just once or twice will be instructional enough. The goal is for him to
understand the amount of thinking and problem solving that goes into feature X
before a line of code is even written.

------
gexla
Time is a resource more valuable than money because you can't get more time.
How many hours can you work in one day? How many tasks are on the list?
Prioritize those tasks and go over the list with your co-founder. Tell him /
her how much time it will cost. Is it still worth it? If your co-founder
doesn't understand coding, then he / she should understand cost of resources,
especially the resources of someone as critical as a co-founder.

------
starkfist
Just tell him it's not easy, or that it's not actually hard, just time-
consuming. If it's easy for you, but not necessarily "easy," just tell him
it's a hard problem but easy for you, so he's lucky to have you around. As the
technical half of your dynamic duo it's your right (some may say
responsibility) to be crotchety about schedules and cocky about your
abilities.

------
iamwil
"Easy is a word you use to describe other people’s work or jobs" - Jason Fried

------
jules
> How do you explain this stuff to someone who's never coded?

Let him watch you code an "easy" feature.

------
Aaronontheweb
Use a visual.

------
stiggz
He's aware of your skill- you need to read between the lines. When he says,
'it looks easy', he means that based on the work he's seen you do, it looks
like something that you could easily do. He obviously believes that you
possess significant skill in coding if he's jumped into a start up with you.
I'd suggest hiring a co-op student or volunteer (many people will work for
free for programming experience) to do some of these 'easy' tasks. This will
enable you to teach others how to program in your style, and allow you a
mentor relationship which will GREATLY increase your coding and management
skills. Your designer may also benefit from taking a student under his wing

