People understand that the compiler/executable doesn't run any faster the less newlines there are, right?
This is cute, but as others have pointed out it, it isn't really a correct implementation of a hash table. Also, it wouldn't pass a code review anywhere I've ever worked.
Well that's the whole point, right? This is clearly written for fun, it's not production code, it's not supposed to pass a code review. It's just supposed to be cool and interesting, and a challenge for the author.
Exactly! Building cute but ultimately useless[0] programs is a lot of fun and makes for great brainteasers. It's also a great way to interact in a friendly but still technical way with your programmer peers. I recommend it to everyone!
The only aspect that seems like it might fall under the category of anything except for age discrimination is the photo requirement.
Summarizing the highlighted passages:
- they want a go-getter
- they want someone who enjoys working long hours
- they don't want people who do things only for the perceived social benefit
- they don't want people who have no social skills
a.k.a. a culture fit.
Granted, the job requirements are a bit hefty for the salary (US $3.2-4k/mo), and the 1+/2+ ratio of years managing vs. years developing seems a bit... naive, but maybe that's market in Singapore (which IIUC has a flat, low income tax), or maybe perhaps they are just trying to underpay - like most un-/under-funded startups everywhere.
If you have a pilot license, and call into the ATC to get clearance, can you operate a drone for commercial purposes (e.g. taking photos for real estate listings)?
No, under present rules, drones are regulated without consideration of the operator's qualifications in other aircraft types. And for the moment, no commercial use of drones is being permitted, which means the use to which the drone is put is the issue, not who is operating it.
But this is going to change relatively soon -- there's too much public pressure to allow drones wider operational latitude.
Excellent write-up, but having taken Corporate Accounting courses the "triple-entry bookkeeping" moniker tripped me up a bit - it's an inaccurate metaphor (see http://en.wikipedia.org/wiki/Double-entry_bookkeeping_system to understand why).
Curious, could you elaborate? The wiki page is long, not sure what I'm looking for... It seems like "triple-entry" is often used alongside "momentum accounting", but its not clear to me why they are conflated. Disclaimer: I'm no accountant, so the simple terms are good. :)
In the OP, double-entry accounting is taken to mean that the two parties to a transaction each keep a record of it (and by extension triple-entry accounting is if three parties keep a record of it). This is a mis-use of the term "double-entry accounting" to mean "two-party recordkeeping".
Double-entry accounting means that for each transaction, there will be two (sometimes more) entries in the ledger (set of accounts) - one on the "credit" side, and one on the "debit" side. For example, when you withdraw $100 from your bank account, from the bank's perspective it is crediting an Asset (Cash) and debiting a Liability (Customer Accounts), so a credit entry of $100 would go into the Cash "account" and a debit entry of $100 would go into the Customer Accounts "account".
Triple-entry accounting implies that a third entry would go... somewhere else in the ledger; but OP isn't describing a classic set-of-accounts ledger.
> We eventually gained each others trust, and our visions started to coalesce, but only after spinning our wheels for 6 months.
> Everyone on the team suffered from burnout.
> 11 months later, our team decided to cancel the project.
My guess is that the lack of a singular clear vision caused everyone to become disenfranchised / burnt-out in the first six months, and it took another 5 months for people to realize the project wasn't going anywhere.
I think the story underlines the importance of having product leadership - it's all well and good to have a flat organization when the product is already defined and the only thing left is adding features / fixing bugs (as is the case with the github platform), but if you are starting from scratch you can't expect a product grow to grow organically from the combined whims of individual contributors.
> The best software comes from a team where everyone shares a vision, cares deeply about the result, and are motivated to make it happen.
Definitely!
> That level of caring and motivation can only come from people that had a role in crafting the vision and own a piece of it.
Yes, but Design by Committee is a cliché for a reason.
Yay, the electronics are 100% compatible and we might just need to work out our CAD to attach it to your carriage. That would be a good way to structure out our GitHub.
Isn't that an example of a "diversification" strategy, similar to the "join many clubs/activities in high school" approach? The fact that it's a strategy (and therefore involves prior decision making - specifically the decision to follow the strategy) doesn't make it a "determinate" strategy.
I believe the lecturer (Thiel) is advocating for determinate strategies - which, practically speaking, reduce the surface area for luck since time is a finite resource. My interpretation is that he is advocating for "moon shot" approaches (examples given: Tesla, Space-X, AirBNB) where the plan/vision is laid out from the beginning.
This contrasts with the iterative "lean startup" approach whereby an initial product is launched followed by an iterative customer feedback loop. The evokes raises an interesting question: is the "lean startup" methodology an artifact of "Indeterminate Optimism"?
