When you have 20K (like Hardcover), it is much easier to be focused on each of them (or at least small groups of them) than when you have 20 million - much less a few multiples of that number.

As we grow, even Hardcover will have to evolve. This noted, I know this team (including myself, to be clear). Adam is truly focused on innovation and dev excellence. Ste, our lead designer, always has his eye on UI/ UX improvements and listening to what our users want/ how our users are using the site. As for myself, I'm the data/ social media guy - always looking to make our data as solid as possible and looking to use social media as effectively as possible. :)

Reviews are a by product IMO. I mean Goodreads reviews setup is horrible, no screening, nothing helpful in the implementation, etc

National databases like the Library of Congress are significantly better - WorldCat is best used as a fallback for books that aren't included in the high-quality databases.

Nobody sees the extensive graveyard of massive time sink projects that got no traction and went nowhere. Even if they would have been big had they caught on.

There wasn't a "minimum viable product" launched in year 1 followed by finishing the product in year 4.

I've literally seen a post here where someone scolded a failed game developer for finishing their financial failure of a game before launch. The comment was something along the lines of:

"Read a business book. You shouldn't have spent a lot of time making your game. Instead you should have released a minimum viable product after doing market research."

Otherwise it's a hobby, and enjoying your hobby 10 hours a day, 7 days a week is an envious life, if you can afford it. (Barone specifically could not; he had to have a part-time job as an usher in a theater; that was work.)

Some would say it’s the other teams fault for not adding a cross-test against my teams code. And while that would have solved it, some things are hard to test. Even in companies who have good testing standards some things are still hard-to-impossible to test. In my humble opinion tests are great if and only if they are hermetic and fast. Unfortunately, the important things that can go wrong are usually the least testable.

In either case, in a non-perfect world (ie ~all large companies and most small ones) people optimize for not breaking things, and there’s a solid argument for that being a local optima, both for short term stability and career wise.

Generally this is not tractable because it cannot scale. But there are certain applications where it scales fine.

Nothing. Except that in 3 years the junior dev that gets a ticket about doing something in this area will come in and not notice the code isn't a dumpster fire. Or, in 3 years, you won't notice that you didn't have to optimize this code a year ago.

What they do notice is that you were insisting on working on some mumbo jumbo and ok good they're done now they can actually work on something useful. Haha aren't these devs quirky? Sometimes they take a few days and work on something weird, and all the other senior devs nod and salute solemnly and I'm too scared to ask for more details, but they don't usually take too long so let's just indulge them for a few days to keep them happy so they don't leave too.

It takes a very, very deeply engineering-first org to really cultivate this intentionally. And similarly it seems like succeeding as a startup requires at least a decent amount of shipping some shit code fast so you get a series B, so usually you don't start in this posture and never shift into it before it's far too late.

And also unfortunately, devs often _do_ spend time optimizing/refactoring personal pet peeves as opposed to things that might have a good chance of mattering. I once saw another senior dev spend a week optimizing string allocations on our hot path. Our owner loves people who can do this kind of stuff, so it got a lot of praise. The microbenchmarks looked great, pretty graphs. Users noticed nothing, the actual metrics we track literally did not change, and now the already-complicated hot path is decorated with some contorted string-allocation-avoiding warts here and there and the next person to go in and change the code is _definitely_ going to keep doing that pattern, for sure. Meanwhile our oauth flow is still a tortured, unloved, twisted writhing mass of pain and suffering that prints bug reports like CVS receipts.

So... extraordinarily difficult to intentionally cultivate a culture that does this judiciously.

And that's the real reason service architecture took off

You have to be good at your job, good at the specialty, and more interested in doing the right thing for the company (and more irritated at the stupidity of the files being there 10 years after they were needed) than you are at looking productive to management. Management does not want to hear “well there was a directory structure of two million files that was a backup of a Linux machine from 8 years ago, I spent two days extracting the dozen files that we might need some day, getting the okay to proceed, and deleting the files.”

Notice (Dec 13): code cleanup continues; please keep reporting bugs to support@pinboard.in

The fact that gender is mentioned at all, when it's never mentioned in posts that have "one man dev team" in the title, doesn't imply anything to you?

I think everyone making it out to be some big thing (which, the [dead] comments are bringing it up in a negative light for one reason or another) is the 'remarkable' thing.

I voted up. Words and behavior matter.

If your identity is so hung up on being a man and believing that men are “better” than women, your identity is a frail illusion.

Try to imagine being so “weak” that you can’t accept that there are women who are successful and some do better than you.

People seem to be reacting to it like it's poison.

Can you not do this here?