atrk

Uhh how about a little more detail? I installed it, but I have no idea how to open it in a tab. Unlike my other extensions, I don't see any icon buttons next to my URL bar.

EDIT: If like me, you're using a Mac, you can use Alfred to open Postman. I still have no idea where to find the extension (I have both the extension and the "packaged app", whatever the difference is, installed on my machine)

I think LOC is actually a great proxy measurement of productivity. 3x the code is 3x the code that can break and 3x the code you have to wade through while debugging or adding features.

I see what you're getting at with "magic" abstractions, but it's like comparing Python and C. I don't know everything that happens under the hood in Python off the top of my head, but I also don't care. I could learn it if I needed to (e.g. needing to use the FFI, or if I find a framework bug). Not knowing is not the same as not being able to know.

I did a similar thing when I was seeking out a MVC framework for my company's JavaScript. I built a page using the same manual JQuery and JS I was using, then I built it with Backbone JS, and finally Angular JS (after learning each one in a tutorial and using TodoMVC as a guide).

Each step I reduced the code size by 50-75%, particularly the boilerplate of tying user interaction events to updating the logical model in JS. Angular's automatic 2-way data binding was definitely the selling point for me on the framework.

So your argument is that the primary difference between geniuses and the rest of schlubs is sheer volume of rote practice? I think you're confusing creativity with tool proficiency.

Personally, the two big draws to me of Angular were "free" (as in, I don't have to write much code) DOM<->data binding, and the explicit goal of testability.

As a learning exercise, I wrote a page using just jquery, rewrote it in backbone, and then rewrote it in angular. Backbone helped me separate concerns; Angular helped me do that while writing _way_ less code, since I didn't have to manage keeping the DOM and the JS model in sync.

Several of these are generally applicable to programming:

* Keep functions small and composable

* Keep functions at a consistent level of abstraction

* Use constructors to ensure objects always exist in a complete, usable state

* Use meaningful method names in place of comments

It is nice to see that other people struggle with functions with lots of parameters + lots of partial state variables. I don't suppose anyone here has a better solution?

That sounds fantastic. The few times I didn't get an offer from an interview (early in my career), the "we can't tell you more in case you sue us" answers to why I didn't get the job were as crushing as the actual rejection. I always felt terrible having to give that answer when I worked for a big company, particularly for the marginal candidates. The terrible candidates aren't going to be able to improve enough to game the system, so there's no real risk to giving them the information as well.

My experience is just the opposite - systems being hard to adapt to changing models of reality is usually a bigger function of "bad code." If I can understand the code, I can tell that it's "wrong" i.e. that it doesn't match my model of reality. If I can't understand the code, I can't tell whether it's right or wrong, which makes me afraid to change it in case I'm making it wrong-er.

I've had at least one coworker like this at previous jobs. They've tended to fool me repeatedly until I notice the pattern and revise my opinion of them. The confidence they display makes me think they're smarter / more informed / more thoughtful than I am, until enough evidence causes me to stop all positive weighting of their opinions. It's worse when you have imposter syndrome for the first several months of any new situation.