Why Folders are holding back hassle-free File Management & Tags are the Future. - <AUTHOR> http://blog.doctape.com/why-doctape-uses-tags-at-its-core <comment><USER3> I tried tagging my files for a while. I quit. Part of it was that tagging is done via an add-on, of course, and it added an additional step to creating a file.

But I also feel like there are a lot of problems that need to be solved about streamlining the process of tagging files, dealing with typos, and auto- creating maps of the tag structure.

And even if we did move to a wholly tag-based userland, your non-technical relative/coworker would STILL find ways to lose their documents.

Maybe tagging will be a better way. But I think "files" in "folders" have survived for the entire history of file systems for a good reason - they're conceptually simple for our brains to manipulate. There's enough of an aura of physicality to them that we can leverage the part of our brain that's good at storing maps. Honestly I think the way to move forwards is more along the lines of Raskin[1] - interfaces designed to make things MORE spatial - <USER2> into tags, which are incredibly ethereal to our brains.

Files and folders are, I think, a local maxima of efficiency. Tags may be more efficient in the long run, but there's a painful trough of uselessness to trudge through before we can get there.

(Other problems I see with tags: \- importing existing filesystems, without losing the existing hierarchies - do YOU want to go back and manually tag every file you've ever made and are still holding on to?

\- can't control the importance of information. Sure, that project you just finished gets drawn huge in your tag cloud. But it's done, you want to move on, you don't even want to think about it right now because you're in the middle of the next one.

\- suggesting tags as you type is not good enough, there needs to be a lot more work put into associating tags, so that if I'm saving a file with, say, the tag for my current comics project, I'm instantly presented with the associated tags of "web final images", "book file images", "fan art", "model sheets", and various subtags of those. )

[1]: <http://www.raskinformac.com/features.php> \- and now I kinda want to try that out again, it's been a while.

</comment><comment><USER4> Let's see. I'm sitting in front of a workstation with about ten gigabytes of data. It stores all manner of projects, from pure mechanical to pure electronics as well as software-only products. They are organized quite well by product or project as required. Each product lives in a stand-alone directory that is fully self-contained. Need to work on that project on another workstation? Clone it or fork it onto that workstation and you have all files relevant to that project and nothing else.

This method works very well and has been in use for quite some time across multiple workstations, operating system revisions, tools and software revisions as well as a number of engineers. The only effort required in order to maintain this system is to abide by common sense agreed-upon directory structures. For example, if working on an electro-mechanical project, the fasteners might go in the "Fasteners" directory under the "Mechanical" folder and the embedded software might go under "Software", which, in turn, lives within the "Electronics" directory. Not tagging. Nothing that can get lost or royally FUBAR'ed if tags are lost or corrupted, etc. Just a darn simple file cabinet analog that works very well and is perfectly usable, easy to understand and fully searchable.

Don't get me wrong, I like tags. They are great for certain applications. I just don't see them as practical for anything I've ever touched in terms of project or file management.

</comment><comment><USER5> Yet another company promoting a file management app to fix a problem that does not exist. It's not even particularly unique. I've seen at least dozen such solutions. Even tried a couple of them (Anyone remember Brain - an associative array file management platform?). I always gave them up.

The real problem, I think, is that folders reflect reality. Tags do not. Most people are think of a file as belonging in one specific category. So you tag it as such. Very few people would bother trying to remember multiple tags to apply to their files. The process of organization is too cumbersome, so you stop doing it.

So what do you get if you only apply a single tag to a file? You get a flat list of folders. If the tags have a hierarchy, you get exactly the same thing as using folders. So why bother with tags?

With my Email I don't even use folders. In that case, I don't bother organizing anything. Search works just fine for me. In fact, search works just fine for most of my files these days.

<comment><USER4> "folders reflect reality" +1

<comment><USER6> I fought tooth and nail to not support proper albums for The OpenPhoto Project. After about 6 months I gave in and we implemented a native album API[1] (not something that rides on top of tags).

It's true. The argument that tags do everything that albums do and more is false. Perhaps for an engineer but the brain thinks in terms of albums (or folders for files). Nature or nurture, it doesn't matter. This is not a battle you win with engineering.

[1] <https://github.com/openphoto/frontend/issues/124>

</comment></comment></comment><comment><USER7> The obvious benefit to using tagging is that tags can be anything. The obvious detriment to using tagging is that tags can be anything. Take, for example, a contact in an address book. Did I tag "contact", "friend", "acquaintance", "people I know", or something else? How do I know what to search for? Obviously a contrived example but it easily extends for any type of document; put simply, a hierarchy is much easier to remember than a "cloud" of unlimited options. Not to mention the time it takes to save a file in a hierarchy versus tagging (how many tags should I use for optimal performance?)

I think the true future is in a hybrid. Improve the metadata on a file (Windows is making giant leaps in this territory), improve file search indexing and capabilities, and retain a hierarchy. This allows ease of both searching and browsing, and is not any different from what we're doing today (no retraining Grandma).

<comment><USER8> One way to deal with ambiguous tags is to use aliases and related-to indicators.

But I agree with you that a system can't discard the file hierarchy without discarding important qualities many people need.

<comment><USER7> That's of course a good point. However, one of the things the tagging proponents claim is that tagging reduces the effort of taxonomy. Having to manage aliases and tag links would then negate any such benefit, and might even be much more time consuming.

Now, were we to talk about some standard of tagging that has link relationships baked in, we might be talking. But then we sacrifice customization.

</comment></comment></comment><comment><USER9> There have been tagging apps that I've tried in the past (i.e. <http://www.ironicsoftware.com/leap/>) but in my experience, tagging is significantly more work than using folders.

</comment><comment><USER10> Tags are not a replacement for folders, and the opposite is true too.

A folder defines a directed graph. Combining tags loose the "directed" part. It may be good enough for some, but it's not the same and will fall short in some cases. This difference is the 1st point mentioned in the article. The article says that it's inflexible. In some cases yes, then use tags. In other cases, it will be exactly what's needed and tags will be cumbersome.

The two other limitations (related to searching and sharing) are bogus IMHO. They're not limitation of a folder system, but maybe of some implementation.

</comment><comment><USER11> Tags are good in conjunction with folders, because they provide another way to search when you forget where a file is, and you don't remember the file name.

But folders are really good at collecting files with a similar purpose together. Does a good tagging system have a notion of a "collection" or something, instead of just categories and tags. If so, it just seems like folders by a different name. Moving away from folders entirely, I would be wary of losing track of some seldom-used files completely.

But maybe this is just as much about how files are stored on disk, and disk efficiency.

<comment><USER12> The ideal implementation of tags (at least during the transition) is tags as pseudo-folders. That is, you drop a document into "Projects"->"2012"->"Foo" and the flexibility of tags is simply hidden away until needed.

When it is needed, that file can also be 'added to' the 'folders' "Teams"->"Alpha" and "Clients"->"XYZ Corp".

So, sort of like folders by a different name. But more like folders++. With complexity hidden until desired.

How files are physically stored is neither here nor there.

<comment><USER13> I completely disagree with this based on my experiencing working with several companies who moved to Google Apps. Some of these companies are small businesses (10-25 employees), but some are large organizations with hundreds of employees and retail locations around the country.

The problem with tags as pseudo-folders is that it breaks a core promise of "folders". Folders are a metaphor, and when you use a metaphor like files & folders, you're making a promise to the user. You're saying: "I'm making these things familiar to you so that you don't have to learn a new behavior."

To be clear, I have no problem with tags, and I do believe that the standard "hierarchy of folders" we use today is untenable with the volume of documents we generate, but extending folders is a bad idea.

The reason this breaks so badly is that users expect to preserve the basic move/copy dichotomy of a file/folder when we represent items as such. This expectation is rooted in the metaphor of a file or folder in the real world. I cannot place a physical document in to two folders without copying it. When I copy the document, changes made to the replica are not retroactively applied to the parent.

I have seen many Google Docs users lose hours of work because they used the "collections" feature of Google Apps incorrectly. An example, I've seen plenty of users do the following in an attempt to copy a file to a new collection in Google Docs:

* Locate an item that is already in a Collection

* Check the item in the Document List

* Click the "Organize" icon (it's a folder)

* Check the box next to another collection where they want the copy

* Click "Apply Changes"

The vast majority of the users I work with assume that the "same" document cannot exist in two places at once. They assume this because that is the way that files & folders have always worked. If an action results in the appearance of two documents, there are _two documents_. The item has been copied. It doesn't matter whether the language "copy" is used. The action is implicit in the learned behavior of files & folders.

Tags should be called tags. Users are smarter than you think. As engineers, we might be frustrated by the assumption made above, but in reality, the user is drawing an inference based on past experiences. They're applying conceptual knowledge that _we_ taught them. That's "smart".

Implement a tagging system in a way that solves users' problems and they'll flock to it, but don't make it opaque by masquerading as something they already know.

<comment><USER12> It's not about whether users aren't smart enough for tags. It's whether tags work the way users want them to.

Tags are for organization. People like to organize things in terms of visual hierarchies and landmarks. Raw tagging systems aren't popular, because most people don't memorize precise strings. [1] They remember roughly what directories look like and 'know where things are' based on whether they believe they can confidently determine "it" from "not it" while they navigate a structure.

e.g. Was the tag "RaptorX" or "2012 Predator" or "FooBird"? The user doesn't _know_. But they do know that when they navigate their project folders, they'll be able to pick out whichever project was fuzzily translated to "something like a bird of prey" in their mind. And they'll be able to do this as they navigate into a tree, as fast as if they _had_ remembered exact strings. [2]

So when people are looking for something quickly, they're going to like the visual hierarchy. And when they're first saving a file [3], or when they're looking to open something when they 'know' where it is, they respond very positively to a visual hierarchy.

It's not about 'hiding' the fact that those 'folders' are tags. Or hiding the fact that files can live in multiple places (with multiple versions no less). We're still talking about new software that people would have to be trained on and told about its particular attributes.

So the fact that, yes, you need a dialogue to capture explicit intentions when doing move/copy operations in a pseudo-folder tag system is not a problem.

[1] Also why command line OSs and command line navigation are unpopular. People _really_ like _visual_ organization.

[2] In my experience, this is what people are really saying when they insist they'd rather navigate than search, even when they 'know' where something is. It's because they "know" where something is, in terms of landmarks in the visual tree. They know in a fuzzy way. And fuzzy searching is either frustrating, or requires nailing down enough tangential data (user/date/file type) that searching isn't any faster than navigating.

[3] Almost no-one wants to think about proper taxonomy or organization or an exhaustive document profile when they're drafting a new document. They just want to stash things somewhere where they can find them tomorrow and/or reasonably direct a third party to them. Proper organization is almost always a discrete mental process that happens after a document is 'done'.

<comment><USER13> I agree with pretty much everything you said there. I guess you could summarize my post as, "just don't call them folders."

I do like that idea though. Users often treat folders like tags. In a manner of speaking folders _are_ tags, in that they label the contents. They just happen to be organized in a hierarchy. The tags get more specific as you dig deeper in to the tree.

I'll have a go at reasoning by anecdote. For some reason, the default behavior of the Finder search field searches your entire computer as you type. This always struck me as odd, because it is 180 degrees from what I wanted. I would frequently:

* Navigate to a relatively shallow point in a folder hierarchy

* Start searching from there, expecting that my search would be constrained to this location

I do this because I know (generally) where something might be, but I can't recall exactly where.

I ended up reconfiguring Finder to behave like this.

If you split the folder path by separator, you often get a set of tags. So, by drilling down in to a folder heirarchy, you're "scoping" your search by tags, getting more detailed as you go.

I think hierarchy may be the missing piece of the tagging puzzle. A hierarchy would provide guidance (and a visual component). It says, "start broad, then get specific". Imagine a workflow where you would navigate to a specific point in the tag tree, then create a document. Doing so would associate the document with the current tag set without any additional work. If needed, the user could add additional tags, drilling down as they go.

My most important point about "folders" is just that we should avoid referring to these new systems as such. If we want to make progress, we need to unhinge users' thoughts from old concepts.

<comment><USER12> > _"My most important point about "folders" is just that we should avoid > referring to these new systems as such."_

Fair enough and I absolutely agree. Though be prepared for _users_ to refer to them as such.

And as to tag hierarchies - that's where things have been going. At least, those things I follow (DMSs, CMSs-not-named-Wordpress). It also addresses the concern raised upthread of "Company A\Secrets\Company B vs Company B\Secrets\Company A". With hierarchical tags, this isn't remotely a problem.

</comment></comment></comment></comment></comment></comment><comment><USER14> What do these people who continually trash the concept of folders do for a living? Do they even work at all?

</comment><comment><USER15> Again, BeOS had a working indexing system so the folders it supported didn't effectively matter and no tagging was needed. Of course, you could create virtual folders for queries.

What made the difference to other indexing systems was that the queries were _fast_ and _real time_ because it was all implemented in the file system itself. That's what's needed to make people first trust indexing and subsequently use it as a daily tool, like we use 'ls'.

</comment><comment><USER16> How would this file system work for the non-technical user? I'm sure there will be plenty more people chiming in on the inefficiency and inferiority of the folder structure, but how about the average user?

Genuinely curious. The more I think about this type of system, the more questions I have. It seems like you would only want to use this with a SSD or other non-disk based storage.

<comment><USER17> "How would this file system work for the non-technical user?"

It does raise a number of questions that aren't immediately obvious without immediately falling back to a hybrid approach, even if it's internally. But then, you're back to folder structures again, just in a way that is opaque to the user.

For me, I was actually curious how existing namespaces in languages that are so intertwined with nested folder structures would now work (such as Java and Python).

<comment><USER18> Not to mention web browsers and web servers, which expect URLs to map to a hierarchical file system. E.g., <http://example.com/dir1/dir2/foo.htm>.

</comment></comment></comment><comment><USER8> Currently, I am working on a file management tool that uses tags fairly heavily. Obviously I think tags can be useful.

But the claim that folders can or should be eliminated is seriously misguided.

* Tags aren't enough once your file number exceeds a certain amount.

* File path provides a unique human-readable and human-understand identifier for everyone's file. A system where pieces of data don't have unique identifier is going to be serious drag at some point. Even average people need logical consistency occasionally.

* While folders may be a somewhat hard metaphor for new and casual users to understand, _so are tags_. A many-to-many relationship isn't actually something people quickly understand _fully_ even if they can quickly get fuzzy understanding it.

* When you throw out the spatial metaphor of folders and files, you've thrown out the guarantee that a file is "somewhere". I've lost and seen other lose files in a disturbing fashion on MACs. Without a keyword for file X, that you just uploaded, you can't "look around" for it.

<comment><USER19> Indeed. Have enough tags (and with files, you'll end up with enough tags) and you'll need ontologies for those tags; you'll end up recreating hierarchical structure out of naming conventions. The same tag "name" within different contexts will have different meanings, and the concept of "context" by itself tends towards hierarchy of analytic decomposition.

</comment></comment><comment><USER20> Pfshaw, tags are old hat. They are also just a re-hashing of the humble search keyword of olde.

The real new hat is search and all major OSes are doing this more or less correctly now. I don't recall the last time I browsed to a document.

Also worth mentioning that the concept of "documents" is itself a quickly aging hat. With some very few exceptions most documents are tied pretty closely to just one app and apps and those apps in turn can have more specific ways of handling those documents (i.e. projects, libraries etc).

The internal representation of files and programatic access is another matter - we do need a better way to segregate access and assign metadata to files. Possibly a relational file system would be the way to go, but it's not a problem that very urgently needs solving for anyone so nothing too exciting there for a while....

</comment><comment><USER21> Folders work standalone, tags don't.

Tags don't work without a search feature - we might tag religiously but others don't and won't.

If you're implementing a search feature then you no longer need tags.

It won't take off. Especially as these days we seem to be moving away from files full stop.

</comment><comment><USER22> While I do like tags for myself, they are also inherently problematic with a group. I tag a photo of my friend "Chardo" (his nickname). Friend #2 tags another photo of him "Richard" (his real name). Now viewing all items tagged "Richard" won't show all the photos of Richard. (Replace human names with names of places, descriptions ["bbq" vs "tom's party"], etc)

Do you have any plans for how to address this?

<comment><USER23> There's not really any need to address it specially. Tags only get added to the extent that users care, so mismatches are a problem of abundance, and to the extent tags are meaningful/accurate, they facilitate editing to personal preference.

I'm sure that successful file managers will also have some degree of fuzzy matching. But tags are still useful, even if we never realize the RDF dream of a perfect global ontology.

<comment><USER24> Do they, though? I'm not very good at remembering which tags I use, and once you have hundreds of documents sharing a single tag, if you mis-tag a new file, you may never find it again.

Folders make using previous organizational decisions easier than creating a new organization. Incentivizing that behavior is a net win.

<comment><USER23> Do what what?

I'm not all gaga over tags, keeping 'primary organizational tags' around makes lots of sense to me. We can even keep on calling them folders. My point is that you really have to construct a silly, user-hostile system for a tagging capability to actually make things worse than no tagging.

</comment></comment></comment></comment><comment><USER25> "oh I just forgot to explicitely mark this file as private, now everyone in the world can see it" - how about no ?

</comment><comment><USER26> If you wanted to "tag" files, could you not simply create hard links to the files inside a folder "tagname"?

Of course, using hard links is currently not easy for the technically incompetent, but you could change that, and it ought to be easier as you're just interfacing with existing capability.

<comment><USER27> How do you search for files with multiple tags? E.g.: "Taxes" AND "2009"

<comment><USER26> Good question. As a first pass, I'd think a search assistant that runs two searches in the background and takes the intersection of the results.

I'm a big fan of building on existing capabilities, as you can probably tell.

One other thought- in Explorer or Finder, is it possible to search within a set of search results?

</comment></comment></comment><comment><USER28> Has Microsoft done away with folders in their upcoming OS? Just curious. What about the file systems of other OS's out there?

It is indeed true that folders are the least efficient aspect of operating systems but it is strange that we're still holding on to them.

<comment><USER16> No. Metro is just an interface.

Curious, how would an OS work with no folders? All the system files just have a "system" tag?

Personally, I've learned folders. Now I have trouble thinking about a filesystem that wouldn't have them. How would you organize files on a physical disk with no file structure?

<comment><USER29> You can do away with folders in the user experience without getting rid of them under the hood. They are pretty indispensable for how software is structured.

</comment></comment></comment><comment><USER30> I do agree that files/folders are bad in general, but tags will probably not fit the bill too. I think the future file system should be lying within graph theory. Something like semantic web, if you create a file, you need to create at least one semantic link to other files. if you remove one, you need to bridge the separated graphs. But how the semantic link could make sense for human, requires far more work and research I guess.

</comment><comment><USER31> Yes, managing files (especially documents) with tags is a good idea in many cases, but not all cases.

I had an idea for a tag-based file manager for Windows, I even have registered a domain which I think is cool -

taganizer.com = tag + organizer

But I didn't go for that idea for various reasons, I'm now working on <http://liveditor.com>.

</comment><comment><USER29> People have known that folders are doomed for a while now. For instance, it's been part of Gmail's core philosophy since it was launched 8 years. The question is when the major operating systems are going to phase it out from the user experience. (Presumably, folder hierarchies will still exist under the hood.)

<comment><USER32> I don't see folders going away. (I like them much better than tags, frankly)

Google Docs started out with no folders. They added them with Google Drive [http://support.google.com/drive/bin/answer.py?hl=en&answ...](http://support.google.com/drive/bin/answer.py?hl=en&answer=2375053)

EverNote used to just have tags. Now they have "stacks", which seem to be hierarchical tags. I'm not sure who really uses that kind of stuff, it seems like quite a bit of work

DropBox is obviously predicated on the idea of folders.

<comment><USER29> GoogleDoc has them because it's integrated with GoogleDrive. GoogleDrive and DropBox have them for the same reason: for compatibility with the existing OS paradigm. This doesn't say much about the inevitability of the demise of folders except that Google and DropBox recognize that it won't happen for many years. But this is obvious given that Windows 8 and Mac OS X are both built on folders.

(I don't know anything about EverNote.)</comment></comment></comment>


Foreign Language Requirements Are a Waste of Time and Money - <AUTHOR> http://econlog.econlib.org/archives/2012/08/the_marginal_pr.html <comment><USER2> I like this guy; I took 3 years of Spanish when I was younger. This education helped me briefly when selling clothes to Spanish speaking clients. They appreciated the effort and I made good commission. That was almost 20 years ago; I have forgotten almost everything I had learned in those years of foreign language instruction.

It is clear to me, in retrospect, that it is much better to embed yourself in a culture to pick up their customs and language. Classroom instruction is simply not enough to be worthwhile.

</comment><comment><USER3> yeah, because that's what Americans should keep telling themselves:

"everyone wants to learn English and come here to America anyway because we are the best and have better versions of everything. If you want to know anything about the world, don't bother leaving New York City"

The subject of the article above is symptomatic of a larger navel-gazing mindset which literally has trapped hundreds of millions of peoples thinking patterns in a box shaped like the modern English language. Far be it for the author to examine any use for other languages further than his interest in Opera. One wouldn't seek to engage in global travel, re-settle elsewhere, conduct business or gain an education abroad, or attempt to communicate with those outside of the English Language Bubble, surely that would be inconceivable.

I want my 5 minutes back.</comment>


Is Tcl/Tk Dying Out? - <AUTHOR> http://www.markroseman.com/tcl/dyingout.html <comment><AUTHOR> For reference:

Jeff - Jeff Hobbs, aka Tcl Guy, currently CTO and VP, Engineering at ActiveState ([http://www.activestate.com/company/management](http://www.activestate.com/company/management))

Larry Virden - a well-respected Tcl community member ([http://wiki.tcl.tk/16](http://wiki.tcl.tk/16))

Richard Suchenwirth - Dev Engineer at Siemens Postal Automation -- famous in Tcl community for coming up w/ seemingly infinate _brilliant_ small solutions and demos ([http://wiki.tcl.tk/496](http://wiki.tcl.tk/496)) and happens to be a voracious consumer of cinema

Dave Welton - our own @davidw, a recovering Tcl'er ([http://journal.dedasys.com/2010/03/30/where-tcl-and-tk- went-...](http://journal.dedasys.com/2010/03/30/where-tcl-and-tk-went-wrong/))

Jean-Claude Wippler - prodigious developer, respected community member ([http://wiki.tcl.tk/10](http://wiki.tcl.tk/10))

Richard Hipp - Tcl Core Team emeratus, SQLite ([http://www.sqlite.org](http://www.sqlite.org)), fossil ([http://www.fossil- scm.org](http://www.fossil-scm.org)), among other things

Larry McVoy - ex Sun, Google ([http://en.wikipedia.org/wiki/Larry_McVoy](http://en.wikipedia.org/wiki/Larry_McVoy)), of lmbench ([http://www.bitmover.com/lmbench/](http://www.bitmover.com/lmbench/)) and bitkeeper ([http://en.wikipedia.org/wiki/BitKeeper](http://en.wikipedia.org/wiki/BitKeeper)) fame, among other things...

Gerald Lester - respected developer/community member, Tcl Board of Directors.

John - John Ousterhout: Brilliant thinker/developer ([http://www.highlyscalablesystems.com/3525/favorite- sayings-b...](http://www.highlyscalablesystems.com/3525/favorite-sayings-by- john-ousterhout-precious-experience-and-advice-for-building-systems/)) who brought us Tcl, log structured filesystems ([http://en.wikipedia.org/wiki/Log- structured_file_system](http://en.wikipedia.org/wiki/Log- structured_file_system)), great articles on event-oriented programming ([pdf] [http://web.stanford.edu/~ouster/cgi- bin/papers/threads.pdf](http://web.stanford.edu/~ouster/cgi- bin/papers/threads.pdf)) and testing/life-cycle-management ([http://web.stanford.edu/~ouster/cgi- bin/sayings.php](http://web.stanford.edu/~ouster/cgi-bin/sayings.php)), as well as the raft consensus protocol ([http://en.wikipedia.org/wiki/Raft_%28computer_science%29](http://en.wikipedia.org/wiki/Raft_%28computer_science%29)).

</comment><comment><USER2> I would like to see Tk/Tcl get more attention. I've been working with it in Python (tkinter module), and it's actually really nice. The fact that tkinter is part of the standard library is what drew me to it initially, and after using it for a couple of cross-platform applications, I see no reason to mess with QT or GTK dependencies.

I wrote a GUI application about a week ago in just a couple of days, under 200 lines of code including the GUI and backend logic. Since it's Python, it 'just works' in both Windows and Linux. Using the ttk widgets, the interface looks native wherever it's run.

Python's built-in IDE, IDLE, is written with tkinter. It's not feature-packed like the big name IDE's out there, but it works and looks decent enough nonetheless.

I wouldn't want to learn GUI programming with Tcl/Tk (again), but now that I have, it's quite easy to get what I want done with it and quickly.</comment>


Google interview questions - fun brain teasers - <AUTHOR> http://jhorna.wordpress.com/2007/09/08/google-interview-questions-fun-brain-teasers/ <comment><USER2> If using ambiguous questions and brainteasers gets Google good employees, then surely using even more ambiguous questions and even harder brainteasers will get a company great employees, right? I propose the following interview questions:

1\. The Fibonnacci sequence starts with 0, 1, 1 and each subsequent term is the sum of the preceding terms. Write out the rest of the sequence. You have 30 seconds.

2\. The problem with American democracy is that the qualities tested for during the election process (charisma, fundraising ability) are unrelated to the qualities necessary to be a good leader and policy maker (integrity, sound judgement). Briefly outline a better system of government that is equally fair.

3\. How many golf balls will fit in the average blender? Will they blend?

4\. Observe that 8 = 5 + 3, 10 = 3 + 7, 12 = 5 + 7; show that all even numbers can be expressed as the sum of two primes.

5\. Imagine you are shrunk to the height of a nickel and your mass is proportionally reduced so that your density is the same. Now, how much would you charge to wash all the windows in Seattle? (Note, you can't hire anyone to do it for you, they'll just squish you and keep all the money)

6\. Consider the set of all sets which do not contain themselves. Does this set contain itself? Answer yes or no.

7\. Using only three sentences, explain to an eight-year-old why she cannot have a puppy. (Cue entrance of crying child)

</comment><comment><USER3> I don't get questions like "How many golf balls can fit in a school bus?" or "How many piano tuners are there in the entire world?". What is the point of that? To see if you're good at estimating ridiculously large numbers?

<comment><AUTHOR> Just to see your thought process. That's why they recommend to think out loud so the interviewer gets a sense of how you think.

<comment><USER4> Exactly. If you just stare and be like "I dunno" you may be a bad candidate. If you try to resolve it, even though you are way off with the answer, it means you may be a good candidate.

<http://www.joelonsoftware.com/articles/fog0000000073.html>

(Ctrl-F impossible question)

<comment><USER3> Well, putting my natural instinct to disagree with most of what Joel says aside, I've never liked that approach. Those are the kind of questions that make me think I probably don't want to work at wherever I'm interviewing. If I really needed to solve that problem, I would probably look up the answer. I certainly wouldn't make a whole bunch of estimates that all have ridiculous margins of error; that shows a willingness to problem-solve coupled with an inability to recognize your own ignorance, which isn't a super combination

<comment><USER4> You're right on the fact it's a stupid question you have to look up, and brings barely any value to the interview (I think in a follow up version he removes the question).

Regarding not recognizing your own ignorance, I think you definitely have to mention in your answer that really you are making up all the numbers and just tackling it in the first logical way you came up with.

</comment></comment></comment></comment></comment><comment><USER5> I think questions like the golf ball and blender ones are silly, but I like questions like "How would you find out if a machine's stack grows up or down in memory?".

Here's one way in C...

        void stacktest(void *pa) {
            int b;
            void *pb = &b;
            printf("grows %s\n", (pb < pa) ? "down" : "up");
        }

        void main() {
            int a;
            stacktest(&a);
        }

<comment><USER6> We just talked about this problem in the office yesterday. My officemate got asked this for the job he got at Google, and solved it the same way. His boss pointed out only after he accepted the offer that there's no need to make a function call--just allocate two local vars in main...

Also, the same answer basically works to implement "sizeof" for ints.

<comment><USER5> I was actually asked this problem on a job interview (not Google) and gave the answer your boss pointed out, but the interviewer then pointed out that local variables aren't necessarily laid out in memory in the order they're declared.

The function call is the only reliable way I can think of. Any others?

<comment><USER7> would this work?

in main: int x; int *p = &x; start writing random data to p, p-1, p-2, etc etc return; if nothing bad happens the stack grows up?

<comment><USER6> What's your definition of "nothing bad happens"? And how do you recover if it does happen?

</comment></comment></comment></comment></comment><comment><USER8> How much would you charge to wash all the windows in Seattle: "$100 per window"

</comment><comment><USER9> 14\. You are at a party with a friend and 10 people are present including you and the friend. your friend makes you a wager that for every person you find that has the same birthday as you, you get $1; for every person he finds that does not have the same birthday as you, he gets $2. would you accept the wager?

Is this a trick question? The answer is a definite no right? Or is there some tricky detail that I am missing? If the answer is no what is the question for? To see that the candidate can think clearly and don't try to come up with "smart" solutions when not needed?

<comment><USER5> At first glance this seemed like it might have something to do with the birthday paradox (<http://en.wikipedia.org/wiki/Birthday_paradox>) but that only says something about the probability that a pair of people out of a group has the same birthday, not the probability that a single person has the same birthday as someone in the group.

Now, if the bet were "I win $x if any two people at the party have the same birthday, you win $x if none do" then _that_ is exactly the birthday paradox. If there are 23 or more people at the party then the probability is greater than 50% and you should take the bet.

So unless I'm missing something it's either a stupid question or a trick question.

</comment></comment><comment><USER10> I interviewed for Google and they didn't ask any of those.

Some of the questions they did ask however included one about polymorphism, and how C++ deals with constructors and deconstructors of a class and its child class. And one where they asked to write a function that flips the bits inside a byte (either in C++ or Java) while saying out loud your thought process. And one where they asked to write an algorithm that take a list of n words, and an integer m, and retrieves the mth most frequent word in that list.

</comment><comment><USER8> You are thrown into an empty glass blender, the blades start moving in 60 seconds. What do you do? "Stand under the blades"

<comment><USER4> Forever?

I would think start running around in circles until the blender turns over. Heh.

<comment><USER11> I'd tell jokes, stories, tap dance, something to entertain whoever threw me in, because frankly, if you've been shrunk to a nickle, picked up by some entity, and thrown into a blender, you've got more than just some blender blade to worry about. You need a champion among the big ones.

</comment></comment></comment><comment><USER12> These aren't Google interview questions.

<comment><USER13> No, they sound an awful lot like old Microsoft interview questions -- in particular, ones collected in a book called How Would You Move Mount Fuji? I wrote an article about the book for Wired News back in 2003...: <http://www.wired.com/culture/lifestyle/news/2003/06/59366>

<comment><USER14> By the way, MS improved their interview process and are not asking these stupid questions anymore... well, not putting a lot of focus on them anyway. These types of interviews have been a mixed bag for them.

</comment></comment></comment><comment><USER15> > 16\. You have eight balls all of the same size. 7 of them weigh the same, > and one of them weighs slightly more. How can you find the ball that is > heavier by using a balance and only two weighings?

Take (any) 6 of the balls, and divide into 2 groups of 3. Weigh the groups of 3 against each other on the balance.

If one group is heavier: The heavier ball is in that group of 3. So take (any) 2 of the 3 balls in that group, and weigh them. If either is heavier, you've found the heavy ball. If those two weigh the same, the 3rd ball is the heavy one

If both groups weigh the same: The heavy ball is one of the remaining 2 balls. Weigh those two to see which is heavier.

Given _n_ weighings you can actually identify the heavy ball out of a group of upto _3^n_ balls.

<comment><AUTHOR> I like this question because of you word it slightly differently, you get an entirely different answer.

If you remove the condition that one of the balls is heavier and just say that one of the balls weighs differently, instead of slightly more, you can no longer solve it in 2 weightings.

In an interview, you can follow up the listed question with this one to see the response.

<comment><USER16> By the same token, the pirate question in the article is worded incorrectly for its proposed solution.

If, as the problem is usually posed, all pirates get to vote on a division of loot, then the lead pirate can indeed get away with the hinted 98 coins.

But the article says that "the other pirates get to vote on his plan and if fewer than half agree with him...", implying that the lead pirate does not get to vote. The solution requires different logic -- I think the best the lead pirate can do in this case is 97 coins.

</comment></comment></comment><comment><USER17> A real Google interview question I got asked: "What's 2 to the power of 64?"

.. I wasn't expecting it and it totally threw me. I worked it out though.

<comment><USER5> 10000000000000000000000000000000000000000000000000000000000000000

... in binary.

Seriously though, I think a lot of times questions like that are trick questions. Unless it's something totally idiotic, it probably can't hurt to give the simple answer first before working out the more complicated answer, especially if you make it clear you know it's the simpler of two answers.

<comment><USER17> Actually, it's a pretty good test I think.

To work it out in your head (in decimal you cheater! :D ) you need to know a bit about dealing with powers of two.

<Spoiler alert!>

So for example, if you happen to know that 2^32 is roughly 4 billion, then you can figure out that 2^64 is 2^32 squared.

4 billion is 4x10^9 .. so 2^64 is roughly 16x10^18.

<comment><USER18> Just know that 2^10 is about 1000, so you do 2^4 followed by 1000^6, ie 6*3 zeros.

</comment></comment></comment></comment><comment><USER19> There's a black widow at the door, a rattlesnake in the window, and a scorpion on the phone. Do you: (A) None of the below...

<comment><USER19> ADDENDUM: My comment is a joke that refers to a simpsons episode. I have the bulk of the series completely memorized, and so I can summon up an appropriate quote for almost any situation. Since most people don't know what I'm talking about, they are likely to pull a quick google:

[http://www.google.com/search?q=There%27s+a+black+widow+at+th...](http://www.google.com/search?q=There%27s+a+black+widow+at+the+door)

What do you see? My stupid comment. WTF? Obviously, ynews is rated extremely high by google.com. This seems like a design flaw, since any idiot [1] can post here. The quote comes from a very funny sequence [2] in the simpsons when homer subscribed to a questionaire-only magazine:

<http://www.snpp.com/episodes/BABF16>

[1] eg: me, drunk off my ass

[2] The sequence was funny, the episode was stupid

</comment></comment><comment><USER8> What happens when the queen says "At least one man has cheated" - "Every woman immediately kills her husband".

<comment><USER5> Are you sure?

If all 100 men have cheated then every woman already knows that 99 men have cheated, and the queen's announcement doesn't add any new information.

Now, if the women can tell each other that they know 99 men cheated, then all women will instantly know their husbands cheated and must kill them (even before the queen makes her announcement). If they can't communicate, they have no way of knowing their own husband cheated (even after the queen makes her announcement, the "at least 1 husband" could have been any of the other 99, or hers, but she can't prove that).

Or am I missing something?

<comment><USER20> The solution uses something called common knowledge, which is that everyone knows that everyone knows that every one knows, ad infinitum. Before the queen makes the announcement they may all know that the other husbands are cheating but they don't know if everybody else knows. To see the difference consider the case where there are only two husbands (H1, H2) and two wives (W1,W2). So, every man has cheated on his wife, and when the queen announces that a man has been unfaithful, then consider the situation from W1's perspective. She knows that H2 has cheated on W2, she doesn't know that H1 has cheated on her, and she can't talk to W2 about it. With the announcement, from her perspective, there are two possibilities (both H1 and H2 are cheaters), or (just H2 is a cheater). Now, to continue we need to think about what W1 will think about these two possibilities given her incomplete information: If it were possible world where (just H2 is a cheater) and H1 is honest, then since W2 would know that H1 hasn't cheated then W2 would conclude that (just H2 is a cheater) since at least one husband had cheated. Thus, by the laws of the island W2 would kill H2 the day of the announcement.

Since W1 considers it a possibility that her husband, H1, was faithful, she won't do anything the first day; instead she'll just wait to see whether W2 kills H2.

By symmetry W2 will go through the same line of reasoning about W1. Thus, both will do nothing the first day. So then on the second day, W1 will realize that (just H2 is a cheater) must be false, since W2 didn't kill H2. So, she'll go ahead and kill W1. (Apply the same reason symmetrically to W2). Therefore, they'll both kill their husbands on the second day.

The rest of the details are pretty easy to establish. The point is that 99 days later all the men are killed.

<comment><USER9> But if they can talk to each other about it they would have killed all the man before the queen came.

<comment><USER16> ...which is why it's implicit in the problem's statement that they can not talk to each other about it.

</comment></comment></comment></comment></comment><comment><USER21> is the "birthday paradox"-like one there to catch out those that have been training for these questions, spot a birthday question, immediately calculate for 10*9 pairs rather than just 9?

<comment><USER16> It certainly seems to be some sort of trick question, but it couldn't be to catch the mistake you mention: The bet is a losing proposition even if you win $1 for each person sharing any other's birthday, not just your own. It remains a losing proposition even if you bring the number of people up above 23 (the birthday paradox number) _and_ reverse the 1:2 payoff _and_ assume the bettor has no special information.

Perhaps the kind of solution they're looking for is something along the lines of "Only if I knew that seven of the other people's birthdays matched mine." Or maybe this is simply one of those "impossible" questions designed to test your creativity.

</comment></comment><comment><USER22> For most of the questions, I as an entrepreneur would answer like "does this really matter?". You normally have other problems than that...

<comment><AUTHOR> Well it's a matter of sales - you have to sell yourself and if that's what they are looking for, you might as well do it.

The same way you impress your clients you have to impress the people interviewing you.

Also, these are fun to do and give your brain a slight workout.</comment></comment>


Ask HN: PSD2 - Is EU trying to rid itself of all SaaS? - <AUTHOR> Stripe just emailed their customers a link to this page:
https://stripe.com/docs/billing/migration/strong-customer-authentication
If I read it right, it means that the EU is forcing a 2-factor authentication flow for every single payment, recurring or not.
I'm running a SaaS business (https://talkjs.com). My reading of this is that we have to send every EU customer we have an email each month that goes "Hi! It's time to pay again! ^_^" with a link. They then have to click that link, login to our site, and then go through a 2-factor payment authentication flow. This means they need to have all the required gear for that on them, which depending on their bank will often mean having a special bank-issued debit card reader ready that can generate unique one-time auth codes.
Our customers will get one such email every month for every service they use. If they're a SaaS-heavy business like we are, they'll get tens of these emails each month, driving them mad and away from us, to any alternative that can help them escape from this madness.
Am I reading this right? Is this stuff really this insane? Does anyone have more insights here? Mitigation strategies? <comment><USER2> > is forcing a 2-factor authentication flow for every single payment, > recurring or not.

Only for the first payment. But the first payment might be later than the user signing up to the SaaS. "Examples where the first charge is delayed until a later date are free trials, metered billing, and $0 plans."

If you charge the same amount every month, then there is an extra step for the initial payment but no distraction later.

</comment><comment><USER3> (I work at Stripe, specifically leading our subscriptions and recurring revenue product, Stripe Billing)

On a high level, the EU is trying to protect consumers from predatory businesses. We think protecting consumers is awesome. However, by virtue of creating stringent laws to do so, they've inadvertently caught many good businesses in the trap as well.

You're right that the worst case scenario is that you'd need to send an email (or just use the pre-built emails we created/tested/optimized) to your customer every month, for every charge. But it's quite unlikely that this worst case scenario would happen. This is because the regulation allows for exemptions, which means that certain charges don't need to go through 3D Secure2 every time.

Examples of exemptions include regular amount subscriptions (same amount, same interval; only the first charge needs to be authenticated), what's called "Merchant Initiated Transactions" which means that metered/usage based billing can also be exempted, and "merchant whitelists" where customers can just put trusted businesses on an exempted list. The challenge with these exemptions -- the reason we can't 100% promise all of your same amount recurring charges won't have 3DSecure applied -- is that it's up to your customer's issuing bank (e.g. Chase, HSBC, etc.) to apply the exemption at their discretion. We have been interviewing top EU banks in the past months and the vast majority of them plan to exempt recurring transactions when they assess fraud level as low.

We know this is complicated, developing expertise on the vagaries of issuing banks and global regulators is not everyone's dream job, and is not why you started a SaaS business.

But this _is_ where we have spent time developing expertise, and that's why Stripe Billing wants take care of this for you: we will automatically apply for an exemption whenever it is potentially available, and deeply optimize for recurring related exemptions in particular. We will understand the nuances of different issuing banks, and give them the right information in the network request we make to maximize chances of success. From your standpoint can treat this logic kind of like a black box -- just attempt the charge, Stripe will either tell you it's all good or not. If it's all good, you'll just see a successful outcome. If not, you can then choose to have Stripe auto-send emails and reattempt the charge, or you can do so yourself.

Most importantly: Stripe wants to do whatever is in our power to help SaaS businesses and other subscription businesses succeed. As this continues to develop (and btw, it looks like something like this is going to happen in Australia as well), we've got your back and promise to do whatever we can to maximize your revenue under these regulations.

If you have any other questions, would love to be helpful. Stripe will stay in touch — we'll be emailing you as changes happen — but you can always email me at email@example.com, or just reply to the email you received earlier today!

(edit: quick grammar fix!)

<comment><AUTHOR> Thanks for your extensive reply!

It's really cool how much work you do to smooth over the insane legalisms invented by politician lawyers. Do you know whether Stripe is planning to one day do the same with the EU VAT mess? Right now I can't use Stripe's autogenerated receipts, and I can't Stripe Checkout, merely because both lack VAT number field.

<comment><USER3> it's funny you should mention...

We're actually launching something next week. Stay tuned!

</comment></comment></comment><comment> BA4gDY-cqjsEPWn Assuming you are actually reading it right. I'm probably not your average SaaS consumer, but here's my 2 cents:

As a person who prefers to manually pay every bill every month I consider this a great thing. I'd be happy if this was already in place for every company in every country.

I do find 2FA very annoying though so I wish they didn't put that in...</comment>


Ask YC: What time zone are you in? - <AUTHOR>

Am I the only one to notice that responses here are not only related to the quality and interest of the content, but also to the time of day?  Seems like a lot of activity while I sleep (U.S. Eastern Standard Time GMT-5).  Maybe I need to shift my "hacker.news day".  Where is everyone at? <comment><USER3> I am steadfastly in GMT. Wherever I go, my watch, phone and laptop remain in GMT. Even in the summer, in the UK, which goes to GMT+1, I stay in GMT.

What hours am I awake? Whatever hours are the most productive. If I have admin tasks then I'll be in daylight hours. Otherwise, I'm most productive doing extended stints.

I've noticed there is a large contingent of UK hackers on this forum. This could account for some activity outside of US office hours. The remainder is probably people doing irregular hours.

</comment><comment><USER4> I was just thinking the same thing while responding to the bootstrapping thread which seems to have made it to the front page since I left work yesterday, with a ton of comments.

I'm right here with you at GMT-5.

</comment><comment><USER5> GMT -8 (Pacific Time). I'm surprised that there aren't that many over here it seems.

<comment><USER6> I'm sure there are plenty but most are still in bed.

<comment><USER7> I'm PST, and I've been up for quite some time, but that was for the purpose of talking with JST.

</comment></comment></comment><comment><USER8> It's clear that the majority of YC hackers have been lucky enough to avoid Timezone coding -- otherwise you'd not consider "GMT-5" a timezone!

It's America/New_York, according to the Olson DB.

</comment><comment><USER9> Pacific Time

<http://www.kirubakaran.com/phr0zen> has twice-a-day snapshots of Hacker News front page. May be that will help?

<comment><AUTHOR> Nice hack. Thank you.

</comment></comment><comment><USER10> I'm in EST also. I notice there's a lot of stuff later on, but I always assumed that was because there were a plethora of night-owl hackers. :)

</comment><comment><USER6> CET which is UTC+1

<comment><USER11> So do I.

</comment></comment><comment><USER12> Alaska Standard Time -9 GMT

</comment><comment><USER13> GMT+5.5 Bangalore, India

</comment><comment><USER14> central America/Chicago

even though i live in milwaukee

</comment><comment><USER15> GMT +1 (France)

</comment><comment><USER16> GMT +3, Moscow

</comment><comment><USER17> GMT - <USER2>

</comment><comment><USER18> GMT+5.5 India

</comment><comment><USER19> GMT+2, SAST

</comment><comment><USER20> GMT+2, EET

<comment><USER21> I'll double that. EET. Turku, Finland, to be more exact.

</comment></comment><comment><USER22> PST here.

</comment><comment><USER23> GMT+2

</comment><comment><USER24> GMT+8

</comment><comment><USER25> GMT-6

</comment><comment><USER26> GMT+1

</comment><comment><USER27> GMT+1

</comment><comment><USER28> UTC

</comment><comment><USER29> IST

</comment><comment><USER30> pacific time for me. daytime is reasonably active IME. at 2am, not so many people are on. that's no surprise: 2am my time means it's later for the rest of the US.

</comment><comment><USER31> I'm timeless. (Really!)</comment>


The Real Amazons - <AUTHOR> http://www.newyorker.com/books/joshua-rothman/real-amazons <comment><USER2> The knights in the movie 'King Arthur' (with Clive Owen and Keira Knightley) are Sarmatian knights. Without respect to Amazons and the women, it seems the movies somewhat accurately represents the knights.

</comment><comment><USER3> about the equalizing role of technology (well, horse and bow was the technology back then :)

"But, on the steppe, "the horse was the great equalizer, along with the bow and arrow, which meant that a woman could be just as fast, just as deadly, as a man," "

</comment><comment><USER4> Seems like a lot of wishful thinking and projection of current ideology, a la Margaret Mead in "Coming of Age in Samoa" of which she later admitted she fabricated much.

<comment><USER5> "of which she later admitted she fabricated much."

That is stunningly inaccurate.

[http://en.wikipedia.org/wiki/Margaret_Mead](http://en.wikipedia.org/wiki/Margaret_Mead)

[http://en.wikipedia.org/wiki/Coming_of_Age_in_Samoa](http://en.wikipedia.org/wiki/Coming_of_Age_in_Samoa)

At most there is a wildly controversial claim from another anthropologist that Mead's subjects told her fabrications.

</comment></comment><comment><USER6> That's a nice article. I found the style good, the content interesting.</comment>


Build a RESTful API in less than a week - <AUTHOR> http://berest.io <comment><USER2> So you built a PHP framework and are trying to sell it as a SaaS?

<comment><AUTHOR> Yes, that's what we are trying to do. The Saas part will mainly be to get the updates and new features as we add to the framework.

<comment><USER2> Okay. How do you differ from open source frameworks that are completely free and not attached to a service?

<comment><AUTHOR> I've been using a lot of them and found out I had to rebuild the same thing over and over again when moving from one company to the other, like localization management, user management, account management, database connectors, etc. This is what we do different, we provide tool so developers can build a RESTful API in a few days. It actually sits on top of Silex, a micro-framework for PHP.</comment></comment></comment></comment>


What are some things you wish you knew when you started programming? - <AUTHOR> https://www.quora.com/What-are-some-things-you-wish-you-knew-when-you-started-programming/answer/Ken-Mazaika?share=1 <comment><USER4> Write 5 tests for a piece of code that you think is working but has no tests. You will find at least 1 bug every time.

Staying at work longer won't help you produce more and better code. Sleep and exercise will.

People who get angry about technical choices like what framework to use or what coding style or how tightly to enforce rules will flame out. Don't be that person.

If you think you need to rewrite it from scratch, think again. Look up Chesterton's Fence.

<comment><USER5> "Chesterton's fence is the principle that reforms should not be made until the reasoning behind the existing state of affairs is understood."

 _In the matter of reforming things, as distinct from deforming them, there is one plain and simple principle; a principle which will probably be called a paradox. There exists in such a case a certain institution or law; let us say, for the sake of simplicity, a fence or gate erected across a road. The more modern type of reformer goes gaily up to it and says, "I don't see the use of this; let us clear it away." To which the more intelligent type of reformer will do well to answer: "If you don't see the use of it, I certainly won't let you clear it away. Go away and think. Then, when you can come back and tell me that you do see the use of it, I may allow you to destroy it."[1]_

Source - Wikipedia.

<comment><USER6> Chesterton's Fence is a great example of why code comments are critical.

If the code is doing something that isn't immediately obvious to a programmer on a deadline, there should be comments explaining why it's there.

"Go away and think" just means the programmer who wrote it couldn't be bothered to take a couple of minutes to be clear, resulting in later programmers wasting hours or days (or worse) re-discovering the reason for something in the first place.

<comment><USER7> A counterpoint to this is that the very reason to refactor code usually is that it isn't understandable anymore. I'd rather read it in the way that you shouldn't rewrite code for which you don't understand _the problem it 's trying to solve_.

In my experience, that part is usually much easier, since you're working in hindsight.

There's a great interview Peter Seibel did with Bernie Cosell[1], where Cosell explains that his approach to debugging usually consisted in

a) understanding what a specific piece of code is _supposed_ to do and

b) rewriting it so it _actually would do it properly_.

Of course there's much to be said on when this approach is overkill and when it isn't.

[1]: [https://en.m.wikipedia.org/wiki/Coders_at_work](https://en.m.wikipedia.org/wiki/Coders_at_work)

</comment></comment></comment></comment><comment><USER8> 1\. Learn to be criticised and to gain as much knowledge from that, as possible.

2\. Learn to fail and feel good with that. And as above, to gain as much knowledge from that, as possible.

3\. Learn to be confident enough to defend your solution.

4\. Read as many non stricly technical books related to programming as possible. Ie. "The Pragmatic Programmer", "Rework", "Clean code", etc.

5\. Don't take your job too serious. If you worry about your code after hours, stop! And if you can't, change your employer.

6\. Everyone makes mistakes. Just try to not repeat them.

</comment><comment><USER9> I think that 5. and 10. are not as good advice as they sound. Not many people are good teachers and if you try to learn with other, they will oftentimes attempt to do all the work, especially thinking part, for you. If they already know more, there is no way for you to match their speed and you end up just doing what they dictate - worst possible way to learn. If you want to become good, you need to spend time learning alone, when you can try out wrong path for a few minutes, solve problems independently even if it is slower, make mistakes and finding out by yourself.

It is different if people around you have good social skills on top of tech skills, but many people are not like that. A contact with community is important for motivation and having possibility to work with good quality people is indispensable. However, much of important learning happens when they are not in the room and they can not take control of keyboard and tell you solutions to problems before you had the chance to think.

</comment><comment><USER10> "9\. Trying to understand everything is a lost cause. In the beginning, I tried to chase down the "why" to every problem I encountered. This isn't necessary."

Nonsense. That is literally the worst advice you could give to an aspiring programmer. It is precisely necessary to get to the bottom of your programming problems and bugs, that's the stuff that increases your knowledge and lets you understand systems deeply. Be curious! Track things down all the way to the OS and the hardware! Recently, I just found an OS bug that negatively affected the realtime performance of our controllers. Dig deep! Never write code based on ignorance!

<comment><USER11> Wanted to write exactly this. This is a hurtful advice.

</comment></comment><comment><USER12> Since I see no mention on wages (maybe OT) I will chime in:

Value your work, even if you think you are "still learning". I spent way too much time on under-market salaries writing good code. I wish someone had told me I could be earning 5x whilst still at uni.

<comment><USER13> Correct. I thought that somehow getting that degree suddenly qualified someone as a "real engineer". You're better once you've finnished, but your capability is still on a continuum starting prior to your first class.

</comment></comment><comment><USER14> Don't drop critical thinking and "hammock time" in favor of Agile. Some problems require a bit of personal reflection, without it you can easily end up building something atrocious, even while following all the "best practices". I spend a couple of years at a SCRUM shop and all we did was "finishing stories" without any regard for architecture. The technical debt was truly stunning. These days I easily spend a day just thinking about the problem before writing some code, which then still happens in a REPL-driven style to allow for experimentation and feedback. Best of both worlds I think. Also, most programming is actually fairly easy. Focus on the (business) problem you want to tackle instead of the code. Code is ephemeral, the only thing that matters is the business value and the user experience for getting there.

</comment><comment><USER15>
      side effects are bad

      code should follow data

      it won't do what you intend until you've verified it

      solve the problems you have, not the ones you anticipate you will have

<comment><USER16> > side effects are bad

How are side effects an inherintly bad thing? They are pretty important in many cases.

<comment><USER15> Side effects from functions that modify global state (or importing global state elsewhere) are bad because they increase the complexity of a program in a way that can very rapidly spiral out of control. The operation of a function reading global state is no longer easily predictable and you'll be tracking hard to replicate bugs.

Better to have a function rely entirely on its arguments and to output the result as a return value.

Side effects that do things such as persisting data or producing output are - for the most part - acceptable, if they are contained in such a way that you move to as much of a 'functional' approach as soon as you can.

So reserve your side effects for the edge of your program, keep the rest as side-effect free as you can.

Now that was a little long for a bullet point list hence the abbreviated version.

</comment></comment></comment><comment><USER17> Although I had done some programming before, I always remember the first lecture of the first year of the CS course I did where the lecturer basically concentrated on the importance of KISS (i.e. Keep It Simple Stupid). He did say that we'd probably not believe him, and of course we didn't as we were all desperate to prove how awfully _clever_ we were. He did also say that if we stuck at things long enough we'd probably come to share his view.

How I wished I'd manage to believe that bit of advice a bit earlier in my career and saved a few projects from my zealous architectural astronautics. Well, at least that's one lesson I did eventually learn.

<comment><USER18> Can't agree with this one enough. I'm currently battling through a project full of people that are too smart for their own good and too stupid to realise it.

I had a huge argument today with someone that wanted to wrap a certain type of higher order function ("foos") in another higher order function with a particular name ("fooGenerator()") for the sole purpose of differentiating it from a different kind of higher order function in the same file ("bars").

I lost the argument. It turns out using heading comments to seperate groups of similar functions, or god forbid splitting up the 400 line file into multiple smaller ones, is too confusing and prone to errors by maintainers ("What if they put a new foo function in the section for bar functions!")

<comment><USER19> I am learning that sometimes people try to defend their ideas by coming up with ways to make their idea work. If accommodating the solution is more work than actually implementing it, it might not be the right solution.

</comment></comment></comment><comment><USER20> That unless you are in a pure code monkey position, programming is at most, 30% of the job and there is an array of skills that have nothing to do with programming that when mastered, will give the impression that you are an expert programmer.

<comment><USER21> I have some idea what you're hinting on but no entirely. Im in my 3rd year in and have seen a lot of bullshiting. Should I just learn to start bullshiting?

<comment><USER20> Is everything other than programming, "bullshitting"? Far from it. I am referring to a multifaceted spectrum of skills, no different than one every other non-technical professional has to contend with. Linguistic skills, logical fallacies (recognising other peoples' bullshit), arguing pro and contra, team dynamics, business knowledge (if you're in line of business software, which most of us will be in), testing (a science in itself)... and yes, the softer skills such as marketing yourself and trying to present your work in the best possible light.

I would also recommend learning how politics function in the workplace, if only so you can defend yourself from other peoples' black magic.

</comment></comment></comment><comment><USER22> This is what I've learned over the years (since 9/BASIC in 1989.)

1\. Number of active users of language matter more than the language itself.

1.a Fads come and go.

2\. Math matters.

3\. Elaborate design/architecture before programming is a waste of time. Emphasis on elaborate, not architecture.

<comment><USER19> On #3: Agreed. In my experience, every time someone comes up with some grand design before writing any code, it's built on one or more assumptions about the problem. Then work begins, and one or more of the assumptions inevitably turn out to be incorrect and the whole design gets deflated.

</comment></comment><comment><USER23> Besides all the good technical advice already mentioned here I'd like to add some things I find very important, as I'm watching over the career progress of 2 junior developers.

Take VERY good care of your mental and physical health. Do not overwork yourself. It's a marathon and you will overcome most challenges with time and discipline. You don't have to be a genius/prodigy.

Don't put too much pressure on yourself - and it's hard not to due to all the praising of highly successful programmers - but nobody is an overnight success.

Enjoy your time off.

</comment><comment><USER24> How about: \- Its not about code, its about solving problems. \- Learn to cope with change. Programming constantly changes, make sure to deal with it and don't get your self stuck on one thing you can do. Pick the cherries out of every programming language and frameworks out there. You're a C# guy? Do some ruby, you ruby guy? Do some node. \- Don't give a shit about mainstream. Do what works for you. But keep an open mind and consider every option, and always try to investigate why stuff works a certain way. \- Dont freak out if you're lost in new things. Its normal, fork repos, join groups, irc channels get familiar with things. \- There is no end-game. If you think that you're going to be finished in a couple of years you're wrong, there is aways shit tons of new stuff to learn. \- Dont be a perfectionist, its gonna stall you and make you never deliver. \- Always deploy, refactoring shit is easier when you know what problem your code introduces, so don't optimize prematurely.

</comment><comment><USER25> That there is a huge amount of marketing hype that comes out of silicon valley for languages, projects, etc. and for the most part you are wasting your time to get too deeply immersed in any one thing.

</comment><comment><USER26> "Let go of your emotions" is very superficial and not really doable with the advice that is given.

We build emotions based on the truths we perceive. The only way to healthily change emotions is to change those truths. If you feel very attached to your work and flip out (fear, anger) if someone else finds an error in it - <USER2> need to change the believe that something bad will happen to you when you make mistakes. Nobody will hit you over the head * , nobody will laugh at you * , you will not lose your job or career * . You will not be worth less as a person. You made a mistake because your brain is built in a way that allows for errors, and so is every other human brain on this planet.

* Ok somebody might do these things to you. But you will cope, and other people will help you cope.

</comment><comment><USER27> The true language of computing is mathematics, and its power and beauty are masked to those who cannot speak it. Programming languages are powerful tools for communicating ideas and encoding the _language of mathematics_. You can use these tools to shovel bits around without understanding the language, but you won't be able to see or say much unless you become fluent. Creative expression comes with fluency, and fluency requires the perspective unlocked through deep understanding. Becoming fluent in the language of math is the rite of passage one must cross to receive its true potential.

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

<comment><USER28> Logic more so than mathematics. Mathematics as a means to achieve efficiency, which is an afterthought most of the time. Most working programmers don't need more than a basic understanding of algebra.

<comment><USER27> Logic is a form a mathematics, and understanding logic is essential. Indeed, for many programmers, that's the extent of the math they know and use. And that's what limits them. There is so much more.

<comment><USER28> Unless you're solving mathematical problems, how does math directly translate to programming (ignoring efficiency)? I agree with the sentiment that the connection is over-stated. Whenever I hear this argument, it feels like reductive FP propaganda. I'm interested in FP, but not because "it's just math". Sometimes it's nice to piggyback off of mathematics, and it's true that a program is a sort of proof, but sometimes (most of the time) it's better to not be so formal, and not be so academic.

Also, math and logic are obviously related, but logic is not "a form of mathematics". If anything, mathematics is a form of logic.

</comment></comment></comment></comment><comment><USER29> I wish I knew back then that being an employee is not the only way to earn money through programming.

<comment><USER30> Can you elaborate?

<comment><USER29> I spent my first 5 years after university as an employee because "everybody has a job" and it never occurred to me that I might freelance or start my own business.

Doubly pitiful because I didn't need that much income back then, and later it became much more complicated to stop being employee due to higher cost of living in a place I moved to and due to need to support the family.

</comment></comment></comment><comment><USER31> > 7\. You don't need 5 monitors.

No, but more than one can work wonders for productivity if you are looking up documentation while coding, so you don't have to constantly alt-tab and forgetting where you were.

<comment><USER32> I think this one is really a horses-for-courses situation. For me, my current setup of two 2560x1440 monitors plus a 15" laptop is absolutely optimal - <USER3> can spread a load of stuff out everywhere, flip between a few spaces, and just generally be super-productive. I can still be productive working from just the laptop in a coffee shop, but I feel very constrained and find myself shuffling windows around to get stuff done (even just writing an email whilst referring to something else), and I generally don't like it and pine for my multiple monitors, especially if I'm doing any sort of development work.

Other people seem to be able to be just as productive from a single monitor or laptop, and tabbing between things is very much just part of their workflow - I remember at one gig we bought a couple of displays for one dev and he never even bothered plugging them in.

(I don't think anyone really "needs" five monitors, though.)

<comment><USER33> To chime in anecdotally as a one-screen guy, for me it's all about being able to unplug my laptop, switch locations, and not feel like my workflow's crippled. I don't like feeling anchored to my desk, or even the office as a whole.

</comment></comment></comment><comment><USER34> I wish I knew how unsavory a long-term career in tech would be. I wish I had just tried to get rich instead.

</comment><comment><USER35> 1\. Learn regex properly and thoroughly, in one go. Learning it incrementally, will take a lot more time in the long run.

2\. Write code that works reasonably well, then refactor it to be smart/elegant.

</comment><comment><USER36> For anything you want to learn in your life the best thing you should learn:

Learn from the Masters, do not seek advice in random people on Internet.

It is called "modeling". Pick your masters-mentors carefully.

For example we have people in my company that could do the work of tens or hundreds of people just by themselves because:

-they are incredible experienced and smart. -they know regular expressions, know how to automate everything. -they understand good design, and understand people as well as computers.

Just living around this people you will start modeling them, and doing the same they do.

But people also model bad behaviors just by proximity. Fat people use to have friends that are fat, and family members that are fat. The same happens with smokers or drug addicts. You pick from your surroundings subconsciously.

For example someone here recommends you to not use vim, use an IDE. Well , the masters I know either use vim or emacs a lot. They can use other tools like IDEs too, but instead of depending on someone else for automating the stuff they need they use to make their own tools.

Remember that no big company like Microsoft, Apple or Google are going to make your life easier for making your software multi platform for example, but for your company it could be essential. On the contrary, if you only use their tools your life will be miserable if you go against the interest of those companies.

</comment><comment><USER37> Seek out well written projects and contribute to them, you'll learn far faster the principles of good software than working alone or on badly written code.

Focus on maintainability above speed, terseness, or perfection. Worse is better (<\-- it took me many years to truly understand this expression)

Your plans/thoughts on any matter are strictly inferior to your thinking after putting it into practice, so do not plan too much. Instead, experiment.

<comment> GuB-42 I think there is value in working with poorly written code. You will learn all the details of the language, because you will see many edge cases. You will learn about all the bad ideas (aka anti-patterns) so that you can avoid them. You will learn that comments are lies and that there are things that you can't trust. And hopefully, you will learn how to turn bad code into good code without introducing more bugs than you have fixed. If you end up coding for a living, you are more likely to see really bad code than good code. Not only because though budget cuts and the occasional mess up by incompetent coders, but also because good code simply works, and there is no need to touch it.

I totally agree with the "experiment" part though. Everything you learn is worthless unless you actually code something, preferably something useful.

On a more technical point, I think that terseness is undervalued. The first rule of good code, for me, is "write short code". There are a few exceptions but these are just that : exceptions.

<comment><USER37> I was writing from my own regret. I feel that I learnt surprisingly little by spending a decade rewriting badly written code. I should have found out what encapsulation was years earlier. Sure, there are lessons there, but I think you will pick most of them up anywhere; you're always exposed to code you don't like.

I still value terseness highly, as in my opinion it's strongly correlated with readability (though not at all when taken to extremes), but I very often have to increase verbosity to increase maintainability. E.g. don't take shortcuts that will leak through abstractions.

</comment></comment></comment><comment><USER38> If you can afford the time cost, type out the code you were going to copy/paste from somewhere else. You'll get a better feel for what's happening as you type, allowing you to assimilate style conventions in with the rest of your codebase. The few typos you will likely make will force you to understand how exactly the code achieves goal.

</comment><comment><USER39> 1\. Don't stay in a job that makes you miserable.

2\. The design and specification stages of programming are not pointless enterprise makework, they are genuinely useful.

When writing a program, make sure you understand what you're trying to achieve in detail, and write a plan about you intend to do that.

If you don't know what you're trying to achieve (and by extension your customer/client doesn't either), schedule in some research / exploration work as the first part of your plan.

Once you have a better idea, redo your plan (and maybe your budget) and check it with your customer/client.

3\. If something is going wrong, or you think something is going to go wrong, it's much better to tell someone as early as possible. Even if it's your fault, don't sit on your shame - get some help.

For example, if you're going to go over budget, you may be able to get some more budget. Or you may be able to get some features cut.

</comment><comment><USER40> Code coverage doesn't say anything - if it doesn't fulfill the requirements it's useless.

</comment><comment><USER41> The vendor's way of doing things is just one of many possible ways, the vendor is often not right, the vendor often has their own agenda, the sky will not open and smite me if I don't go the vendor's way.

</comment><comment><USER42> You will write tests, because without them, you cannot refactor.

With them, you will be able to quickly and easily make your code better and better, with much less risk of regression.

As a result, the initial implementation details of your code are not very important, and you don't have to spend much time thinking about how the code might evolve in the future (which is unknowable anyway).

PS Don't spent much time testing the internals of your code. Check that the inputs and outputs are correct, as thoroughly as you can. Testing internals actually makes refactoring harder.

</comment><comment><USER43> Smalltalk plus the book about patterns. That would have been a game changer. It happened to me but years later and largely improved my coding quality on all other tech stacks

<comment><USER44> >the book about patterns

Could you be more specific?

<comment><USER45> I think he means Kent Beck's book.

</comment></comment></comment><comment><USER46> Use an IDE, not VIM

<comment><USER47> This advice is of such low caliber and so out of touch it's almost as if you didn't even bother to open the submission before posting. It's practically useless to anyone, especially when you don't even attempt to give some motivation for it.

It's over-generalized, likely because you know only one thing or you've developed into doing only one thing and for that one thing vim is the worse choice.

<comment><USER46> No, it's so spot on and correct it does not need lengthy justification.

</comment></comment></comment><comment><USER48> Quantity trumps quality: if you code a lot and keep your eye out of quality, your style will improve.

As a perfectionnist, I had to learn this the hard way.

[https://blog.codinghorror.com/quantity-always-trumps- quality...](https://blog.codinghorror.com/quantity-always-trumps-quality/)

</comment><comment><USER49> If you are constantly turning work down keep raising your prices until you have enough work to keep you busy.

<comment><USER30> What are you coding that you're receiving contracts for?

</comment></comment><comment><USER50> That I would still be programming 35.5 years later. I would have quit and gotten a PhD and then continued.

</comment><comment><USER51> Lurk GitHub repos for solutions that you've done some time ago. It could clearly show what you've been doing correctly and what you could improve. Then, if you see some place for improvement in some repo, make a pull request. Great way to learn, period.

</comment><comment><USER52> Not waste much time learning all the trending programming languages of the moment.

</comment><comment><USER53> I wish I had learned many programming paradigms; I only started experimenting with functional programming a few years ago. Imperative/OOP dominated every college course and book I read.

</comment><comment><USER54> Review how others write in your language by examining GitHub projects.

</comment><comment><USER55> > What are some things you wish you knew when you started programming?

That the status of being a programmer would drop to subzero levels in the next two decades :S

<comment><USER38> Care to elaborate and/or provide supporting evidence?

</comment></comment><comment><USER56> How to write good tests. I love writing tests now that I know how to do so. It's like flowcharting, but with code!

</comment><comment><USER57> The most important thing is not the code - it's the people that use the code. The more it helps people, the more valuable it is.

</comment><comment><USER58> I don't agree with 9.

I tend to want to know how _everything_ works; this let's me reason about anything and it helps a lot when debugging.

<comment> Bat-fink Personally, I've found that getting that just getting a book on the technology as a resource accomplishes two things --

1) Read the first chapter to get a fair understanding of how the technology works (recently getting them for both Spring security and Hibernate search helped emensely) and;

2) A way to sanity check your stackexchange solution you'll inevitably refer to.

</comment></comment><comment><USER59> It's not like being a plumber or electrician where you learn once and can make a living all your life

</comment><comment><USER60> When I was younger I used to not know the benefits of hash maps and used arrays for almost everything.

</comment><comment><USER61> That if I stopped, it would be 20 years before I'd be able to start again.

</comment><comment><USER62> the moment I discovered how to use for( $i = 0; $i < 100 ; $++) that was quite a moment, how to use loops properly was something I wished I knew earlier.

</comment><comment><USER63> Have anyone already said English?

</comment><comment><USER63> Anyone already said English?

</comment><comment><USER64> Read more code.

</comment><comment><USER65> Write codes more and more and try to be creative</comment>