Live data from Hacker News

Ask HN: Seeking advice from programmers for non-programmers

news.ycombinator.com

31–36 of 36 posts

Re: Ask HN: Seeking advice from programmers for non-programmers

#31
WARNING: THIS IS MY PERSONAL OPINION

1. Uninformed.

2. By not consulting on "business decisions" which are actually mostly tech decisions.

3. Make sure you have AS MUCH COMPLETE as you POSSIBLY CAN - things like idea/strategy/wireframes/html mockups/product alpha/prototypes/customers who have intent to use product if it exists/realistic 1st year numbers/plan on who is getting merchant account/incorporating/vesting of stock/who is doing accounting/what is the bare minimum for v0.5 of product.

4. Be honest, open & encouraging. Mostly honest & open though.

5. None

6. Money & Recognition

7. Money & Recognition

Re: Ask HN: Seeking advice from programmers for non-programmers

#32
It may be helpful to remember that programmers look at things logically. That's why I'm no good at sales. I look for direct paths and solutions, and understand yes/no, not negotiations. I tell you this to show how/why I have respect for effective marketers. It's a bit like magic to me because my brain doesn't work that way (so you see how the tables can turn).

As for the questions, think about it in terms of any business relationship. Show that you can and will bring value to the table, and follow through on promises. Programmers do hard work; we would appreciate and respect a "business guy" walking back in the door with tie crooked, hair tousled and perspiring after a day working their marketing magic.

Re: Ask HN: Seeking advice from programmers for non-programmers

#33
Your choice of the word "cog" to represent a programmer and "gear" to represent a team indicates you might be internally (to your mind) objectifying the people involved with your potential projects. I could see such an internal objectification causing various problems with your interactions with the "cogs/gear" in various ways during a project. You can quickly lose someone's respect if he learns that you think of him as a replaceable part of a soulless machine.

A problem for "business types" is that they are trained to think of people as "human resources." This is probably a bad idea on any scale of team/organization. But it's an absolutely horrible idea w.r.t. the small-scale teams of which startup companies are made.

Re: Ask HN: Seeking advice from programmers for non-programmers

#34
- How do they come to respect or disrespect someone in this role?

Earn respect by investing not only in your product, but in your programmers. If you're a carpenter, you'd think your boss was crazy for asking you to drive nails without hammers or a nail-gun; and yet, this is how programming environments sometimes operate, causing consternation.

Earn disrespect by treating programmers like cogs. Do not ever assume that you can simply replace one programmer with another; there is an absolute chasm between the skills of the best and the worst. One way to judge your programmers is in adaptability; do they at least seem willing to tackle anything you throw at them, or do they not really have a clue how to start most of your ideas?

- How can I best approach a software engineer with an idea?

Do not make any assumptions about how simple the implementation could be. There are hard things that sound easy, and vice-versa. At the same time, be prepared to deconstruct your idea to say "well what if we only did X and Y"; you may be surprised how different the answer is.

- What can a business type do to build trust with a programmer?

Be detailed; communicate without filters. There's nothing worse than being asked to drop everything to provide one or two tidbits of information "immediately", only to find out later that the wrong question was being asked and that the priority wasn't really accurate. Heck, if you have to tell the programmer your 3-year plan for the product, do it; that may affect how the implementation proceeds.

Be flexible. Programmers will be productive at the weirdest times. If you see someone who comes in late and works for 12 hours straight, then takes a day off, they could still be the most productive software developer you've ever seen. Even if we aren't actively working on an idea in front of a computer, we are often putting it together in our heads. Perception is not reality in most cases. Having said that, do demand evidence (simple documentation, occasional updates, and definitely prototypes).

- What motivates programmers? Success? Personal fulfillment? Money?

I want to feel like my projects are useful. I want to have the freedom to design, and not feel "stuck" with any bad decisions.

Money is only important enough for me to live comfortably (I don't need a mansion or a yacht). On the other hand, if it became clear that someone who contributed very little was going to be showered with millions from my ideas, I'd definitely want my cut.

- How do software engineers perceive business types?

As a necessary evil. :) Software is relatively easy to distribute, so there isn't much to prevent people from acquiring your product. On the other hand, there is a lot to prevent them from finding products, so marketing is quite important. Not being sued is important. :)

Re: Ask HN: Seeking advice from programmers for non-programmers

#35
post #2

A problem I've seen from both sides of this fence is that one side tends to over-simplify what the other side needs to do to get something done. A business guy may say "oh just slap this together and you're done", while a software guy might say "just go get some sales and we're golden". I think taking a few minutes to find out the actual effort required to make something happen can go a long way; for both business pe…

> they also tend to know the full problem domain a little better than most of the business people they deal with

This is too often overlooked.

It is development's job to "re-engineer" this domain in some fashion. Don't neglect the expertise they bring to the table and/or acquire in doing so.

And... if you are dealing with a corresponding "business type" at the client/customer, realize that this applies on the other side, too. When working with/through such contacts, you may not being gaining a full picture of what their end users really need.

Better model: Put the users and developers in closer contact with each other. Use your expertise to mediate this especially from a financial and legal perspective. Scheduling fits somewhere in between, and should have the active participation of both parties -- business and technical on your side, and ideally both business and technical on their side as well.

It can be like a light bulb going off, when e.g.your tech lead finally gets to communicate directly with theirs. An hour -- sometimes 15 minutes -- of direct communication can obviate weeks of "memos" and such. Especially if they are freed to communicate in a forthright manner on an ongoing basis.

Your job is to define the boundaries of communication and to adequately defend property rights and profitability. Don't insert yourself too heavily into nor try to micromanage the rest. Assuming you have good staff.

This is based upon my ad hoc observation of situations that have worked and situations that haven't. I'm not formally an "expert" in this.

Re: Ask HN: Seeking advice from programmers for non-programmers

#36

Dan your points are all valid and your intent clean. As a programmer turned business person, who (IMHO) has a decent enough grasp of both, I'll say this: you're missing the elephant in the room here. Your approach to the problem seems to be: I have an idea and a plan, I just need someone to build it. What you should be doing though is seeking out your opposite: Programmers who have built the software, but need someon…

Can't agree with this enough. I'm a programmer, and I solve lots of problems. Build lots of things. But not only do I not know how to sell anything, I don't even know anybody who knows how, or know how to meet anybody who knows how. And there's no way it's just me.
Post reply on HN