Ask HN: Starting same business of the company I left?
5 comments
I assume the business service being offered has value to clients? I gave up hope long ago of ever finding a company where they were both profitable and the engineering decisions made over time were correct and the code wasn't a mess and...
I eventually concluded that it's better to be like Facebook or Slack: and idea that works despite having been built on PHP and MySQL and then hire the experts needed to mitigate the issues that come with having built on PHP and MySQL than to spend an inordinate amount of time building a technically perfect product that lacks business value.
I eventually concluded that it's better to be like Facebook or Slack: and idea that works despite having been built on PHP and MySQL and then hire the experts needed to mitigate the issues that come with having built on PHP and MySQL than to spend an inordinate amount of time building a technically perfect product that lacks business value.
Nothing immoral... but can you really do better? Is it a good business to be in? Most stuff degenerates to duct tape for a reason: complexity, lack of resources (money, time, people...), higher priorities, etc. And most customers don't care, as long as it works. So if you build a better mouse trap, will anyone care?
> Most stuff degenerates to duct tape
Sure, but here the point was exactly that could literally do what they wanted. It didn't and it shouldn't had gone that way with the resources they had.
> So if you build a better mouse trap, will anyone care?
Potentially I think it could, given that the customers were raging and pissed off and the fact that it was unstable.
In the end, I am actually thinking about doing it even just for myself, to follow a project from scratch, and if it turns into something good, otherwise, still experience.
Sure, but here the point was exactly that could literally do what they wanted. It didn't and it shouldn't had gone that way with the resources they had.
> So if you build a better mouse trap, will anyone care?
Potentially I think it could, given that the customers were raging and pissed off and the fact that it was unstable.
In the end, I am actually thinking about doing it even just for myself, to follow a project from scratch, and if it turns into something good, otherwise, still experience.
I think this happens a lot. Did you sign a non compete? Some companies make you sign that for around 1 year.
My take on non-competes.
You might be lucky and they didn't make you sign one.
If not, then you have to look at any possible commercial dispute like so. There are really four possibilities, based on the binary outcomes of
A. Company A hits it big, and
B. Company B hits it big
even though it is a touch more complex than that. A lawsuit is expensive and isn't worth pursuing unless there is money to fund it and an expectation of a monetary outcome.
If A and B both fail there is no risk. If B succeeds then at least you succeeded at B. Getting involved in some situation like Zuckerberg vs. the Zwinkelvoss Clone would be great. Possibly you share some with A. A could shut you down and might do so if A was bigger than B, but if B got bigger than A, they have no reason to kill the golden goose.
If you fail on your own then you would have failed anyway. The legal risk is real but the impact should be discounted by concerns like the above.
I cannot fault the engineer who walks out of a company with an understanding of how NOT to build a system. Don't walk out of there with any artifacts (other than other people's open source software) that could possibly help you build a system that is competitive because that gets you into trade secret law, copyright law and means you can be accused of crimes that are easy to prosecute someone one.
If you have contact with their customers, that opens another range for a perception of personal betrayal. This could happen to an engineer but could also be done by a salesperson, customer support person, etc.
People who are afraid of a commercial dispute of this sort (either imminently or over the next decade) should also file a provisional patent application (PPA) with the USPTO which has the latest knowledge you have that the other parties does not have.
It is two weeks of work and a less than $200 filing charge and it starts the clock for patent protection, you do not need a lawyer. I've put marketing papers, etc. samples of source code, architecture documents, that are oriented around technology necessary for solving the problems you claim to solve in the marketing papers.
If you have a dispute with someone, the PPA is an awesomely intimidating legal document -- no matter if you are the employee, employer, vendor, customer, etc.
You might be lucky and they didn't make you sign one.
If not, then you have to look at any possible commercial dispute like so. There are really four possibilities, based on the binary outcomes of
A. Company A hits it big, and
B. Company B hits it big
even though it is a touch more complex than that. A lawsuit is expensive and isn't worth pursuing unless there is money to fund it and an expectation of a monetary outcome.
If A and B both fail there is no risk. If B succeeds then at least you succeeded at B. Getting involved in some situation like Zuckerberg vs. the Zwinkelvoss Clone would be great. Possibly you share some with A. A could shut you down and might do so if A was bigger than B, but if B got bigger than A, they have no reason to kill the golden goose.
If you fail on your own then you would have failed anyway. The legal risk is real but the impact should be discounted by concerns like the above.
I cannot fault the engineer who walks out of a company with an understanding of how NOT to build a system. Don't walk out of there with any artifacts (other than other people's open source software) that could possibly help you build a system that is competitive because that gets you into trade secret law, copyright law and means you can be accused of crimes that are easy to prosecute someone one.
If you have contact with their customers, that opens another range for a perception of personal betrayal. This could happen to an engineer but could also be done by a salesperson, customer support person, etc.
People who are afraid of a commercial dispute of this sort (either imminently or over the next decade) should also file a provisional patent application (PPA) with the USPTO which has the latest knowledge you have that the other parties does not have.
It is two weeks of work and a less than $200 filing charge and it starts the clock for patent protection, you do not need a lawyer. I've put marketing papers, etc. samples of source code, architecture documents, that are oriented around technology necessary for solving the problems you claim to solve in the marketing papers.
If you have a dispute with someone, the PPA is an awesomely intimidating legal document -- no matter if you are the employee, employer, vendor, customer, etc.
The story behind the question, if you are interested:
I worked for 2 years for a small company (25 people), in a small team (4/5 people, all pretty young, 27/33). Basically fresh from college, I was hired as a backend engineer to re-do the backend services (DB, APIs). Lots of decisions were already taken when I joined.
These decisions were not great: a lot of architectural choices were done with no rational behind, just by feeling. DB was a mess, no triggers, inconsistent data, zero to null security, and so on. Application layer even worse.
What's worse is that the dev team was given ALL THE TIME AND SUPPORT from the management to redo everything from scratch, but still made a mess, eg, again, de-normalizing the DB without knowing if it would really be a performance plus, but just because "I feel it would be".
I don't claim to be the best, but I think that as engineers we should at least try to take decisions based on real things, and not "by feeling" (which I could accept from someone with a lot of experience and recognized in a field).
I learned a lot, but lots of things I wanted to do, implement and improve did not get approved. So, at some point my I had enough and left, because I saw that the only things we were doing was trying to fix the mess that was done, and I didn't want to go on with that when clearly the whole codebase was so messy that the only solution would be to start over with a real and well defined plan.
The service now works somehow (with "duct tape", as we say) -although there are lots of complaints from customers- so management now is kindof ok with that (because they spend money and time in the redo, so don't want to do that again), although they know its shitty (once again).