Don't distract new programmers with OOP - <AUTHOR> http://prog21.dadgum.com/93.html <comment><USER2> Provocative.

The suggestion is that thinking in OO terms makes you think about architectures instead of programs, and the result is to move you away from thinking about the problem and the solution and towards thinking about the program's organization. This is always assumed to be a good thing, especially when accompanied by the usual examples of writing programs for teams of programmers with varying levels of skill.

But if we grant that non-OO is better for someone learning to program, why wouldn't it be better for someone reading a program for the first time?

EDIT:

Thinking further about this, I am not against the idea of design considerations that should be kept from the beginning programmer. But OO isn't really a design consideration, it's a _metaphor_.

If it really "worked," then new programmers would be looking all confused trying to write a Towers of Hanoi program, and you would explain, "Think of each tower as its own thing. What can it do? What does it have?" And slowly you could tease out a program by designing objects from the ground up.

But if it actually doesn't work to teach programming using objects, if you teach programming without objects and introduce them as an 'advanced' subject, then at some level you have to wonder if the metaphor is fundamentally broken. If the purpose of OO is design and organization rather than a fundamental way to think about programs, then really we shouldn't say things like "Everything's an object."

We should ask what we need to do to design well-factored programs that are cohesive without being coupled and then design language features that directly address those organization requirements rather than thinking that there is this obvious "metaphor" that naturally leads to well-organized programs.

<comment><USER3> I don't know that OO's main goal is to be readable, but rather to manage complexity (which _should_ help readability, but I don't think that's the focus). There's an inherent level of complexity in OO that isn't necessary when you're solving basic, learner type problems, but it can help keep complexity down when you're solving problems that have solutions that can't be kept in your head at any one time.

To put it differently, think of an algorithm that's constant time, but has a very large constant and an algorithm that's O(n). The constant time algorithm will be worse for small sets, but better for large sets (once n > that constant). That's the problem with teaching OO to people new to programming. You're adding an additional thing to an already difficult topic, and that thing you're adding doesn't really benefit you at that level of problem, but get to a bigger problem, and it starts to make sense.

<comment><USER4> I agree, but it's good to step back and think why that's true.

The real value in OO programming is being able to reduce complexity by reusing code in a new ways. Either by creating several instances of the same object that all manage a complex internal state, or by inheriting from another object and extending functionality. I need to add a window, I already have lot's of windows, but this one is different because X works in OO. I need to build my first window starting from scratch and suddenly OO does not give you any leverage.

Which is why OO seems pointless for most being programmers, they can't deal with sufficiently complex problems to gain anything from OO programming. However, you don't need to understand object's to use them. It takes a while to understand why you can keep adding <<'s after cout, but most beginners quickly prefer it over sprintf.

<comment><USER2> _Which is why OO seems pointless for most being programmers, they can't deal with sufficiently complex problems to gain anything from OO programming._

Beware, this is not biconditional. I'm sure you won't have to go very far to find programmers who deal with complex problems but who do not feel that they gain anything from solving them using OO.

And there is also the argument that OO as implemented in popular languages introduces its own complexity, such that it ends up being used to solve the problems it introduced in the first place.

</comment></comment></comment></comment><comment><USER5> Speaking from personal experience, when I transitioned from C (first language that I was three months into) to Objective-C, I couldn't STAND the number of cutesy metaphors used to describe what objects were and how they functioned: "Like, you can send the duck a message to swim, or to fly." "Ducks inherit from birds."

Coming from a highly plausible programming world of data and operations on data, this came off as nonsense. I wanted to tear my hair out finding a sober explanation of what an object actually WAS, practically, in practice instead of hearing them referred to as things that could be told to do stuff. Apple's Object-Oriented Programming was by far the most enlightening document in my early days:

[http://developer.apple.com/library/mac/documentation/cocoa/c...](http://developer.apple.com/library/mac/documentation/cocoa/conceptual/OOP_ObjC/OOP_ObjC.pdf) (chapter 2)

<comment><USER6> > Coming from a highly plausible programming world of data and operations on > data, this came off as nonsense.

It _is_ nonsense.

On IRC the other day, I said this:

        19:19 < xentrac> I propose a new rule for discussions of object-oriented
                         programming
        19:20 < xentrac> which is that anyone who brings up examples of Dog, Bike, Car,
                         Person, or other real-world objects, unless they are talking
                         about writing a clone of The Sims or something,

        19:20 < xentrac> is immediately shot.

<comment><USER7> Person _is_ shot.

<comment><USER8> Person _has a_ GunShotWound, which _is a_ subclass of Wound. (cf. AbrasionWound, LacerationWound, etc.) Also note the new properties such as bulletType, entryPoint, and fragmentationPattern.

<comment><USER7> Sorry. It's Java. The GunShotWound has to come from a GunShotWoundFactory.

<comment><USER9> Unfortunately, GunShotWoundFactory now needs to implement AbstractGunshotWoundFactory so that we can support multiple types of gunshot wounds.

Of course, we'll need an AbstractGunshotWound as well and a subclass for each type of gun used.

Needless abstractions make my head HURT!

<comment><USER10> DON'T WORRY GUYS! Dependency injection to the rescue!

<comment><USER11> The WoundFactoryFactory will take care of it.

<comment><USER10> Actually, I'll be honest: I quite like dependency injection. There are a lot of really good things that can be done with Guice. I've written one for C++ here: <https://bitbucket.org/cheez/dicpp/wiki/Home>

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER12> As a former TA, I agree.

Objects are not ways of solving problems. They are a metaphor, which gives you _a_ handle into the problem space.

OO design is building a metaphorical data storage mechanism for your system, and then you need to cross the data into the metaphor and back again.

I wasted countless hours when learning programming trying to wrap my head around coding in an OO fashion. Eventually I integrated enough OO to make my programs better. But I never really got 'into' OO, although I tried real hard!

I don't have good words yet to explain the problem in detail, but fundamentally, a metaphor is not the solution. Most discussions of object orientation badly confuse themselves with that. As an example - an interface (ala Java/C#) is not an interface as a hardware engineer would speak of it: an interface from the OO perspective is some sort of promised type or 'protocol'.

Are you building a model of your problem? Or are you solving your problem. I'm willing make a small wager that building models of your problem doesn't pay off until you really start scaling your system in some direction. If we use the Pareto idea, only 20% of your systems actually need the heavyweight approach - the other 80% can be put together without the heavy object-oriented machinery.

Anyway, I'd rather be given the opportunity to teach in Scheme or other functional untyped language, instead of Java or C++. :-)

<comment><USER13> _I don't have good words yet to explain the problem in detail, but fundamentally, a metaphor is not the solution._

A number of years ago I wrote <http://www.perlmonks.org/index.pl?node_id=318257>. You may find that it solves the problem in a reasonable mount of detail.

</comment></comment><comment><USER14> couldn't agree more. i started with java in high school and was too caught up in "public static void main" to realize that it was up to me to define methods that made sense and that things generally ran top to bottom. switching to php for a while made everything "click" before heading back to java

getting rid of CS terms and data types allows you to learn how to think in program flow and "what am i actually doing here". failing to capture the attention in this first step is lethal to most people that otherwise would be good at programming if they hadn't run quickly at their first try

<comment><USER15> That's precisely why I think Java is a horrible language to start people out in.

Well, not language. _Library_. It's abstracted to the _extreme_ , and confusing as heck to anyone just starting to learn how to _think_ about how to program.

Start people out in something simple. Ruby can teach bad habits, so don't tell them about monkey patching, but it's so simple it's a great way to hook people, and has simple console / file IO that'll let newbies actually _do_ something with their skills, instead of being glad their project doesn't overflow its array bounds or get stuck in hideous C input handling deathtraps ( _which_ flags do you have to reset in the input stream if they start inputting Japanese? I forget...)

Best of all, despite being OO, _you don't need a class to start doing things_. Something Java gets wrong for beginners.

      #!/usr/bin/env ruby
      puts "hello world"

Classes can wait, they're a whole can of worms that should come after people learn to think clearly enough for a computer to understand them.

<comment><USER7> If you're burnt out on using Java for introductory courses, consider using Groovy. (<http://groovy.codehaus.org/>). It takes a lot of the pain and boilerplate code out of java, making it easier for students to focus on what they're actually doing and not writing "public static void main String args" all of the time.

Similar to your example, this is a valid groovy program:

println "Hello!"

But, unlike Python or Ruby, you're still in the Java world so migrating back to to pure Java is a lot easier. Though, the shrieks of pain you'll endure when you explain why they now have to write constructors or getters and setters might hurt. :-)

<comment><USER15> Have seen it, but never used it. It looks decently active on the forums, despite the home page showing an award from 2007 (and looking older than that)... how's the community / code health? On something like a .NET-to- Ruby/Python scale? I'll keep it in mind for any future Java necessities.

</comment></comment></comment></comment><comment><USER16> Interesting, but one could go further with this: there still seems to be the assumption that learning OOP concepts is indispensable and necessary in the long run.

This may or may not be true depending on the application area, language and intent of the programmer. Some languages and frameworks make it impossible to get anything done unless you know how to subclass things; at the other extreme you've got Stephanov-inflected C++.

Arguably you would have people learn at least a little more about algorithms and data structures of greater complexity before dropping the OO-hammer. I still have moments where mid-way into astronauting up a class hierarchy I realize that all of this could be done more clearly in 10 lines of STL/Boost (and yes, I'm aware of the problems of that style of coding, too).

<comment><USER17> I agree but STL/Boost hard tiny bit to hard. Teach that stuff with Scheme, python or something that isn't <insert what you hate about C++>

<comment><USER16> You misunderstand. I'm merely using STL/Boost as one example of advanced non- OO programming. Many other such paths to sophisticated programming exist that don't go through OO, including the ones you name.

I use STL/Boost in this case not because I think they're wonderful but because they're realistically what I'd have to use, as our codebase is mostly C/C++.

</comment></comment></comment><comment><USER18> I don't think objects unavoidable lead beginning programmers to get lost in "architecture."

My go-to language for teaching new programmers is Ruby--in part because it's my strongest language, but also because it's capable of expressing most programming problems intuitively.

Is Ruby object-oriented? Yes and no. Certainly, objects are core to its design. But it's also a scripting language that can be used purely imperatively. Or you can use it like a functional language.

What makes it so good for beginners, in my opinion, is that in Ruby, things are objects that _naturally seem like objects_. For example, it's very natural to think of a string as an object that can be passed around and manipulated, and Ruby makes this totally intuitive.

Writing "Hello world".downcase.sub('hello', 'goodbye') doesn't tempt beginning programmers to create bizarre class structures or reams of boilerplate code. But it does make you feel empowered, and because it's so darn logical, it makes programming seem way less scary to a beginner.

<comment><USER19> Agreed. It's the hogs like Java, C# and C++ that gave OO a bad name. Moreover, in dynamic OO languages like Ruby, even scary things like design patterns usually take lot less time and lines of code to implement and, later, understand.

</comment></comment><comment><USER20> I'd actually skip on Python and give them Scheme with a copy of "The Little Schemer."

However, I agree with the OO sentiment. It brings a lot of vernacular and concepts that are not important to the building of a program; at least not at first. Classes, objects, meta-classes, inheritance, multiple inheritance, method resolution order, operator over-loading, class methods, static methods... it's all baggage for a new programmer. It's an interesting way of organizing code and encapsulating the responsibilities of different parts of a larger program... but it's a purely architectural tool.

For a beginning programmer they aren't worried about such design concepts. They just need to understand inputs, outputs, and control flow. A single function is a program for them. Once they have a grasp of the fundamentals then you can think about introducing them to OO programming.

Beginner's mind. It's hard for an experienced programmer to grasp.

</comment><comment><USER21> Exactly.

Its like trying to teach someone basketball for the first time and at the same time trying to explain a pick and roll, a full court press, Triangle offence etc. You'll just confuse them.

Teach the basics and slowly ease into the big picture/strategy stuff when they have a handle on the fundamentals.

</comment><comment><USER22> It's a question of scale. Modules become increasingly important for larger projects. It's a form of infrastructure, ridiculous for a birdhouse, essential for a city.

</comment><comment><USER6> I wonder if part of the problem is that objects and classes are additional concepts to understand, on top of statements, variables, functions, modules, data types, if, while, for, and so on. In a language like the ς-calculus, you wouldn't have to introduce objects and classes separately from those other things.

</comment><comment><USER23> Object Oriented programming exists because it is how humans conceptualize the world around them. Humans think in objects and actions on, in and between objects. OOP is a translation of natural thinking into systems and behaviors. Why is this a bad thing, especially for learning?

I guess my question is, why does OOP and an natural translation between the real world and the code world lead to this discussion and a certain level of condescension around utilizing the concepts of OOP?

<comment><USER17> Why don't you use Erlang? Its much closer to you definition of OOP.

<comment><USER24> Exactly.

And I think that Erlang is most closest to Kay's definition of OOP. (If we can drop "Everything is object")

Erlang processes are objects.

</comment></comment></comment><comment><USER25> Better yet, teach them a language which doesn't even _have_ the "extra layer of [OO] nonsense". Teach them something simple, clean, and logical. Teach them Haskell.

<comment><USER26> You need monads to do any IO, that's not an easy first lesson. And you are a great distance from hardware.

<comment><USER27>
        main = print "Hello, World!"

Not a monad in sight. Yes, print is an IO Action, but you don't have to use monads to do IO. Add in 'interact' and a you can be writing trivial stdin / stdout programs very quickly.

</comment></comment></comment><comment><USER28> A reminder, The the objects are only in your mind not in the computer. They exist only as a metaphor to allow you to wrap your mind around programming easier, Rarely does the easier path yield any benefits except shorter travel time.

</comment><comment><USER29> I couldnt agree more. The first "programs" I ever wrote were BASH scripts. Definitely no OOP distractions there.

<comment><USER15> That's hugely debatable, actually. If you ever called a command-line application in one of those scripts, you called what's essentially an object - it encapsulates its own behavior, hides how it does it, you can create multiple ones (instances) without them competing or sharing information, the command line arguments are arguments to the constructor, etc. They're nearly identical.

<comment><USER30> OOP concepts aren't what's getting in the way. It's the boilerplate most languages require for their preferred object systems. A good language for beginners would have to make it easy to progressively encapsulate things as the program grows, without requiring substantial rewrites. It should be very easy to go from a few named variables to an array or dictionary, and then to add methods to that to make it a proper class.

<comment><USER31> Sounds like JavaScript or Lua.

</comment></comment></comment></comment><comment><USER32> People often ask what's the single biggest difference between a good programmer and a great programmer.

I've heard a lot of good answers dealing with talent, hard work, experience, imagination, communication, cleverness, simplicity, vision, and even laziness.

 _The shift from procedural to OO brings with it a shift from thinking about problems and solutions to thinking about architecture._

This makes me think about my answer: You first enable yourself to become a great programmer the moment you stop worrying about your own problems and focus primarily on your customer's.

<comment><USER33> Despite the other comments, I think you make a very valuable point. Take out the "customer" angle and I think they'd also agree. It's really thinking about the problem, working the problem and solving the problem. Thinking about and working on your toolset is not solving the problem. Whether the problem is yours or your customer's makes little difference.

</comment></comment><comment><USER34> As someone who is just making the transition to OOP in Python I totally agree with this post.

I started with PHP:

Learning programming syntax was really annoying then learning loop and nested loop structures was hard then learning a set of useful built in methods was hard then learning how to interact with other systems was really hard

All the time I was learning this basic stuff I was writing code primarily for myself. I was the only one who maintained it and had to use it.

Now that I've moved over to python and I'm working on a code base that I expect to last, and will get to work with others on, OOP makes a huge amount of sense.

OO code may have more overhead to write (it does) but I find it much easier to _read_ good OO code now that I understand the model, than I ever found procedural code even as I grew comfortable with writing it.

As a number of others have mentioned, OO code is about architecture and that seems to be what matters when you're trying to grok other peoples code. The specifics of how they did it only matter when you start debugging or optimizing. (In my limited experience to date)

I look forward to really getting OO, writing lots of code, and then starting to climb the functional programming mountain. But the poster is right, start bare bones, start simple, and build from there!

</comment><comment><USER35> I think that a language for beginners should be as paradigm agnostic as possible. Lua does not force OO or functional programming upon the user. And unlike Ruby, there aren't a bunch of list-like datatypes like lists, arrays, and hash tables to keep track of. There is just the table datatype which takes care of all of those.

<comment><USER36> Lately I lament that Python, Perl, Ruby and PHP are the dominant scripting languages instead of Lua. None of the former really justify their extra complexity, IMO.

</comment></comment><comment><USER37> I think this is a bit silly. The problem isn't OOP, it's how OOP is taught, and how OOP is abused.

To be honest most programming education is so terrible that it will still come down to who has the talent and passion to figure things out on their own, that's been true completely orthogonal to the presence or absence of OOP education.

<comment><USER17> And thats we people write blogpost about it.

</comment></comment><comment><USER38> As a new programmer I felt blessed when I learned OOP.

I could actually write long and clean pieces of code, without spending double time on restructuring them. Clean and coherent structure is important for understanding, while understanding your own code, and remembering what it does, creates a more fruitful development. Since new programmers often work iteratively by adding new features to their code, this is rather positive, than negative and that extra learning effort is always rewarded.

By knowing OOP you can access other's libraries in the language you recommend. By using other's libraries and by altering them, you can create more cool stuff faster.

</comment><comment><USER39> Or you could use a language that uses object orientation in a more natural way, such as Ruby and Scala, which both are fundamentally OO languages.

You can do procedural-y things with both languages, much to their credit, but packaging up functionality is both natural and intuitive.

Over building APIs is not a hallmark that Objects are bad. They're a hallmark of bad design.

So, yeah, i agree, prototype a minimal solution and iterate, and teach others to do this. This is an issue that is orthogonal to object orientation. At least, it is in languages that don't make you jump through weird hoops (C++ & Java, i'm looking in your general direction).

<comment><USER40> The delta between Python and Ruby is way, way smaller than the Ruby community seems to think it is. You are aware that everything is an object in Python, too, right? The idea that that isn't true still seems to be knocking around the Ruby community. Everything he said about Python applies precisely to Ruby (or fails to apply in exactly the same way if it is a bad argument), because there's hardly any difference that matters to a newbie.

"But, but, _len_ is a function! And you can't monkeypatch the base classes even though you can monkeypatch everything else!"

Yes, please, by all means burden your neophyte with that tirade. They'll really appreciate it while they're trying to figure out what an "if" statement really does or why calling a function with the wrong capitalization doesn't work.

<comment><USER41> > You are aware that everything is an object in Python, too, right?

Python is missing encapsulation and message passing. It's object model seems to be similar to something like PHP or JavaScript: objects are essentially hashes. In practice, that's not a huge deal, but they aren't quite the same.

This is not important for beginning programmers, but for programmers thinking about their toolset more information can only help.

<comment><USER42> "Any traditional OOP programmer might tell you that essential elements of OOP are encapsulation and message passing.

The Python equivalents are namespaces and methods.

Python doesn't subscribe to protecting the code from the programmer, like some of the more BSD languages. Python does encapsulate objects as a single namespace but it's a transluscent encapsulation."

From: <http://www.voidspace.org.uk/python/articles/OOP.shtml>

<comment><USER43> TBH, private fields are a stupid idea. It's just a cutesy concept that gives the newbie a false illusion of being in control. I've never seen a program where a private field was actually _important_ to the integrity of the program.

<comment><USER44> I'd have to politely disagree; if your class has mutable state and you want to maintain some invariant relationships amongst the elements of your class then as far as I can see you really need to be able to specify that some operations can only be performed within the class. If your class is immutable then I'd agree that in most cases privacy offers you few benefits.

<comment><USER40> Yes, that's the theory. In practice it doesn't seem to work out so well. Neither the promised benefits of using private fields actually manifest, nor the promised costs of not having private fields, but the costs of actually having the private fields manifest in spades. In cost/benefits terms, the benefits are almost entirely theoretical and the costs much higher than advertised. I consider them a major net loss for OO.

<comment><USER44> I wouldn't really agree that it doesn't work out in practice. For the systems that I work on, the concept of privacy is extremely useful, perhaps we're doing things 'the wrong way' to believe that but I don't think that's all that likely.

What would you suggest as a better alternative, outside of a purely functional approach? Just as an example, suppose that Java's LinkedList class didn't have a cached size and that instead it went and iterated its elements to calculate its size each time someone asked for it. I might write a wrapper around LinkedList with two private variables, the LinkedList and an int to cache its size in. Then I would update the int each time an operation was performed on my member list. If I can't make those two members private, how can I ensure that no one accidentally updates the list without updating the size, or vice- versa. It mightn't be an unreasonable mistake for someone to think calling mylist.size = 0 would empty the list. What is the 'safe' way of constructing this concept?

<comment><USER43> > If I can't make those two members private, how can I ensure that no one > accidentally updates the list without updating the size, or vice-versa. It > mightn't be an unreasonable mistake for someone to think calling mylist.size > = 0 would empty the list. What is the 'safe' way of constructing this > concept?

Conventions. In Python, for instance, all private fields and methods start with a double underscore, i.e., '__'. This is merely a convention, outlined in PEP8. Documentation tools don't pick up "private" fields. Even when they do, they don't list them in the same section as the public fields.

You could argue about the safety of this approach, but at some point you have to let go of the training wheels and let programmers make their own judgments.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER45> This is very true. I write most of my Python code using only procedural/functional constructs and limit the OO parts to a minimum and that's the way I want to do it.

Now, I haven't known exactly _why I want_ to do this, except maybe that OO constructs soon turn my code ugly but that's a gut-feeling argument which I've kept to myself. Maybe I've thought that I've unconsciously absorbed from the athmosphere enough of that Java-hating mentality to let it show up in the way I write Python, too. But maybe I've been on to something as well.

I'm glad to read about someone else thinking in the same way.

</comment><comment><USER46> _Modularity_ is a fundamental design principle that pre-dates computer science: complex systems should be broken down into independent components that interact through formal abstractions. It's very simple and obvious. Everyone understands it on some level.

OOP is really just taking the principle of modularity and making it a first class language feature. There's no reason not to teach it to a beginner. They are going to be using the concepts right away anyway.

Also, OOP is ubiquitous in the real world and rookie coders need to get involved with the real world as early as possible.

<comment><USER17> If you build a house you dont need worry about the inside of bricks. Objects dont have that property, Pure Functions do.

The Objects loss this proberty because they have inheritance. The other problem is that every in OO the data is mixed with the functions.

Rich Hicky on how it can be done right: [http://www.infoq.com/presentations/Are-We-There-Yet-Rich- Hic...](http://www.infoq.com/presentations/Are-We-There-Yet-Rich-Hickey)

<comment><USER47> _If you build a house you dont need worry about the inside of bricks. Objects dont have that property, Pure Functions do._

I see this _exactly_ the other way around. Objects makes sure you don't have to worry about what's on the inside, but if you use pure functions you need to know how the function is implemented, how it processes data, how it expects input to be and how the output will be.

Using pure functions requires you to seek out lots of information and verify implementation. Not that you shouldn't investigate this when using OOP, but in OOP a lot more of this is formalized in class-definitions IMO making the interaction easier to understand.

The way I see your analogy, is that if you use pure functions, the electricity in your house needs to know what material the bricks are made of so that current doesn't accidentally leak and cause a fire. With OOP this is a detail you don't have to worry about as long as the pieces fit.

If that sounds somewhat flawed or too simplistic, I will take the liberty of blaming the poor metaphor. I'm just pointing out that I see the exact same metaphor in the exact polar opposite way ;)

<comment><USER48> Why would I need to know the implementation and how it processes data?

The entire point of pure functions is that you don't need to know. Referential transparency guarantees that a pure function given inputs X and Y always returns the same output Z. So if I just follow the interface specification about accepted inputs and accepted outputs I can switch in any arbitrary implementation of that function and have my code keep working.

<comment><USER47> _So if I just follow the interface specification about accepted inputs and accepted outputs I can switch in any arbitrary implementation of that function and have my code keep working._

The funny thing is that this is what I would say about OOP, while for functional solutions I often find the specifications much looser, so that I cannot trust this to always be true.

I'm not saying you are right and I am wrong. But I am saying that the arguments about what holds true for what, and especially the arguments for "OOP is bad" or "FP is bad" etc, they just seem to be highly subjective.

And unless someone can come up with empirical evidence to show that one side is actually better/right, I find this debate both pointless and rather amusing. Pointless in that it doesn't give more insights. Amusing in the sense that it makes people reveal lots of the preconceptions and prejudice against things they seemingly don't fully grasp.

<comment><USER17> What how do you have to know about the implementation of the function? Think of something like quicksort or a partiton function (partition 2 [1 2 3 4]) => ([1 2][3 4]). How do you have to know anything about that functions implemantation. Sure if the function has a name like myfunction and no docs then you have to look at the code but thats the same with OO.

In clojure you can say (doc anyfunction) and you will get a description of what the function does and it does only that.

You describe the perfect case in OO where you have only objects that only have immutable members and pure methodes. :)

I n the realworld I you often see that something does not work anymore because im some other object some variable changed or that it worked first but after a variable somewhere changed it breaks. With inheritance adds to that a hole set of new problems.

I'm not saying you cant make a good design with object im saying with a FP stile its easy to do the right thing while with objects its harder to do the right thing.

Thats as good as I can argue in a comment.

<comment><USER47> _Think of something like quicksort or a partiton function (partition 2 [1 2 3 4]) = > ([1 2][3 4]). How do you have to know anything about that functions implemantation._

Well. I need to know that it accepts two parameters, first being an integer, the second being an array of integers.

In an OOP solution this would at least be exposed by type signatures, something you don't always see in FP solutions (often due to type-inference). Hence you need to check the implementation.

And this is for a simple example. What about more complex example? Where the input-data has a more complex nature? Take the following example:

        var data = [ { id: 1, value: 2 }, { id: 2, value: 3} ];
        var ordered = orderByValue(data);

Ignoring the "var data ="-line: Without checking the implementation, how would you know how the input-data should be formatted? What types and properties are needed, and in what format the function accepts the data? A seq? A list? An object with properties? You don't.

In C# the same function would probably be contained in a relevant class and have a signature akin to the following:

        IEnumerable<ValueHolder> OrderByValue(IEnumerable<ValueHolder> data)

Now I _know_ what it returns, what it expects and don't have to worry about that. The type-signature tells me everything. The types it expects tells me everything. Moreover, this is probably already implemented on a specialized collection class, so all I need to do is:

        var data = new ValueHolderList();
        // populate
        var ordered = data.OrderByValue(); // notice -pure- implementation in OOP ;)

Again. The implementation tells me what I need to know. Details are blackboxed, abstracted and objects easy to work with. I don't have to worry about functions, context, what they expect and in which order the glue is expected. In FP you are more commonly exposed to the internals of things and need to figure these things out yourself.

I'm not saying I am 100% right and you are 100% wrong. I'm saying there is lots of grey here which this thread doesn't really seem to cover or acknowledge.

FP is not a silver-bullet and nor is OOP. FP has strengths. So does OOP. Lots of the "weaknesses" I see people complain about with regard to OOP here are what I consider weaknesses in FP and strengths of OOP.

I sometimes wonder if we are living on the same planet.

<comment><USER31> In both OOP and FP, to know what a function (or a method) does, you need (at a minimum) to check its type signature. There are _many_ OOP languages which do not use explicit type signatures, and many FP languages which do; it seems to me that you have confused the OOP vs. FP issue with the issue of explicit vs. implicit typing, or perhaps with static typing vs. dynamic typing. There are languages available to suit pretty much every combination of those properties, so you can easily avoid whatever you don't like.

Further, when you check a type signature, what you read is much more valuable in a pure FP context than in a typical OO context, because OO languages generally (1) allow and encourage the use of state, and (2) do not distinguish in the type system between functions/methods that use state and those that don't. The type signature of a pure function strongly constrains what that function can actually do - so much so that it's possible, and effective, to look up the function you need just by specifying the type that you expect it to have. In a typical OO language, the type signature indicates much less about a method's behavior, because its inputs include not only the parameters you provide, but also the entire "world" at the time it is invoked; similarly, its outputs include the entire "world" in addition to its return value. As an example, a pure function that takes no parameters can only be a constant, but an impure method that takes no parameters could play a song on the speakers, display a window on the screen, or launch a missile.

FP and OOP certainly have both strengths and weaknesses. I suspect one reason that OOP catches so much flak around here is that people are more familiar with it, and the flaws in tools you're familiar with are easier to see. Unfortunately, when you're not familiar with a tool, it can also be easy to see flaws - flaws that aren't really flaws at all, but simply aspects of the tool you don't yet understand. The result of this, I think, is that one should ignore criticisms of OOP from people who aren't deeply familiar with it, and similar for shallow criticisms of FP. Unfortunately, there are a lot of both on Hacker News.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER49> I didn't even know this was a big, controversial issue still. Coming from a PHP, Ruby, and Obj-C background (and having taken C and Java classes in college), I always saw it as "use objects when you want things to be easy, use C when you want things to be fast".

Of course, being primarily a web developer and not having implemented a linked list or a bubble sort since college, the anti-OO people probably wouldn't consider me a "real" programmer anyway.

<comment><USER50> This is a serious question: is there ever an occasions when someone working on a real-world project should be implementing linked lists? I've no experience with C, but surely this stuff comes from libraries now?

<comment><USER51> The C world has various reusable linked lists, but yes, there is occasionally a reason to implement one yourself: a {data, next} tuple usually fits in a single cache line, whereas some libraries only offer {data pointer, next} tuples, which requires loading in the memory that <data pointer> points to. The performance difference _can_ matter.

That said, some more agreement on reusable code may be useful, especially for things that aren't as easy to implement as linked lists.

</comment></comment></comment><comment><USER52> Hm, nobody seems to have yet mentioned that OOP was practically _invented_ as a teaching tool for novice programmers: [http://samizdat.cc/shelf/documents/2004/08.02-historyOfSmall...](http://samizdat.cc/shelf/documents/2004/08.02-historyOfSmalltalk/historyOfSmalltalk.pdf)

<comment><USER17> Atomic Power was invented to build bombs do you really thing that we should use everything for what it was invented for?

</comment></comment><comment><USER53> This OO complexity becomes more pronounced once you start talking about serious persistence, which today, likely means SQL.

Has the object/relational problem been solved? Last I checked, it's still a confusing and complicated inelegant hack-job to reconcile inheritance/polymorphism vs. relational storage schemes.

</comment><comment><USER54> I just think of it in terms of OO is important for the design patterns. That's when I'd 'use it.' I wouldn't bother trying to explain the theoretical underpinnings to a beginner - the definitions passed around in these types of debate are hilariously confusing.

</comment><comment><USER55> My obligatory link to Joel Spolsky's lament on JavaSchools and championing of C: [http://www.joelonsoftware.com/articles/ThePerilsofJavaSchool...](http://www.joelonsoftware.com/articles/ThePerilsofJavaSchools.html)

</comment><comment><USER56> I'd start with BASIC. For real beginners and kids, GOTO is their friend. [http://erehweb.wordpress.com/2010/06/24/goto-considered- help...](http://erehweb.wordpress.com/2010/06/24/goto-considered-helpful/)

</comment><comment><USER57> I completely agree. I wish I was taught Python or Ruby at University instead of Java.

</comment><comment><USER58> If only someone told me what on earth they mean by OOP...</comment>


North Korea propaganda taken off YouTube after Activision complaint - <AUTHOR> http://www.bbc.co.uk/news/technology-21351051

<comment><USER2> The original video, <http://www.youtube.com/watch?v=HKWJSKYBDXE>

Currently says, "This video has been removed by the user."</comment>


Developers are still making games for NES - <AUTHOR> https://www.washingtonpost.com/video-games/2019/11/28/nes-console-was-discontinued-these-developers-are-still-making-games-it/ <comment><USER2> Yeah but..where can we download them? (Sorry, site not available here)</comment>


Show HN: Super Mail Forward, an HTML email that evolves as you forward it - <AUTHOR> https://medium.com/@hteumeuleu/super-mail-forward-an-email-that-evolves-as-you-forward-it-84466596f30d <comment><USER2> This is great for pranks: you send a serious looking email to someone, and then they forward it to someone else thinking they sent some chart or whatever but the next receiver instead sees another picture of your choosing

<comment><USER3> Or a new way to distribute spam? ;)

<comment> semi-extrinsic Or spearphishing. Send a secretary something that looks like a nice business proposal, then when she forwards it to her boss it's a link to some XSS attack.

<comment><USER4> Should be the other way around. You forward an email that's "obviously" spam, and then the abuse guys go "what do you mean, this is a regular project status update!"

<comment><USER2> you can use it to send "for your eyes only" stuff.

example: send an image to Mary and tell her not to send it to anyone else. She inevitably sends it to someone else, but the image magically changes to another image that says a message, maybe it says "DAMN IT MARY, I SAID DON'T SEND IT TO ANYONE ELSE!"

<comment><USER5> I'd replace it with "Mary's STD Test results" so the person who receives it will be very confused.

</comment></comment></comment></comment></comment></comment><comment><USER6> TL;DR: A series of markup and styling hacks that exploit HTML interpretation quirks of various web email services can be hacked to intentionally vary message appearance between services. Coupled with forwarding, which further transforms the email using service-specific quirks, you can make a game where different paths of forwarding across services trigger different appearances.

Fun hack! I feel like there should be some clever practical applications but I'm drawing a blank.

<comment><USER7> One great application of this would be to hide the unsubscribe link if the email is forwarded.

<comment><USER8> no anti-pattern is ever "great".

<comment><USER9> I wouldn't call that an anti-pattern, it prevents people you forwarded the mail to from easily unsubscribing you from the mailing list. They aren't subscribed, they shouldn't be able to unsubscribe.

</comment></comment></comment></comment><comment><USER10> More than anything, this thing shows the sad situation of CSS support in different email clients.

<comment><USER11> Sad situation? I'd say it's limited for security and user comfort. I can't say I've ever felt HTML emails beyond basic text formatting and links improved my life.

<comment><USER10> How is Gmail not supporting 'box-shadow' or ignoring 'display: none;' but allowing 'display: none !important;' a security feature? Not supporting classes? Why does AOL messes with inline URLs (so that they stop working)?

This article is full of examples that are obviously bugs. And worst - it's all neither documented nor standardised.

<comment><USER12> And then there's Outlook. My quality of life is so much better since I left the email marketing industry.

</comment></comment></comment></comment><comment><USER13> One challenge many services face when sending emails is that you often want to log a user into the account if they've clicked in from an email – after all, if they have access to the email account, they can usually reset the password.

But the rub is always the propensity for users to forward on those same emails. If they do, then the second recipient gets control of the first recipient's account, and that's rarely the intention of the first recipient/forwarder.

I haven't had a chance to dive in enough, but I wonder if a technique like this could effectively swap tokenized links with generic links (even if you're just swapping 'display' rules) when a message is forwarded. You might have to use different message style/markup output depending on which service you're sending the message to, but my read of this article is that it's not a ridiculous thought.

</comment><comment><USER14> Ironically, Lotus Notes Webmail is the only client I have seen so far that actually uses iframes to display HTML emails. If webmails just could embed the HTML content into an iframe with the proper sandbox attributes... _nods off and dreams_

<comment><USER15> Wow, you could embed entire videos with the data: uri, or run entire web apps with inline javascript with Lotus Notes if they don't sanitize it. Or completely breach their privacy by scanning their LAN for webcam URLs or taking screenshots with WebGL textures using Nvidia driver bugs... _nods off and dreams_

<comment><USER14> No, that doesn't work with proper sandbox attribute. To quote w3schools ([http://www.w3schools.com/tags/att_iframe_sandbox.asp](http://www.w3schools.com/tags/att_iframe_sandbox.asp)):

When the sandbox attribute is present, and it will:

* treat the content as being from a unique origin

* block form submission

* block script execution

* disable APIs

* prevent links from targeting other browsing contexts

* prevent content from using plugins (through <embed>, <object>, <applet>, or other)

* prevent the content to navigate its top-level browsing context

* block automatically triggered features (such as automatically playing a video or automatically focusing a form control)

I'd say alone blocking scripts, form submits, preventing links to change other contents and checking if there's behavior stuff in the CSS (which facilitates Javascript injection) is enough to have a secure webmail display. Responsive webmails \o/

<comment><USER16> Oh man, that _is_ a dream. I had no idea that this was a thing. Too bad iframes themselves are kind of tricky to size correctly or I'd be using this willy-nilly. Skip sanitizing HTML and use a full sandboxed HTML iFrame for every comment on a user forum!

<comment><USER14> > Too bad iframes themselves are kind of tricky to size correctly

You could use an injected JS (postMessage with the iframe window height) and update the iframe height from the outside. And for the content you should just strip any script tags so you can safely allow scripting.

You should strip script tags in any case so that someone cannot use an API call which outputs raw comments as a delivery vector.

Also, you're putting users without sandbox attribute support on risk of being exploited... so you'd have to switch between two paths for display.

<comment><USER16> > Also, you're putting users without sandbox attribute support on risk of > being exploited... so you'd have to switch between two paths for display.

An evil part of me considers that a feature, not a bug.

And as for stripping script tags, I'm always reminded of this story:

[http://blog.codinghorror.com/protecting-your-cookies- httponl...](http://blog.codinghorror.com/protecting-your-cookies-httponly/)

</comment></comment></comment></comment></comment></comment><comment><USER17> This would be great for an email marketing campaign. You could probably get a lot of people to refer their friends just for the opportunity to see some cool animation or graphics.

</comment><comment><USER18> HTML email made me think of IE6 as the iPhone 6. The rendering engines on most clients are horrible.

<comment><USER14> tbh Thunderbird is the only standalone mail client using a full-featured browser engine as backend. Even Outlook uses a castrated-beyond-belief IE.

<comment><USER19> Some versions of Outlook use the even worse MS Word engine.

</comment></comment></comment><comment><USER20> This is a really interesting hack.

I love things that exploit the oddities of the landscape to do artsy/funky things; far more interesting than finding yet another way to trick someone into installing a password stealer.

</comment><comment><USER21> This reminds me of the old concept of "tab damage"[1] on usenet/mailing lists. People used to leave little "devices" in their signatures that based on this that would point to the number of times a message had been forwarded or quoted, because client software would typically indent the quoted message.

[1] [http://linuxmafia.com/~rick/afw/#tabdamage](http://linuxmafia.com/~rick/afw/#tabdamage)

</comment><comment><USER22> This can leak the user's client by changing links per client.

Make a link per identifiable client, show only the one for the current client, and give each link a post/get parameter identifying the client. Quite easy to do, but a lot of work to have broad client support.

Tada! I now know you read your email on your [obscure and bugged client], which is susceptible to [this and that exploit].

<comment><USER23> Why not just insert the exploit into the first email? What do you gain by identifying the client?

<comment><USER22> This is an exploit as well, just a different kind. It doesn't require any programming errors in the clients, instead it relies on the non- standardization of clients.

</comment></comment></comment><comment><USER24> Wow, this was a very creative use of forwarding.

</comment><comment><USER25> Nice work here and also nice post about the Brave thing and internet business model on your site btw. I agree 100%.

</comment><comment> alch- That, sir, is totally awesome. Well played.</comment>


Why the boss wants you to build that Software in-house? - <AUTHOR> https://medium.com/@nesovok/why-build-software-in-house-not-f3c9bc726b1#.qlulrxtgn <comment><USER2> While interesting, the conclusions just aren't true. Here's one more in favor of in-house.

Integrating the vendor solution will be more complex for the sake of unused feature over a simpler solution developed in-house.

Another: The solution to our problem doesn't use the other pieces we want/need to integrate, or doesn't exist. There's several solutions to manage docker clusters now, and effort has been made, but when they all started (some originally in-house) those solutions weren't widely available.

Another: the existing vendor solutions are sub-par for our needs (and/or the needs of our customers). Could you imagine if Joyent had just used VMWare as it's virtualization solution instead of the Jails from their OS based on Solaris? They have the only solution with _really_ locked down Docker.

Sometimes creating a new trail really is the better solution. I wrote a test LMS a bit over a decade ago, that worked well enough for a lot of integrations before being replaced by a big vendor's LMS and it cost more for the integration alone than the customizations to the one I built... 10 years of service cost less than the 1 year of integration.

</comment><comment><USER3> He didn't mention the big reason for in-house: security

Telling an outsider about your needs (revealing insider info, trade secrets, etc.) is risky. It's even worse if the result will not be fully air-gap isolated from the Internet. That gives somebody a hole into your business.</comment>


Caching COUNT with PHP and Redis - <AUTHOR> http://forrst.com/posts/Caching_COUNT_with_PHP_and_Redis_Forrst_http_fo-m0v

<comment><USER2> > if for some reason the memory cache diverges from the true count, we just > wipe out the memory cache and the app takes care of regenerating it > automatically

Warning, this is a myth: once you starte relying on caching to serve your amount of traffic, flushing the cache will have the result of taking the site down. This is why persistence is an absolute requirement of a serious caching server IMHO. With Redis when things may be in desync it's better to selectively remove entries with (RANDOMKEY+DEL) at a rate that the system is able to handle.

Also given that you are using Redis that has atomic increments, why not going the extra mile and issuing INCR/DECR operations when something is added/removed?

<comment><USER3> I should have been more specific--technically the cache would be wiped for a specific post, never for the entire db of posts. But you're totally right about the persistence --that's why something like redis made sense to me.

Useful tip about randomkey and del, thank you.

I def. could switch it over to an incr/decr setup. Maybe I'll do that tonight.

</comment></comment><comment><USER4> Doesn't this seem too basic to have been voted up so much? That is, compared to the rest of the technical posts that are voted up.

And perhaps MemcacheDB (<http://memcachedb.org/>) is a better bet if you don't need Redis's list and set operations. But I don't understand why the cache needs to be persistent.

</comment><comment><USER5> Two things occur:

1\. This is a better fit for memcache than redis, since you can get the counts to expire automatically

2\. If you are fetching paginated results with a LIMIT (and you usually are) then you can use the SQL_CALC_FOUND_ROWS prefix on your SELECT to get these counts for "free" from MySQL without needing to do your own caching (see <http://dev.mysql.com/doc/refman/5.0/en/select.html> )

</comment><comment><USER6> Assuming good indexing with non-enormous tables, he could use subqueries to get the COUNT() data at the same time that he pulls the records themselves. And, as he notes, he could have a count field in MySQL, caching at that level instead of in Redis.

</comment><comment><USER7> Redis is great, maybe memcached would serve better for this pupose as some of the comments have mentioned. I just want to point out one thing about his multiple count queries per page.

You can also do a grouped count query in a single query, by using something like:

SELECT COUNT(*) FROM comments WHERE GROUP BY post_id;

From that he gets an array of all the counts, so he can look those up easily.

And that result can also be cached as well, of course.

</comment><comment><USER8> MySQL already caches these. You've added a cache on top of a cache. Is a round trip to the database so slow?

<comment><USER3> I was under the perhaps false impression that count star queries with or without where conditions are not cached on innodb tables.

<comment><USER8> Not exactly. On isam table the count(*) queries can sometimes directly lookup the answer from the index, or the table statistics.

On innodb, because of transactions, this is not possible, and it needs to actually count the rows.

BUT, the query itself is still cached - at least until the underlying table gets updated, which invalidates the cache (I'm not sure of the exact invalidation strategy, but it's part of MySQL and doesn't depend on the engine).

<comment><USER9> Updating the table invalidates all cached queries that refer to that table, making the query cache useless for any site that gets a decent amount of updates.</comment></comment></comment></comment>


How accurate are Zestimates? Zillow awards $1M to trio for improving them - <AUTHOR> https://www.seattletimes.com/business/real-estate/how-accurate-are-zestimates-zillow-awards-1-million-to-trio-for-improving-them/ <comment><USER2> It's ridiculous in many cases. For example, they rate my next door neighbors place (townhouse, _identical_ floorplan) as $400K more than mine. Their record of my purchase price is half what it actually was.</comment>


Syntax matters - <AUTHOR> http://weblog.bignerdranch.com/?p=52

<comment><USER2> I'd argue it's the ONLY thing that matters

<comment><USER3> Why? What about the underlying model? Procedural, OO, or functional? Availability of libraries? Culture of the community? Efficiency of the compiler/VM? Ease or difficulty of application deployment? Size of the minimum memory footprint? Concepts for dealing with concurrency?

Why don't these matter?

</comment></comment><comment><USER4> Long live the DSL.</comment>


The history of file-sharing - <AUTHOR> http://torrentfreak.com/the-history-of-filesharing-120422/

<comment><USER2> Just nitpicking: DC++ is one implementation. The network is usually referred to as "direct connect". DC++ wasn't even the first DC client, it just happened to be the most popular one at the time the network itself was still quite popular.

</comment><comment><USER3> I can see the trend of file sharing size as the internet speed also increase. I'm pretty sure that it will still evolve as the internet gets more faster.

</comment><comment><USER4> Last two sentences...

>Filesharing as a technology is good. Let's make sure it stays around so that we may continue to share our thoughts, ideas, and art in order to better ourselves, our communities, and our earth. Anyone who is against that must obviously dream of world destruction, or at the least, wish for human progress to stop.

No one is against file sharing, they are against copyright infringement. Why does this childish stuff keep getting upvoted? It doesn't help the cause.

<comment><USER5> Hi J3L2404 - while on the face it appears that nobody is against file sharing, regulations that continue to be introduced do, in fact, seem to be against such sharing (even if that may not be their original intent).

I do agree, it may be a childish statement, but it's our childish dreams that lead us to a better future.</comment></comment>


Clarifying the Future of Firefox Screenshots - <AUTHOR> https://blog.mozilla.org/futurereleases/2019/01/24/clarifying-the-future-of-firefox-screenshots/ <comment><USER2> I support this - IMHO Screenshots made it frighteningly easy to dump sensitive information to a mystery server, and did not make clear enough when data was leaving your control.

<comment><USER3> How do you click a button with an arrow going into a cloud, and then be surprised that you've uploaded the screenshot online?

Super useful feature. Will miss it.

<comment><USER4> > _" How do you click a button with an arrow going into a cloud, and then be > surprised that you've uploaded the screenshot online?"_

God forbid somebody clicks the button called "Save" thinking that it would _save_ the file, rather than deciphering the icon to determine that the button labeled "Save" is actually "Share". Why not rename this ([https://0x0.st/zKfv.png](https://0x0.st/zKfv.png)) menu entry to "save" too while they're at it? And why is that the only button with text in it? The others have tool tips, but otherwise they're just bare icons. The only one with text is the share button that says "Save".

It's indefensible. It should have never made it past code review, let alone stuck around for several revisions. If the button had said "Share" instead of "Save", there never would have been any complaints about it.

</comment></comment></comment><comment><AUTHOR> Anyone who's running 67 (in beta now) will lose the ability to upload screenshots for sharing.

Weird move from Firefox, especially as they start promoting Firefox Send. Screenshots as a whole is an essential feature to me that really helped set it apart from Chrome. The hosted screenshots aren't integral, but I'm disappointed that they're taking away functionality for stated reasons that aren't particularly interesting.

<comment><USER5> I don't get why they don't integrate Screenshots with FF Send.

<comment><USER6> We have discussed it.

<comment><USER7> I hope that you do end up doing it. This seems like the perfect kind of thing to use Send for, removes the need for mozilla to maintain extra infrastructure (maybe just a STUN server? I haven't looked at the Send architecture) and would let people keep the files up for as long as they'd like at the same time.

</comment></comment></comment></comment><comment><USER8> The "making it simpler" for users is definitely only an excuse for Mozilla to not pay for the servers anymore. Kinda disappointed as uploading was a dry useful way to share in, high quality screenshots. I can't fathom that it would've cost then much to keep the platform running

<comment><USER9> not running a server that stores images uploaded by anyone on the internet also saves them from having to deal with any legal issues associated with running a server that stores images uploaded by anyone on the internet

</comment></comment><comment><USER10> I did not know that screenshot was a feature in Firefox, and I suspect that almost no one does.

Seriously, where is it? It's not an ANY of the menus, at not on Mac OS.

<comment><USER11> Isn't it right in the address bar on a default Firefox install? If it isn't, then it's definitely in the 3 dot menu in the address bar.

<comment><USER12> It defaults under the 3-dot menu. (Which is the perfect place to stash features you don't want your users to know about.)

</comment></comment></comment><comment><USER13> A lot moves at Firefox lately seems to focus on making the life of their devs easier but not necessarily their users.

<comment><USER14> i respect that though. happy devs is a precondition for happy users.

</comment></comment><comment><USER15> If I want to make a screenshot I press either alt-print or shift-alt-4, which I've configured to run "xfce4-screenshooter -r"

I select the area of the screen I want, and it pops up a window which allows me to save, copy, upload to a couple of sites, or open in a program.

[http://imgur.com/s8IeaMNl.png](http://imgur.com/s8IeaMNl.png)

What could be simpler.

Apple has a more limited version of this with shift-apple-4 I think.

The only thing I can think of that would need it in my browser rather than my OS is to capture non-visible parts of a webpage, but that isn't the functionality that's pushed.

<comment><USER16> Have you tried it ?

One neat feature is the ability to select a DOM element of the page, like with the inspect tool, and take a clear picture of it.

You can also screenshot the whole page, including what's below the float line.

<comment><USER4> Note however that floating bars, such as the one used on this article, mess it up: [https://0x0.st/zK9t.png](https://0x0.st/zK9t.png)

Zapping that element with ublock origin fixes it, but needless to say the UX needs work.

</comment></comment></comment><comment><USER17> (January 24, 2019)

</comment><comment><USER4> Thank the gods. This is the sort of thing that keeps me using Firefox. Just when it starts to seem like Mozilla never listens to the community, they prove me wrong.

> _" User feedback about the button copy had nothing to do with the removal of > the server. "_

O-Oh. Well nevermind then, it's just a happy coincidence according to them. Whatever, I'll still use their browser even if they're too prideful to ever admit fault without filtering it through PR (see also their response to community outrage over them injecting "Mr Robot" advertisements.) Between Google and Mozilla's management, users are stuck between a rock and a hard place</comment>


Wikipedia is down - <AUTHOR> http://status.wikimedia.org/

<comment><USER2> Why does anyone care? These posts are getting increasingly popular. It seems like reputation-bait to me and really detracts from coming here to do what we do - read articles.

<comment><AUTHOR> I made the post informationally -- it seemed worth it for anyone who runs into a problem and is looking for validation from the community that "it isn't just them".

I was using wikipedia at the time and went to IRC to find out what's up, but not everyone will go that far or think to look at the status page. I don't know what downforeveryoneorjustme would return in this case -- I did not think to check the headers being returned.

If there were a karma-donation mechanism, I'd give you the 20 points or so I've gotten out of this for making a good point. :)

<comment><USER3> It's called www.downforeveryoneorjustme.com

Why would anyone go on hackernews to check if a website is down? That doesn't make much sense, there are so many mechanisms out there to deal with this kind of thing....

</comment></comment></comment><comment><AUTHOR> From #wikipedia-overflow on irc.freenode.net:

09:29EST <@RD> Wikipedia is currently down - network issues (that is all that we know at the moment) - <http://status.wikimedia.org>

</comment><comment><USER4> From IRC: "Status: Down - routing issues to Tampa" (edit: removed conjecture)

</comment><comment><USER5> I think the panic occurring already over Wikipedia being down for less than an hour reflects on just how reliable the site usually is - especially for one relying exclusively on donations.

</comment><comment><USER6> Oh no, I forgot to donate! Sorry, Jimmy!

</comment><comment><USER7> And it's back up now. :)</comment>


Inside X, Google's Moonshot Factory - <AUTHOR> https://www.theatlantic.com/magazine/archive/2017/11/x-google-moonshot-factory/540648/?single_page=true <comment><USER2> I once asked a friend how hard it was to get a job there. He replied "two PhD's might get you an interview".

I wonder how hard it actually is, sounds like a brilliantly cool place to work.</comment>


Startups, Your Use of Alcohol Can Be Problematic - <AUTHOR> https://backchannel.com/startups-your-use-of-alcohol-can-be-problematic-and-points-to-deeper-issues-4ce621070103?source=rss----d16afa0ae7c---4 <comment><USER2> SJW 'weasel word' detected ('problematic'). Excessive whininess and pearl- clutching ahoy.</comment>


Twin Peaks is coming back in 2016 - <AUTHOR> http://www.theverge.com/2014/10/6/6919003/twin-peaks-is-coming-back-in-2016-on-showtiame

<comment><AUTHOR> And David Lynch will direct all episodes :)

Looks like Laura Palmer was right when she said she'd be back in 25 years: [http://www.theverge.com/2014/10/6/6919641/twin-peaks- prophec...](http://www.theverge.com/2014/10/6/6919641/twin-peaks-prophecy- foretold-2016-return)</comment>


Why doesn't Facebook sue Google for Google+? - <AUTHOR> http://www.quora.com/Patents/Why-doesnt-Facebook-sue-Google-for-Google+ News is breaking that Apple has some lethal patents that seriously threaten the fate of Google's Android OS.
Google is doing the same thing to Facebook with Google+.
Has anyone heard anything about any potential legal action Facebook might take? <comment><AUTHOR> News is breaking that Apple has some lethal patents that seriously threaten the fate of Google's Android OS.

Google is doing the _same_ thing to Facebook with Google+.

Has anyone heard anything about any potential legal action Facebook might take?

Please contribute on Quora ;)</comment>


What no one talks about when building a team: letting people go - <AUTHOR> http://joel.is/post/61468652377/what-no-one-talks-about-when-building-a-team-letting <comment><USER2> I wonder what the turn-over rates are for most startups. I was recently let go from a start-up that over the last two years has seen 200% turn-over (3-people team, 6 new hires didn't make the cut).

I've also spoken to a friend just left a start-up that he figures has had 90% turn-over since he arrived a year ago, and the start-up is just two years old. So, if the past year is any indication, about 180% turn-over on a team of about 18.

Is this really that common? Or am I just hearing of the horror stories?</comment>


Kicked out in America - <AUTHOR> http://www.nybooks.com/articles/2016/03/10/evicted-kicked-out-in-america/ <comment><USER2> > That's partly because restrictive zoning and overzealous building codes > drive up the price.

The problem is self-inflicted. As ever, it is the government that causes this problem. They do not want third-world shanty towns popping up, but on the other hand the demographic with incomes below $15 000/year will not magically disappear either.

I live in Southeast Asia. American zoning -and building codes would mean that 95% of the population in this country would be homeless, destitute, and begging in the streets. They are not and at the moment they are still doing fine, but only for now. Someone could copy bad ideas, imported from elsewhere, and start kicking out people into the streets.</comment>


90 Cents of Every 'Pay-For-Performance' Dollar for CEOs Are Paid for Luck - <AUTHOR> https://corpgov.law.harvard.edu/2016/09/29/90-cents-of-every-pay-for-performance-dollar-are-paid-for-luck/ <comment><USER2> I remember an interesting theory about golden parachutes in Steven Landsburg's "The Armchair Economist". In a typical publicly traded company, the CEO is actually much more heavily invested in the company than the shareholders. His salary, and probably the major part of his assets, are dependent on the performance of the company. On the other hand, the average share holder is well diversified. Therefore, a CEO will be incentivized to pursue a highly conservative strategy, while the shareholders may wish that he takes more risk. To offset this, the shareholders may make it known that a generous severance package, as well as generous benefits if the company does exceptionally well, are on the table, to simultaneously soften the blow if he takes a bad risk, and sweeten the deal if he takes a good risk.

In other words, the point of executive compensation may not be to produce better results on average, but rather to increase the variance of the results.

<comment><USER3> > Therefore, a CEO will be incentivized to pursue a highly conservative > strategy

I _strongly_ disagree. A CEO is probably highly personally invested in the company, but that investment almost always has an unusual structure: it resembles a call option, not equity. If a CEO generates a large gain over the course of a few years, the CEO makes a lot of money. In contrast, if the CEO generates a large loss over the course of a few years, the CEO loses very little. This can give a CEO an incentive to make extremely risky decisions because the CEO doesn't personally suffer much more from a huge loss to the company than from a small loss to the company.

This problem exists for investment managers. In a hedge fund that charges a performance fee on investment gains, managers have a perverse incentive to take large risks. It gets more pronounced if the fund is already down for the year: if, say, the fund has taken a 40% loss, it can look very attractive to the manager to bet all of the remaining assets on a coin flip. Heads, they get their bonus. Tails, they now have a 90% loss, but they weren't getting their bonus either way and they lose nothing.

Edit: At least the coin flip is neutral on expectation. But the same issue exists for a bet with negative expected value: the manager gets some benefit if they get very lucky, so the manager has positive expected value even if the fund has very negative expected value from their decision.

<comment><USER4> Actually hedge fund managers tend have a large portion of their net worth invested in the fund also.

<comment><USER3> Even when this is true, it doesn't necessarily solve the problem. Say you're 28 years old and you're running your first fund. You have a net worth of $500k (because you worked 100-hour weeks as a banker for a few years, paid your student loans, and saved up). You put $400k into your fund and raise $50M. You charge a 25% performance fee.

If you get 10% returns, that's $1.25M for you (at a possibly low tax rate, too) plus $40k on your own investment. If you lose 20%, you're out $80k. What's your incentive here?

</comment></comment></comment></comment><comment><USER5> Excellent points in this article - another factor is they are often paid outrageous base salaries (plus options) for the success of a company, when the success of that company can often be in spite of the CEO, coming from within, and embodied equally by all of the collective employees.

Executive comp is a major racket, enforced by the standard that this is "what the market average is". Which is set by executives overpaying themselves.

Ask yourself if your CEO is really working 100x as hard as you, or 100x smarter than you. The answer is usually a definite no. I'd really like to see more fair pay in this area and a culture that treats contributions of all employees more equally.

<comment><USER6> A _general case_ CEO/exec job is far, far riskier than a IC software developer. If you're a fantastic (heck, halfway decent) developer, you can be fired, laid-off, or simply quit and find a new job relatively quickly. And yes, you're generally paid a lot of money (compared to the rest of America).

As an executive in a _general case_ (sure, we can all find outliers) company, there are comparatively far fewer jobs for you to go to. If you fail, you fail spectacularly/publicly and may not be employable for _years_. The high compensation is in exchange for the risk of the job and the low probability of finding a new one.

Semi-related (not what you said - of course): "I deliver $1M in value to the company so I should be paid $1m" is a thing I see every now and again. That's not even remotely how any of this works.

<comment><USER7> The general case is CEOs are part of the management club, a club that protects itself much like a trade union.

CEOs fail all the time, and they aren't shunned but rewarded with golden parachutes and positions on boards of other companies, biding their time until they can "come off the bench".

The management club is something to be admired and I wish engineers would try to adopt some of its behaviors instead of viewing ourselves as mercenaries.

<comment><USER8> It's divide and conquer.

Engineers are too impressed by their own intelligence.

<comment><USER9> No, it's that we are too idealistic and are turned off by the messy, immoral greater world in which the management club makes their money. We want things to be beautiful and fair and so we spend our time constructing abstract fantasy lands in miniature.

The great irony, of course, is that the messy and immoral world intrudes even there because rational idealists can't find consensus and are subject to the biases that require conventions, institutions, politics and regulation just like the legal and business worlds.

If we were rational you might say we chose "playing with fun toys" over "controlling thousands of people and millions of dollars, and influencing millions of people and billions of dollars". Perhaps, for some people, that is indeed the rational choice if you don't really trust yourself.

</comment></comment></comment></comment></comment><comment><USER10> From my years of startup experience: luck determines basically everything. What company you end up picking, what team you get placed on, how your interviews goes (remember merge sort)?, what problems you need to work on, who your boss is... even if your company survives. Your entire company can lose funding because of an argument on a golf course or Apple TOS change (sigh). At larger companies what team you are on is well.. everything. How were you picked for that team? Because the boss of the other department was on holiday that day.

I smile when I hear people actually think they can control their own luck. That is how religion started. Whatever makes you happy.

"I am going to pick my OWN boss, I am going to join the start up I want to join with MY purpose." No, you will pick the boss from a super small subset that has a position open and you are going to find a company that needs you 'currently'.

Who gets promoted? Generally, lucky loud people. Who makes sales quota? People given the best accounts (luck). Who goes IPO? People that bumped into an untapped market.

Do what you want. People's evaluation of you is just based on luck.

<comment> rm_-rf_slash Everything is based on luck. 99.9% of humans in history were born into what the average American today would consider extreme, abject poverty.

I did not choose to be born into a family of upper-middle class American academics. I did not choose to be born on time with excellent health any more than my uncle's fetus chose to be exposed to lead paint, get born 3 months early, and become severely developmentally disabled for the rest of his life.

Even if spmeone came from literal rags and made literal riches, they still benefited from a civil society, rule of law, access to education, and so on.

I am fully convinced that the only healthy and ethical approach to live is to be grateful for everything you have, and empathetic for others whose needs are unmet.

<comment><USER11> > Everything is based on luck.

ITYM _chance_ , not _luck_. Luck describes a supernatural force. Chance describes simple randomness.

<comment> rm_-rf_slash The way I see it, chance is what is out there, luck is getting what you didn't know you had.

</comment></comment></comment></comment><comment><USER12> I don't think it's possible to reliably link pay to performance for anything other than measurable immediate production - like manual labor. Forget reliably doing it for executives. The reason is, because long term price impacts of individual performance are not knowable, so they cannot be priced effectively.

The executive compensation system right now is built on social proof and positioning, not on auditable causal decision chains. Too many dependencies to make causal connections.

</comment><comment><USER13> Bonuses are not to be considered to be pay for performance.

They are to be considered as a part of pay that can be withdrawn if either the company does badly and can't afford it, or if the employee does visibly badly.

They are a good thing for the company because they can decide not to pay it, except in as much as they allow the company to pay more because they can withdraw it if necessary

<comment><USER14> Bonuses for executives or bonuses for regular employees? Every bonus item in any employment package I've had has always been tied to the company's performance and my individual performance. I have never once worked anywhere with an automatic, performance-independent bonus, from tiny shops working as government contractors to large and well-known corporations. This is anecdotal, obviously, but I'm talking about myself and literally hundreds of thousands of other employees across all the organizations I've worked for. I am not denying such bonus structures exist in some places, but I'm skeptical that it's common or not considered an extreme aberration.

<comment><USER15> I don't know if it's common, but I'm currently employed in such a company. Basically, at the interview I asked for $X / month after benefits[0] and taxes, and what I'm being paid is ($X - benefits - taxes) / month base, + performance bonus equal to the amount that went to the government in my name. I get the bonus by default, but they can suspend it if I perform visibly badly.

[0] - don't know the right English vocabulary for that; in Poland, if your employer pays you X directly, then he actually costs you Y, where Y > X, and the difference is what he pays as a contribution to your social security and health insurance.

EDIT I was misremembering things, so I doublechecked my payslip and fixed the comment to reflect "real reality".

<comment><USER16> Interesting arrangement. If your tax rate goes up, does your pay go up too?

<comment><USER15> It probably will, though most likely only after renegotiation of contract. The bonus amount was calculated off the $X I asked for and is "hardcoded", not computed dynamically from the taxes and social/health payments.

AFAIK we didn't have the (income) tax rate changes since at least 2009, so I don't know for sure.

</comment></comment></comment></comment></comment><comment><USER17> I love this very honest appraisal of how pay-for-performance incentives ought to work, and I wish more companies would step back and ask themselves if their "traditional" incentive structures have the motivational factor they're "traditionally" assumed to have.

While _startup_ performance is less correlated to market performance than an established firm, the concept of setting the bar as outperforming the industry/market is brilliant, and I wonder if there's a good analog in the startup space, particularly for employees.

Bonuses and stock options are all well and good, but they incentivize the firm's survival and success. A single employee may be unable to change that, even if they perform exceptionally. Those incentives are great for "share the wealth" and "all for one, one for all" camaraderie, but they don't incentivize individual performance.

</comment><comment><USER18> True at all levels; statistics are rarely taken into account in _any_ performance review or measurement process. It is always assumed that the individual is responsible for his or her own performance. However, the opposite is largely true: the system and environment the person is in accounts for a disproportionate level of the end result.

It's an uncomfortable truth because it mucks with our sense of free will and control, but it is a well known phenomenon (attribution bias) with countless examples. This CEO incentive pay version is simply the most extreme.

</comment><comment><USER19> Or you know, 'luck' is just what couldn't be mathematically described in the model, attributing it to randomness.

</comment><comment><USER20> A while back I came to the following conclusion : "We often attribute our success to our skills and talent and failure to luck - while quite often it is the other way around." :)

</comment><comment><USER21> As much as I'd like to believe that CEOs are basically payed for chance, this research is deeply flawed. As in, it's literally trying to measure the (practically) immeasurable.

More specifically, it's this assumption:

> We model the impact of a manager on her firm's performance by assuming that > a manager who exerts effort and manifests her talent increase the firm's > expected return by the magnitude of her talent.

that is simply not true. The performance of every CEO is amplified by the amount of people he's affecting. And that is made even worse by the fact that companies are competing against each other, meaning that usually it's not their total performance that matters, but the difference to the next best company. You end up with so much noise in your data that yes, the result looks random. But is it? We don't know.

The only accurate measure of performance (that we know of) is performance itself.

</comment><comment><USER22> On a related note, is there any successful pay for performance scheme for engineers?

Pay-per-performance is well established in sales and marketing. Even when the sales/marketing strategy requires a large team to implement, the spoils go to the top.

It seems the only time engineers get properly compensated for the value they create is when it is so obvious and the owners can't get away with stiffing them.

Startups are well known for stiffing engineers because the teams are small, there are no repercussions and the founders don't have much of reputation to begin with. It's harder in bigger companies since it sends the wrong message to others in the company and destroys your reputation.

Maybe there is no such thing as fair compensation. Just get leverage and negotiate or obtain a position of power (authority) within the company.

<comment><USER23> Patrick McKenzie has written about this extensively.

<comment><USER22> He wrote on salary negotiation and creating value as a consultant + boosting his rate.

Is that what you are referring to by pay-per-performance for engineers?

<comment><USER23> Yes.

</comment></comment></comment></comment><comment><USER24> "I've met very few good plumbers, it takes a special person of talent to be a great plumber."

"I've met very few good truck drivers, it takes a special person of talent to be a great truck drivers."

...

There is a whole premise in many post about this story that it's somehow a very rare thing to be able to run a company well and that the person filling the role of the CEO is the main driving factor of success. (Instead of economic factors, outside forces, performance of other employees... oh! I know! The other employees performs solely because the great CEO makes them do so.) I think there's a lot of egotism being expressed in this thread...

(Especially by VCs who basically say they're impervious to misjudging someone's abilities and its true influence on success.)

</comment><comment><USER25> They found a way of structuring bonuses that works nearly twice as well — too bad it was a bit buried in the summary: "Indexing the option, and setting the strike price much higher than the granting-day price almost doubles the option's motivational power"

</comment><comment><USER26> It's well worth it to remember than equity is just a call option on the value of the firm.

Therefore, it's often in the equity-holder's interest to do two things:

1\. _increase_ the volatility of the underlier (by making riskier investments, etc.)

2\. Re-strike the option to be closer to at-the-money, by loading up with more debt or paying out cash as dividends

Both actions increase the odds that the firm goes bankrupt, but also increases the expected payout to equity holders.

When you increase equity compensation to executives, you basically encourage them to do riskier things.

</comment><comment><USER27> I think this video, by Louis Rossmann, is very important to this discussion.

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

I don't think you can ever accurately account for what is "luck" and that it is actually harmful to our own abilities to call something luck and write off whatever was actually done by the CEO. I think this is a good watch and I look forward to hearing what others think about the video.

</comment><comment><USER28> I think there is a simple and rationale explanation for this...

I believe founders that step away from the role of CEO seek to put in place someone who prioritizes the business as (close to) as much as they do (ie before family, friends, life etc). The problem is how do you find someone to love (yes love or at least pretend to) the business without them owning a meaningful piece of it (the equity that is)? When granting sixeable equity is not an option (most founders I know who built successful companies are highly protective of it) the solution is you buy it. Mark Zuckerberg owns 30% of Facebook. The professional CEO that one day replaces him will own 0.0000001% of it. That's not very motivating for entrepreneurial CEO types who are ideal for these roles. Mark isn't going to go to sleep easy at night unless he knows the person running the show eats sleeps and breathes Facebook the way he has for the last 30 years. That person is buying his dream, he's buying their loyalty and commitment (and great judgment, etc etc).

</comment><comment><USER29> The article seems to assume that CEOs are believe that they have very little impact on a company's success, and that they calculate how much effort to exert accordingly.

My understanding is that CEOs tend toward hubris and that this assumption is false in most cases. If so, then it might be more efficient to up the strike price, but the current situation isn't as inefficient as it seems (thanks to hubris).

Relatedly, if CEOs were granted deeply-underwater options, wouldn't they demand much more in base pay, to compensate? I'm not saying they "deserve" higher base pay—just that if a board wanted to institute this change, they'd get push back from the individual. Otherwise it would look like a disguised pay cut (imagine if your boss came to you and said that to incentivize employees to work harder, all options were going to be issued underwater).

</comment><comment><USER30> People keep talking about "shareholders" in the comments here. Where, exactly, do shareholders come into the picture?

C*O compensation is set by the board of directors. The board is determined by the executives' recommendations. The only shareholder who matters is Carl Icahn; the only power most shareholders have is to sell shares. And I'd be willing to bet something that their willingness to do that is only related to short term performance.

</comment><comment><USER11> > ... Paid for Luck

I wish academics would have the sense to avoid the word "luck" when "chance" is the principle at work. These people should know better.

</comment><comment><USER31> Michael B. Dorff wrote a book about this called "Indispensable and Other Myths": [http://blog.translusion.com/posts/CEO%20Salaries/](http://blog.translusion.com/posts/CEO%20Salaries/)

His conclusions were that CEOs don't really matter all that much. Exceptional ones like Elon Musk or Steve Jobs are quite rare.

</comment><comment><USER32> Not sure how one would control for "luck" in a (legitimate) academic study. The definition of it is broad, to say the least.

</comment><comment><USER33> Does overpaying the top executives of a company, regardless of performance, increase motivation of all the other employees of the company? After all, the underlines want to become the CEO one day. The higher the reward for the CEO, the more tantalizing the carrot dangled in front of his underlings.

</comment><comment><USER34> Analyses on this topic are always so bad. Some counterpoints:

(1) CEOs are intentionally aligned with shareholders, for good reason. Shareholders often make money due to luck, so eliminating luck from CEO compensation without breaking alignment is a very hard problem.

(2) Going in, a CEO (or a shareholder) needs to lock down a big future payday in the upside case, in order to compensate them for the risk of the downside case. Yes, the upside case usually involves some luck, but the "optionality" to get paid in a lucky outcome is a valuable part of the deal.

(3) CEOs are also paid to be trustworthy agents for shareholders/boards. Like... if I am a billionaire looking for you to oversee a big part of my capital, I may pay a lot just because I know you are a good/smart/reasonable person who will be autonomous but raise the right issues to me if needed, reliably. I might know all that just because we have been buddies for years, and even though there are lots of objectively more talented people out there who would do the job for less, paying you more would not be irrational for me.

<comment><USER35> (1) The study specifically talks about the motivational effect of performance pay and finds that the component of luck means that performance pay must be more difficult to achieve in order to motivate the executive officers to align their interests with the company.

(2) You could reduce the financial risk of executive officers by paying them a fixed salary. In fact, different companies offer very different compensation plans. This was a review of those plans to see what did and did not work. Generous performance pay does not work.

(3) This is an issue of whether executive officers should be paid well in general, not the value of performance pay. And at any rate seems to be a justification for nepotism in an area of business that is already dysfunctionally nepotistic.

</comment></comment><comment><USER36> Is this 90% a upper or lower bound?

I mean did they try to measure luck and found that it accounted for 90% of returns?(lower bound because their measure of luck was probably imperfect)

Or did they measure talent and were able to account for 10% of the returns(upper bound).

</comment><comment><USER37> Replace the definition of T with "the number of unicorns helping" and nothing changes. The author's T does not represent anything tangible or measurable. These conclusions are meaningless in any practical sense.

</comment><comment><USER38> Now consider that whether you end up born in an industrialized country into circumstances that will let you become a CEO in the first place requires a lot of luck...

</comment><comment><USER39> This is a profound misunderstanding of corporate governance, and the fact that so many people here somehow agree with the assertion that CEOs are paid for luck is astounding.

<comment><USER40> It would help if you could add some more substance to that assertion.

CxOs clearly require some competence- I don't think that is in dispute. It is the 200x + salary differential that is in question and the subject of the article.

Can you cite some other studies that contradict this?

</comment></comment><comment><USER41> Sounds like a good racket.

</comment><comment><USER42> Please update the headline to reflect the fact that this study is focused purely on CEOs, and stock-price-based-performance. The vast majority of people who are paid-for-performance are not CEOs, and are not graded based on stock- price movements.

</comment><comment><USER43> CEOs are primarily paid to bear risk, so this makes perfect sense to me.

<comment><USER44> What risk are they bearing in comparison to the company itself, or separately even its shareholders? Or heck, even its bond holders? About the last person whose shouldering risk is an officer of the company, that's the whole point of officers vs boards vs shareholders.

<comment><USER45> Officers are increasingly taking on more and more legal liabilities. There's definitely a growing need for danger money in some industries.

Would you be a bank CEO if it meant jail if one of your 100,000 employees was caught laundering cash or passing on insider information?

<comment><USER46> >Would you be a bank CEO if it meant jail if one of your 100,000 employees was caught laundering cash or passing on insider information?

IF that was actually a risk, I might consider it, but thanks to the Holder Memo, we have "Too big to jail".

"Kareem Serageldin was an executive at Credit Suisse who was described by friends as an "investment-banking monk."[1] As of April 30, 2014, Serageldin was also the "only Wall Street executive prosecuted as a result of the financial crisis" that triggered the Great Recession.[2] On Friday, November 22, 2013, Serageldin—the former Managing Director/Global Head of Structured Credit in the Investment Banking Division of Credit Suisse Group—was sentenced to 30 months in prison in connection with a scheme to hide more than $100 million in losses in a mortgage-backed securities trading book at Credit Suisse.[3] Serageldin also agreed to give back $25.6 million in compensation to Credit Suisse, and was later ordered to pay more than $1 million to settle an SEC lawsuit." [1]

[1] [https://en.wikipedia.org/wiki/Kareem_Serageldin](https://en.wikipedia.org/wiki/Kareem_Serageldin)</comment></comment></comment></comment>


A Leadership Library for Engineers - <AUTHOR> https://leadership-library.dev <comment><USER2> Cool, this looks nice!

I'm currently mentoring new tech leads, and I'm using books heavily as a tool. I usually break a book into two or three parts which we discuss and try to apply to our every-day problems. It works quite well.

However the biggest challenge I had wasn't finding good leadership books, but narrowing my list of books down.

I currently read with my mentees:

\- The Managers Path

\- Elastic Leadership

\- Simply Said: Communicating Better at Work and Beyond

\- Nonviolent communication

"Simply Said" is a good example for my struggle: I picked it because I needed a single book that covers written communication, presentations, body language, focus on the needs of the person communicated to etc.

There are surely better books for each topic individually, but picking a single one was tough!

<comment><USER3> So glad to hear you're finding Simply Said helpful!

That's our company's book, written by our managing partner, Jay Sullivan. I was pleasantly surprised to see it pop up while browsing HN.

What's one thing you learned from the book that's been helpful for you?

(Nonviolent Communication is also a good one that's on my reading list)

<comment><USER2> The advice on trying to pick one person per sentence and to keep eye contact with that person was most helpful for me. I either tended to flick between people quickly, or look at one person for a longer period of time.

</comment></comment></comment><comment><USER4> I've read and can highly recommend the following three from the leadership list:

1\. Turn The Ship Around: A True Story of Building Leaders by Breaking the Rules

2\. The First 90 Days: Proven Strategies for Getting Up to Speed Faster and Smarter

3\. Principles: Life and Work

</comment><comment><AUTHOR> A curated collection of engineering leadership resources that I wish I had when I took on my first management role. Hope you find something useful :)

<comment><USER5> Can I also recommend my book for software team leads to be included? "Elastic Leadership: Growing Self Organizing Teams" [https://www.manning.com/books/elastic- leadership](https://www.manning.com/books/elastic-leadership)

</comment></comment><comment><USER6> This is a wonderfully curated resource! Thank's for putting it together.

As you look to put things into practice from the resources you find here, I'd love to offer myself up to help in your learning journey. I run a 100% free mentoring service for live 1:1 conversations with managers and leaders. In the past 12 months, I've met with over 100 managers, and I've held over 150 sessions. I do sessions 5 days a week, and I've met truly wonderful people from this community through this service project.

[https://freemanagermentor.com](https://freemanagermentor.com)

Hope to talk with you soon!

<comment><USER7> I would love to know more about this project of yours. Do you have something written about how did you got it started, what lessons have you learned, or plans for the future?

</comment></comment><comment><USER8> This is a great list.

Missing from the Architecture & System Design list is Martin Kleppmann's Designing Data Intensive Application, IMO the best modern book on systems / scalability.

</comment><comment><USER9> Error 1027, This website has been temporarily rate limited

</comment><comment><USER10> I am not familiar with the books in most of the categories however, I can say with confidence that the "Startup Books" section lacks a lot of books for leadership, let alone for leader engineers.</comment>