Just try it: how successful and glamorous does your rich banker friend seem when you describe him as an obtainer, rather than as a creator of wealth?
360 karma · joined June 5, 2009
Just try it: how successful and glamorous does your rich banker friend seem when you describe him as an obtainer, rather than as a creator of wealth?
Suppose there are two companies with the same business model, operating in the same countries etc. One files taxes "fairly" and one minimizes its tax burden as far as the law will allow. Which one do you think is going to be in business for longer? Which one would you buy shares in?
You can get as angry as you like at the companies, or the legislators, but in the end it's the system you need to be scrutinizing.
Another thought- it's possible that your supervisor's manager is aware of the action being taken against you. You might be able to get better advice talking to someone in a different reporting chain if you can find them.
I'd have gladly paid for someone to take that pain away. There's probably a viable business model in there somewhere if someone can independently put a competent customer service layer in front of companies like ATT.
Reading the comments here it seems that there is a massive gap in understanding, empathy and plain old data - are there no studies answering the questions being speculated on here?
If you could find a way to address that gap of understanding - provide the technologists with data, and fully describe the constraints - perhaps there can be a useful discussion in the technology community.
It's arguable that the 'unplanned' part is not a necessary feature of a currency. In fact, no fiat currency in circulation today has survived without a significant amount of planning.
In contrast, the planning which went into Bitcoin seems to have made it closely fit the theory's description of money. Arguing that its planned nature negates its 'moneyhood' (to coin a phrase... sorry...) seems a little like arguing that an artificial organ won't work due to not having been grown within the host, or that a genetically engineered organism will fail due to not having gone through an evolutionary process.
The curious thing about the world's most talented Houdini programmers is that they don't consider themselves programmers at all; their job titles normally include the term 'artist'. I've worked with people who wrote whole procedural simulations, image processing algorithms and shaders, who swore that they could not do programming.
As a seasoned coder by the time I first encountered Houdini, it took me months to get my head around it. It took me days to put together systems artists were able to build in hours. The lesson was: my knowledge of text-based, imperative programming was not directly transferrable to the node-based, procedural world.
Therefore, don't trust the judgement of a text-based programmer who declares that the tools of a visual programmer suck - it's not just a different dialect or different language, but a different medium entirely. And, effective visual programming systems are out there, but they don't have 'programming' written on them, because 'programmers' are not the target market.
So this has been a long-time coming, and while the quality of Pixar's implementation is undoubtedly welcome, the main advantage to studios is relaxation of the patent requirement - something Pixar should have done years ago, since all anybody wanted to do with those patents was better utilize the tools they had licensed from Pixar in the first place.
I have fond memories of my first years in the VFX industry being made a fool of by non-programmer effects artists who, by hooking together a few nodes in the industry-standard package Houdini, could in minutes recreate algorithms that took weeks for me to code the 'right' way, and in a couple more minutes interactively tweak the constants to get results which I would have taken even more weeks to derive 'scientifically'. It was a crash-course in the value of rapid-prototyping, but also in that particular case introduced me to new ways of thinking: Houdini presents a completely different view of geometry and image processing, which is thoroughly non-intuitive to the typical comp-sci graduate. Houdini taught me an (almost literally) orthogonal way of thinking about computer graphics problems.
The lessons are more general: - rapid prototyping is not necessarily coding - sometimes the non-technical, 'designer' approach is the more efficient one (not necessarily in this case - there is plenty of merit in both approaches) - the more tools you learn, the more leverage you have - why not learn some of those design tools and learn a different way of thinking about things.
(This comment is inspired-by, not directed-at, the two dice portrait posts.)
I'm not going to ask how to write good code, but I think this is a fair question: can someone point to a coding standard / style guideline for Javascript + jQuery?
E.g., when to choose a single-use named function over an anonymous function? When to bind jQuery results to variables vs. go crazy with chaining? Any advice on good selector practices? Good html naming conventions?
I'd love to see all that stuff documented in one place. It must be out there somewhere.