Ask HN: "I'm sure that'll be really easy" | Hacker News Reader

Ask HN: "I'm sure that'll be really easy"

32 pointsbabyduck40 comments

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.

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.

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.

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

View on HN

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.

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

Agree that keeping lists is very useful for exposing what you're doing to others (and it improves productivity!). Disagree in this case with making these lists digital and giving your cofounder the ability to add entries because it encourages micromanagement and it sounds like your cofounder is rubbing you the wrong way with that already.

What I've seen work is short daily meetings of 5-10 minutes where people update each other on what they are doing. You can bring your notebook and he can bring his. Neither of you should have the spare time to micromanage the other. Keep him busy, and keep yourself busy too.

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

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.

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.

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.

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.

This sounds like a great situation. You just need to explain to them how long each idea will take to implement. Then you can all talk about what should be done first.

I do not see the problem.

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

Agreed, as someone who started off as a non-technical person and realized the necessity to gain more technical skills, I can remember saying things like "Oh, this seems pretty easy, you can probably just do x, y, and z and be done with it." Boy do I feel like an ass when I remember those days.

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.

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.

If it makes you feel any better:

The iPhone 4G does not look like the iPhone 3G

Google has reinvented their entire crawling infrastructure at least 4 times.

When evaluating leaders historical actions, historians often say that it is unfair to evaluate their decisions in the light of information which they were unaware of. Perhaps you may like to consider something similar.

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?

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.

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.

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.

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.

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

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.

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.

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.

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.

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.

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.

I have trouble explaining the difficulty of stuff to myself.

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

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.

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

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.

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.

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

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.

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.

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.

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

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

Let him watch you code an "easy" feature.

Use a visual.

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

Reply on news.ycombinator.com