261–270 of 303 posts
Earlier quoted context omitted.
It's about the ratio. Employees to users. And the profit per employee is quite high.
That's great and all, I like them fine, but they're not a one-person-band.
> Pretty nice, 1 dev 3 team members in total and 1 million users?
So probably pretty close when they originally started their venture.
Earlier quoted context omitted.
Once you're #1 on Google searches for half of the published corpus of humanity you stop caring about little things like that... Surprised storygraph even has that many users when they're nowhere on Google when I search books.
well, books and book related stuff tend to propagate more through word of mouth than direct search or advertisement.
This is a crazy question, but what song is used in the intro of that video?
StoryGraph isn’t necessarily better than Goodreads but it’s definitely just as good and it’s great to support software not owned by Amazon. They may own e-books but they don’t have to own reading.
Earlier quoted context omitted.
Good code and bad code are not objective values. I have worked with many people that spend days replacing good code with bad code because they are ”paying down technical debt”.
This is a good point, but I think it's mostly a precondition to having the luxury of the problems I was describing. If you can't even broadly agree on what is good vs bad code, your engineering org has deeper problems. You don't even need substantial agreement, just enough to identify what the genuine problem areas are, vs what's just not how someone would've written it themselves.
Then someone proposes a solution for the problem, and you review the code to see that it solves the problem. If the solution is not bad and the problem is big, you can let them merge it.
StoryGraph is an excellent tool and I continue to use it daily. I’ve also found Hardcover.app, which I quite like. It has an API and a slightly more refined UI, but it’s clearly more than one person working on it. Of course, if your focus is book clubs, Fable is likely the app for you
Solidifying my dislike of Goodreads, I got my “year in books” email from them today and the first thing that loaded, at the top of the email, is an ad. For pillow cases. Folks, don’t do that
Earlier quoted context omitted.
Building an engine from scratch cannot be the hard part. It’s not complicated. Iterating on all the things that make the game fun is hard, and making all the ”content” in a game like Stardew Valley is very time consuming.
Building an engine is a famously huge time sink, to the point where the standard advice is to make a game or an engine, but not both if you want to ship.
It’s not if you just write the code you need for your game.
99% of people getting stuck on it have no real desire to make an actual game.
Earlier quoted context omitted.
it's always fear for me. I'd rather leave it commented out for a decade or so to be safe.
I never understood commenting out code when you have version control. I get why people do it, I’ve done it myself and then two days later been confused which of the 3 commented out function was actually the most recent. It’s infinitely more clear from the version control since the history is there for you to zoom through.
I'm not suggesting that one should comment out code but I never understood why if they have version control and there is a new bug a significant amount of devs do not actually go through the history to find the working version.
Now - after writing the above and thinking while writing, I am going to suggest scenarios when you want to comment out code.
You write a great bit of code that does not work, you find out it is because API X is not correctly implemented, therefore you have to do a workaround kludge until API X is correctly implemented.
What do you do? I think the optimal solution there would be to comment out the great bit of code above the workaround kludge with a comment - API X has a bug, I have made a bug report out on the API X working group. I suggest checking periodically and then getting rid of the kludge and moving this code in. Dated, so that people can see when they should check.
It's true I have seldom had the pleasure of working with people where this optimal way of doing it would have been at all useful, but it has happened maybe twice over many years. Probably it will only help you out when you see the comment over the coming months, or when you get an email that your bug has been fixed.
I'm sure you can imagine other similar scenarios in which commenting out the code makes more sense than using version control.
[flagged]