sethkojo

I've been in the same boat and I've discovered that the way to get better at programming is to get better at computer science. Most books on programming usually contain a lot of basic knowledge about language constructs. It's all variables, functions, classes, and then maybe some things about web programming. For the most part language constructs usually aren't enough to solve problems. It's very hard to take that knowledge and apply it to a fundamentally different problem than what was worked out in the book. And because the problems the book worked on were most likely trivial, you don't really gain much perspective on how you would build something more complex.

That's where computer science comes in. CS deals mostly with abstract concepts -- algorithms, data structures, parsing...that type of stuff. If you train your mind to think in these terms, then you start seeing programs as the sum of their parts (state machines, stacks, trees, grammars) and complex programs become less of a black-box. In effect you're transforming And because you can now picture how someone else has built their program, you just put those same pieces together and with a bit of thinking and googling, you can glue them up into something similar. Eventually you'll be able to picture your own solutions from scratch.

The thing, though, is that computer science is math. A different type of math, but math all the same. It's something you have to work at your own pace, patiently. Deliberate practice is not just a catchy phrasing. It's a very important concept. I stress this because I made the mistake of rushing through a lot of this stuff. I only half got it, but it's worth taking the time to fully understand even seemingly simple concepts because it opens up so many possibilities!

So in order to solve your tutorial problem ("what you need to learn, in what order, to get started"), I would suggest you pick a problem that's interesting to you, find out what sorts of concepts it depends on (what data structures are involved, what fundamental algorithms, ... that sort of thing) and work your way from those concepts to the solution (a working program). For example, if you were interested in building databases, you might want to learn more about b-trees, but in order to learn about b-trees you might need background in simpler data structures and work your way up. You might also want to learn about how to build a query engine, so you might want to learn more about lexing, parsing, and all that. From there you just learn how to implement those things (or find a decent library) in your language of choice and go from there.

Nope, I personally think it's bad design in that there is too much color in too many places. I don't know which stories are important and which aren't. Worse yet, I can't even read the headlines because the pictures are so distracting.

The linear model is much easier to parse since the stories are sorted. The grid model is not inherently worse, but they would need a better understanding of color to make it work. Maybe a bit less saturation to give prominence to the headlines?

It's not really about impact, but about context. If someone writes something that turns out to be obviously wrong, given the time-period, you could excuse them -- quite a few great physicists come to mind. Without that information, you might mistake them for an idiot. Or it can make a work even more impressive given the limited knowledge of that time-period.

Dates can also help when someone is talking about a technology which might have iterated past the point that their article is even relevant.

Language is very much context-dependent. Providing less context usually only helps misunderstandings.

Maybe you're over thinking it? It sounds like you're already doing the right things.

All the details might not be filled in, and there are surely things I overlook from the high-up view, but for the most part I already envision the solution.

The design part of TDD is just the expectations. So if you were to test an add function for example, you might write something like

  assertEqual(add(5,2), 7)
  assertEqual(add(-5,2), -3)
  assertEqual(add(5,-2), 3)

before actually implementing the function. So here the design is that the add function takes 2 arguments. That's it.

For other things like classes, your expectations will also drive the design of the class -- what fields and methods are exposed, what the fields might default to, what kinds of things the methods return, etc. Your expectations are the things you saw in your head before you start coding. So it's pretty much the same as what you do already. The benefit of TDD is in knowing that you have a correct implementation and you can move on once things are green.

One thing that's easy to misinterpret is that TDD doesn't mean writing a bunch of tests before writing any code...That's pretty much waterfall development. TDD tends to work best with a real tight test-code loop at the function level.

One problem is iOS devices won't play any videos with hidden controls.

Node's event loop is very easy to work with since all the standard tools are async from the start. It's not like eventmachine where standard Ruby calls are synchronous and they can throw a wrench in your logic.

There's no need for a mature standard library. Things move faster nowadays and you can't wait for things to get standardized. Node embraces the open-source spirit and trusts that the best libraries will rise to the top eventually.

And then you do all of it in JavaScript.

JavaScript is actually a top notch language. Cream of the crop. Lambdas, higher-order functions, apply/call, and OO. What more could you ask for from a dynamic language?

I recently got a bunch from sillysaurus2 (https://news.ycombinator.com/item?id=6345990). I personally feel like he has great taste, so he's a pretty good filter for interesting papers.

It can be the other way around too. What if you feel so strongly about your company's role in society that you rationalize socially destructive practices in pursuit of attaining/maintaining that role?

I doubt passion for business has much to do with morality. Simply being mature and having a bit of empathy is enough.

I use Sublime. I prefer an editor over dedicated software or a blog mainly because of the indenting; it's also the most powerful text-manipulation tool I know. I have a certain indented writing style that helps structure my thoughts -- I flesh out thoughts in indented paragraphs (the more detailed a thought, the more nested it is). This helps me read a bit faster as I can easily skim by reading the outer most paragraphs and only diving into the details when necessary.

I organize my journals by keeping each month in its own file <month yyyy> (e.g., "jan 2013", "aug 2011"). And in each file I write the date (mm/dd) as the outer most indentation, then write the entry (indented) underneath it. So a typical file might look like:

  09/27
    Some notes here.

    An idea here.

    A particularly good idea here.
      So I flesh it out here.
        And add more details as I go.

    Some things I learned..

  09/28
    Today's entry...
      

I use software over paper for two reasons -- it's much faster to get my thoughts down and I can easily search through my thoughts later (a simple matter of Ctrl+Shift+F). Getting your thoughts down quicker helps with brain dumps which tend to be more useful than refined sentences later on as they capture more of the state that you happened to be in.

I'll probably have some questions after looking over some more of the papers. We seem to have a healthy intersection of common interests. What's the best way to get in touch?

Thanks for this. I actually like that it's not curated, it's a good way to discover things I didn't know about. The fluid simulation stuff looks especially interesting.