A thread on HN about bad code in legacy projects both makes me think how little we've learned as a discipline over the years and, honestly, how little credit we give ourselves for some pretty major

Fun going down this list and thinking: "Hmm, plausible at a well-run modern software shop", "Hmm, possible, but requires implausible tradeoffs", "Literally disallowed by languages", and "If you were to attempt doing that our test suite wouldn't let you merge."
I think we as an industry celebrate (not quite the right word) failure too much and don't celebrate success nearly enough. There is no DailyWTF for competent execution, word of which generally stays pretty local to the source while incompetence passes into legend.
Alrighty let me try to thread the needle on being the change I want to see in the world while not giving away anything that will get me in trouble:
Ruby has wonderful developer ergonomics. Typed languages are easier for machines to guarantee the correctness of. We built a type checker for Ruby (and I believe it is slated for OSS release sometime).

c.f. https://t.co/S5XIDxFUrH
We have an infrastructure at work which allows one to specify an invariant about not just code but e.g. objects or the environment and then have a range of response options if that invariant changes.

(Parallel evolution of code: I wrote a less-well-specified one at last gig.)
Git, continuous integration, and workflow-driven mandatory code reviews are all younger that the Joel Test, at least insofar as them being common features of median-sophistication engineering shops.
It is not astonishing to start a new engineering job in 2018 and have a developer environment which reasonably approximates the production environment available on one's laptop or tested, repeatable ways to spin up and spin down a new server w/o "build it by hand."
It is highly likely that a service which is hard down learns of that fact faster than Twitter can apprise them of it, assuming that service is operated in a professional fashion.

At risk of stating the obvious: this is a relatively novel development.
The industry has decisively adopted:

* a single, common encoding for almost all human languages
* a single, parseable, human-readable data interchange format
* a default protocol for information transport
You can round to "Any new application talking to any application written by a competent team in last 10 years will be talking to it over an encrypted link which neither side had to think deeply about because the technology is reliable, ubiquitous, and uncontroversially legal."
While it's not literally the case that you could replicate an entire modern software company's deployment for zero dollars in software licenses, that can almost round to true, due to the pervasive use of OSS.

This is very good for learners.
You can get a full development environment capable of doing Hello World spun up in your well-supported language of choice in, almost certainly, less than ten minutes of effort (contingent on you using a Mac, sadly).
The majority case for libraries, APIs, and file formats of interest to you will overwhelmingly be "If you Google the thing you want you get exactly what you need very, very quickly."

More from Patrick McKenzie

So the cryptocurrency industry has basically two products, one which is relatively benign and doesn't have product market fit, and one which is malignant and does. The industry has a weird superposition of understanding this fact and (strategically?) not understanding it.


The benign product is sovereign programmable money, which is historically a niche interest of folks with a relatively clustered set of beliefs about the state, the literary merit of Snow Crash, and the utility of gold to the modern economy.

This product has narrow appeal and, accordingly, is worth about as much as everything else on a 486 sitting in someone's basement is worth.

The other product is investment scams, which have approximately the best product market fit of anything produced by humans. In no age, in no country, in no city, at no level of sophistication do people consistently say "Actually I would prefer not to get money for nothing."

This product needs the exchanges like they need oxygen, because the value of it is directly tied to having payment rails to move real currency into the ecosystem and some jurisdictional and regulatory legerdemain to stay one step ahead of the banhammer.

More from Tech

(1) Some haters of #Cardano are not only bag holders but also imperative developers.

If you are an imperative programmers you know that Plutus is not the most intuitive -> (https://t.co/m3fzq7rJYb)

It is, however, intuitive for people with IT financial background, e.g. banks

(2)

IELE + k framework will be a real game changer because there will be DSLs (Domain Specific Languages) in any programming language supported by K framework. The only issue is that we need to wait for all this

(3) Good news is that the moment we get IELE integrated into Cardano, we get some popular langs. To my knowledge we should get from day one: Solidity and Rust, maybe others as well?

List of langs:
https://t.co/0uj1eBfrYj, some commits from many years ago..

@rv_inc ?

#Cardano

(a) Last but not least, marketing to people with Haskell, functional programming with experience and decision makers in banks is a tricky one, how do you market but not tell them you want to replace them. In the end one strategy is to pitch new markets, e.g. developing world

(b) As banks realize what is happening they maybe more inclined to join - not because they would like to but because they will have to - in such cases some development talent maybe re-routed to Plutus / Cardano / Algorand / Tezos

You May Also Like

"I really want to break into Product Management"

make products.

"If only someone would tell me how I can get a startup to notice me."

Make Products.

"I guess it's impossible and I'll never break into the industry."

MAKE PRODUCTS.

Courtesy of @edbrisson's wonderful thread on breaking into comics –
https://t.co/TgNblNSCBj – here is why the same applies to Product Management, too.


There is no better way of learning the craft of product, or proving your potential to employers, than just doing it.

You do not need anybody's permission. We don't have diplomas, nor doctorates. We can barely agree on a single standard of what a Product Manager is supposed to do.

But – there is at least one blindingly obvious industry consensus – a Product Manager makes Products.

And they don't need to be kept at the exact right temperature, given endless resource, or carefully protected in order to do this.

They find their own way.
12 TRADING SETUPS which experts are using.

These setups I found from the following 4 accounts:

1. @Pathik_Trader
2. @sourabhsiso19
3. @ITRADE191
4. @DillikiBiili

Share for the benefit of everyone.

Here are the setups from @Pathik_Trader Sir first.

1. Open Drive (Intraday Setup explained)


Bactesting results of Open Drive


2. Two Price Action setups to get good long side trade for intraday.

1. PDC Acts as Support
2. PDH Acts as


Example of PDC/PDH Setup given