|
ConCongrats! and a lot of of course!
|
|
|
|
|
Happy Birthday and good luck with your new job!
Have a or more.
|
|
|
|
|
Nice. I always like starting a new job. Besides creating new relationships from scratch, you're normally on your toes and ambitious. A very exciting thing, a new job!
|
|
|
|
|
OK, so a birthday equates to: "I'm getting OLD!", and a new job equates to "I wasn't good enough at my last job!", so could you spend a moment to clarify what exactly it is we're supposed to be celebrating?
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
Nope, sorry but it means my last job wasn't good enough for me.
|
|
|
|
|
The first wiords that come to mind are: "Been there, done that".
Good luck with the new people.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
"I wasn't good enough at my last job!" - far from it, new management made decisions that necessitated me working evenings, weekends and holidays because they simply were unable to listen to any advice I gave.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
modified 12-May-16 2:30am.
|
|
|
|
|
I have similar experience.
At my new job I have a boss that's better than me at what I'm doing, a very unusual situation for me. And quite scary to be honest.
|
|
|
|
|
Yes, going from being the expert to being the new guy who knows nothing is quite scary at times.
Good luck with your new job
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
|
|
|
|
|
|
GuyThiebaut wrote: I work to live not live to work.
Good luck with the new gig. I'm sure you'll do well!
/ravi
|
|
|
|
|
Happy birthday and the best of luck with the new job! You deserve it.
Get me coffee and no one gets hurt!
modified 11-May-16 18:57pm.
|
|
|
|
|
congrats & well done
|
|
|
|
|
|
Happy Burp day, have a good start at the new job
Rules for the FOSW ![ ^]
if(this.signature != "")
{
MessageBox.Show("This is my signature: " + Environment.NewLine + signature);
}
else
{
MessageBox.Show("404-Signature not found");
}
|
|
|
|
|
Wish you a very Happy Birthday!! And congrats on your new job!!!
|
|
|
|
|
|
Happy birthday and good luck at your new job.
New version: WinHeist Version 2.2.2 Beta I told my psychiatrist that I was hearing voices in my head. He said you don't have a psychiatrist!
|
|
|
|
|
Congrats!
|
|
|
|
|
Note: I hope this can't be considered a programming question...
When you sell code to the customer which kind of license do you use?
What information do you leave on the code? i.e. programmer, date, company A to company B...
What should be taken into account when doing that?
Any hint?
how you avoid problems/responsibilities when code is changed by the customer?
Thank you all!
|
|
|
|
|
Joan Murt wrote: how you avoid problems/responsibilities when code is changed by the customer?
Have a bullet proof EULA (for what it is worth).
Document your code.
Have working examples and samples that showcase your source code.
Have unit tests for your own source code. (ship them).
Have good technical support.
I'd rather be phishing!
|
|
|
|
|
That depends entirely on the customer.
If they're good people, give them what they need.
If they're @rseholes, be an @rsehole.
If one or the other doesn't come naturally, fake it.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
Development manager here. Seems like you might need to differentiate between 2 different things: selling a packaged product and selling source code.
In my experience purchasing products, buying raw source code is rare. But if done, this is a special situation with different terms that say (in essence), "The client is buying the source code. All maintenance and support are now the client's responsibility." This is typically at a much higher price that if you just licensed it to the client. They want to make a customized version of the functionality OR if you're a small shop, they may want the source code in case you go out of business, esp if it's something critical for their operations.
Usually we see the finished product that is a compiled/built application that has an installer or something like that where you cannot see or get at the source code. (And if you do, please look into a code obfuscation product...)
You are starting to hit on the problem in your question. You mention, "how you avoid problems/responsibilities when code is changed by the customer?" You do that with an agreement from the start. If you provide a product, you license it to them and provide support & updates. If they want the source code, then you have no reasonable way of controlling what is done to it over time, making support almost impossible.
But if you want to do this, you can raise the price for the source code as I mentioned before. You can also sell your support services as a consultant to the client with the understanding that the source code is still their ultimate responsibility.
|
|
|
|
|
If they want the source code in case you go out of business, there are code escrow services available (eg here[^], only an example, no recommendation) - I've no idea how to get the source out if you should go bust, but that could offer them the assurance they need.
|
|
|
|
|
If they just want your source code in case you go out of business, a viable solution is to pay a lawyer to keep your source code, so that it is available if they want to buy it in the future from you (or you heirs). I suggest to charge them for the cost of the lawyer an extra cost for you in the case you have to continue to develop the application, so you periodically have to send a copy of the updated sources to the lawyer. This means that this cost cannot be payed just one time, instead it should be considered as a subscription to a service to keep the source updates always available to the customer.
|
|
|
|