penguat

Except of course smartphones

It strikes me that this is most likely to be used as part of an exfiltration mechanism for a malicious JS package or similar.

Try reading it as "muggle specs" - specifications which the majority of the population will read.

"INSERT only, no UPDATEs" - sounds like event sourcing?

I don't always run the code in my head exactly - i do something more important, which is consider the set of possible situations the code can be in, and look for problems.

with filter splitters being a thing now, I think they would be, yes.

Which is why best practice is now to start with CI in production - it needs limited access to dev, and the access from development environments into it can be literally just enough to collect the latest artifact.

For your average consumer, this is probably a bad thing.

we ask almost everyone the same thing, which can be resolved to one of the unimaginative but straightforward things above, but is not necessarily obvious at first glance. We fail the people who evidently can't code, not the people who fail to resolve it to the magic answer.

hmmm, about this not having to pay rent - prisoners with partners and children currently can't pay their chunk of the rent, but I bet many would, if they could.

If the patient is a dependent of someone, or a minor, or dies, does someone else pay? Is the consumer the person paying, or the patient?

I don't know if feedback is provided as standard where I work, or only on request - but we do provide meaningful feedback as far as possible.

I suggest that few companies will object to you asking about their timeframe for decisions, or (once that has expired) asking for feedback. Some companies won't be set up to provide it, which is unfortunate, but I suspect many will.

One of the awkward things about people is the more they spend on something the more they value it and the better behaved they are to the creators of it.*

This may be why subscriptions are so expensive - because part of the cost of the subscription is customer support, and the less expensive it is the more customer support costs.

*alternate, complementary theory: the less it costs the more poor people have it where they have to do more financial juggling and get into weirder situations. Thoughts, HN?

at which point you're into extrapolation, I wonder how accurate it could be. I'd guess good enough for most situations.

You have invested your time in some ways; others have invested theirs in other ways.

Lazy is a very loaded term - I'm hesitant to subscribe to the notion that keeping up with Game of Thrones is any less an investment of time. As examples of the value of such an investment, you can then discuss it with your friends and coworkers, facilitating social cohesion and acceptance. You can use it a tool to encourage you to take a step back, and look at other things you are doing from a different perspective.

Sleep is another investment, the value of which has been much-discussed here and elsewhere. I'd encourage you to invest in it.

Perhaps your investments have been commercially focused - this is no bad thing. You will have learned directly about the work you have been doing, people's behaviour around you and yourself. You have learned some of what you are capable of - working so hard in impressive in itself, this is a capability you can understand and rely on later! You will have gained a reputation with some of the people you have been working with. If you are still on good terms with any of them, you can use this to better understand yourself, and you can seek recommendations from them.

That said, not all investments work out. I'm sorry your investment has not brought you what you expected.

Please try to focus on what you have learned and gained, and keep actively choosing your investments. You're almost certainly doing fine, and if not, please ask for help.

Case a: you're expecting to do ongoing business, do well, and both benefit. wrangling contract is not good for you, beyond a basic level. Make sure you're on the same page, and hooray.

Case b: This is a one-time deal, they have no reason to care. be more careful.

I am in no way an expert, but looking at the incentives the other side of the negotiating table is surely more important (and way cheaper and quicker) than lawyering up a contract?

They need to maintain their customers' perception, which is not so much about trying as actually having an effect...

Where I work it is standard policy to send meaningful feedback after a face-to-face interview. We actively work to make this helpful.

And it needn't look like eval: http://www.jsfuck.com

Who said anything about including the word "eval"? Javascript is really rather bad for allowing surprising things: eval is possible in just 6 innocuous-looking characters - see http://www.jsfuck.com

Pair programming neatly sidesteps a number of problems, when done well. For a team, it helps to spread knowledge among the team, encourages people to follow the team discipline, gives a second pair of eyes on any bugs and gets people up and running faster.

done well is the tricky bit. You need people who get on ok with it, social skills need to be developed, and you need discipline around not committing code which hasn't at least been reviewed. Social skills is the hardest part IME: knowing you can ask for a break, some time to think, or to split for some research before resuming work as a pair.

Often this means providing an abstraction which won't break for most users. sadly, such abstractions are often like a duck - paddling madly under the water.

I use my second slot for JPG, reasoning that I can get good enough results out of a JPG if I desperately need it - and the cheaper, slower, bigger card I put in the backup slot will hold a couple of days' shooting as JPG and not slow the camera down.

The answers already here address the direct effect in terms of company costs - there are fixed costs of an employee as well as variable costs.

I am more interested in what it does to your typical team in your something-like-typical corporate environment: I think it would tank team productivity. Instead of programmers getting up to maybe 6 hours' writing software done, programmers would get significantly less time doing that. And we would all hate it.

This effect would happen because a) there are interruptions, and communications overheads to being part of a team; and b) because you need a bigger team to cover the reduced productivity, all of your things that scale poorly with the size of a team mean you need an even bigger team, with each person therefore doing less development.

I think companies which are smart about this whole building software thing are more interested in teams and their capabilities than individuals and their capabilities, and I think many of those would look at this in the same way as I just did.

but I do see my nose - in serious double vision, and way out of focus, but I do see it.

or "It's what I have on my office computer and I don't get admin rights"

I believe it is an array of sensors operating at different focal points, presumably with depth-of-field set such that it will overlap slightly. From that data, you can indeed construct something that looks a lot like an actual light field.

The big limitations are probably on photons coming in at one end, and data going out at the other end - in the middle, I'd believe it does something so close to what it claims that you won't notice the difference.

One of the things that people aim for in writing tests is orthogonality - different tests should not break for the same reason. This promotes the ability to refactor and change your code. I have also seen massive codebases, with masses of tests which were rarely run, and which effectively concreted the code and stopped it from changing.

It's more likely that it is kept secret to reduce potential liability and to maintain competitive advantage.

Have you been through some sort of responsible disclosure? I don't know enough to tell if this is an immediately usable vulnerability.