Despite Bitcoin's Dive, a Former Soviet Republic Is Still Betting Big on It - <AUTHOR> https://www.nytimes.com/2019/01/22/business/georgia-bitcoin-blockchain-bitfury.html <comment><USER3> I clicked on the link thinking. "Oh, some country is using Bitcoin as a reserve currency. That could be interesting."

But no. Georgia is allowing an American company mine Bitcoin at scale. It uses a lot of power and a lot of infrastructure. But isn't a huge bet or anything interesting.

<comment><USER4> I'd love to see a government experiment with having its central bank issue a dollar-backed stablecoin.

I mean, fundamentally the issue is that the rise in digital payments puts most of the money supply in bank ledgers... if the money supply was on a public ledger, individuals could still deposit it with a bank, but they could also send it peer-to-peer if they so chose.

<comment><USER5> The loss of privacy in this case may not be worth using a public ledger.

In general though, I think it would be an interesting experiment if individuals can hold central bank money directly instead of going through commercial banks.

<comment><USER4> I think there are plenty of ways that privacy could be regained... layer 1 settlements, use of an anonymous protocol like MimbleWimble, etc. It wouldn't necessarily need to be Bitcoin as it's implemented today.

But I agree... that experiment would be quite fascinating. It might not even be that big of a change... most people would probably continue to entrust a bank with their funds, and banks could potentially continue to operate a fractional reserve system.

</comment></comment></comment></comment><comment><USER6> > Georgia provided land and cheap electricity so Bitfury, an American company, > could set up a Bitcoin mining center in Tbilisi.

I hope they realize the digital currency doesn't necessarily "stay" in Georgia. Either way, the prime minister provided a loan out of his own investment fund, and it's been paid back. Not sure they are betting big on crypto, but they are using 10% of their electricity for it...

<comment><USER7> >The governing Georgian Dream party sold 45 acres for $1 for Bitfury to set up shop.

yes this looks like textbook corruption: the government just "gives" land and energy to cryptocurrenncy mining operations? seems very probably that not the government but those in government who set it up are getting crypto bribes in return...

<comment><USER8> Happened all over the US last year. Lots of cities around me gave tax breaks and land to bring in "hundreds of tech jobs"... what we actually got was 12 jobs and jet engines cooling the servers stuffed in old buildings to the locals annoyance.

There was money to be made in crypto. But not by buying coin low and selling high.

<comment><USER7> wow, I didn't know this was happening in US as well, are there any articles on the subject you can recommend?

<comment><USER9> See this N.Y. Times article focusing on Plattsburgh, NY: [https://www.nytimes.com/2018/09/19/nyregion/bitcoin- mining-n...](https://www.nytimes.com/2018/09/19/nyregion/bitcoin-mining-new- york-electricity.html)

<comment><USER7> thats sad on so many levels of course, but least comprehensible at all is:

>With electricity so cheap that most residents use it to heat their homes, the city's consumption exceeded its allocation on several days, Mr. Read explained. As a result, the Municipal Lighting Department had to purchase additional power at much higher prices — a cost it spread across its customers.

The machines are generating heat (and cryptocurrency) from electricity the locals were using to generate heat... At least they could have co-located the machines with the locals in a way that heat can be exchanged with inside and outside, and a meter measuring energy consumption when heat is directed inside...

The least wasteful form of mining is by replacing electric heaters with mining rigs, but that's not what happened here, it's more like going to the library to fetch some books because you ran out of toilet paper...

thanks for sharing the article

there's lots of similarities in this article with the Georgia one: besides the local economic depression, in both articles they also mention the local prison and the local casino...

<comment><USER7> it's really a shame they're not even trying to be creative:

for example why not use the heat to pasteurize milk? co-locate the miners with the pasteurization plants

even better: desalinate water to steam, use the steam to heat the milk and the milk to cool the steam, now you have desalinated water AND pasteurized milk...

but oh no, that would actually create a job for a couple of people to work it out and change the plants and negotiate and discover similar opportunities...

</comment></comment></comment></comment></comment></comment></comment><comment><USER10> Dived since the last year, but price has been stagnant within 3000 - <USER2> range for the few couple of months

<comment><USER11> The last big dive from ~6500 occurred mid-November. That might be old news by cryptocurrency standards but 2 months isn't a whole lot of time.

<comment><USER12> Big money is now involved so expect the next climb to happen quickly and the next crash to be in quickier.

</comment></comment></comment><comment><USER13> Without knowing the absolute production capacity and utilization pre-Bitcoin / post-Bitcoin; that 10% isn't a very useful metric.

If Bitcoin is using locally underutilized electricity, I don't see anything wrong with this adventure.

</comment><comment><USER14> I have some friends who started working on interesting projects in the crypto space after Bitcoin 'died'. It seems to me there is still some potential for innovation in this area, as evidenced by the market sizing. Just need to cut some of the ICO/marketing cruft away and be realistic about its usecases.

</comment><comment><USER15> Nice touch on referring to Georgia as a "former Soviet Republic". The article must have then described Bitfury as a company from a former British colony :)

<comment><USER16> Referring to Georgia as a "former Soviet Republic" is similar in tone to calling Ukraine "a historic part of Russia".

There _were_ both what they've been called, sure, but given the current state of relationship between Russia and any of the two countries, it's like looking for trouble.

EDIT: what?

<comment><USER17> Ukraine __is __a historic part of Russia though. It never was a country on its own until 1992. And I say this as someone with Ukrainian heritage. My ancestors never immigrated from a country called Ukraine even though they were Ukrainian (or back then often called Ruthenian). It 's just historic facts.

<comment><USER16> > It never was a country on its own until 1992

That's beside the point. Right now, there's a growing nationalist sentiment growing in Ukraine. If you go to Ukraine and shout this historical fact in the streets of, say, Kiyv, you might just encounter a group of people who violently disagree with the "underlying idea" (which you won't express, but they'll perceive) that Ukraine is Russia's bitch.

Imagine shouting about the Armenian genocide in Instanbul, or about the extermination and oppression of Native Americans in a major city in Texas.

Maybe not exactly, but you get the idea.

> My ancestors never immigrated from a country called Ukraine even though they > were Ukrainian (or back then often called Ruthenian)

That kind of Ruthenian? [[https://en.wikipedia.org/wiki/Kingdom_of_Galicia%E2%80%93Vol...](https://en.wikipedia.org/wiki/Kingdom_of_Galicia%E2%80%93Volhynia)]

Or that kind of Ruthenian? [[https://en.wikipedia.org/wiki/Ruthenians_and_Ukrainians_in_C...](https://en.wikipedia.org/wiki/Ruthenians_and_Ukrainians_in_Czechoslovakia_\(1918%E2%80%931938\))]

Your ancestry might as well be "Polish with a mix of Lithuanian", 'cause who knows at this stage, no? Did you take a DNA test?

<comment><USER17> > Right now, there's a growing nationalist sentiment growing in Ukraine

Yes there is, but Ukrainian Neo-Nazis aren't exactly known for their understanding of history.

> Imagine shouting about the Armenian genocide in Instanbul, or about the > extermination and oppression of Native Americans in a major city in Texas.

Except Ukrainians and Russians are the same people, and it's Germans and others who slaughtered them.

> Your ancestry might as well be "Polish with a mix of Lithuanian", 'cause who > knows at this stage, no? Did you take a DNA test?

Maybe, it's a region that's had many conquests and we're all mixed to some degree. But my ancestors all spoke Ukrainian and were Orthodox, and Slavic culture has always been defined by culture, not necessarily ethnicity.

<comment><USER16> > Except Ukrainians and Russians are the same people

I don't think that's for either of us to declare.

I'm at least quarter-Ukrainian from my father's side (I think my parental grandfather was Russian, but parental grandmother was certainly Ukrainian). You sound like you have much less than that in you. We're in no position to dictate who's one people and who aren't.

I do consider Ukrainians and Belarussians brotherly peoples, from my view as a Russian. I wish either of them no harm, and all the best, and hope that no major conflict arises between either of the three.

But they're going to be the ones to tell me what nation they are and what other traits they identify themselves with.

> and Slavic culture has always been defined by culture, not necessarily > ethnicity.

I don't think Slavic culture – if there is, indeed, such a thing – defines itself _with itself_. It can't be its own description, see?

Aside from that... Don't you think there's this whole new massive issue of nationality that defines a people?

<comment><USER17> > I don't think that's for either of us to declare.

Were the same people then? Historically there were few differences.

> You sound like you have much less than that in you.

Ethnically? Mother is 100% Ukrainian.

> I don't think Slavic culture – if there is, indeed, such a thing – defines > itself with itself. It can't be its own description, see?

Historically, Slavs are defined by language and culture. Kind of like various Celtic groups. Just the way archaeologists and historians group them.

> Aside from that... Don't you think there's this whole new massive issue of > nationality that defines a people?

Of course nationality matters now and to the future of a country. It's all that really matters. But people shouldn't try to rewrite history.

</comment></comment></comment></comment></comment></comment></comment><comment><USER18> Is Bitcoin diving again? I can never keep track.

<comment><USER19> No, it has been meandering around $3600 for a month or so (around the average electricity cost to mine one[1]). To put that in perspective, at that price the total value of all bitcoins that will ever exist is about $75 billion. That's close to the total value of Swiss Francs or Mexican Pesos in circulation[2], which still seems insane to me given that you probably can't even use it to buy lunch.

[1] [https://www.marketwatch.com/story/heres-how-much-it-costs- to...](https://www.marketwatch.com/story/heres-how-much-it-costs-to-mine-a- single-bitcoin-in-your-country-2018-03-06)

[2] [https://en.wikipedia.org/wiki/Circulation_%28currency%29](https://en.wikipedia.org/wiki/Circulation_%28currency%29)

<comment><USER8> >No, it has been meandering around $3600 for a month or so (around the average electricity cost to mine one[1]).

I had wondered why that $3300-3600 mark seemed to be the bottom. That seems to be a fair explanation. It doesn't seem good. I wonder; has the demand for gold ever been lower than the cost to mine it?

>which still seems insane to me given that you probably can't even use it to buy lunch.

Anyone still calling it a "currency" doesn't seem to grasp what currency is supposed to be. Crypto-commodity is much more appropriate.

<comment><USER20> > I wonder; has the demand for gold ever been lower than the cost to mine it?

It has definitely happened that mines were closed because of a decline in price:

[https://www.cdfund.com/en/gold-mine-closures-due-to- current-...](https://www.cdfund.com/en/gold-mine-closures-due-to-current-gold- price/)</comment></comment></comment></comment>


Software Design Patterns Are Not Goals, They Are Tools - <AUTHOR> https://www.exceptionnotfound.net/software-design-patterns-are-not-goals-they-are-tools/ <comment><USER4> It probably seems like an obvious statement to a lot of HN, but I have a feeling that it isn't to the majority of developers, who for some reason appear to love immense complexity and solving simple problems with complex solutions. I think a lot of them started with OO, which immediately raises their perception of what is "normal" complexity --- at that point, they're already creating more abstraction than is really necessary. Then they learn about design patterns and all the accompanying "hype" around them, so they think "awesome, something new and shiny to use in my code!" and start putting them in whenever they can, I guess because it feels productive to be creating lots of classes and methods and hooking everything together. It's easier to dogmatically apply design patterns and generate code mindlessly than to think about what the problem actually needs to solve it. The result is code that they think fulfills all the buzzwordy traits of "good software engineering practice" (robustness, maintainability, extensibility, scalability, understandability, etc.), but in reality is an overengineered brittle monstrosity that is only extensible in the specific ways thought of when it was first designed. That almost never turns out to be the case, so even more abstractions are added (including design patterns) on the next change, on the belief that it will help with the change after that, while leaving the existing useless ones in, and the system grows in complexity massively.

I did not start with OO, I never read the GoF book, and don't really get the obsession with design patterns and everything surrounding them. I've surprised a lot of others who likely have, by showing them how simple the solutions to some problems can be. Perhaps it's the education of programmers that is to blame for this.

The statement could be generalised to "software is not a goal, it is a tool".

Related article: [https://blog.codinghorror.com/head-first-design- patterns/](https://blog.codinghorror.com/head-first-design-patterns/)

<comment><USER5> > _I did not start with OO, I never read the GoF book, and don 't really get > the obsession with design patterns and everything surrounding them. I've > surprised a lot of others who likely have, by showing them how simple the > solutions to some problems can be. Perhaps it's the education of programmers > that is to blame for this._

Design patterns are mostly crutches for languages that have pretty weak expressive power. In a powerful language, you don't need most of them.

See also: [http://norvig.com/design-patterns/design- patterns.pdf](http://norvig.com/design-patterns/design-patterns.pdf), slides 9 and 10.

<comment><USER6> That presentation makes a funny assumption that it's dynamic languages that do that. Haskell is _nearly_ as far from dynamic as possible, with all the same advantages w.r.t. patterns.

<comment><USER7> Haskell needs "zip3" when there are three arguments to zip.

That's a design pattern for optional arguments straight out of ISO C.

<comment><USER8> I think it would be possible to create a generalised `zipN` function, using the Haskell printf trick[0], but it would be a lot of complication for little benefit. It's rare that you need to merge that many streams at once, and adding a single digit is not a huge hassle in those cases. Also I'd probably consider splitting the operation up into stages if I was using anything higher than `zipWith3`.

[0][http://stackoverflow.com/questions/7828072/how-does- haskell-...](http://stackoverflow.com/questions/7828072/how-does-haskell- printf-work)

<comment><USER9> You also have an equivalent on a family of isomorphic types, namely the types

        forall z. (a -> b -> c -> ... -> z) -> ZipList z

This is gotten by taking your `list_a :: [a]` etc. and writing:

        \f -> f <$> ZipList list_a <*> ZipList list_b <*> ZipList list_c <*> ...

You can of course also use Haskell pair-stacks to do all of this, storing (a, b, c, ...) as the type (a, (b, (c, ... ())))...

</comment></comment></comment></comment></comment></comment><comment><USER10> YES.

Design patterns are super useful as tools.

As "goals" they are idiotic. I think lots of people that think they are idiotic have been exposed to them as "goals", or don't realize that's not the point.

I think there is a larger issue here, which is that many kinds of software development, including web dev, has become enormously more complex in many ways than it was when many of us came up.

People coming up now are looking for magic bullets and shortcuts and things they can just follow by rote -- because they are overwhelmed and don't know how to get to competence, let alone expertise, without these things.

It's easy for us to look down on people doing this as just not very good developers -- and the idea of 'software bootcamp' doesn't help, I think it's probably not _possible_ to get to competence through such a process -- but too easy to forget that if we were starting from scratch now we ourselves would likely find it a lot more challenging than we did when we started. There's way more stuff to deal with now.

"Design patterns" are never going to serve as such a magic bullet or thing you can follow by rote, and will often make things worse when used that way -- but so will any other potential magic bullet or thing you can follow by rote. Software doesn't work that way. It's still a craft.

<comment><USER11> "People coming up now are looking for magic bullets and shortcuts and things they can just follow by rote"

This is the normal progression of learning. As a beginner, following the rules by rote is the goal. So, for the newbie that is first being exposed to design patterns, implementing some of those patterns should be the goal so they can learn where they fit in the toolbelt.

<comment><USER12> For another somewhat funny take on Design Patterns watch the first two minutes of this talk from last year DEVOXX

[https://www.youtube.com/watch?v=e4MT_OguDKg](https://www.youtube.com/watch?v=e4MT_OguDKg)

Speaker echoes similar sentiments about design patterns being written by highly experienced developers and should be used to communicate about code etc.

</comment></comment></comment><comment><USER13> Patterns are from software archaeology, they were naming things that were commonly seen and what they were for -- they were helping build a vocabulary to talk about larger constructs.

They are useful if you have a problem and one fits it perfectly, it can help you start thinking about it -- but it might not be a good fit.

In general we should be keeping software as simple as possible, with the understanding that it can be changed and adapted as needed. Often large "pattern" based projects devolve into a morass of unneeded complexity to support a level of flexibility that was never required.

<comment><USER14> They are rather from the interest of certain software developers in the work of the architect and philosopher Christopher Alexander, who saw patterns as the basic elements of a humane and sustainable style of building and communicating knowledge about building.

The concept, like so many other concepts, drifted from its origin and became a more rigid and doctrinaire "system", especially after the misunderstood book by the "Gang of Four".

In reality, patterns are everywhere in software, whether we call them that or not.

Game loops, event servers, compilers, map/filter, microkernels, stdin transformers, for loops over arrays, etc etc etc.

Richard P. Gabriel's book _Patterns of Software_ is freely available and goes into the history and meaning of patterns. Alexander himself wrote a preface that's worth reading on its own.

<comment><USER15> This is an aside, but it's significant that Alexander's own architecture is fairly unsuccessful. His emphasis on loose formal structure and codification of practices (e.g. built-in window seats, vestibules of whatever it is) is prescriptive and doesn't help with the real problems of architectural design, which is something profoundly intuitive, circumstantial and very subtle. Architectural education is a fascination of mine, partly because it seems to succeed so rarely.

On a tangent, anyone in London is recommended to visit the end of year shows of student work at the architecture schools, coming up at the end of June. A lot of very intriguing and complex activity. (UCL Bartlett, Architectural Association, London Metropolitan (CASS) etc.) I can't speak for other cities.

<comment><USER16> This seems opposite to me. Most architecture is prescriptive and there is little tolerance for Alexander's circumstantial and use-based design. If the story he recounts in The Battle for the Life and Beauty of the Earth is true, his preference to use simple materials and let the budget constrain the design makes him an enemy of building firms which use standards to justify cost overruns. What did you think about that book?

<comment><USER15> I agree that much building is standardized and conventional. Architecture, for me, connotes a more ambitious attempt to build creatively and appropriately.

When I say "prescriptive" I suppose I'm referring to the propositional nature of patterns, like an engineer's rules of thumb. The contrast is not so much with individual genius and variation as with the maintenance and passing on of tacit knowledge, which is a mysterious process involving multiple senses and observational learning.

[http://www.lse.ac.uk/economicHistory/Research/facts/tacit.pd...](http://www.lse.ac.uk/economicHistory/Research/facts/tacit.pdf)

That attitude might sound very conservative, but it's based on my own experience and not any preference for a particular technology or style. Alexander is too reductive and abstract; he's not properly in touch with actual sensory knowledge or craft skills. Or with economical industrial tech, e.g. the work of Lacaton & Vassal which uses cheap industrial building systems to create generous spaces.

I haven't read the book you mention. Informing myself about it now.

<comment><USER16> Let me know how you like it! (I get emailed when someone replies to an HN comment of mine.)

I think Alexander's patterns rely on tacit knowledge. Many of them involve designing in a way that real usage can shape the building or land. For example, the way many colleges will not pave paths until they see the tracks real students leave between buildings is the sort of thing Alexander has written about. Thank you for the paper; looking forward to reading it.

<comment><USER15> I've read a brief summary of the World System A and B concept. It seems like what I have come to expect from Alexander: some reductive rhetoric and claims that he has rediscovered a true, virtuous way of being. I'm not keen on encouraging "them and us" thinking, or cultivating the idea of life as a state of war (the battle for x). I agree in principle that architecture usually gets imposed on users, when it should be made in a participatory way.

Building "according to the dictates of the human heart" is all very well in theory, in practice it sounds like it would translate to an ideal of each family building their own home on a small lot. So where are we in relation to e.g. the left-right political axis? (It seems like Alexander is proposing a bottom-up approach to building and planning, in contrast to something imposed by the state or by corporations.)

If there's one major point I'd make in response to his dualistic picture of the world, it's that there are potentially varying degrees of citizen participation in the design process. A pragmatic approach would be to work on improving participation where possible rather than demonizing the supposedly pure form of "World System B" in categorical terms.

Here's a theoretical tool which presents a spectrum of participation: [http://lithgow-schmidt.dk/sherry-arnstein/ladder-of- citizen-...](http://lithgow-schmidt.dk/sherry-arnstein/ladder-of-citizen- participation.html)

If there's more, architecturally speaking, to what Alexander is proposing than just a theoretical opposition between "how things are", and a utopian and backward-looking idea of "how things should be", I think it's probably a potential revalorization of the art-historical categories of "linear" and "painterly".

(For details of "linear" and "painterly" see [https://en.wikipedia.org/wiki/Heinrich_W%C3%B6lfflin](https://en.wikipedia.org/wiki/Heinrich_W%C3%B6lfflin) )

In architecture these really correspond to a "structuralist" emphasis on modularity and interchangeable components on the "linear" side, and an expressive emphasis on overall form and image-making on the "painterly" side.

To give an example of each in its pure form, Hermann Hertzberger is a linear, modular, structuralist guy, while Zaha Hadid would be on the painterly end of things.

Alexander is not proposing Hertzberger-style buildings -- he wants to bring back traditional architecture -- but essentially I think his background is structuralist, emerging as he did from mathematics in the 60s. It's this flavour to his work that makes me feel strongly that he doesn't really care about tacit knowledge and the intangible, non-propositional aspects of architecture, the aspects that just cannot be put into words.

Oppositions are hard to avoid in thinking about this kind of thing, but of course they need to be treated with care to avoid falling into simplistic thinking.

Approaches to architecture are awash with irrational aesthetic decisions, even when they claim to be fully rational. There's a famous book from the 60s called "Architecture without Architects" by Bernard Rudofsky that might be of interest, as it documents the kind of qualities of traditional anonymous architecture (not the elaborate, royal or religious kind).

A final thing that comes to mind is the philosophy of Deleuze and Guattari. They are French post-structuralists. Although, coming from that theoretical milieu, they come out against the binary "arborescent" nature of simplistic thinking based on oppositions, they do allow themselves to introduce a significant contrast: they compare the mode of existence of nomads with that of the state. They talk about the smooth space of nomads as the origin of the (improvised) war machine (essentially, of science), while the striated space of the state is the space of complex social structures and institutions (the university, for example). Their ideas are very rich and thought provoking, popular with architects but potentially still strange and radical at the same time. Their work is evidently a distillation of a huge amount of reading and contemplation. In my opinion Christopher Alexander's ideas look very tame and unimaginative in comparison, and the scope of his thinking appears just disappointingly limited.

Here's a link to a summary which might whet your appetite for Deleuze and Guattari (their writing is also interesting and compelling, but this PDF document just gives the bones of one of their main ideas): [http://www.protevi.com/john/DG/PDF/ATP14.pdf](http://www.protevi.com/john/DG/PDF/ATP14.pdf)

<comment><USER16> Thanks; really appreciate the reply.

I will go through the links. As you recounted your impression of the A vs. B system, I remembered that I didn't care so much for the introduction as I did for the actual story of building Eishin campus. It seems like his most important principles are to let real usage finish the design and to choose materials that support that as well as completing the work within budget. My gut says: how can Alexander be reductive and non-tacit when he is trying to allow space to be shaped by the people who use it, i.e. directly incorporating tacit knowledge? There is an "us-vs-them" to believing users know something designers don't, I suppose, but it's tempered by the humility of believing the users will do better than the architect advocating for the users. But there certainly are multiple ways to obtain tacit knowledge and involve it in a project.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER17> >, if you ever find yourself thinking, "I know, I'll use a design pattern" before writing any code, you're doing it wrong.

Unless I'm misunderstanding him, I would disagree with this. When you're doing it wrong is when you use a design pattern without understanding what problem its solving, and whether you have that specific problem.

To use his tool analogy - if you're a joiner who turns up to a job thinking "we always need to use a hammer" and start randomly hitting everything, then you've gone wrong. But equally, if you're halfway through knocking a nail in with your shoe and think "Oh look, I'm using the hammer pattern now", you're doing it just as wrong.

If you're looking at two things you need to attach together and you've considered whether glue, a screw, a nail or something else is the most appropriate for this specific job, decide it's the nail and _then_ think - "I need to use my hammer now", then you're doing it right.

<comment><USER18> I would say that using your shoe to emulate the hammer pattern is a good sign of flexibility and understanding the heart of the pattern.

The point of the hammer pattern isn't the hammer, but the movements and the forces applied. In Europe hammers are an axiomatic part of their nails already so they don't even have a name for the hammer pattern!

On the other hand, if you're with your screw and trying to spin it with the hammer because someone said use the hammer pattern...

<comment><USER17> It's a good sign of flexibility, but not a good sign of being a professional on a job.

And it's something I see depressingly often with programmers - <USER2> problems that there's a fairly well known existing pattern for, but not being aware of the pattern and either spending days/weeks rediscovering the pattern for themselves, or even worse inventing a new and less effective way of solving it.

</comment></comment></comment><comment><USER19> Design patterns aren't the problem. All a design pattern is, is a well-known way of doing something.

When you build a house, do you re-invent how to frame, plumb, wire, and roof it? No. That's all a design pattern is. Choosing the right design pattern is akin to making sure that your basement is made out of cement and your walls framed with wood. (You don't want to put shingles on your countertops!)

The problem is that some developers think they are some kind of magical panacea without really understanding why the pattern was established and what it tries to achieve. These are the over-complicated projects that everyone is complaining about in this thread. (These are the projects where the basement is made with wood or the concrete walls too thick; or the projects where someone decided to put shingles on the countertop.)

I try to pick, establish, and follow design patterns in my code. It helps ensure that I don't spend a lot of time re-learning why some other technique is flawed; and it helps achieve a consistent style that everyone else on the team can work with.

</comment><comment><USER20> I found both his definition of the adapter pattern and his example to be a bit off. In his example, the adapter extends the external interface instead of the client interface. By definition the adapter must implement the client interface. It's even in the UML diagram displayed on the website he quotes ([http://www.dofactory.com/net/adapter-design- pattern](http://www.dofactory.com/net/adapter-design-pattern))

      > The fact was that I just didn't understand them the way I thought I did.

      > To be clear, I've never read the Gang of Four book these patterns are defined in

After admitting he has a less than desired understanding of design patterns (proven by his poor example), he makes bold claims like:

      > if you ever find yourself thinking, "I know, I'll use a design pattern" before writing any code, you're doing it wrong.

I'm having problems taking this article seriously.

</comment><comment><USER21> "Software Design Patterns Are Not Goals, They Are Tools" \- I do not understand why this needs to be said in the first place.

<comment><USER4> I suppose you haven't seen much of the world of Enterprise Java Applications?

[https://docs.spring.io/spring/docs/2.5.x/javadoc- api/org/spr...](https://docs.spring.io/spring/docs/2.5.x/javadoc- api/org/springframework/aop/framework/AbstractSingletonProxyFactoryBean.html)

Many years ago, I briefly worked in that industry and thoroughly hated the rigid, dogmatic, extreme overengineering culture and the resulting code it produced. I'm glad to be away from it all.

<comment><USER22> Much of the Java+Patterns=<3 stuff came from java lacking syntax for functions that didn't involve creating an entire anonymous inner class with an apply function; the Strategy pattern is an excellent example of a pattern that just goes away when you can pass functions around. There just are not good ways to express certain solutions without using at least one or two, for any sufficiently large piece of software, without that syntax. And if your language is making what you're doing awkward, it's probably not how most people are going to code. Guava had an entire disclaimer in their functional documentation that essentially said "whenever you reach into this toolbox, think about if it's really what you want". Now that Java8 has syntax for them, we should see people reaching more for Streams and their functional methods.

Now, that said, it's often more tempting and easier to just add complexity, which results in crazy codebases. It's much harder, especially under pressure of deadlines, to REMOVE patterns as they don't make sense anymore, which gives us what people think of as enterprise Java. Not all Java is like that, I promise.

<comment><USER23> Sadly, it seems that most of the java devs who created these monstrosities learned the wrong lessons.

As far as I can tell they seem to think total lines of code was the real issue (It couldn't be the Abstractions/Patterns, those are good!) and are now on a kick to move as many lines of code as possible to annotations. I call this "Annotation based programming" and any new problem starts with a google search since how any tool kit handles something is pure guesswork.

<comment><USER22> If you're going to denounce annotations, you must also denounce decorators in both Python and Javascript. Annotations are a super powerful tool that get used too much. To borrow from Lisp: data > functions > macros. They should be the last tool you reach to, in order to remove a bunch of repetition with the intention of simplifying your code. "Could you do what you're trying to do with a library of functions that you simply call into? Or some sort of composition? Or maybe a parent class?" type questions should be asked before you reach for any sort of metaprogramming.

Take a look at the Retrofit library from Square for a good example of usage of annotations. To the original Spring link posted, while there's lots of annotations, they're replacing the XML that used to plague Spring projects, which I find much more magical. At least I can jump to an annotation's definition in my IDE.

</comment></comment></comment></comment></comment><comment><USER24> I have been interviewing a lot of developers recently, and one of the best questions I've found is to ask them _why_ they have used MVC pattern in the test assignment (most do). Most of developers misunderstand the question at first and either start to explain how MVC works or explain how they would've implemented it without MVC (when you ask people why they did something, they often take it as "you shouldn't have done it"). But even when I clarify the question, a surprising number just can't even begin to answer it — instead they stumble and at best just tell that that's how they have always been taught to do it.

<comment><USER25> That you haven't been up-voted more affirms my belief that you are on the right track. If they can't explain why they don't know the value of it. If they don't know the value of it, they can't weigh that value against any others.

<comment><USER26> Is "it's the first thing that came to mind" an acceptable answer?

<comment><USER25> That's falls somewhere between "because its the way we do things around these parts" and "it's what we used on my last couple of projects".

Perfectly fine for a certain degree of utility (maintenance, finishing, junior dev?), not quite so much for a lead, system designer or architect.

</comment></comment></comment></comment><comment><USER27> As far as I can tell design patterns are mostly about taking something simple and obvious and using terms to describe it that make it obscure and difficult to understand.

<comment><USER28> Patterns are about giving developers a common vocabulary so they can discuss what they all do without having to go into insufferable detail each time. We all do lots of the same shit and it's extremely helpful to all use the same names for those things.

<comment><USER27> Why do I have to call it "the strategy pattern?" What was wrong with "passing in a function?" Giving it a name like that obscures the idea. Yes, I realize that if you don't have first-class functions you have to work around that with interfaces or similar, but now we're describing a workaround for a language limitation, which seems a bit less inspiring than what "design patterns" are sold as.

<comment><USER29> I think the word "strategy" encapsulates more about the semantics than "passing in a function".

For example, the "visitor" pattern could also be described as "passing in a function", but there's a significant difference: a visitor is intended to be called on each element of a data structure in turn (i.e. a bit like an iterator callback), while a strategy defines an algorithm that you're expecting the caller to select at run-time (e.g. different cipher implementations).

Syntactically, they may well be the same ("passing in a function") but semantically, they're very different.

It can be useful to be able to have this shared vocabulary when talking about designs.

<comment><USER27> "Visitor" has always bothered me too. If you look it up it's tons and tons of text to describe "pass in a function and descend a graph calling it on each node."

<comment><USER30> That's actually _not_ what the visitor pattern is about, though the way it's typically presented and the poor name tends to confuse the fact. Visitor isn't about traversing trees. It's about letting you define class-specific behavior outside of the definition of the class itself.

It gives you a way to "add a method" to a set of classes without actually stuffing them in the class definitions themselves.

In practice, most visitor patterns are used with AST classes or other types that are stored in a tree-like fashion, but that's coincidence. The visitor pattern itself is really about using virtual dispatch to avoid an ugly and non-type-safe type switch.

<comment><USER31> So pattern matching?

<comment><USER30> Sort of. It's a way to emulate a simple subset of pattern matching in languages that lack it.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER32> This article makes way more sense when he says he never read the Design Patterns book. If he had, he would know that before he started. They explain that the book is a collection of patterns that they have compiled from a bunch of people and from years of experience. The patterns did come about organically, and they were never meant to be the way to design software. They were only trying to come up with a common lexicon for something that they were all already doing.

</comment><comment><USER33> I'm reminded of a set of tweets from Harry Roberts about whatever new hot CSS naming convention was popular for the week:

> Modularity, DRY, SRP, etc. is never a goal, _it's a trait_. Don't let the > pursuit of theory get in the way of actual productivity.

> That's not to say Modularity, DRY, SRP, etc. aren't great ideas—they > are!—but understand that they're approaches and not achievements.

There's nothing super revolutionary about these thoughts, but they've stuck in the back of my mind for a while now.

[https://twitter.com/csswizardry/status/539726989159301121?re...](https://twitter.com/csswizardry/status/539726989159301121?ref_src=twsrc%5Etfw)

</comment><comment> awinter-py design patterns are guru thinking. they're bad ways to describe self- descriptive tricks like callbacks. don't let a person who talks this way write docs ever; they'll focus on 'what's being used' rather than what's happening.

design patterns are like when a consultant creates a stupid name for something that already exists -- the name isn't about expressive power, it's about declaring ownership so the consultant can sell the 'Consulting Method' to solve your problem.

when a phenomenon or trick has an easily understood one-word name, don't let a nonexpert rename it to something nobody understands.

<comment><USER10> Callbacks only become self-descriptive or obvious once you've seen them a bunch of times.

To a new programmer, say in javascript, who has never seen them before, they aren't at all self-descriptive or obvious. It is super helpful to have the term 'callback' to talk about them, and to understand what they are -- say, just a function you pass in that's then called back or whatever.

Then you'll be able to recognize what it is when you see it in existing code/api, and how to use it, as well as when to use it when writing your own code/api. If you really just tossed someone at Javascript and they were a new programmer and had no idea what a 'callback' was, most people would have a lot more trouble figuring it out from themselves only from code examples, or would never think of using it themselves when writing code/api never having seen it before.

That's all a "design pattern" is. "Callback function" is a common and successful design pattern in Javascript. (Less common or useful in some other languages, depending on the affordances of the platform). That's it.

Yes, focusing on "what's being used" instead of "what's happening" is a problem, yes, thinking you can construct software just by robotically putting together "design patterns" is a problem.

Design patterns are still a useful and inevitable part of software development, and recognizing that can make you much more efficient at learning how to write software, at designing comprehensible and maintainable software, and at reading other people's software.

<comment> awinter-py Yes, I meant 'callback' is a better title than 'visitor pattern', not that callbacks are obvious without explanation.

<comment><USER10> A difference of opinion about what a pattern should be called is not an argument against the utility of the concept of design patterns.

It's definitely called 'callback' in Javascript, I don't know if that name would be as obvious or useful in other environments.

</comment></comment></comment></comment><comment><USER34> > Here's the problem I have with design patterns like these [Adapter Pattern]: > they seem to be something that should occur organically rather than > intentionally. We shouldn't directly target having any of these patterns in > our code, but we should know what they are so that if we accidentally create > one, we can better describe it to others.

It's not clear what the author would have done differently in this example. It's one thing to raise concerns about pattern-first thinking in general, but quite another to spell out what exactly is wrong with reaching for the Adapter Pattern to solve a very specific problem under a given set of constraints. I can imagine a number of situations in which going straight for an Adapter is the only sane choice.

I've come to view with great suspicion any general discussion of programming divorced from its context. Architecture Astronauts and Cowboy Coders can each do a lot of damage if left to their own devices.

</comment><comment><USER35> Design patterns, OOP, to a large degree programming languages are just tools. You don't hear of craftsmen saying things like "The only thing you really need is a hammer. It's been around longer than the other tools and you can use it on every project". Replace "hammer" with C or Java and you have a legitimate comment on a score of threads.

 _> What patterns don't help with is the initial design of a system. In this phase, the only thing you should be worried about is how to faithfully and correctly implement the business rules and procedures._

I submit that should be your overriding concern at _all_ times, not just the design phase. If you have to refactor some code in order to extend it, tie it back to the changed requirement. This forces you to make the least amount of changes, refactoring the least amount code, breaking the least amount of unit tests and introducing the least amount of bugs into production.

<comment><USER36> Unfortunately looking at just the business rules and procedures leaves the oft-hidden 'soft' requirements (the -ities) in the dust. Unless you explicitly state the corresponding requirements, having the business rules and procedures as your overriding concern will lead to pain. And explicitly stating a testable requirement for e.g. maintainability or security tends to be quite hard in practice.

</comment></comment><comment><USER37> While we're here, SOLID is a nice acronym that is helpful as a checklist of generally good ideas to consider. It's not a law of physics, it's not compulsory, following it blindly can lead to worse outcomes and if transgressing it leads to a better outcome (with all things considered) then it should be transgressed.

</comment><comment><USER38> Just now realizing there is ambiguity around the terms "design patterns." Say it in a different crowd, they'll think you are talking about the kind of design patterns Brad Frost is writing about. [http://atomicdesign.bradfrost.com/](http://atomicdesign.bradfrost.com/)

<comment><USER25> Maybe there's a common (patterned?) ambiguity to the idea of design patterns?

</comment></comment><comment><USER39> Goals should include:

      1) Solve the problem
      2) Make it maintainable
      3) Make it extensible
      4) Make it scalable (server)
      5) Optimize it for memory, speed

So the reason to use an existing paradigm and a well-tested framework is because it makes the above easier, especially #2. And over time, #2 winds up saving you a lot resources and probably saves your project from tanking.

Finally, using an existing well known platform also lets you hire developers who know what they're doing from the beginning, leading to more prosuctivity and less dependence on any one particular developer. We leverage the knowledge that's already out there.

</comment><comment><USER40> His problem may be learning about those concepts from snake-oil sellers - <USER3> mentions he didn't bother to read GoF and gets his knowledge from things like [http://www.dofactory.com/products/net-design-pattern- framewo...](http://www.dofactory.com/products/net-design-pattern-framework) .

My advice is to learn from people like Martin Fowler or Kent Beck and if you want to look at companies, look at something like ThoughWorks.

</comment><comment> V-2 As pointed out (arguably a bit harshly) in comments under the original article, this is really a strawman argument. That's because that ol' classical GoF book on design patterns - which the author admits has not even read - addresses this concern already. It's still a valid argument, but not exactly a fresh one. And speaking on the subject without even bothering to read the piece widely considered as canonical is a bit arrogant.

</comment><comment><USER41> YES

The point of design patterns is a way to describe what you've made succinctly.

NO

When you set out to do something that you don't yet know how to do, having a crank you can turn to get out functioning code _is a good thing_.

I think what you mean is "Design Patterns are Tools, not Dogma".

Plus, _a lot_ of design patterns only make sense in typed and/or OOP languages, so under those circumstances, they _can 't_ be applied as goals.

</comment><comment><USER42> > In other words, if you ever find yourself thinking, "I know, I'll use a > design pattern" before writing any code, you're doing it wrong.

I completely disagree... if I'm working with a team. I've spent far too many hours trying to fix fragile code that comes about as a result of different devs with different methodologies trying to tie their code together.

<comment><USER43> What you're describing sounds more like a teamwork problem - you're likely either missing someone with the "big picture" who is reviewing code, or a collaborative code review process.

<comment><USER42> I would agree that lacking either of those things would cause the problem I described, but in this case we have both of those.

Most recently, I was the one joining a project after its incipient stage, so I was not the big picture guy, but the big picture guy chose not to establish any kind of patterns or standards so when others started joining the project-- even with an understanding of how it should work--suddenly the app had a lot more functionality but it all performed terribly because of a lack of uniformity in design. Code review helps, but ultimately because there are no established patterns there is no justification for telling someone a task should be implemented differently, right? The only solution I can see is to establish that justification by trying to get the big picture guy on board with a massive refactor to establish some standards.

</comment></comment></comment><comment><USER44> Kind of relevant to the discussions in this thread: [https://en.wikipedia.org/wiki/Rule_of_three_(computer_progra...](https://en.wikipedia.org/wiki/Rule_of_three_\(computer_programming\))

When I do hit the magic 3 and can justify restructing code, I consider my options in terms of design patterns (which are very much tools!)

</comment><comment><USER45> Stated in other terms, patterns are a _means_ to an end. Not the end goal.

Patterns will organically emerge as the result of ongoing refactoring.

</comment><comment><USER46> I can say the same thing about programming.

Thats why when I read HN I'm trying to understand what are you trying to achive. Something that goes beyond staying in front of the computer 10 hours a day.

</comment><comment><USER47> "I didn't read the article or the comments but I think you're all wrong, maybe it's bad upbringing or maybe something else but whatever". ok thanks for sharing.

</comment><comment><USER48> How can someone doing research on these patterns not have read the most basic/important piece of literature on the subject?

</comment><comment><USER26> When I was in college, I assumed (like most) that patterns were received wisdom in how to construct software. Then I actually attended a talk with John Vlissides and realized that patterns were an entirely different thing, closer to the "archaeological" sense dantheman mentioned. In this way, the study of design patterns correspond better to the study of rhetoric or poetics in human language. "Homeric Simile" could be a design pattern in poetry.

In software, some rigidity of expression might be preferred, and so the design patterns also help us avoid creating new terminology for things that have been appropriately described.

There are places where each pattern might have utility, and I suppose if there is any sense to the term "software architecture" it is in the ability to make sense of what the system should look like in a way that can be explained to the relevant parts of the team.

There is a tendency, as well, among software developers to think that a complicated architecture must be the result of countless stupid decisions, probably made by junior technicians, who were doing things without understanding what's going on. Thus you find people exhorting others for simplicity, and acting like they've done their job at that point. But instead, complicated architecture is the result of compromises and rewrites throughout the software's life, and attempts to discard those old architectures and start afresh with similar tools usually result in an initially simplistic, but ultimately inflexible, design that will eventually evolve into a different complex architecture.

The Linux kernel is an example of a complicated architecture that was designed from a standpoint of simplicity initially, and developed its own object- oriented layer on top of C, with pluggable elements all over, loadable modules, etc., and millions of lines of code. BSD is smaller and more coherent, but also much more limited in scope.

There are also examples like Windows NT, which suffered from being the second system to 3 systems: Windows, OS/2 and VMS. In this kernel, there are so many design features that were included before implementation, that it seems incredible it was ever built. But they persisted and made it happen, and even eventually made it fast, in some cases by working around its design with new compromises and approaches. Still, it lacks the simplicity of a Plan9 or an Oberon, but what it doesn't lack is users.

Anyhow, I digress. What is important to me about patterns is the language that we get from them, and the ability to recognize what's going on in code. They can provide useful hints about implementation gotchas, and they can also help people stop reinventing the wheel.

</comment><comment> bjr- Read the book. Then read the books that inspired the book.

</comment><comment><USER49> THIS

</comment><comment><USER50> A design pattern is a reusable solution to a recurring _problem_. Too many inexperienced devs forget that part, and use a pattern where the problem it's designed to solve doesn't exist. Had the author read the GoF book (he admits he still hasn't) he might have avoided that pitfall.

<comment><USER51> Yeah, I can't believe someone would write a blog post about design patterns without reading the GoF book.

The authors are very explicit in every chapter about what problems are a good fit for that design pattern.</comment></comment>


Helping100 - Free Startup Help - <AUTHOR> http://www.helping100.com/

<comment><USER2> I've been doing exactly this for the last few months. I estimate I've mentored around 40 start-ups in the last two months alone.

You're likely to get more leads from MicroMentor.org , Clarity.fm , SoHelpful.me , PopExpert and Quora.

Feel free to contact me if you need more details. Contact details in my profile.</comment>


Google Cloud Functions (AWS Lambda Equivalent) - <AUTHOR> https://cloud.google.com/functions/docs <comment><USER2> Cloud Functions / Lambda are great for setting up things such as serverless architecture but they lack a few things necessary for typical "fast data" or stream processing tasks. One could do significantly more with these if they had a method for saving state in a thread-safe manner. I know you can call out to dynamo or the like but an in-memory solution is necessary for any sort of reasonable request rate.

With some state one could implement bloom filters, top-n, cardinality estimations, etc...</comment>


Secure your code against the finalizer vulnerability - <AUTHOR> http://www.ibm.com/developerworks/java/library/j-fv/index.html <comment><USER2> FWIW, from Bloch's "Effective Java" (2nd Edition):

        "Finalizers are unpredictable, often dangerous, and generally unnecessary.
        Their use can cause erratic behavior, poor performance, and portability
        problems. Finalizers have a few valid uses, which we'll cover later in this
        item, but as a rule of thumb, you should avoid finalizers...

        One of the shortcomings of finalizers is that there is no guarantee they'll
        be executed promptly.  It can take an arbitrarily long time between
        the time that an object becomes unreachable and the time that its finalizer
        is executed. This means that you should never do anything time-critical in a
        finalizers.  For example, it is a grave error to depend on a finalizer to
        close files, because open file descriptors are a limited resource...

        Not only does the language specification provide no guarantee that finalizers
        will get executed promptly; it provides no guarantee that they'll get
        executed at all. It is entirely possible, even likely, that a program
        terminates without executing finalizers on some objects that are no longers
        reachable. As a consequence, you should never depend on a finalizer to update
        critical persistent state...

        Oh, and one more thing: there is a severe performance penalty for using
        finalizers."

Why would anyone ever consider using a finalizer?

<comment><USER3> Well, to stay with the example of file handles, one might forget to explicitly close the file. The finalizer would then act as a safety net and close the file as soon as the object is garbage collected.

But indeed, it is a very bad idea to rely on that. Even in languages that have reference-counting garbage collection semantics (such as Python) it is recommended to explicitly close files, as someone might still have a reference around.</comment></comment>


The Imbox: It's not a typo - <AUTHOR> http://itsnotatypo.com <comment><USER2> It's an email provider costing $99/year.

<comment><USER3> pay nothing, get crap, get tracked.

<comment><USER2> I don't get your point. Yes, that's their manifesto, but so what? I posted a descriptive statement, not a value judgement. It isn't clear from the title what this is (at first I thought it was yet another email app). By putting it succinctly in a comment, whoever knows they're not going to pay $99/year for an email provider doesn't need to waste time navigating the website.

I also don't understand the "get crap" comment. Free email services (at least the popular ones) are more than capable.</comment></comment></comment>


Average Power: A Cautionary Note [pdf] - <AUTHOR> https://statmodeling.stat.columbia.edu/wp-content/uploads/2020/08/avgpower.pdf <comment><USER2> Wasn't the type of power I expected:

Abstract

Replication is an important contemporary issue in psychological research, and there is great interest in ways of assessing replicability, in particular, retrospectively via prior studies. The average power of a set of prior studies is a quantity that has attracted considerable attention for this purpose, and techniques to estimate this quantity via a meta-analytic approach have recently been proposed.

<comment><USER3> _Wasn 't the type of power I expected._

Me either. I thought it was going to be about power measurements for non- standard waveforms. Switching power supplies, inverters, and other devices generate loads and outputs that don't look like a nice sinusoidal AC waveform. There are power factor problems, where voltage and current are not in sync.

It's hard to measure average power for strange waveforms. Average voltage times average current can be way off from average power. You need the integral of the product of voltage and current. The simplest way to get that is measuring the heat emitted from a resistor in series with the load, and that's what a classic RF wattmeter does.

It's a practical headache for transformers, power distribution, and such. Transformers lose efficiency and heat up on such waveforms. Motors don't run well This used to be a big problem with low-end inverters for solar systems.

The "free energy" people run into this trap. They build some weird oscillator, measure voltage and current, and think they got out more than they put in.

So that's "Average power, a cautionary note" for electronics.

<comment><USER4> It's quite common to see "I thought article was going to be about <x>" on HN. Less common for the disappointed punter to dive right in and write the article they expected. Nice one!</comment></comment></comment>


Show HN: A Chrome extension to help save books you want to read - <AUTHOR> https://chrome.google.com/webstore/detail/babelshelf/hagchccjngldonihokhncngknojhabgc <comment><AUTHOR> After getting tired of manually making note of all the books I find online that seem interesting (from Twitter, HN, Reddit, etc.) I made a chrome extension to help me keep track of them + the website where they come from. Thought this would be of value to some other readers out here. Would love some feedback!

<comment><USER2> How does this compare to Pocket?

<comment><AUTHOR> Not too familiar with how Pocket works but this one is more focused on books rather than articles / text. It'll be able to recognize books based on highlighted text, then save the author and cover and back blurb to your list.

</comment></comment></comment><comment><USER3> I don't think this will be a popular comment here, but I use an amazon shopping list for this.

<comment><USER4> I use Goodreads. There is even a third party Chrome extension.

A pro for Goodreads is the massive user base so reviews and groups etc are good resources for finding out if a book is worth your time.

Although I do like the Babelshelf interface. Clean easy to find a saved book. Goodreads is horrible to look at and can be super distracting.</comment></comment>


It's Never Too Early to Fire - <AUTHOR> https://a16z.com/2017/05/24/on-firing-why-when-how/ <comment><USER2> Actually, pretty good advice in the opposite direction, too. If I had known at 18 that I could have easily and successfully walked away from teams, bosses, companies, partners, and investors who gave 'bad vibes', I would easily have (at least!) an extra couple million in the bank.

I wasted countless opportunities waiting for things to get better, when I probably intuitively knew that they wouldn't. Partly, it was because I didn't want to be considered inconsiderate or rude. But, also, it was because I latched on to other things: the mission, the market, the tech, the product, the teams, etc.

<comment><USER3> It's odd, because my first two dev jobs I had to be let go. First time was due to them needing someone of senior skill yet paying for a junior salary and let me go after just 3 weeks, and the other due to money running low and let me go after a year of working for them.

This taught me that businesses are out for themselves no matter how nice the people are. It then taught me that if I don't like somewhere, I will just outright look elsewhere and bail.

After being let go from my second workplace, I left my next one due to him promising me more money and then going back on it with another deal which sounded great, but actually sucked when I thought about it. He is a really nice guy, but such a shady businessman, so I looked elsewhere and then handed in my notice.

The workplace after that one wasn't any better, they wouldn't use GIT, worked on each site whilst live (no dev environment). I hated it, so I took a week off to search elsewhere, found something better and handed my notice in.

Also, I tried to push for better practices which the other devs loved, but my manager and boss just wouldn't listen and refused any of my input.

There's actually a guy in that workplace who is super nice, but has never been let down like I have so he feels he owes the company everything and won't leave. Whenever he tries, the boss will offer him more pay and then he stays. It's sad, because he deserves so much better. :(

<comment><USER4> yup, basically kept getting increases in pay (but not promotions or authority to change the situation I was in for the better) to stay.

Don't take the bait.

it's an admission that they know you are more valuable than you are being treated, and an acknowledgement that your misery in the situation is not going to change, which is exactly why they are hoping you will be ok with continued frustration in lieu of more money.

<comment><USER5> That's still a pretty good deal though. Plenty of companies will never budge on money. They'd rather you quit and just find another sucker.

<comment><USER4> sometimes.

However, if a company has gimpy organization and technical APIs for many complex pieces of software and or processes in which making mistakes is costly and expensive, it is economical to raise someones salary $15k than have to invest in a newb to spend the next 7 months being able to operate as quickly as you do. It took me about 7months to be up and running efficiently with everything and be able to train other people. I still had to perform at full capacity on day one, but I was less efficient and because mistakes were so costly, I would have to wait 30-45minutes to find someone else to confirm an operation before making one, instead of making a mistake in production, until I knew how to do it myself.

In the manufactoring line, bottlenecks for tools being down was calculated by the millions per hour, because linear bottlenecks in product production actually cascade down a 4 months timeline for meeting product deadlines, which have payment associated with them, and significant penalties for being late.

Additionally, metrology tools to check errors sometimes cannot, based on chemistry and physics, detect errors in production until multiple steps down the line. So if there is a mistake in a base design, it won't get picked up for 3 weeks, and the entire line has to be restarted, so it really helps to have people know how to not screw up even if there isn't an official process for it.

They kept me on because I worked hard, and because I knew how to use over 18 different independent horrible pieces of software with no APIs, and run them simultaneously in realtime in production while operating a team of 15 people.

Losing me was uneconomical for them.

</comment></comment></comment></comment></comment><comment><USER6> Just a note, this isnt about firing junior people fast. That is absolutely scummy.

This is about hiring/firing very senior, well paid people with lots of prior experience.

If you are hiring and then firing junior people fast, you are the problem.

<comment><USER7> > If you are hiring and then firing junior people fast, you are the problem.

I'm going to challenge this point of view. It is absolutely, and obviously, expected that junior people have a ton to learn, and they should be given leeway for that learning process. So yes, if you fire a junior person because you're not willing to put in the mentorship necessary, then I agree, you are the problem.

However, junior people really _shouldn 't_ have any problem with motivation and drive, and in those cases where I've had to fire people, I've always wished I had done it sooner. More importantly, their _peers_ wished I had fired them sooner, too. A bad or lax attitude can be an absolute killer for team morale if the person in question isn't dealt with quickly and fairly.

<comment><USER8> You're pointing out an important difference: firing because of experience/performance vs firing because of behavior.

Being a bit naive, making mistakes, and needing ramp-up time is to be expected, especially from a junior hire. You absolutely need to give time to correct that sort of thing, and firing fast is not a good move. Some of the best devs I've worked with needed a few months to ramp upbefore they hit full stride.

On the other hand if someone is dicking around instead of working, being insubordinate, refusing to try to improve, upsetting coworkers, etc., then you've got behavioral problems on your hands. And those are absolutely good reasons to fire if they persist beyond an initial stern warning.

<comment><USER9> I just want you to know that I'm a beginner in management (having hired two juniors for my startup), and I'll use this advice (The junior is not productive, but him being reasonably motivated is the reason why I'll keep him).

<comment><USER10> Conversely, ramp-up time should not be infinite. A junior employee should not be limping along after a year at the company. Either that person just isn't a fit, or there is something terribly wrong at your company.

<comment><USER11> As a step before firing for a junior employee that shows any sign of promise, a 3-6 month performance improvement plan with regular check-ins and measurable progress points could make a world of difference. I currently have multiple juniors on PIP's and they are taking them very seriously and improving less than acceptable behaviors.

</comment></comment></comment></comment></comment></comment><comment><USER12> In the first company I confounded, we recruited a friend of my cofounder to a senior job. He looked like the right guy for the job but he actually really wasn't. He was completely underperforming and junior employees looked at him and lost respect for both and my cofounder for keeping him on.

Because he was a friend who had left his job to work for us, we didn't fire him and he continued undermining the company with his poor performance for a year. I think this was the worst mistake I did. In the end, he left the company and screwed us over on some account.

So, I've learned from this:

\- do not hire friends as senior executive

\- if you insist on hiring friend, have a clear backup plan if things don't work out so that you can both end the relationship. Be prepared to lose your friendship in doing that.

\- never let an underperforming senior employee fester in your company. It's like rot, it will drag down the entire company by devaluating the work your other employees do

<comment><USER13> Alternatively, don't recruit friends that already have jobs or need to relocate. If someones out of work to start then letting them go is arguably less traumatic.

</comment></comment><comment><USER14> >I have never fired anyone too early.

This may well be true but how do you know? The only way I can think of is if the employee went on to become such a rock star at some other place that you actually hear about it. But that's not the only situation where they might have been valuable to you after a while.

<comment><USER15> You'll probably never know if you fired too soon. Confirmation bias Will confirm the decision. You'll always know if it was too late.

<comment><USER16> isn't it always "too late"? The fired employee would have to have a long pattern of problems. With the benefit of hindsight you'd know that you should have fired them after the first 5 or 10 problems.

</comment></comment></comment><comment><USER17> Weirdly, I think we would all benefit quite a lot from a normalization of fast firing. Part of the reason it's hard to get a job is that companies are afraid to fire you, so they jump through all kinds of strange hoops to try to predict how good an employee you'll be based on, really, no information.

This also forces companies to filter out "possibly good" candidates and only hire "probably good" candidates.

If it were normal to get fired after a day or a week, you could get hired at 10 different companies over a span of two months and likely find a really great position, where you're a great fit.

My next company will have explicit rubrics for what it takes to get fired, and your status will be tracked daily. You'll know at all times exactly how close you are to getting fired with how much severance. It will never be a surprise, unless it's a reaction to an acute event (sexual harassment, etc). We'll hire pretty much everyone who walks through the door with a plausible story for how they add value. Anyone we fire we'll sit down in the exit interview and write a plan for how they can get re-hired in a few weeks or months if they're interested. We'll also try to spin off a separate business with the fired person at the head, instead of just firing, whenever possible.

<comment><USER18> >My next company will have explicit rubrics for what it takes to get fired, and your status will be tracked daily

>You'll know at all times exactly how close you are to getting fired with how much severance

Good luck getting anyone to stick around! People want job security, they don't want to feel like they're walking on eggshells every day. You seem to think the only thing people want out of a job is money.

>Anyone we fire we'll sit down in the exit interview and write a plan for how they can get re-hired in a few weeks or months if they're interested.

I don't think you know what firing means. It's not a mutual decision and you really don't want that employee working for you at that point. It's a serious legal risk to re-hire fired employees.

<comment><USER19> >It's a serious legal risk to re-hire fired employees.

That's interesting to hear. Could you explain in what way?

<comment><USER20> Maybe its a US thing - here in the UK I've seen multiple people re-hired and in each case it worked out pretty well.

<comment><USER21> I'm not sure if this is common knowledge outside the US (it wasn't for me): "Fired" and "let go/laid off" don't mean the same thing. Fired means they were laid off for some gross reason, e.g. incompetence, stealing from the company, etc. Laid off means they were just let go because of reasons not very related to their performance.

Please correct me if I'm wrong.

<comment><USER22> I don't know if there are precise definitions, but I've always used (in the US):

* Fired with cause - gross reason: sexual harassment, illegal activities, etc.

* Fired - incompetence, laziness, other ineptitude related specifically to the employee, but nothing illegal

* Laid off - financial reasons or business direction reasons for the company. (Some people who are borderline performers get swept up into lay offs, which helps the employee save face.)

In the latter 2 cases, people generally get severance arrangements. In the last case, people are generally eligible for re-hire should conditions or direction change.

<comment><USER21> I see, thank you. That's pretty clear.

</comment></comment></comment></comment></comment></comment></comment><comment><USER23> This post left a bad taste in my mouth. Firing can be hard on all parties involved. Your dumb startup is not that important. If you can't figure out how to utilize an employee, that's on you.

<comment><USER24> Its just an advice article for C-suite wanna-be's. They love, love, LOVE stories about leaders who make "snap" decisions and win. The guy even quoted Jack Welch.

You're right that firing is hard for everyone. It creates an environment of chaos and uncertainty, which if it is not properly managed, may precipitate scores of top employees to shift to job-search-mode.

FWIW, however, I do think a lot more high-level execs (which is what the article is _really_ about rather than juniors) need to on the chopping block earlier and more often. At the very least it may help to promote more empathy about hiring people that have been laid-off as these people climb their way back into leadership positions.

</comment></comment><comment><USER25> It takes time to build trust, at least several months, maybe even years. If you fire everyone before you even get a chance to build up trust with them, you'll never get a great team.

<comment><USER26> I think it comes down to supply and demand too. If you have 10 qualified applicants, I'd be more apt to fire quick and reach back out to the pool to find a better fit. If it takes 3 months to find a qualified applicant then I'd be more likely to be patient in building trust and working through challenging times. That said, I've fired people after a day on the job. If the hiring process failed, no sense in wasting my time or theirs on trying to create a fit that doesn't exist. Better to move on and fix the hiring process. But don't fire quick and keep your same hiring process, that's just repeating mistakes, rather than being agile.

<comment><USER27> This is why signing bonuses are so nice, firing someone on day 1 is just awful. If I was an employee at a company who did this to someone I would start looking for another job.

</comment></comment></comment><comment><USER28> "You can never fire someone too soon" is a ridiculous statement as it is non- falsifiable.

<comment><USER29> "You can never comment to early", on the other hand...

He clarifies the provocative title in the section titled "How long should you give people a chance?"

</comment></comment><comment><USER30> > Of course I'm being a bit provocative to open this post with, "I have never > fired anyone too early." I have almost always given people a chance to > correct course, and suggest you do too.

For anyone that didn't reach the end.

</comment><comment><USER31> It's necessary to fire early, but investors should keep pushing money into unicorns without any business model because ...

<comment><USER32> Right. It's like putting a band-aid on cancer. Or perhaps tearing off the band-aid.

</comment></comment><comment><USER33> Why would anyone work in a person or company that is known to fire quickly?

<comment><USER4> the big thing here is the struggle between companies like amazon google apple who have tons of applicants, and a startup who has less applicants, and less experience from hiring false positives and identifying false negatives. They acknowledge that they turn down many good people, but also most if not all of the people not qualified. They arent worried about false negatives, they are worried about false positives. So they are willing to filter out a good portion of qualified people they aren't quite sure about who might have some overlapping results as people who are not qualified, knowing they are filtering out most if not all unqualified people.

Startups do not have the same level of people experiences to draw conclusions based on interviewing thousands and thousands of applicants and tracking the success of accepted applicants based on a large portfolio of information.

Probably the best thing you can do in a situation like this is GET someone from a company like that who has had years of experience interviewing candidates, and they will be able to bring along that experience of identifying potential false positives from the get go. That is honestly the biggest asset to these companies, their ability to hire and maintain high quality people.

in addition to the countless benefits and opportunities for varied career trajectories in multiple and evolving technologies for smart people once getting into these places, is the fact that they highly value the social network of these work places, and they cannot be duplicated in many places elsewhere, further incentivizing them to stay and internally recommending other high quality friends from elsewhere to interview.

<comment><USER34> There is no real evidence that companies like Amazon / Google / Apple are actually better than other organizations at filtering out false positives, or that they have struck the optimal balance between false positives and false negatives. These are simply unsupported subjective assertions.

<comment><USER4> mm, perhaps but I'm echoing documented hiring philosophies of the companies. They are aware they make mistakes. But they feel confident they filter out a majority of false positives along with many false negatives. They have their own metrics for determining this in relation to how many people they hire are able to complete a minimum satisfactory work.

They have documented people who can do this in relation to the people they hire, and even have internal portfolios tracking employees by age, experience, major, and schools, as well as how they performed on interviews. This is a fact.

Everything is subjective. But ultimately a company decides based on its own subjective priorities how an employee meets up to their subjectively defined needs for the position that person fills, and they can pretty onjectively within that context evaluate whether the person can do the work or not, and even track commitments, errors, time to cdoe to completion, amount of bugs, amount of time team has to spend fixing their bugs, etc, and parse out a pretty good idea of performance.

Thats why theres multiple books written by these companies designed to help you pass their interviews, as they have identified indicators of low performance in interviews....

All companies can do this, but many don't, and many arent based in software and therefore do not have embedded ability to track performance metrics the way code commits can.

small companies can do it too, but big companies who also have this system in place can take advantage of larger sets of data for more accurate indicators that seem to correlate with low performance.

</comment></comment></comment></comment><comment><USER35> Although there are lots of these career "advices" that are perceived as "universal truth", I hardly believe they are the only truth. Life is more complicated than that sometimes, so are your workplace. Use your best judgement(s), rather than follow the dogma. Long enough you will have your own believes, perhaps from a different angle to the same dilima.

</comment><comment><USER36> Given a shortage of supply for a job, firing early might not be a good idea. It takes months or even years to find an appropriate good fit for a job.

Sometimes it's easier to just give the person another chance, than to fire him and have no one to do the work.

<comment><USER37> This is a similar logic to folks that "settle" with marriage. It's not a long term win, and if you're not building for the long term, why do it at all?

<comment><USER38> On the countrary, there is a lot of evidence that people who "settle down" have lower levels of stress and overall live a better life.

It might not be causation but correlation, but nonetheless, you are wrong. Marriage is definitely a long-term win. For the short term, there is Tinder.

<comment><USER39> This might be an issue of idiom - "settle down" and "settle" do not mean the same thing. The latter refers to disregarding reasonable qualms and known issues with a potential life partner and going ahead anyway, more or less on the theory of "oh well, where am I going to do better?"

Doing so _can_ work out in the long run, I suppose. But it very often doesn't.

</comment></comment></comment></comment><comment><USER40> >Don't trigger the decay model of trust — why is management tolerating this shit?!

I can't reiterate this enough. Once company I worked for fired the COO that had built the operations when he had serious personal issues that bled into the working environment. I knew it was a serious company after that, I could imagine how difficult it was and he created a great operational culture and working environment before his issues.

Fast forward a few years after an acquisition. The new owners have so many Bozo's in executive positions the place is toxic.

<comment><USER41> >> Fast forward a few years after an acquisition. The new owners have so many Bozo's in executive positions the place is toxic.

Someone once summarized that as "The fish rots from the head".

</comment></comment><comment><USER41> >> After a while of trying and challenging them directly to step up you've realized that what sounded like their "experience" in the interview and even confirmed in reference checks, turns out to be things they observed but they didn't really drive (or truly understood from within) and therefore can't replicate.

That is a sign of a poor hiring process. It's a common mistake but it's the number one thing I try to figure out when hiring. I'll have to write a blog about it some time.

</comment><comment><USER42> Is intuition infallible? I want to hear stories about people who followed their intuition on staying or going (or keeping or firing) and it ended up being the wrong decision long-term. Falsifiability is IMHO an important element of arguing for "intuition"

And yet, I look back and I can't think of a single example in my own life where "listening to my gut" seemed to lead me astray. But I also don't trust my own brain to remember such instances...

<comment><USER16> if you fired someone too early, how would you ever know? They're at a different company. You'd have to somehow hear from a separate, trusted source that they were actually doing way better. Incredibly rare.

the whole thesis of this article ("you can never fire someone too soon") reeks of selection bias

<comment><USER42> Exactly!

</comment></comment></comment><comment><USER43> I like this sort of mentality in companies that think they are some sort of hot start ups that can fire anyone they feel like. I dunno how it is with management types, but this sort of approach is extremely amusing to me in niche skill areas.

For example, this happened to me a few times, but as I am 1 in 25 people in the country that can do what I do, it takes that company 12-18 month to find a replacement, if at all.

</comment><comment><USER44> The way the job market works is the larger problem. It usually forces both employers and employees to make a big commitment based on deeply imperfect information. It's like asking someone to marry after the second date, usually when they're already married and can't survive long without being married.

</comment><comment><USER45> From the last couple paragraphs this reads like a16z is still mad over getting fired years ago. They should know that being fired is a traumatic experience, and not use this as justification for their future carelessness. Two wrongs don't make a right.

</comment><comment><USER46> From the book 'Peak: Secrets of the new science of expertise', Anders Ericsson and Robert Pool state that to be an expert you must be successful at something more than once.

Which means that just because someone was successful doesn't mean they were directly responsible for it. Like being on a team where you may have even been the manager but the team players were what made it truly successful. If you were successful on two different teams then the odds of you being a key player in that success are much higher.

</comment><comment><USER47> Even more important is to take the blame yourself and fix your hiring process. In the example below, detect the exaggeration during the interview not after they start.

> you've realized that what sounded like their "experience" in the interview > and even confirmed in reference checks, turns out to be things they observed > but they didn't really drive (or truly understood from within) and therefore > can't replicate

</comment><comment><USER48> This is probably the worst advice for a young founder.

Had a client who was a 24-year-old startup founder, one of his investors got me involved to help him hire some folks and help define project process.

We hired a great developer, who freaked when he saw how sloppy the code was. Rightfully said, "We can't maintain this..."

Anyway, the founder had written a lot of it, so it wasn't a shock to him that the code was bad and needed to be re-done. Hew knew it was all quick and dirty and hacked together. By the time I got inovlved, we had issues doing deployments (deployments would take half a day and a lot of stress around testing once code went live), we had issues around infrastructure being unstable (lost 2 days worth of customer data once after a bug caused the DB to crash), and of course, nothing would have scaled. No code review, not much of a QA process, just a million things that needed to be done better -- you can cut some corners as a startup, you can't cut every corner.

There were a handful of paying clients, but most had been sold a promise of feature A-through-Z, and really the tools did like A-through-C... the moment one of them complained the young CEO lost it because he hated criticism, especially from customers, and he didn't want people to think he had lied to them... even though he had pretty clearly over-promised.

The dev I brought on wanted to re-do a lot of things, write unit tests, set up a CI / CD process, proper backups, basically do all the stuff that should have been done day one to ensure we could work fast and have confidence the wheels wouldn't come off. The founder had been on board with trying to reduce outages and crashes, but about a week into it, when one of the customers complained about something, the young CEO freaked when he couldn't simultaneously have new features and a re-done core codebase on the schedule he wanted.

So even though a week before he had said that he liked the idea of reducing a lot of our technical debt, and giving the new dev a chance to work on clean good code... since he was young (not sure if that's the best excuse) he flip- flopped. And three weeks into the overhaul (that was supposed to take 5 weeks), he was furious. "This dev is costing us time and just doesn't get our culture and isn't aligned with our goals and just isn't working out!"

I got called in, looked over what the dev had done. Nothing short of a miracle he had accomplished so much so fast. I said as much. Later that day I get an email from the founder, "I had to let [the dev] go, he just wasn't working out." I left the project shortly after, and the founder burned through another $300k in seed money (his parents') before shutting down.

Anyway this whole "trust your gut" thing... and "don't ask around before firing" \-- that's only good advice if you've got some experience and a cool temperament.

If you're a new CEO, ask around. Figure out what's going on, and if you tell people to zig, and they zig, don't get mad at them for not zagging -- they aren't mind-readers. Flipping on decisions like that are extremely demotivating to everyone who works for you, and flipping on a hire (firing someone) is the potentially most demotivating thing you can do if it's not done correctly. You hire smart people, if you can't trust their expertise, don't hire them. Since you trust their expertise, don't micromanage them, or expect the impossible from them.

<comment><USER49> In fairness, the article is about executives, not employees, but everything you said is right.

One of the biggest and hardest jobs a startup exec/founder/whatever has is having a steady hand in the face of _serious fucking freakouts_.

It's a natural tendency to blame juniors for shit being all fucked up, even though a) shit being fucked up is your natural state of existence and b) shit being fucked up is all your fault. You fucked shit up.

My cofounder and I have talked each other down from the ledge many times. I'm maybe less patient with junior cats naturally than I should be, but I know my tendencies towards Jobsian ass-chewing and I am mostly successful in suppressing my bloodlust when things go wrong and I have to fix them.

</comment></comment><comment><USER50> That's crazy; Extra Credits posted a video about this exact same topic a couple days ago, (with an extra focus on indie game development): [https://www.youtube.com/watch?v=mnhlDwCRwkU](https://www.youtube.com/watch?v=mnhlDwCRwkU)

</comment><comment><USER51> I like the article, and it has some really good ideas. And it is not about making firing people easier or cheaper. It is about on how to decide when to fire someone.

About firing fast and easy, it is a bad idea.

I work in Sweden. I don't think I have seen ever anyone fired. What I have seen is some of the best hiring processes. The process looks at the candidate values, and skills. And there is a discussion about what we expect from her, and what she expects from the job.

I worked previously in Spain, I saw a lot of people fired for no good reason. And they were also hired without too much attention. Shorts interviews, no real testing, are part of a process that ends consuming a lot of effort from everyone after hiring someone that is not the correct person. Other times that people is good, and leaves, because was not the job for them.

Both seem related. Cheap and easy firing produces careless recruiting. And that is more expensive that people realizes.

<comment><USER52> I have worked in Sweden, and I would like to offer a counter point.

I don't think we disagree that the reason the hiring process is so involved in Sweden is because it's so hard to fire someone. This results in a situation where the company does everything they can to minimise the risk of hiring the wrong person.

The downside of this is that companies will not take any chances when it comes to hiring people. I believe this is the reason why I have seem some really bad diversity (both cultural and gender) in the Swedish tech industry, compared to other countries where I have worked.

If it's easier to fire someone, it's also easier to take a chance on someone that might night be the "perfect candidate" at first glance, but perhaps he or she will shine if given the opportunity.

<comment><USER53> I work in the UK and it's similar. Except we have a lot of diversity due to a vibrant contractor (at-will) market. Which the Tories are trying desperately to destroy, for some reason.

Permanent employees are basically impossible to fire. It's a mixed bag I think. On the one hand, there is a large social benefit to having such gov enforced job security. On the other hand, it drives down wages, and hurts companies that get stuck with a really bad employee. At least as workers we can choose to earn more money and take the riskier route via contracting.

<comment><USER20> "Permanent employees are basically impossible to fire."

That really isn't true at all - you can be fired for pretty much anything in the first two years and after that the process is pretty straightforward.

I've never seen a company fail to get rid of someone they didn't want working there - one way or another.

<comment><USER32> It's harder to do in Europe, but it's still possible. Especially, as you say, if there's management determination that the person has to go.

<comment><USER54> You really can't generalize across Europe

</comment></comment></comment></comment></comment></comment><comment><USER55> "No one was ever fired too soon"

Steve Jobs may have been but then again maybe he did need time to cook in Next before coming back.

</comment><comment><USER56> It's never too early to remember that in a startup the decision to get fired depends mostly on the emotional state of a founder. That there is no process in place. It's random. If you do get fired, you have a good chance of ruining your carrier, not being able to get a good reference from your last place of work, wasting opportunities.

</comment><comment><USER57> Jeepers. That text needs to be a lot darker or a lot thicker.

</comment><comment><USER58> I have a different take. Never forget that you can get fired but also never forget you can fire!

You can fire jobs.

You can fire friends.

You can fire customers.

Makes life so much easier!

</comment><comment><USER59> >To be provocative: No one ever fired someone too soon.

how about when the board fired Steve Jobs? (Specifically, stripped him from all responsibilities, removed him from the head of the mac division, gave him an office with nothing to do). No?

After all, he didn't code, was kind of a weirdo, and the board had every reason to have some doubts.

Was that a "wrong" decision?

<comment><USER60> It's really hard to imagine an early-90s Apple that Jobs wouldn't have left anyway - probably with high drama - if he hadn't been fired.

But the Apple story makes the point - most CEOs are mediocre. Sculley and Amelio (and Spindler, whom almost everyone has forgotten) were all competent in their previous jobs, and usually also in subsequent jobs.

But you don't want to settle for competence in the C-suite. You want outstanding - a genuine 10X CEO.

There aren't many of those around. But there are plenty of 0.1X pretenders, and you'd _better_ hope you don't end up hiring one, because no one will do more damage to a company.</comment></comment>