Live data from Hacker News

Ask HN: Best business advice for software developers

news.ycombinator.com

271–280 of 325 posts

Re: Ask HN: Best business advice for software developers

#271

Earlier quoted context omitted.

I would use NodeJS for MVP. I think it is super important that you can have backend + frontend in the same technology.

Why? If you're proficient in multiple languages, there's no real upside, especially if each language is easily hireable. And it's particularly irrelevant if the front-end or back-end is weighted more heavily than the other in terms of product value , when you might hire distinct rather than "full stack" devs someday.

Two big reasons are:

1. Your devs can always go to where the work is - if you divide FE/BE and suddenly you have a feature that needs a lot of BE dev, you can move people from the now-mostly idle FE team rather than try to hire them

2. You can share business logic between FE/BE for client-side functionality. I've seen a surprising amount of bugs that boiled down to "oh we updated code on the back end but forgot it surfaced somewhere in FE code as well and didn't update there"

Of course, YMMV and this probably highly depends on your project, architecture, quality sensitivity, etc etc. But to say sharing FE/BE languages has "no real upside" is a bit... optimistic IMO.

Re: Ask HN: Best business advice for software developers

#272

Since this is an audience of passionate technologists, here's the top piece of advice I have: Do not be seduced by the technology! I killed one of my startups this way. I've seen many many die this way. It can hurt your pride as a passionate technologist to choose non-cool but mature and easy-to-hire-for tools. But it's those tools that are the most economical. Remember, your customers care 0% about the backend techn…

This is excellent advice. There is a local company near me that has been working on their SaaS for almost 2 years now and still yet to launch. They started it on Angular 1 and are now re-factoring it on Angular 2 (or maybe 4 now). During this time they released a small open source Angular library but not even an alpha release of their own product. Keep in mind their product is not gear towards devs. They also hit eve…

Who are their investors, or if you can't name names, are they seed or angle or self funded or what?

Re: Ask HN: Best business advice for software developers

#273
post #219

Earlier quoted context omitted.

There was a time when Ruby was "the cool exotic and unproductive technology". A lot of wheels had to be reinvented (and new ones added) before it became what it is today, there is nothing special about it. All mature technology will come with a known set of tools and processes to tackle almost any problem very quickly, as long as you're familiar enough with the stack.

> there is nothing special about it. One thing that's especially productive about it that helped to grow the 3rd party ecosystem is that the options you have for dependency injection in Ruby due to monkey patching give you an experience much closer to Aspect Oriented Programming. It also makes it easier when you need to add functionality somewhere high up the inheritance chain without having to rebuild the entire cha…

At that same flexibility in monkey patching makes the codebase rubbish in a year when it's time to upgrade dependencies.

Re: Ask HN: Best business advice for software developers

#274

If you allow it, your customers won't always pay you the money they owe. Always assume that if you don't have the money, it may never come, and arrange your life around that possibility. Disclaimer: in my experience small privately held companies do pay consistently and on time. Other kinds of customer, not so much..

Where are your customers based? Delinquency has never been an issue for us. In some 25 years we only had one customer not paying us an invoice of USD 1,500 over accumulated revenues of US 30 million, and it was because the customer went bankrupt the month after the invoice (unlucky). However we noticed that US-based customers may delay payments sometimes for months but in Europe they tend to pay on time.

Silicon Valley typically but also the East Coast, and also the mom and pop individuals we used to provide internet service to locally weren't always great at paying. Note that I don't necessarily mean customers won't pay ever (although that's happened many times to us), but rather they will pay randomly, not according to the agreed payment terms, treating you as a free bank to fund their working capital needs; a way to improve their cash flow position when they're being acquired; and on and on.

Re: Ask HN: Best business advice for software developers

#275

My slogan about startups: > Startups don't create new technology, they create new technology-dependent business models. I wouldn't say this is 100% true, but it is probably 95% true.

That is debatable. If you are going from 0 to 1, a lot of times new technology is created. It may not be something revolutionary and ubiquitous like the internet or the wheel, but it may be some form of vertical integration, such as Tesla Cars or the iPhone.

Re: Ask HN: Best business advice for software developers

#276

Since this is an audience of passionate technologists, here's the top piece of advice I have: Do not be seduced by the technology! I killed one of my startups this way. I've seen many many die this way. It can hurt your pride as a passionate technologist to choose non-cool but mature and easy-to-hire-for tools. But it's those tools that are the most economical. Remember, your customers care 0% about the backend techn…

> You're running a business, not a technological showcase for other engineers (who are not even your customers!).

Unless you are building tools, products, or services for other engineers.

> Build your business for your customers, not for your technological pride or to demonstrate your technical prowess to friends.

I'm going to assume that if someone is going into business for themselves then they are planning on having customers. There are ways to show off that don't put your mortgage and credit rating on the line.

> Remember, your customers care 0% about the backend technologies you're using as long as they are getting the value you promised them.

I'm going to assume, this too, is obvious. What I mean is that anyone who has written a fair amount of software has probably already realized this.

What is it that makes people think programmers are a bunch of navel-gazing narcissists that take great pleasure in impressing other programmers? We do, but we're also rather intelligent people.

I say: be seduced by technology. Programming is beautiful. Hard problems are a joy to solve and bring great value to the world. Do what pleases you. Life is short.

The specific business advice I have is: learn to be a leader. Take responsibility for outcomes, give ownership to your team, and learn to guide people. If your business grows and takes off you might find you won't have much time to program everything and will have to act more like a guiding hand and lead your team in the mission and trust them to take you all there.

My other advice is: avoid intuition and gut-instincts. Use data: analyze commit history, watch your issue manager, track performance indicators just as much as sales and marketing. A business is always shifting and changing. Rely on data to help you identify trends and make effective decisions. A gut decision should be a last resort.

Re: Ask HN: Best business advice for software developers

#277
post #244

Earlier quoted context omitted.

Is Ruby/Rails faster now? I built a few simple sites on Rails 2.3 via Passenger, and my God, it was such a performance hog compared to every other web stack I'd ever used. Probably mostly a function of how heavyweight RoR was, but I never got deep enough to figure out what was so slow about it. It may also have been user error, but it seemed like others were bragging about getting it to levels of performance that wou…

It is. Come a long way since Rails 2. There are still much faster options out there but it's nowhere near the beast that it used to be.

Great to hear, I might revisit it in a future project then - the experience was generally really nice, but the performance was really painful.

Re: Ask HN: Best business advice for software developers

#278

SHIP IT. Even when you are embarrassed about it. Ship it and try to sell your ugly baby. If you can't sell it, ask why and iterate on that. I've seen what happens when you keep the product secret, trying to perfect it before you show it to the world. You'll run out of money making a pretty baby that no one wants.

I agree. I developed a Pinterest-like app around the same year they launched. I even had a perfect domain name for it. Being a perfectionist, I never shipped. I was worried about things like scaling to support tens of thousands of photos, a "similar images" feature, etc. A few years after abandoning the project I discovered Pinterest. ¯\_(ツ)_/¯

sad, but made me laugh

Re: Ask HN: Best business advice for software developers

#279

1) Figure out who you are selling to and what problem you're solving for them BEFORE you build something. It's very easy to fall into a routine of building the best software ever while forgetting you need someone to buy it. 2) Banks will loan you money when you don't need it and won't loan money when you do need it. Apply for a loan or line of credit when you're flush with cash in case of a rainy day. 3) Running a bu…

Excellent points beyond the boiler template on what to do to succeed. This reads like a lot of personal experience in here.

Re: Ask HN: Best business advice for software developers

#280

Earlier quoted context omitted.

> there is nothing special about it. One thing that's especially productive about it that helped to grow the 3rd party ecosystem is that the options you have for dependency injection in Ruby due to monkey patching give you an experience much closer to Aspect Oriented Programming. It also makes it easier when you need to add functionality somewhere high up the inheritance chain without having to rebuild the entire cha…

At that same flexibility in monkey patching makes the codebase rubbish in a year when it's time to upgrade dependencies.

It really depends on the interaction between the discipline of your team and the failure modes of the tool. A culture of code review which puts a high bar of justification and documentation-for-new-contributors on monkey patching can counteract this failure mode.
Post reply on HN