294 karma · joined July 10, 2019
I was hesitant to take any medication. I was concerned it would make me anxious or similar.
Instead, my anxiety was greatly reduced. I had the thought, “is this what normal should feel like?” I don’t like the idea of being dependent on any one tool, but I’ll use a tool if it helps.
You can see the “violent few” drag and beat an officer to death. You can see and hear the surrounding mob cheer themselves on. So how many people need to witness a murder in progress before doing anything about it?
Yikes. This is painfully true. Maybe Apple knows they have a ton of breathing room here.
I’ll jump through a few more hoops to continue using the machines they make. Then again all I do is edit text.
A: “Passing control”
B: “Taking control”
A: “You have control”
B: “I have control”
This is how I remember it (6174, UH-1Y).
What does this mean? How does this relate to current logo? Is this a color blindness issue?
Don’t be afraid to “go deep,” learning begets learning.
Read more. This might sound obvious: the more you read, the more you _can_ read. You might find it helpful to stop memorizing info in order to just ceremonially regurgitate it (eg. onto some quiz/exam).
Read with a pencil/pen and take notes in the margins. The goal is to keep moving; you will eventually find something you think is really worth digging into.
You’ve highlighted your own points of failure, now you can get to work on correcting these perceived failures. A big part of solving complex problems is learning how to break them down into small chunks and then simplifying those chunks if need be.
There are plenty of books that try to teach problem solving skills (eg. how to solve it, George Polya). You can also find a clip of Feynman talking about how solving a lot of problems made him a great problem solver.
Forgetting about the whole “cult-of-interviewing flavor of loving to solve problems,” solving problems becomes more fun the better you get at it. It’s like anything else, you have to practice. Other students thought I was a “math genius,” but these same students rarely studied or completed their assignments. I did (and I don’t advocate this) every problem in the book, then got a second book and started working through it.
Consistency is key and its effects compound. You’re going to have a much longer career than you think. Now is the best time to exercise disciplined consistency. It seems like you’ve realized there’s no magical path—-that’s great. There isn’t any path except the one we carve out for ourselves, step by step, one foot in front of the other. So, keep going.
Confusion is the sweat of learning.
That said, I enjoyed reading through and finding “Edit: I was wrong about X.” Learning experiences all around!
Also, might have been mentioned but is this a typo?
> I’m guessing that FORTRAN is faster on small inputs due to the threading overheads, but faster on large inputs
Anyways, thanks! Enjoyed the article!
- Scheme: pure fun. Pairs well with, Structure and Interpretation of Computer Programs
- Elixir: also a lot of fun, I really enjoy the elixir help-docs/man-pages... Really ergonomic, almost no hassle.
- Haskell: endless fun; tbh, for me, setting up a Haskell environment wasn’t what I hoped it’d be. It’s getting there, but if you’ve used Cargo (rust) or Mix (elixir) and expect to have a similarly smooth experience in Haskell, you’re going to have to work for it.
- ReasonML: I’m pretty excited about this and interested to see how it goes. I’m a big fan of OCaml-flavored languages.
- Racket or Clojure: both are cool, docs/guides for both are great. The online Clojure docs/reference are fantastic. Same with racket.
If you’re leaning towards F#, try to lean Scala. Just my 2cents.
Now, I read differently, where I _read to finish_; I try to minimize the time-to-big-picture.
Ive found reading with a pen or pencil to be helpful. I also sometimes prematurely seek out an answer to some piece of text that’s expounded on a few lines later. So my recipe now is, open book (or whatever), write the date and time, read the table of contents, read through and annotate, write questions and answers in the margins, and get to the other cover quickly; each time I pick up the text I read over something I previously noted (in fifo order). These second passes are slow, the first pass continues at the same speed.
On the other hand, games are never just games there’s always a point.
I’m not sure if I’d tackle ML/DL unless you have the chops for it (I don’t mean to discourage you, just saying becoming a SWE might be easier/quicker). However, there’s more tools at your disposal than ever before to guide you towards your software engineering/ML goals.
One route would be to improve your engineering skills and land a job at a mature “startup.” Perhaps something boring, with good financials, and relatively few employees. Some might disagree with this next part: don’t aim for companies claiming to be doing ML/AI. You’re good with databases, so if your company lacks an ML engineer, get close to the data and try to add value—then continue this trend until you can do some meaningful ml tasks.
- grep (now using ripgrep)
- code navigation
- rust
- functional programming (scheme, Erlang, Haskell, Elixir, etc; structure and interpretation of computer programs).
Yep. I’m currently feeling this. I’m thankful I’m not a complete beginner and thankful for the Haskellers that blog their opinionated experiences. But this is such a roundabout way of learning.
It’s also almost unfair to compare things to Rust’s Cargo (and Elixir’s Mix). They set the bar pretty high IMO.
Haskell would be more widely used if the ecosystem was more cohesive (perhaps a bit more centralized).
I’ve been enjoying Haskell enough that I’d like to help improve things.
If the things you value are valuable in your new environment, you’ll find the tact, time, and patience to improve the codebase.
One thing that helped me was helping others. Writing documentation, documenting processes, playing dumb sometimes...
Your standards are _not_ unreasonable, but they are _your standards_. If you want others to adopt them, you must lower the cost for them to do so—and must do so in a genuine way.
Lately, I’ve found the quickest way to be “right” is to allow others to be “wrong.”
No ads. No pay wall. Damn I love man pages.
I “designed” the commands (the grammar, collected terms, syntax and semantics, etc.) before implementing them. The goal was to provide a “guessable” interface, eg. if you ‘load’ then it makes sense to ‘unload’.
Next time I do something graphical, I’d like to design a scriptable CLI interface first, then use end/entry-points to build the GUI.
Rust and Scheme have been gateway drugs ha. I found I really like OCaml-y languages.
Now, I’m very interested in Erlang (and to some degree elixir). I’m learning as much as I can about Erlang and the ecosystem; I’m trying to answer the question, “why isn’t Erlang more popular?”
Any guesses? Reasons? (syntax aside)
Very experienced pilots share similarities with very experienced engineers. Maybe the analogy I’m looking for is: an engineer might not know the capabilities and limitations of each peripheral device they use, but can still be experienced. Also bear in mind, that this type of piloting is a high-stakes job; extraterrestrial craft are arguably less common than those made on earth and the pilots probably take this into consideration.
That said, I think this this whole ordeal is really interesting. Reading the comments, I think the “lasers” and “plasma” stuff + dropping “vehicle” from the nomenclature (i.e. “unidentifiable aerial phenomenon”) is rather interesting.
Humility is something many never get an opportunity to learn. But at the end of the day humility does not pay the bills.
Read or listen to Enders Game, by Orson Card.