How to Read Other People's Code -- And Why - <AUTHOR> http://designbygravity.wordpress.com/2009/10/23/how-to-read-other-peoples-code-and-why/ <comment><USER2> _Read the comments, but don't believe them_

Love that one. A grad student friend I work with, whenever he catches me poring over documentation, always tells me to read the code. Such a seemingly simple tip, but so valuable.

<comment><USER3> As my boss likes to say, the extension for Ruby documentation is ".rb".

<comment><USER4> The extension for Haskell-documention is `.lhs'. But you can compile it to a `.ps' or `.pdf' with LaTeX if you want to.

</comment></comment></comment><comment><USER5> one technique i often use when trying to understand someone else's code is to add in comments myself in my private branch (of the form "I think that X works like Y and Z"), or even better, adding in run-time asserts that I think ought to hold, and then running tests to make sure they do hold.

Of course, i never check in my comments/asserts to the main branch, since i'm not sure whether my understanding is correct

<comment><USER6> Code management tools need a way to add notations without getting in the way of code. Something that can be view thru a link, but is out of the way when poring over the code. ASCII text: anachronism. We're not that far from 80-column IBM punched cards...

<comment><USER7> You want something like literate programming then

</comment></comment></comment><comment><USER8> On the how bit: there is no such thing as reading code once. It is a simple matter of reading a method/object/what-have-you, then rereading it until you see it called/referenced etc and don't ask yourself "wtf does foo do". Trace various code paths often enough and you'll 'get it'.

As for the why: I used to decide I didn't like module X, then decide I was going to implement it myself. After some time I would end up with something looking like X, but not nearly as refined. As such, I learned it's better to read others' code and understand it -- much faster than reaching the same conclusions as the original authors w/ crappier code. Of course if after understanding you decide you still think it's crap -- have at it :).

</comment><comment><USER9> One of the reasons I don't write comments is because it gets outdated so quickly. And I don't need them myself, because I read only the code, even my own. Reading the code makes also for reviewing the code. Quickly changing bits so it makes better sense (like counts outside the for-loop instead of in the statement) etc. And use version-control system to make changes, test them and roll it back (revert). TortoiseSVN helps a lot with this for me. I also try to make the code more readable by adding my codingstyle or the codingstyle by convention (I still think mine is best ;-)

<comment><USER10> Now that you know how comments can fail, you should use that knowledge to write good comments rather than not writing any. There are plenty of very good reasons to write comments.

The most common reason I write comments is to explain the purpose of something that is unintuitive from the pure code. Examples are comments in CSS about a particular browser quirk, or hacking around an edge case in an efficient but opaque way.

<comment><USER11> . . . and one of the plenty of good reasons being producing API documentation automatically via javadoc, doxygen, etc. Having the API documentation source and code live together is a big win. It's easier to maintain the inline documentation so it doesn't go stale. I hate being forced to go read code when I just want to use an API (I'm looking at you, Dojo :-/ ).

One of the first things I'll do encountering a feral code base is run an automatic documentation generator over it, even if there are no API comments, because many will produce at least some level of documentation from pure code, including cross references, a type index, call graphs, type diagrams, etc. This can be especially helpful when the code is poorly organized, and trying to trace simple program flow in an editor means navigating a dozen modules manually. Doxygen, for instance, will produce hyperlinked program listing, so that I can use a browser in a natural fashion to navigate the code structure and program flow. The browser can maintain virtually unlimited context, whereas my brain loses track of where I am once I'm seven levels deep in function call nesting.

Some IDEs and UML tools also are capable of reverse engineering documentation from the code base. The Togethersoft tools used to be excellent at grinding through code (and may still be, but I haven't used them in years).

RE'ed documentation of feral code can reveal how well (or more frequently poorly) the code base is structured, and identify key areas for architectural or design refactoring (if that luxury is possible).

In writing my own code, I decompose until each function or method has a single purpose (f() does X, not X & Y & Z!), and therefore the API documentation suffices to document the code itself. Rarely do I write a comment inside the body of a function or method. That happens when I re-visit the code, and discover that it's operation is non-obvious. The non-obvious stuff tends to be the tricky stuff it took some time to get right, and so it doesn't get mucked around with, and such internal comments rarely go stale.

I wait until re-visiting the code because authorial bias (my code effectively become's someone else's after several weeks, sometimes faster :-) ) obscures what is and is not obvious. I used to over-comment from a tendency to perform a mini-brain dump in comments -- but the knowledge required to WRITE the code (this is what I was thinking at the moment) is no reliable indicator of that required to READ the code (this is what _you_ need to know).

(I've theorized that having someone else comment the code from the start, just like having an unbiased tester, could make for better comments -- wherein the commenter is also necessarily a code reviewer as well. I've never gotten any of the places I've worked to agree to 'cross-commenting' as a standard practise, but most love worthless, perfunctory desk-checks prior to check in.)

To avoid comment churn, and because I refactor aggressively when creating brand new code, writing API comments is the LAST step in coding.

Finally, I developed a habit of writing comments exclusively in point form, because context switching from programming constructs to proper English grammar broke my flow. The point form comments feel like a miniature brain dump, whereas otherwise I'd pause to think about how to put the information into a proper sentence, and then make nice paragraphs, and suddenly I'd be channeling me from 7th grade compsition class. It's also easier to scan and digest comments as point form notes.

That's what I do, and I leave it at that, because telling someone else how to code is like telling them how to raise their children.

tl;dr version

\- at least write API comments, pls

\- doc generators (and other tools) sometimes are a great way to RE docs for feral code

\- write comments in point form

\- write API comments as the FINAL step in coding

\- try to remove authorial bias from comment writing

<comment><USER12> >In writing my own code, I decompose until each function or method has a single purpose (f() does X, not X & Y & Z!),

I hear this one a lot, from a lot of different sources. In practice, it never seems that practical. Here's a trivial example: the dashboard-page function in our webapp. It needs to do all of the following:

1) verify that the user is logged in. If not, bounce them to the login page, then bring them back on successful login

2) collect the list of all their providers

3) collect the list of all their profiles

4) collect the list of all their account information

5) load up and display the appropriate templates to render the web page with the requisite information.

Now, points 1-4 are accomplished by calling other functions, true. But dashboard-page still needs to do 5 separate things.

<comment><USER11> In this specific case, the dashboard-page function is actually sequencing operations, not performing them (except for 5, and I'd wonder why that couldn't be moved to a separate function), and can be described as such:

      // - control the login sequence
      function login_sequence() {
        var user  = verify_login
        if (!user) {
           user = login();
        }
        var providers = collect_providers(user);
        var profiles = collect_profiles(user);
        var account_info = collect_account_info(user);
        load_templates(user);
        display_templates(providers, profiles, account_info);
      }

(Forgive the guess at what your code might look like.)

State may be passed between called functions, and used in control decisions, but state should not be grossly manipulated in sequencing functions (I do find with this style of programming that at high levels the state passed around tends to be large 'context' objects, rather than granular arguments encountered at lower levels). What I would NOT want to see in such a hypothetical login function is ALL the actual lower level code to do the login, collect the data, etc., so that essential higher order detail is obscured by the lower level operations.

A function's API comments do not need to repeat the purpose of called functions.

As I come up with API comments last, I usually think about them in reverse -- it's not 'I need to think of the single purpose of this function before writing it', but 'what single purpose did this function end up serving?'. Not being able to think of a decent answer for the latter is a possible symptom of sub-optimal decomposition. Then again, cutting blocks of code and pasting them into their own functions has become an instinct rather than conscious decision for me, so I'm effectively anticipating writing the 'single purpose' API comments.

At a certain level of detail I don't need to know the minutae of login, just that there is some black box function that controls the lower level details. And if I need to know the details, I break open the function and follow its call flow (or look at the autogenerated call graph in the doxygen docs or similar).

Having read a lot of feral code, I find the major indicator of quality is the static navigability of the code base (i.e. can I find my way around just by reading the code in an editor, without resorting to debuggers or autogenerated documentation), and having a level of detail structure, akin to the zoom feature on Google maps, is one method of achieving navigability (and partially the value of OO techniques). So it's okay to have functions/methods that simply sequence or aggregate calls to lower levels, and to describe them as such.

It was mentioned elsewhere on the thread that debuggers are useful tools in understanding a code base -- and I do often find myself setting breakpoints on code because it's near impossible to understand how particular functions get invoked by just reading the code. Then examining the call stack at the breakpoint I see that event loop called the network code invoked some code to read a database, which called into some code to instantiate widgets, which called back into the database code, which called the code that calculates order totals and tax, which called the widget code again to update those fields, all of which goes 30+ levels deep.

</comment></comment></comment></comment></comment><comment><USER13> If the code is really intricate, I refactor it to understand how it works (and how it _ought_ to work, which can be an important way of spotting bugs).

But even though refactoring is supposed to be perfectly mechanical and "harmless" (especially when supported with unit tests) I'll usually throw away my refactoring, because the risk of breaking the existing code is just too high. It depends on how invasive the new feature is -- if I'm going to have to change a lot to get it done anyway, I might as well incorporate the refactorings. But if the change literally is finding the right position to add a single line of code, no way I'm going to change things once I find it.

When it's clear that adding even simple features takes an extraordinary amount of time because the code is that hard to understand and maintain, getting/making time for proper refactoring is easier, but it's worthwhile even as a way of creating a mental model.

I've never tried unit tests to figure out the semantics of existing code, though, even if it seems obvious in retrospect. I think the code base would have to become very complicated indeed before I go into full scientist mode and construct hypotheses on the semantics and verify them with unit tests. If the code is a tangled mess, it could also be tough to extract the proper bits to test on and/or set up a test environment complete enough for that.

</comment><comment><USER14> Maybe it's just me. But sometimes I draw diagrams describing how the code will work and how the methods interact with each other. A quick drawing with a pencil and paper or on a whiteboard will do. It helps me understand how the over-all system works...

<comment><USER6> Agreed. If it won't all fit in my head at first, put some of it on paper. Especially when learning the code. And re-visit the drawing, testing it against what I'm reading as I go until I'm sure its right. Once its in my head, throw it away. Wish there was some way to use drawings as comments... My friend Bob learns differently - he needs words, skips all the illustrations in manuals, they just don't sink in for him. He's brilliant, just built differently.

<comment><USER14> That'd be the day :D Drawings for comments is absolutely a great idea. Sometimes I wish I could "draw" something in my code (Arrows, bookmarks, quick diagrams, etc. beside comments). Think github with this kind of feature.

</comment></comment></comment><comment><USER15> One productive technique to read other people's code is to step into the code using a debugger (e.g. gdb)

<comment><USER16> I disagree with this. The debugger is a very, very precise tool and it can be used to gain very, very precise insights into certain code, however, very often the debugger is just too precise. It is pretty much like trying to understand a large chip by looking at how gates flip and flop.

Of course, if the code is horrible enough, then you might need to switch down to actually tracing line by line and opcode by opcode, potentially even using a debugger, but for most sane code, I think it is possible and faster to understand larger blobs of code at once.

<comment><USER17> Agreed.

In general, if you're having trouble tracing through a particular function with a narrow band of input, then the debugger can be useful. If you're trying to figure out a larger system and/or how a system works across a large set of inputs, then stepping through with a debugger is useless.

Put another way, the debugger is to programming what the microscope is to medicine: incredibly useful for some things, but not a very good general diagnostic tool. Metrics data and checking assumptions (via unittest and/or asserting expectations based on reading the code) are much better for getting an over-all idea of what's going on. Once you've localized a problem, then the debugger can help you get a precise idea of the issue, or can help you test a hypothesis (to use the medical example, you can use the microscope to test a theory that there's a bacterial infection).

</comment></comment></comment><comment><USER18> I don't mind using code folding when I'm doing this. Trying to fold the code down that I don't care about, this way there isn't as much to read and get lost in.

<comment><USER19> If you're not folding functions, but parts of functions, that's a sign that it's poorly divided up, and a refactor would benefit it.

<comment><USER20> Indeed, but you should understand it before even trying to rewrite it, then folding can help a lot on poorly divided code. `

</comment></comment></comment><comment><USER21> It might be my relative newness to software, but I enjoy looking at other peoples code to see what works (pick up new language features) and what doesnt.

</comment><comment><USER22> I'd also heartily recommend learning to read other peoples code from the assembly - softice/dissassembly listing.

<comment><USER23> Could you elaborate? It doesn't sound like it would improve your understanding of the code.

</comment></comment><comment><USER24> Michael Feathers' Working Effectively with Legacy Code is the authority on this, I think.

<comment><USER25> Not quite - it's primarily focused on safely retrofitting unit testing onto legacy codebases, since restructuring code to make it testable can easily break it.

His definition of legacy code is _code that doesn't have tests_ , so you can't fix it or replace units of it without unknowingly introducing bugs.

</comment></comment><comment><USER26> Also, using a debugger (if it can be used) can be really helpful

</comment><comment><USER27> I quite liked this, regarding this subject:

<http://perlmonks.org/?node_id=788328>

</comment><comment><USER28> I don't know about the rest of you but I got into software development to create software (ideally from scratch) and to learn clever new stuff, not to tinker with someone else's code. Of course, just like every other software developer, I have on occasions ended up working in someone else's codebase. But I have done this not out of choice - and except in a handful of cases, I have not gained any knowledge or mental satisfaction from doing so. I have done it because I have been told to by my boss.

Let's not con ourselves. Becoming a dab hand at maintaining other people's software does not make you a good software developer (writing your own software does that). It makes you a good employee who is willing to do the boring shit. The two are not the same. I for one hate maintaining other people's code, and if I ended up doing that the majority of the time, I would either get a new job, switch careers or kill myself. Probably one of the first two.

<comment><USER22> I think you're missing the point. The idea isn't to have to maintain someone elses rubbish code.

The idea is that reading _good_ code makes you a better coder. Which it certainly does. Having said that, bad code can sometimes teach you lessons in how not to do things.

Good authors probably read other books as well.</comment></comment>


Update on grade strike - <AUTHOR> https://news.ucsc.edu/2020/02/news-article.html <comment><USER2> As far as I can tell (I attend UC Santa Barbara, where graduate students started striking Thursday) this has only strengthened the resolve of the protesters. There were complaints about the strike "hurting the quality of education" which may have turned some against the graduate students involved but with this move (specifically, firing 52 number of graduate students, not providing appointments to others) I can only see the issue getting more heated.

</comment><comment><USER3> I find it ironic that on the same page where the University is detailing how badly they intend to treat the graduate students, they also have a link to make a gift to the University.

If I were in a position to make a significant gift, I would be more inclined to make it to the graduate students (e.g. through a strike fund, or other means).

<comment><USER3> A follow up to my previous comment:

I graduated from the University of California at San Diego more than 45 years ago. I graduated with honors, and I was proud to be a UCSD graduate. After I started working, I made (modest) contributions to UCSD's scholarship funds. I stopped doing that after Janet Napolitano was named president of the University of California.

It makes me sad that the University of California seems to be determined to join the Ivy League schools in becoming a hedge fund with a minor side business in education.

</comment></comment><comment><USER4> One of the better ways that occurred to me when we Cal grad students were protesting a couple of decades ago was, rather than _withhold_ the grades, simply to give everyone an 'A'. That form of protest most directly targeted the institution since it simply affected its reputation. The students were not hurt, the grad students could comply with their obligations and move on. I am surprised that such an approach never took off.

<comment><USER5> How are the students not hurt if the reputation of their university is damaged? Especially if you are a good student. Graduate admissions are aware of this kind of stuff, and it will screw over real A students royally.

<comment><USER6> Harvard awards nearly all A's and their reputation hasn't suffered for it:

[https://www.washingtonpost.com/news/answer- sheet/wp/2013/12/...](https://www.washingtonpost.com/news/answer- sheet/wp/2013/12/04/harvard-colleges-median-grade-is-an-a-dean-admits/)

I suspect it would take a lot more than one "A strike" to substantially impact a school's reputation.

<comment><USER5> I can tell you with 100% confidence that grade inflation is taken into account in grad admission. Been there, done that. Same as arbitrary scale changes (Let's give A+...). But it will be a long time until this impacts Harvard. OTOH, it seems Princeton steered back.

</comment></comment></comment></comment><comment><USER7> Some background:

[https://www.vice.com/en_us/article/wxe45b/graduate- student-s...](https://www.vice.com/en_us/article/wxe45b/graduate-student- strikes-are-spreading-in-california)

<comment><USER8> Semi-OT, but I did a double take at this:

>Like the UC Santa Cruz strike, the UC Santa Barbara work stoppage is a "wildcat" strike, meaning that graduate students are acting separately from the United Auto Worker (UAW) 2865, the union which represents more than 19,000 workers across the UC system.

I thought that was a mistake somehow, but it turns out that, yes, the UC students are organized as a branch of UAW despite not being auto workers.

<comment><USER9> Union names these days are almost entirely historical.

</comment></comment></comment><comment><USER10> Students pay through the nose, grads can barely make ends meet. Where does the tuition money go?

<comment><USER11> Administrators, buildings, and sports usually.

<comment><USER12> Yes. A lot of donations to schools are earmarked for specific things like libraries and sports complexes bearing the donor's name. The university is then forced to hire all kinds of staff to run and maintain these buildings, lest they ruin their reputation by allowing the fancy buildings to fall into disrepair.

Donations that are earmarked to help students are in the form of scholarships and bursaries. To be honest, there aren't nearly enough of those to go around.

<comment><USER13> >The university is then forced to hire all kinds of staff to run and maintain these buildings, lest they ruin their reputation by allowing the fancy buildings to fall into disrepair.

I talked with one of my professors at Iowa State about this topic. He said back in the day, donors only needed to pay the cost of the building and then the university would get hit with tons of maintenance and utility expenses.

For some time now, they have to donate the cost of the building and money for an endowment for expected maintenance costs and operating costs.

<comment><USER12> That's a prudent policy for a state school. I'm not sure private schools work the same way.

</comment></comment></comment></comment></comment><comment><USER14> Striking coincidence that I'm reading a biography on Jimmy Hoffa right now.

$2500 a year is a slap in the face to the $1800 / month the students were demanding.

Something needs to change there. For the Midwest small college town where I went $20,000-30,000 was plenty (for people without kids at least). I imagine it'd be a lot harder in CA coastal cities.

</comment><comment><USER15> > with the hope that we could resolve this unsanctioned strike and return to > our shared mission

I didn't realize most strikes were sanctioned...

<comment><USER16> [https://en.wikipedia.org/wiki/Wildcat_strike_action](https://en.wikipedia.org/wiki/Wildcat_strike_action)

They mean not sanctioned by the union leadership in this case.

<comment><USER17> The strikers have been fighting back against the union's attempts to say that UC should negotiate with the union rather than the strikers, even:

[https://twitter.com/payusmoreucsc/status/1234130912281010176...](https://twitter.com/payusmoreucsc/status/1234130912281010176?s=21)

</comment></comment></comment><comment><USER18> When I was represented by a graduate student union, our department actually tried to raise wages. This was opposed by the union (solidarity!), and the result was that the department essentially invented fake courses to pad the hours of the grad students; the union didn't care because we were "working more" rather than getting "paid more"

This led me to believe that grad student unions were not a particularly useful way of dealing with issues affecting graduate students.

</comment><comment><USER19> What's the objective argument against raising wages?

It seems like they're willing to pay extra money but not via a wage increase?

<comment><USER20> This article may help you understand the whole grad student racket better.

[https://www.ineteconomics.org/perspectives/blog/how-why- gove...](https://www.ineteconomics.org/perspectives/blog/how-why-government- universities-industry-create-domestic-labor-shortages-of-scientists-high-tech- workers)

<comment><USER19> Thanks. Makes things clear what's going on. Does this have a HN discussion thread?

<comment><USER20> Not that I'm aware of. Most of the time when I talk about this topic it gets downvoted pretty hard. Part of the program not covered in the article was to train the population that anyone questioning those policies is the usual litany of bad words. I was very careful this time not to even hint at the content of the article. That seems to have helped.

</comment></comment></comment></comment><comment><USER21> Why did these people accept their positions (with full up front knowledge of their salary) if the money is not enough?

<comment><USER22> Not starving or being homeless are great motivators. But yeah, why didn't they just get $250k FAANG jobs like the other 300 million Americans?

<comment><USER23> I don't think those people had a binary choice between starving and a Ph.D. program.

<comment><USER24> Wanting to have your cake and eat it too is no great sin. In fact, it's what everyone, everywhere in modern society is trying to do. You want a job you enjoy, and that pays well. That seems like something worth fighting for. Just what you're doing eight hours a day is a _very_ large amount of your lifetime.</comment></comment></comment></comment>


Ask PG: will the HN user pages ever come back up? - <AUTHOR> https://news.ycombinator.com/user?id=pg

<comment><AUTHOR> Currently returns

        We've limited requests for this url.

<comment><USER2> Hm? It works for me, both logged in and logged out...?

<comment><AUTHOR> It seems to work now ...</comment></comment></comment>


Mt View studying automated transit to Googleplex. (Community meeting on 9/25) - <AUTHOR> http://www.mercurynews.com/2017/09/13/mountain-view-studying-automated-transit-system/ <comment><USER2> Would vehicles from Google be contenders for this? From the article I'm not certain if the solutions are limited to airport / monorail -types of systems.

Besides Google, who has proven their autobot cars work for miles and miles?

<comment><AUTHOR> Take a look at the website for the study: [https://mountainviewagtfeasibility.com/](https://mountainviewagtfeasibility.com/)

At the bottom, there are a couple mock ups of different types of transportation considered. They include: Rubber-Tired Automated People Movers, Monorail, Cable-Propelled Automated People Mover, Maglev, Autonomous Transit Vehicles, and Personal Rapid Transit, etc...

Basically everything is on the table.

<comment><USER3> Given that Google has autonomous vehicles running on all the streets of Mt View, it seems like that would be the natural choice.</comment></comment></comment>


Microsoft has draped a beginner's user interface (Metro) over the existing GUI - <AUTHOR> http://toastytech.com/guis/win8.html

<comment><USER2> Its more like, a user interface that helps beginners, than a beginner's user interface. It's the first iteration of a UI that will improve and evolve. I really like it, particularly the emphasis on consistency in the metro app design guidelines. I like the search and share charms, the live tiles also work nicely. The emphasis on typography, space and no app chrome may not be new, but it certainly feels new and fresh on an O/S. The touch screen design guidelines are also well thought out, a simple example being the placement of common actions on the bottom right of this the screen when you swipe up, easy reach for the old right thumb! Regarding the hybrid desktop/metro situation, I think that is much ado about nothing, things can still be pinned to the task bar, I am not crying at the loss of the start menu.

<comment><USER3> As the dead user below mentions, one of the issue is that there are sometimes no indication at all on screen on what you can do and cannot do. The problem with such an interface is that it is not "affordable" in the design meaning of the world. It does not provide clues as to what to do next. That is precisely why you had so many videos on youtube showing people testing W8 and not able to find how to shut down their computer. There is no way you can find out unless you RTFM. At least the start button was a way to centralize things. With metro, there is no _center_ anymore and it looks very confusing.

</comment></comment><comment><USER4> There are no valid points in this article. 1\. The interface is extremely easy to use if you stop trying to use it like Windows 95, which seems to be the world you are stuck in. 2.The lock screen fails to tell you to do next, because anyone who has ever interacted with a computer knows to press a key or click when they encounter a locked interface. Not just phones, thinks screensavers. If this is a confusing concept, you should retire. 3\. Touch is not required, so I'm not so sure why this guy is so angry about the addition of a way to interact. 4."OMFG!!!!! cloud connected apps require an account!!!! and I have to use them!!!!" Again, just because a thing exists does not mean you have to use it. If you have a different application, install it. 5.Closing Start menu apps took about 5 seconds to figure out without wasting a page on instructions. EX: "Oh, when i move my mouse to the left a recent apps thing pops up... and to the right I get a control Menu. I wonder what happens when i put my mouse on the top of the screen? Oh a hand, I can move this around and pull it down to close!" Seems like maybe you NEED a beginner interface guy, ever heard of curiosity? 6\. "I don't want to memorize key commands!!!! I don't want a touch interface!!!! keyboards are dumb!!!! MOUSE ONLY FOREVER!!!" Apparently the only acceptable interface to this guy is a mouse, he refuses to learn keyboard shortcuts(that are in every version of windows btw, so maybe NOT learning them is the actual waste of energy) 7\. The had to rename it because of a lawsuit. 8\. The next several pages are just bitching about how the past was different and how there is no start menu, even though you've spent the previous pages talking about how its all that exists now, and how Linux won't work because he watches Fox News or something. In conclusion, according to a guy who has a website that looks like it was on GeoCities, the Windows 8 interface is both designed for children, but also too complicated for him. He needs to do real work, so much in fact that he only interacts with the user interface and makes no mention of the underlying improvements to the operating system. He laments having to use the start page to access all of the apps that he can now access from just the start page. He is so mad that you can now use touch in addition to mouse and keyboards, but is furious that he should know how to use the keyboard, and that he often has to move the mouse(even to the side OF THE SCREEN SOMETIMES! Can you believe that shit?)

Also, that pain in your leg, may be an embolism or deep vein thrombosis. It is often the result of sitting int he same chair since the 80's letting the world run past you.

</comment><comment><USER5> Is the author 12 years old? I mean, he speaks of using a 286, but then he throws 15 exclamation marks on bold and capital print and claims he has to disconnect from the Internet because Microsoft is spying on him.

How did this make the front page of HN? I thought people here cared about decent site design at the very least.

<comment><USER6> He is making valid points.

<comment><USER5> _Any person that gets their dirty, greasy finger prints on my monitor gets a FIST IN THEIR FACE!!!!!!!!!!!!_

 _Cry me a river and get off my lawn! I grew up on 256x192 in 16 glorious colors... on a blurry 14" TV screen, with RF interference both ways!_

 _Oh, I see Microsoft is trying to sell monitors now._

Incredibly valid points, and that's just from the first page.

</comment></comment></comment><comment><USER7> Ugh, someone should have a discussion with him about design aesthetics.</comment>


Hard is not defensible (2017) - <AUTHOR> https://www.alexcrompton.com/blog/2017/05/26/hard-is-not-defensible <comment><USER2> I thing this article is missing a third type of hard: time-consuming/long-tail hard. Google solved a hard problem, but it's a technical problem and it could be replicated by another company, particularly since there are probably a lot of developers who have experience working on Google's Search. But the problem is that there is an absurdly long tail of features (curated news sources, relevant social media results, answer boxes, etc) and being able to serve that long-tail is part of what makes Google so valuable. It would take years for even a well-funded team to catch up to Google in this regard and the high barrier-to-entry is absolutely a moat.

<comment><USER3> I think that's just a type of bodybuilder hard. It just takes a lot of effort, discipline and time to do it.

<comment><USER2> I disagree. Bodybuilder hard at described in the article is just a matter of effort. High barrier-to-entry means that you need extreme resources to start competing. I think they are quite different.

<comment><USER3> Having resources is just a different thing, they're not a kind of work. Getting the resources is work, sure, but it takes either cleverness (maths hard) or effort (bodybuilder hard) to get them, or is not hard at all because you already have them. But actually building the things you cited is bodybuilder hard.

<comment><USER2> That's really not true. You can try as hard as you want but you will not be able to spin up a search competitor right now because the funding literally doesn't exist.

<comment><USER4> Even suggesting you want to tackle Google's lead in search or ads as a startup will get you laughed out of the room.

The amount of time, effort, and funding needed is well beyond what any investor wants to even consider.

<comment><USER5> There are search competitors in non-US markets. The lack of funding begs the question of whether Google's search lead is simply due to no one trying to compete within the last 10 years.

DDG doesn't really qualify here as they aggregate google/bing search results.

<comment><USER3> How about Bing? Yes I know, they're easy to forget about, but....

<comment><USER5> Bing started 15+ years ago as a feature for feature clone of Google. Historically they've simply crawled Google results and replicated whatever Google returns. It could be a data point that Google has made the perfect search system as of 15 years ago - or just a footnote of the balmer era of Microsoft like Windows phone.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER6> > In startups, being defensibile means competitors can't catch you once you're > ahead.

I'm not sure this is a useful concept. Investors are burning billions of dollars trying to ensure that Uber-or-Lyft [or insert other unicorn battle here] gets un-catch-ably "ahead", meanwhile neither is a successful business in the traditional sense. There are tons of successful businesses in the world that just execute well and deliver value in exchange for money. They're not succeeding because they are "ahead" of the competition, they are succeeding because there is plenty of room for multiple competitors to succeed.

<comment><USER7> The difference is whether or not that business has network effects that reduce the viability of competitors.

For example, in the Uber-or-Lyft 'battle', sure, there are and have always been private car companies and private drivers, but when you want a car you're likely to open one or maybe two apps on your phone and call the quickest/cheapest option. Similarly, Facebook competitors have a hard time getting off the ground because when you're the only one in your friend group on a new social network, there's no one to talk to.

Meanwhile, a new email provider has a small amount of work to do to catch up with all the security regulations, but then can just provide value to its customers without having to worry about 'defensibility'. A single app aggregating Uber, Lyft, taxi, and 3rd-party car services on one screen would open those up for competition. Similarly, a federated Facebook that provided various social networks in one client would let you pick your hosting provider, configure your own feed, and communicate with people on other platforms.

<comment><USER8> Uber's problem is people living in NYC etc mostly just stay in NYC or other major city. The app advantage is only really meaningful for travelers which make a small slice of the overall market. A low cost local competitor in NYC would rapidly get New Yorker's to swap over and it could then grow one city at a time.

For now everyone is just waiting until Uber and Lyft run out of money, but longer term it's really not looking good for them.

</comment></comment></comment><comment><USER9> I agree with the article, but I also disagree with investor focus on defensibility over hardness.

If you are investing in a generic software startup at an early stage, it is much more reasonable to ask them:

"How many months/years of head start do you have over the competition, and how will you use my money to solidify this head start into an unfair advantage in your market?"

than to ask them:

"What stops someone else from doing this?"

Because if they are an early stage, generic software startup, chances are that the honest, no bullshit answer to the second question is, "Nothing." And that doesn't mean that it would be a bad business to invest in.

<comment><USER10> I fully agree, but I've yet to meet a VC that really appreciates honest, no bullshit answers.

I've talked with plenty VCs and my impression is they strongly prefer founders that are happy to bullshit them, and ask questions particularly to test that.

My theory is that the good ones do this on purpose, and the bad ones got bullshitted so often that they got used to it.

I don't think it's a terribly bad strategy even. If you're looking for Travis Kalanick style "growth at all costs" type founders, then brutal honesty is pretty low on the list of important character traits.

<comment><USER11> > I fully agree, but I've yet to meet a VC that really appreciates honest, no > bullshit answers.

That's because you need to be able to effectively bullshit your customers and users. If you can bullshit the VC, well then surely, you can bullshit anyone.

</comment></comment></comment><comment><USER12> Bodybuilding hard seems to conflate 2 types of hard tasks: move-a-mountain- with-a-shovel hard, where something is time consuming, such as having to hand- label millions of images for machine learning datasets, and quit-heroin hard, where something is against human desires, such as convincing people to abandon their current way of doing something for something else that is a short-term loss but a long-term gain, for example switching to a more performant but incompatible CPU architecture.

Math hard, as the article says, is not really defensible, since copying is easy. Move-a-mountain hard is more defensible along the time/money axes, competitors need to throw time/money at the problem to catch up. Quit-heroin hard is the most defensible, since customers will loath to pay the switching price regularly.

Of course, it's not as black-and-white as this. All products have a mix of the three, and its where the product lands in the mix that determines the promotion strategies that the company should take.

<comment><USER13> I like how you identified the hard not to do factor

</comment></comment><comment><USER14> Couldn't Google be an example of this? Search is a hard problem, even if you've got MSFT-level resources. There are definitely economies of scale and some weak network effects that help companies like Google, but I'd argue it's most because they do something hard better than anyone else.

<comment><USER3> They're not dominant because it's hard though. Bing is similarly capable, but even if it gained a clear edge would it really win out over Google? Market dominance has little to do with hardness. Making a new cola isn't hard, but brand recognition and ubiquity are huge advantages on a different axis.

<comment><USER15> Habit is also massively important in what products /brands people use. Even if there is a superior, cheaper product many people will continue using the same product because that's what they always done.

</comment></comment></comment><comment><USER16> All you have to do to be "defensible" in many industries is observe the status quo, but add decent customer service.

</comment><comment><USER17> >> It's unrealistic to think that you'll ever have a totally unique insight, let alone one other people couldn't come up with if they really wanted to.

These gentlemen would beg to disagree:

[https://en.wikipedia.org/wiki/Wright_brothers](https://en.wikipedia.org/wiki/Wright_brothers)

Before the Wrights, numerous others had tried and failed to achieve what they achieved. Of course, once the Wrights succeeded (or rather, some time after) their idea was free for the taking. But the Wrights did have a "unique insight" that was only their own.

<comment><USER18> The article says its unrealistic; not that its impossible.

Its unrealistic to tell every star High School athlete that they'll become the next million-dollar NFL player. But, its not impossible; in fact, they bring on million-dollar players every year. The point isn't that its impossible; its that its improbable.

</comment></comment><comment><USER19> I would tend to think the key is the "soft" aspects of your business. The things that can't simply be copied or commoditized. Customer service, being in tune with your target market and their wants and needs, responsiveness to feedback, institutional knowledge.

Everyone still uses Slack even though it is not an especially hard product to build, and even though Microsoft and Google have both shipped clones that work fine and integrate with their other products. Why? Part of it is brand recognition and a network effect, but I think an important factor is that _this is all that Slack does_. Slack _really really_ cares about making the best chat tool for people to use at work. They put all of their energy into constantly improving it; they give it their human attention. The same is partly true of Dropbox vs Google Drive and OneDrive.

Google Meet and Microsoft Teams don't really matter to those companies. They'd like it if you used them, they'll allocate some cash to keep them going. But it wouldn't be a _huge_ deal if they lost the battle and those products died. A company's culture, institutional knowledge, and focus can't simply be copied.

</comment><comment><USER20> This is dead on. I've also heard this referred to as "tactics" and "strategy". "Tactics" are various bullet-lists of things you need to repeatedly do to maintain best practices (eating protein & lifting). "Strategy" is generally longer term and requires clever thinking (like Pythagoras).

</comment><comment><USER21> I highly recommend the book 7 Powers by Hamilton Helmer. Helmer defines "Power" as the ability to retain meaningful profit margins for a meaningful period of time. Each of the 7 Powers is a method he has seem companies use to retain this (network affects, switching costs, etc.). Very insightful read.

</comment><comment><USER22> Tbh, it looks like they are ignoring the elephant in the room: intellectual property...

<comment><USER23> Yeah, this article is assuming a competitive environment when in reality there exists an arsenal of state tools available for corporations to entrench themselves as monopolies: IP protections, subsidies/contracts, regulatory capture, etc etc.

</comment></comment><comment><USER24> I think there are a few issues with this article.

Firstly, body-building hard ignores the fact that a competitor can't build up muscle overnight, and every day they spending building their strength is a day you continue building on yours. They need to be able to catch you, which they can't do.

Another analogy would be a marathon run. If you're already half-way through the marathon when others are just starting, the competitors need to have a strategy or capability which lets them run faster than you.

It's another way to look at why you need to be 10x better than a competitor. You need to be moving faster than they are.

</comment><comment><USER25> "Math-hard" is not defensible in the US because the patent system has been weakened so much. VCs in the 1980s and 1990s looked for a strong patent position. VCs today look for a strong marketing position. VCs as a class made money in the 1980s and 1990s made money. That stopped working around 2000, when throwing money at something to buy market share took over.

(Yes, this will be modded down by the "IP should be free" crowd.)

</comment><comment><USER26> One thing that isn't mentioned is that the 'intrinsic' body-building-hard isn't fixed for everyone.

Obligatory "Beating the Averages" [http://www.paulgraham.com/avg.html](http://www.paulgraham.com/avg.html)

</comment><comment><USER27> Can somebody explain to me why we care about these classifications, and why I wouldn't want to divide these into more (slightly) arbitrary groups?

</comment><comment><USER28> What about Intel?

<comment><USER29> Silicon is bodybuilding-hard. It is extremely hard so there are few competitors, but it is inherently a series of extremely expensive coordination problems. To churn new architectures every couple years takes an oiled machine of thousands.

<comment><USER21> Don't forget that Intel had a few decades where nearly all software was written for their x86 chips. This reinforced every computer needing to have intel, and only recently has the move to web apps made it easier for devices to use something other than intel.</comment></comment></comment>


How to use Tensorboard - <AUTHOR> https://ischlag.github.io/2016/06/04/how-to-use-tensorboard/ <comment><USER2> Chrome is warning me about scripts loading from unauthorized sources - is this anything to be concerned about?

<comment><USER3> It's just the fonts being loaded over http instead of https like the site is.

Easy fix is just change all the font urls to https since Google Fonts supports https as well.</comment></comment>


The Art of the Job Offer: Encourage Candidates to Turn You Down (2008) - <AUTHOR> http://summation.typepad.com/summation/2008/06/the-art-of-the-job-offer-encourage-candidates-to-turn-you-down.html <comment><USER2> _" Really talk through the culture during the offer. If you want your employees to work long hours, you better tell them that is expected before they accept the offer. Conversely, if you believe strongly in a 40-hour workweek, tell the candidate because many people are looking to change the world and they want to work with people who really make the company mission a priority."_

From the Wikipedia article on this company, they were pretty sleazy. Certainly not a "change the world" sort of organization.

Form Wikipedia: _" When confronted by The Wall Street Journal and CNet, it quietly revised its privacy policy both times.[26] CNNMoney described RapLeaf as "selling your identity," and TechCrunch characterized its method of identifiable data extraction of Google and Microsoft employees as "creepy." [27][28] RapLeaf later became known as LiveRamp after entering new markets. LiveRamp spun off the RapLeaf business and sold it to TowerData"_</comment>