I had time to spare so I toyed with the example exercise.
Now I am not sure if I misunderstood something because solution is fairly simple using only channels: https://go.dev/play/p/tD8cWdKfkKW
I replied to your comment on my website, but for posterity here, yes, I do think you did a good job for the part about exiting when bestScore > 100. There's nitpicks, but this is fine! It makes sense, and nice use of a select over a send.
I did expect that this exercise would come after the first one though, and doing this on top of a solution to the first exercise is a bit harder. That said, I also don't mean to claim either are impossible. It's just tough to reason about.
I don't think you examined the code in full. main spawns 10 go routines that are constantly sending player scores to the game. That means 10 different players are sending their scores concurrently until someone reaches score of 100.
Pretty much this. Get hold of your ego and be humble enough to take lessons from experienced people who have track record of delivering successful projects. It is imperative to get the basics right before being able to take on more responsibility later.
"We don't rise to the level of our expectations, we fall to the level of our training."
Make sure you get as much training as possible before raising your expectations. It will be easier for you later when business expects senior output from you but you are under constant pressure on both personal and professional fields.
Can anyone recommend a book that you would use as the guide for building a new software project from scratch? Like something that would provide good overall structural approach and best practices. The goal would be to end with as least amount of tech debt and codebase flexible enough to stand the test of time?
After probably more than 10 years postponing to find what HTDP (how to design programs) is all about I'm now convinced that everyone should go through that book (or an online course) and apply the newly found knowledge in real life.
See the edx links in one of the threads above. Take the course; Actually DO what Gregor repeatedly says in videos and you'll find what you missed.
I do like: Clean Architecture[0], its pretty much language agnostic and has some nice examples on overall structural decision making -- from small to large projects.
>> The goal would be to end with as least amount of tech debt and codebase flexible enough to stand the test of time?
I am not sure if it is possible, to have a comprehensive book with this goal in mind. It very much depends on the project size, the dependencies and your language / framework -- and even if you have that in order, there are your teammates, the process, continuous integration, milestones/deadlines and the general workflow you have to take into consideration.
Depends, what kind of application are you trying to build? What programming language?
I wrote my book Professional PHP [0] as a guide like that, but of course it's heavily skewed towards building a PHP webapp (even though most of it is also applicable to other OOP languages).
But to be honest, I wouldn't try to narrow it down to a single book. Start with the classics like clean code, code complete 2, pragmatic programmer and then work yourself towards effective java, implementing domain driven design etc. I have a list of my recommendations published here [1].
In my opinion no book will really teach you this, only experience. It requires going through cycles of design, implementation and subsequent evaluation of how well those fared and how to improve upon them. After repeatedly going through this experience in a mindful manner you will develop a gut feel for what's good and what's suspect.
An interesting read but this kind of predictions don't work "in advance". Usually it's needed for some market player that is still unknown to show up first. That player will then serve as an example and solidify the argument. To know/feel what SaaS 2.0 is, in advance, would mean that you are the one driving it. SaaS 2.0 is not here yet.
I kept going hitting the recruit option and looking for someone with a law background, but that was likely too specific a skill for the game to acknowledge.
In the good old days you just wouldn't make the joke. Or you'd get downvoted into oblivion even if you apologised. It was a much better site back then.
I sometimes wonder if we've already become Reddit, or at least are moving to that direction. The remarks and comments sometimes just aren't appreciated; if only there were more strict moderation.
We have. We became reddit about two years ago, just after dang took over. I blame the rule against complaining that HN is turning into reddit, but also dang's niceness initiatives, the interventionist moderation (particularly "detaching" negative posts from threads) and the way your own posts don't grey out any more when downvoted.
