Why not share the seed of the map? This in combination with the coordinates visible on screen would make it possible to check if there is cheating involved. It would be even better if the seed was generated and handed out by a trusted party. Do all the speed runs live and it would be quite hard to cheat.
The Go network stack already makes use of epoll and kqueue: https://golang.org/src/runtime/netpoll_epoll.go
So I'm not quiet sure why this would be faster since almost all I/O in Go is event driven, including the networking stack.
I think a new Half Life game would be the perfect opportunity for Valve to showcase their virtual reality kit. So far there are no blockbuster VR games and the Half Life franchise (Portal included) has a history of being very innovative (e.g. HL2 using a physics engine for the narrative, HL1&2: story told through level design). There is a lot of potential to use immersive virtual reality to enhance the story telling.
Efficiency: I do my thinking/coding/building/writing (not writing emails) in the morning before anyone comes in and can interrupt me. I plan all meetings (which I don't consider proper work) in the afternoons. In short: work first, chatting and socialising afterwards. Some people do like to do it the other way around, which I totally understand and respect. I'm more of a morning person. TDLR; My first 8 hours I start with creating value and at the end of the day I a put in a few extra hours (not always) to socialise ;-)
Totally true, I sit at my desk at 7am work till 6pm. The kids come in at 11am and do oh so much over time when working till 7pm. And don't get me started about their relationship problems. And this happy hour is the worst social thing ever. I work in London and there are a lot of people here who don't drink alcohol because of religious reasons or it's not a big part of their culture. Happy hour is only social for people who like to get drunk. No problem with that but a company with a drinking culture will never be diverse and will therefor suffer creatively. I once managed a super multi cultural team (9 nationalities and 5 different religions). We socialised by going to a museum or a historical walk through London. That said, I see a lot of young people who can only can do small talk after a couple of drinks. Which is a shame because it shows when new people join the team.
Knowing when to stop is one of the most important things about delivering a project. After trying this method a couple of times I think many will have learned when to draw the line.
I do like it when people set themselves challenges like this. Clear beginning and end, finishing something in combination with iterative learning is very satisfying. A bit like a hackaton or a game jam. But this made me think, because in a way it limits yourself in what you can do with what you previously learned. The more you learn the more complex projects you can create and halfway through you can create something which doesn't fit in a day anymore; complexity pushes build time up exponentially. E.g. it needs some extra tooling for generating procedural content. So what I propose is instead of 'over the course of 30 days I will every single day finish a project', why not follow the Fibonacci sequence: I start with nothing (procrastinating), next a one day project, followed by another single day effort. Stepping up with a 2 day project -> a big 3 day project -> 5 day full blown project -> 8 day epic. And finally: a full 13 days working on a single masterpiece! (33 days in total).
I couldn't agree more. I just got hired to 'productionize' some proof of concept developed by data scientists in jupyter notebooks. The first thing I did was hiring a Python developer (no data science experience) to start cleaning up the code and a devops to put the infrastructure in place. Second step: I went to the data science department and sat down with them and I taught them how to program properly: test driven development, version control, code reviews (git pull requests) and continuous integration. They all have PhD's so it's not that they would have any trouble learning anything new. They thought it was great. Result: all their new code now directly goes (via code review and CI unit/end2end testing) into pre-production and after sign off from the product owners into production (quite often the same day). I just do not understand why instead of trying to find the perfect person for the job people don't just hire someone to teach them how to do the programming part of their job properly. Good teams are cross functional, diverse and have a strong focus on transferring knowledge.
Slightly off topic: They still can't build proper software. Academics (including mathematicians) are notoriously bad at writhing production grade software. This leads to handovers of 'proof of concepts' to seasoned software developer team who than struggle with the (often complex) mathematics/science behind it. Imho universities should give a bit more attention on how to write quality software; a bit of test driven development and continuous integration is not that hard and would massively improve the quality of the software written by scientists.