Not proving solutions to textbooks seems to be a common theme in mathematics and theoretical computer science. It makes it difficult for those outside of the traditional classroom to learn the material. Instead textbook writers seem to have this adversarial approach against readers, thinking they’ll “cheat themselves” if they look up solutions or attempt to verify their work. Experts make mistakes, beginners would presumably make even more mistakes. Without a feedback mechanism beginners can’t truly know whether their logic is impeccable or if they have a subtle error that they themselves cannot detect. They could easily fool themselves that they have correct understanding.
Due to that I will not recommend this current book to any colleagues.
Hi, here are a few things I wrote in here that could be useful. They are designed to improve remembering to do things, doing things, learn from doing things, make sure everyone knows what they should be doing, remember why we're/if we ought to be doing things in the first place, and doing the right things:
- https://news.ycombinator.com/item?id=24972611 (about consulting and clients, but you can abstract that as "stakeholders", and understanding the problem your "client", who can be your manager, has.)
- https://news.ycombinator.com/item?id=24209518 (on taking notes. When you're told something, or receive a remark, make sure to make a note and learn from it whether it's a mistake, or a colleague showing you something useful, or a task you must accomplish.. don't be told things twice or worse. Be on the ball and reliable).
- https://news.ycombinator.com/item?id=21427886 (template for taking minutes of meetings to dispatch to the team. Notes are in GitHub/GitLab so the team can access them, especially if they haven't attended).
0.0. It pays to provide services through a company. Companies write large checks to companies without blinking; not so large for individuals.
1. Contracts:
1.0. Get a lawyer to prepare contracts for collaborations. Someone at some point might disagree or have trouble remembering what they have agreed to pay you, make sure to have a mnemonic device in the form of a clear contract.
1.1. Companies have typical contracts for collaboration: don't sign anything without legal counsel.
1.2. Retain intellectual property to amortize engineering and sell what you make to others.
1.3. Companies might ask that you do not sell to competitors: define them and contain geographic zone and duration. Get paid for the opportunity cost.
1.4. Split project into tranches for which you get paid. This can help cash-flow and reduce risk, especially in the beginning.
2. Presentation:
2.0. Your company solves problems and being open minded about these problems is useful; so it's not much about finding problems for your solutions, but more like finding solutions to clients' problems.
2.0.0 After enough problems you built solutions for, patterns emerge and you can abstract a solution that serves several use cases. See "Abstraction" section.
2.1. General presentation with broad strokes of your capabilities, including previous work with other clients
2.2. Conversation with the prospect on their worries in a given space
2.3. Conversation with the prospect on their worries in a given space
2.4. Extract problems from that conversation and send a list of N problems to solve/ideas to explore.
2.5. The client finds one problem urgent/highest priority/highest value
2.6. You get together and talk about "desirability, fasiblity, viability".
2.7. Once you agree on what to do, prove the concept.
2.7.0. e.g: organizations give us data and ask us to predict something, say customer churn or subway car malfunction. We return predictions, they validate the predictions, and we can then start the project because they have proof we actually can predict what they want us to.
3. Execution:
3.0. Your opinion on what is valuable for the client does not matter. It doesn't have to be valuable to you, only to the client. A client who gets excited by a functionality that took one hour to implement because it solves a real problem is a learning experience.
3.1. Go above and beyond. Some sectors/clients are hard to get in, but once you're in, you're in.
3.2. Listening and assuming the client is smart goes a long, long, long way.
3.3. Send meeting notes to the client. It clears ambiguities during/after the project.
3.4. Press to get the client's domain experts' collaboration. They will actually use what you're building. Get them at the table.
3.5. Some of the most valuable insights are gleaned after a meeting and not necessarily with your "counterpart".
Don't build the wrong thing.
4. Abstract:
4.0. When you solve many problems, some patterns emerge. You built custom products for your clients, but you can abstract functionality and build tooling to scale your services, and enable others to do the same.
4.0.0. e.g: we we built machine learning products for enterprise clients. After many projects, we built iko.ai, our own machine learning platform to "Get Data Products Released".
4.1. One advantage of this approach is to explore the space while being profitable. Some problems exist not for lack of a nice front-end or lack of knowledge of the target audience. Coming at them from a purely "webdev"/"devops" mindset can bring bad surprises.
This reminds me of “The Bell Jar” by Sylvia Plath, which has a quote Aziz Ansari used in his series “Master of None”:
> "I saw my life branching out before me like the green fig tree in the story. From the tip of every branch, like a fat purple fig, a wonderful future beckoned and winked. One fig was a husband and a happy home and children, and another fig was a famous poet and another fig was a brilliant professor, and another fig was Ee Gee, the amazing editor, and another fig was Europe and Africa and South America, and another fig was Constantin and Socrates and Attila and a pack of other lovers with queer names and offbeat professions, and another fig was an Olympic lady crew champion, and beyond and above these figs were many more figs I couldn't quite make out. I saw myself sitting in the crotch of this fig tree, starving to death, just because I couldn't make up my mind which of the figs I would choose. I wanted each and every one of them, but choosing one meant losing all the rest, and, as I sat there, unable to decide, the figs began to wrinkle and go black, and, one by one, they plopped to the ground at my feet."
If you're interested in helping New York City, you can volunteer your technical skills to solve meaningful problems there! It won't be the latest whiz-bang 5G Blockchain AI tech stack, but you'll have a shot at making a real difference. As cities further adopt open source approaches to technology infrastructure, these improvements will also benefit other cities.
If you want to actually dive into source code - SQLite is amazing. It has very clean and readable code, so I'd suggest using it as a reference as well: https://github.com/mackyle/sqlite
I'm nowhere near as smart as Colin but I'll also share here a little personal story which relates to the topic.
I was also a very high achieving student in high school and university and was similarly all set for a career in academia (also studying mathematics). In my final year however, I had a full-time position doing research with CSIRO, which is a leading research organisation in Australia. I did some interesting work there - applying neural nets for classifying micro-seismic events around mine sites, and won some awards for my research. If I had wanted to, I could have stayed on and continued down that path. But I didn't.
What ultimately pushed me away was everyone I bumped in to in academia was so unhappy. There was constant bickering and frustration around getting funding (a common sentiment in the division I worked in was that you had pander to big mining/oil companies and propose research topics with clear financial gain for them). It was not a happy place to be, and at the end of my time there I jumped head first in to a software job instead.
Tangentially, this I think is also why I'm more open to hearing ideas from organisations like Numenta, and seeing research done outside of academia by folks like Stephen Wolfram. I think increasingly much of the most novel interesting research will be done outside of traditional academia.
A bunch of people I've worked with have done this - my old boss's boss made it to SVP of Search at Google, another boss's boss (inserted into the management chain below the former, actually) is now CPO of Slack, one of the other manager's I worked with is now CTO at DropBox, former coworkers are heads of product at Asana and IPFS, my current manager is up for director, and a college classmate has been a highly successful C-level exec that took a company from series-B to IPO.
Some common threads I've noticed:
1. Don't piss people off. Figure out what people's hot buttons are and avoid them. The exec team at Google circa 2007-2013 was notoriously combative. Who got the CEO job? Sundar, who was a very quiet, unassuming executive who presided over a string of low-profile successes and had a knack for translating Larry's visions into terms that the rest of the exec team could agree with.
2. Be consistent. Successfully delivering base hits, one after another, is often better than striking a home run and flubbing your next project.
3. ...but go after the high priority projects, and realize that priorities change. People who stick to their areas of expertise usually end up getting pigeonholed as ICs or first-level managers. People who rise through the hierarchy usually need to reinvent themselves every 1-2 years.
4. Take people with you. Folks that rise through the hierarchy usually have a core group of high performers around them that they're loyal to and who are loyal to them. Oftentimes these people are folks who don't want to bother with #3 but are very good at what they do, and then their manager provides them cover from the rest of the org so they can keep doing that.
5. Be open to opportunities outside your current employer. Of the folks I listed before, only 2 of them have risen exclusively within Google (and one of those was a high-performer at Sun before then). Everybody else needed to switch jobs. I was talking to the CTO of one of the companies I was applying to recently, and he said that he interviewed at 20 companies and this was the only one that wanted him. Your job search gets a lot less liquid the higher you get - if you're looking for a CxO job, you need to go to the company that is looking for a CxO with your particular skillset, and that may require moving to a different geographic area or considering companies that you wouldn't otherwise want to work for.
Also make sure you really want to do this. All the people I know that have rocketed up to executive levels basically live for their work. A lot of them never bothered to have a family, or if they did have a family, they downshifted their career for a while and only started accelerating again once their kids were in school. Several founder/CEOs I know have broken families - either they're divorced, or they hate their spouse and are just roommates who stay together for the kids. Most of them have friends, but they don't have the type of tight, regular dependable friendships that my friends who are in dead-end jobs have. It's probably that reason why this isn't really a path I'm going for - I had a choice between being a decent father or a decent founder, and chose the former.
The whole app lives in Firebase. Once a user hits a profile page, a cloud function runs, get the data from the DB, constructs the page, and caches it at the CDN for 24h.
If a user add/delete something on their profile, the cache is removed. Otherwise, the content is served from cache only with no need for a lot of computation.
For analysis of new AR/VR technology I highly recommend Karl Guttag's blog: https://www.kguttag.com/
He's an engineer that understands the limitations of physics, especially when it comes to optics and light. He is very good a parsing marketing hype vs reality. (He called BS on Magic Leap years before it launched.)
His posts are exceptionally well researched and explained, even if you don't have a background in physics or optics.
He recently did an analysis of the Apple Glass leaks. I expect he'll post his thoughts on this new technology from FB soon.
Humans observe an object once, such as a cup for drinking water, and we immediately grasp its "cupness". We can identify infinite varieties of cups despite variations in morphology, design, utility and context. Simply based on a single learning instance. This absence of any neural theory of inference is at the crux of the problem ;)
I have immense respect for researchers who venture in these type of disciplines. I don't think I would be able to do it. I do have a bit of a daring question: isn't there a slightly more fine-grained way to quantify that every nook and cranny of such a problem has indeed be researched by researchers? I simply assume that a rigorous research by the best minds of the world has happened, but I never see any data on it, not even anecdata.
I mean, I remember a post from Julia Evans, making a Ruby profiler, where she was astonished on how few people were actually working on it [1].
I suspect that in some cases, probably not this one, but in similar theoretical fields, a similar thing might be occuring. And if not, how do we test that? I'm probably not the only one who's curious.
[1] I found a talk of her in which she emphasizes on it:
> So the three myths that I want to start out by talking about are myth one-- to do something new and innovative you need to be an expert-- myth two-- if it were possible and worthwhile, someone would have done it already so you probably shouldn't try-- and three-- if you want to do a new open source project, you need to code a lot on the weekend and your evenings.
I love podcasts, but I find annotation and pinning very difficult. So many gems are lost once I hear them. I do absorb it, but I cannot reference where I heard it. How do you save the snippets, how do you tag them? Same problem with Audible/audiobooks -- I write notes on the app's note-taking feature but those are mostly lost w/r/t context.
This is not a replacement for someone else conveniently creating an API for you but if you're interested in running your own version of this you can probably recreate this with a combination of youtube-dl[1] (Python) and ffmpeg[2] and build an API around that. Youtube-dl handles A LOT more sites than just Youtube[3]
Not persuaded that the author's advice to rationalize the faults of your ex is sufficient or necessary for "recovery."
I would propose generally that the suffering of any breakup (or loss) is proportional to how much you depended on the other persons reflected view of you for your own idea of self. Getting past it is more of an exercise in self-acceptance, self-forgiveness, and self-improvement than simply knocking down the other to boost yourself up.
If you identified as a partner, husband, father, boyfriend, etc. then the loss of that feels like a loss of self. But if the person in your life was just that: another person, in your life, then you can still miss them, but nothing intrinsic to who you are was lost. You are not broken, shattered, or harmed. In this context, suffering is the effect of a residual belief about the completeness of yourself, and has diminishingly little to do with the other person at all.
Recovery is not "healing," from a "wound," rather, it is resetting your perspective and accepting who you are as self-originating - and not as reflected by another.
Too often, Pascal's maxim "to understand all is to forgive all," is advice given without the necessary condition that you must apply it to yourself first - otherwise it's just a recipe for obsessive thoughts. I would say to someone suffering from a broken heart, whatever it might entail, start with the desire to forgive yourself and whatever happens next, the journey alone is probably going to be worth it.
Check out Sweetwater next time. They are significantly better. Their site actually shows you each guitar/bass they have in stock and they have an entire gallery Of photos for each. If you order one they’ll send a zip or the whole collection of photos.
If you call and talk to the sales rep for you (you’re assigned one) they can usually knock 5-15% off.
They also make sure each guitar/bass is setup to factory spec before sending it out.
Conference Youtube videos. They are a goldmine of useful tips and tricks. Go look for videos from the Node [1] and MongoDB
[2] conferences and you will find tons of war stories and what is actually working for people. Using this option arguably connects you directly with some of the best people in the world who are actually using this stuff.
ps. using the youtube 2x playback speed option can really help digest lots of video content quickly [3]. I use this almost exclusively on youtube now.
Depending on how involved the language you are interpreting is, you might get by having only read chapter 6 of The AWK Programming Language[0] (linked in the article), which covers "Little Languages", including what it terms an assembler and interpreter.
If you are interested in more depth, either Crafting Interpreters[1] (mentioned in the article) or Writing an Interpreter in Go[2] looks promising. I've read more of Crafting Interpreters and really enjoy it, though it isn't yet finished. One of the aspects I really enjoy is that the language is implemented and re-implemented in different languages to gradually introduce lower level concepts.
Finally, this one may be a little more "out there" than what you are looking for, but if you are interested in designing a language more than the plumbing of an interpreter Beautiful Racket[3] is really good.
Due to that I will not recommend this current book to any colleagues.
If you want an example of a fellow hacker news member that did things right, check out http://joshua.smcvt.edu/linearalgebra/
He provides solutions and lecture videos... this is truly a democratization approach to learning and a model that other academics should follow.