4 ms·

Unfortunately in my experience (founded and built a developer focused SaaS that is profitable) projects or products that are for engineers is a soul and gut wre

Unfortunately in my experience (founded and built a developer focused SaaS that is profitable) projects or products that are for engineers is a soul and gut wrenching market. Developers/engineers are perhaps the worst kind of customers. I am an engineer, but these days I enjoy business, finance, and the process of building a company more than pure technology. Engineers have insanely high standards of products. They expect you to be using the latest and greatest tech and design. If you're running a LAMP stack SaaS, must be crap. They will sit and flame war for hours about tabs vs spaces, syntax, best practices, formatting. Then there is trying to convince an engineer to pay for a product. Besides engineers typically being extremely frugal (I think it stems from the enjoyment of micro optimizing spending and finances), they'd also rather just build that product themselves. After all, what's the point of being an engineer if they can't just build it themself? Great engineers will custom build product and tools for internal use, where great founders will find other products and companies that solve the problem and pay for them.

2017throw 9y ago
Well, everyone enjoys greenfield development and a marketable CV. I'd rather got paid for building e.g. my own (crappy) distributed message queue! So if I am forced to use your stuff it's better be top-notch and using latest tech.
naiveattack 9y ago
This is nonsense. And therefore dangerous if used as some form of inspiration. Great engineers do cost benefit analysis. They solve real problems. Great engineers do not just write code for everything to inflate their own egos. My apologies if I missed some form of too-subtle sarcasm here.
- nodesocket 9y ago
  Honest question, have you ran a business before?
  - 0xffffff77a81g9 9y ago
    I don't know your definition of "ran a business", but maybe my story can fit in it. We started a business five years ago. At the beginning, we were only two guys, but the team have been growing since the last three years. To be honest, this have been a super awful experience, mostly due to give support to clients. Of course, we have had awesome clients, but many of them have been a constant source of stress and frustration. I'm planning to change my job in the near future, and the only thing that I'm sure is that I don't want to repeat this. I'm sorry for the lack of details, but I can't tell much more in a public forum
  - naiveattack 9y ago
    Thanks for engaging honestly with that forward comment. Yes, I have. No, I have not sold to engineers. To add some perspective: Airbrake/Sentry error monitoring; NewRelic monitoring; Pingdom uptime monitoring; Log management Ala Papertrail; Github/Assembla version control; are things that I reach for in the initial set up. I think engineers are/(should be) unwilling to give up on control when it comes to their core business areas. This is why I prefer open source (or at the very least known stable and long lasting) solutions for the data layer and core infrastructure pieces. Or at least compatible managed services; no introducing new layers of abstractions. Also they’re unwilling to pay for things like editors, from ideology and from the market today. I’ve seen the build it ourselves approach, primarily put forward by engineers who do not appreciate the costs of building and maintaining things, and from stakeholders with a vested interest in selling particular services. I would call both a circle jerk kind of situation. To reiterate, in my mind, great engineers would quickly outsource all non core competencies so that they can focus on the more important things. It costs me more to build something, both in terms of time and opportunity, than to have an expert do it for me. Herein lies understanding the problem that you’re trying to solve. To me, intelligent engineering is, cliched as it is, about understanding the tradeoffs, and building the bare minimum that delivers. Keeping in mind that the tradeoff could be about investing in future directions. One example that comes to mind was a data pipeline built using ifttt, dropbox, s3, and spreadsheets for data analysis: brutally simple, probably fragile, but brilliantly done for what was needed in that situation. Engineering is not writing code, engineering is solving problems. From a different angle, from a limited vantage point, I’ve seen companies that sell to engineers struggle because they fail to clearly articulate the value that they bring, and because they introduce too much risk to the rest of the system (What if the vendor disappears, or if I want to migrate to another? Why is there yet another API to learn that also strongly couples with my system?) I am curious about where you are coming from on this. Would you care to get into some specifics?
- draw_down 9y ago
  No, it isn't nonsense. Actually your calling it that is a great example of what it's like to interact with engineers.

2017throw 9y ago

Well, everyone enjoys greenfield development and a marketable CV. I'd rather got paid for building e.g. my own (crappy) distributed message queue! So if I am forced to use your stuff it's better be top-notch and using latest tech.

naiveattack 9y ago

This is nonsense. And therefore dangerous if used as some form of inspiration. Great engineers do cost benefit analysis. They solve real problems. Great engineers do not just write code for everything to inflate their own egos. My apologies if I missed some form of too-subtle sarcasm here.

nodesocket 9y ago
Honest question, have you ran a business before?
- 0xffffff77a81g9 9y ago
  I don't know your definition of "ran a business", but maybe my story can fit in it. We started a business five years ago. At the beginning, we were only two guys, but the team have been growing since the last three years. To be honest, this have been a super awful experience, mostly due to give support to clients. Of course, we have had awesome clients, but many of them have been a constant source of stress and frustration. I'm planning to change my job in the near future, and the only thing that I'm sure is that I don't want to repeat this. I'm sorry for the lack of details, but I can't tell much more in a public forum
- naiveattack 9y ago
  Thanks for engaging honestly with that forward comment. Yes, I have. No, I have not sold to engineers. To add some perspective: Airbrake/Sentry error monitoring; NewRelic monitoring; Pingdom uptime monitoring; Log management Ala Papertrail; Github/Assembla version control; are things that I reach for in the initial set up. I think engineers are/(should be) unwilling to give up on control when it comes to their core business areas. This is why I prefer open source (or at the very least known stable and long lasting) solutions for the data layer and core infrastructure pieces. Or at least compatible managed services; no introducing new layers of abstractions. Also they’re unwilling to pay for things like editors, from ideology and from the market today. I’ve seen the build it ourselves approach, primarily put forward by engineers who do not appreciate the costs of building and maintaining things, and from stakeholders with a vested interest in selling particular services. I would call both a circle jerk kind of situation. To reiterate, in my mind, great engineers would quickly outsource all non core competencies so that they can focus on the more important things. It costs me more to build something, both in terms of time and opportunity, than to have an expert do it for me. Herein lies understanding the problem that you’re trying to solve. To me, intelligent engineering is, cliched as it is, about understanding the tradeoffs, and building the bare minimum that delivers. Keeping in mind that the tradeoff could be about investing in future directions. One example that comes to mind was a data pipeline built using ifttt, dropbox, s3, and spreadsheets for data analysis: brutally simple, probably fragile, but brilliantly done for what was needed in that situation. Engineering is not writing code, engineering is solving problems. From a different angle, from a limited vantage point, I’ve seen companies that sell to engineers struggle because they fail to clearly articulate the value that they bring, and because they introduce too much risk to the rest of the system (What if the vendor disappears, or if I want to migrate to another? Why is there yet another API to learn that also strongly couples with my system?) I am curious about where you are coming from on this. Would you care to get into some specifics?
draw_down 9y ago
No, it isn't nonsense. Actually your calling it that is a great example of what it's like to interact with engineers.