Just a bit of input from a former PM turned developer, and consider that we don't REALLY have much info to go on from what you've said, but your 4th and 6th paragraphs lead me to this concept.
You may be right that you created the correct technical solution, but not every consideration should be a technical one. From a business perspective there are MANY other considerations.
You created an 'unconventional solution'. That may be a problem for many businesses, and rightly so. If they were to bring other devs in, what is the lead time needed for a dev familiar with the companies systems to be able to update the system you created. There is a cost involved in that. If the solution you came up with is non-core to the business, that is possibly more problematic, as they are dedicating extra time to a non-essential system simply because it was written differently from the way the company normally does things.
Much of it could be simply a personality issue, and possibly with the PM, not you. You clearly care about your performance and capabilities, so I'd sit down and have an honest discussion with the PM or CEO about what you're trying to accomplish, and make sure that everything you are doing is for them, and make sure they understand that.
In the end, you're developing FOR THEM. I think a few developers could be happier if they realized their job isn't to create the most technically correct/superior code, but to make the business owner happy.
The way I think you make them happy is to give them what they want. If they ask for A and you give them G, that isn't what they wanted. But MY SOLUTION IS BETTER you say. Great, but you still need to satisfy the employer, and the best way to do that, and make them want to keep you around, is to make them want G.
I think if you go in with this perspective, and sell them not only on the code you create, but also on your understanding of their business, and ability to make good platform decisions for the business, they'll look at you quite differently.
Unfortunately I had to cut it down to 2K character so might have missed enough information to be useful.
The NoSQL thing was a total failure on my part, yes it was a really cool idea but I was dealing with vague requirements ( and didn't qualify like I should have).
Trying to explain myself has been fairly useful as it's brought up questions I didn't ask, like why didn't the PM's tell me their complaints up front instead of waiting until the CEO had to get involved. In retrospect that's actually kind of upsetting.
Also three rules as a contractor/freelancer I try to abide by:
#1 Always make your client more money then you cost
#2 It doesn't matter right/wrong if the client isn't happy ( unless they're crazy )
#3 Ignore #2 if it threatens rule #1 by managing expectations ( try to avoid using the word no ).
Last things, long time ago I was on a team that made our own web framework ( routing, MVC, ORM, etc ) and while it worked, it was a failure because of a lack of referential integrity, high cost to spool up new dev's, and lack of an external community support. Since then I try to avoid building my personal space shuttle ( really complex/cool stuff ) for paid work.
I think the reason I am still with the company is that they're in a badlands between small one off projects and more long term/perpetual projects which I've excelled at ( and they're still adapting too ) and I am wondering if the CEO realized that the PM's didn't convey an of their concerns to me before going to him.
So it looks like I need to have some more conversations with the PM's themselves ( I can turn on a dime if given constructive feedback).
1. Make the customer happy
2. Deliver in the fastest, cheapest way possible.
3. if you come to a dificult decision or a better way layout options, pros and cons and let them make the decision.
4. CYA, do it in writing.
5. if you come across a problem that's going to delay delivery let them know as soon as possible.
Comments
Just a bit of input from a former PM turned developer, and consider that we don't REALLY have much info to go on from what you've said, but your 4th and 6th paragraphs lead me to this concept.
You may be right that you created the correct technical solution, but not every consideration should be a technical one. From a business perspective there are MANY other considerations. You created an 'unconventional solution'. That may be a problem for many businesses, and rightly so. If they were to bring other devs in, what is the lead time needed for a dev familiar with the companies systems to be able to update the system you created. There is a cost involved in that. If the solution you came up with is non-core to the business, that is possibly more problematic, as they are dedicating extra time to a non-essential system simply because it was written differently from the way the company normally does things.
Much of it could be simply a personality issue, and possibly with the PM, not you. You clearly care about your performance and capabilities, so I'd sit down and have an honest discussion with the PM or CEO about what you're trying to accomplish, and make sure that everything you are doing is for them, and make sure they understand that.
In the end, you're developing FOR THEM. I think a few developers could be happier if they realized their job isn't to create the most technically correct/superior code, but to make the business owner happy.
The way I think you make them happy is to give them what they want. If they ask for A and you give them G, that isn't what they wanted. But MY SOLUTION IS BETTER you say. Great, but you still need to satisfy the employer, and the best way to do that, and make them want to keep you around, is to make them want G. I think if you go in with this perspective, and sell them not only on the code you create, but also on your understanding of their business, and ability to make good platform decisions for the business, they'll look at you quite differently.
Hope that helps.
Unfortunately I had to cut it down to 2K character so might have missed enough information to be useful.
The NoSQL thing was a total failure on my part, yes it was a really cool idea but I was dealing with vague requirements ( and didn't qualify like I should have).
Trying to explain myself has been fairly useful as it's brought up questions I didn't ask, like why didn't the PM's tell me their complaints up front instead of waiting until the CEO had to get involved. In retrospect that's actually kind of upsetting.
Also three rules as a contractor/freelancer I try to abide by:
#1 Always make your client more money then you cost
#2 It doesn't matter right/wrong if the client isn't happy ( unless they're crazy )
#3 Ignore #2 if it threatens rule #1 by managing expectations ( try to avoid using the word no ).
Last things, long time ago I was on a team that made our own web framework ( routing, MVC, ORM, etc ) and while it worked, it was a failure because of a lack of referential integrity, high cost to spool up new dev's, and lack of an external community support. Since then I try to avoid building my personal space shuttle ( really complex/cool stuff ) for paid work.
I think the reason I am still with the company is that they're in a badlands between small one off projects and more long term/perpetual projects which I've excelled at ( and they're still adapting too ) and I am wondering if the CEO realized that the PM's didn't convey an of their concerns to me before going to him.
So it looks like I need to have some more conversations with the PM's themselves ( I can turn on a dime if given constructive feedback).
Here are my contractor/freelancer rules:
1. Make the customer happy 2. Deliver in the fastest, cheapest way possible. 3. if you come to a dificult decision or a better way layout options, pros and cons and let them make the decision. 4. CYA, do it in writing. 5. if you come across a problem that's going to delay delivery let them know as soon as possible.
You've got the right attitude, and I think that is going to bode well for you. It didn't really come across in your original post.
Best of luck.