76 karma · joined December 29, 2016
If you are paid like an FTE, As long as your employer is satisfied with your level of productivity, then it really does not matter how long it took you to produce results.
Nevertheless, it's shady to insert bugs into your products. My work is my pride is what matters in the end.
It depends on whether you are interviewing the job or the job is interviewing you :)
Just as anti-trust laws are necessary, there will be drives for measures to encourage and even force companies to put their cash piles to use. Cash is the life of an economy, it needs to flow and flow.
Selecting the right framework, platform, model for current needs with reasonable forward looking support takes experience and strong formal fundamentals.
A well-run company will have proper procedures, processes in place to deal with work place issues.
Management and all staff will also be required to take training on a continuous basis.
Professionally managed organizations don't walk around "believing" this or that or spouting off "innocent until proven guilty" and such
:)
As far as a rabbit in your hand now versus 10 in the bushes provided the hunt goes well, consider your own situation and what the 100K would mean. Would you be able obtain a better ROI with 100K in your own hand versus say, staying with the company? Are you young young or young at heart?
Good luck!
It's just a load you are telling yourself your product is too complicated for anyone else to take over.
If the smarts is just a state machine, and the rules are abstracted at the right level, it would not be that hard to support.
"Thick" smartpoints can save on operating cost (infrastructure, personnel, complexity, level of expertise) when your system is "simple enough"
At massive scale, from an economies of scale (all things considered), it may make better sense to go with "Thin" smart endpoints.
The migration between the 2 models is where the art of the design comes in play :) It's an art because it is a decision process involving many players with conflicting and competing goals, decisions, time frames, motivations etc.
It's often not just a "technical" decision
app|agent <-> ... <-> agent|app
Fundamentally, it is the same problem space.
Does the apple pie taste differently with the pie in the apple vs apple in the pie? Maybe in some cases and maybe not in other cases
Maybe I should have blogged about it :)
Anyway, although all the design principles are the same: 1) Transparent and seamless to application code, 2) Control communication end points, the MQ constructs and languages are not as accessible and readily available and visible as HTTP and RESTful.
A MQ can be temperamental and hard to operate. On the other hand, even middle-schoolers can master nginx, haproxy, write their own, etc with a bit of guidance :)
Popularity and rate of adoption depends on availability to the masses and the ease with which the masses can learn to use. If it takes to long (say, 15 minutes) to bring a framework up, hordes of engineers will find a massive number of reasons to roll their own ...
There is good and there is evil.
One evil act does not absolve another.
Goodness lives forever and evil does not die either
It's a business :)
Designing and building for scalability, flexibility, availability, etc does not mean going all out to boil the ocean and then find that you attempted to boil the wrong ocean.
If that did happen, you got the wrong team :)
It will all come down the the experience of the team, esp. the leadership - the managers, the leads.
A strong, experienced, mature and effective leadeship will enable a team to perform "magic" and set the right technology foundation that will prove its worth as the business grows over time
It does not take more time to design properly from the get go.
That, of course, assumes you have a CTO and a team capable of their job :)
However, let's not make a mountain out of a molehill. The lawyer may be good with the use of the sledgehammer of the laws but they will probably not be good with helping you navigate the "inter personal" ends specific to your situation.
Btw, I have worked contracts larger than 25K without a lawyer and using the client's "master contract". I always review carefully clauses that concern me the most: ownership of IP, payment schedule, breach of contract, termination of contract, damages.
For my own consulting business, we have had disagreement at times (IP, amount upward 100K) but all were sorted out just fine without lawyers involved.
And when I represented Fortune 10/100 company, I have resolved 6-7 digits issues without lawyers just fine. However, when you represent Fortune 10/100 companies, things tend to be easier :)
In your case, try to work "inter personally" to get your 25K or even see if those 25K can translate into "credit/equity" that may give you a "slice" of the liquidation, if any. Talk to a lawyer about this one.
Along this line, you would just be a "tech", not a "scientist" That's not to say you won't be real well compensated.
Data Science as in you are someone able to make sense of the myriads of conflicting data, derive pattern, synthesize bits and bytes into action plans, there is no degree in that :)
As an example on this line of thought, people may win the Nobel prize in Economics even though they may have no idea on how to use Excel :)
Live a wild debauched, taste everything, free for all, no care whatsoever and get a life expectancy of: 80yrs? A somewhat lucky draw could see you beyond 90
Hard choices :)
:)