venture_lol

If you are paid according to time and material, you could be sailing in bad legal waters. Ask an attorney about fraudulent billing.

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.

If the candidate starts by drawing 2 lines, then marking start and end on the lines, you know you would be off to having a good chat

I would try to keep the audience and context in mind and answer accordingly.

It depends on whether you are interviewing the job or the job is interviewing you :)

Staff your team with people who are articulate and resourceful. Then, relax :)

When companies hoard profits, they really serve no purpose and no-one but to perpetuate their control and to reduce and eliminate the ability of others to compete. The massive access to capital is akin to a super power. Well, superpower can be used by for better or for worse.

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.

It's way too easy for anyone to pick up Node and CRUD a few pieces of data into a NOSQL store and voila, I am an architect :)

Selecting the right framework, platform, model for current needs with reasonable forward looking support takes experience and strong formal fundamentals.

General observations from experience:

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

:)

You need hard numbers and intelligence available to only you. Once you have the data, talk to people you trust, then make a decision. If you hold 5%, you have rights, rights to information. Obtain the information, then decide.

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!

Rough words, but yeah, definitely better to cry in rolls royce that hunting food stamps in a corolla

Friendliest advice: promote someone NOW! or hire someone -- NOW!

It's just a load you are telling yourself your product is too complicated for anyone else to take over.

Possibly. However, tooling and code generation can help.

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 <-> hub <-> agent <-> app OR app <-> agent <-> agent <-> app OR

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

I architected and built a system based on MQ a number of years ago. The very same design / implementation went from supporting 0 messages to a billion messages a day quietly and silently with full message tracing, retries, multi language support, etc.

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 are good people and bad people. There are monsters and humans even if monsters may have human shape and form.

There is good and there is evil.

One evil act does not absolve another.

Goodness lives forever and evil does not die either