mattbriggs

My mother has a doctorate in social work, they have an idea in her field of "Critical Reflexivity". The idea being that theory and frameworks are vitally important to learn, but at the end of the day every case and every practitioner is different. To be a great social worker, it is not enough to learn theory and apply it, that is just the starting point. What you need to do is apply theory, but reflect at every step of the way on how it is working. This lets you build your own theory of practice, tailored to the way you work with people, and to the sort of people you work with day to day.

That resonated with me quite a bit, I feel like what she described to me is something all great developers I know do instinctually. I think at the end of the day, that constant honest reflection is the single most important thing to do for us. Our profession loves to pull ideas from math and other hard sciences, but at least from my part of it (product/business development), I think we can learn just as much from social sciences, if not more.

So what does that mean to a developer? When you see a problem somewhere, don't just stop at identifying it, try to classify it. What other problems are like it? Why did it happen in the first place? Read a lot of books about how to build software, but when you implement things from those books, try to reflect on the idea behind the solution, not just the solution. When it is done, reflect on how it worked out, and how the code looks at the end, what you like and what you don't like. If you go back to it, try to remember your initial feelings, and see how it panned out.

One of my weaknesses is being terrible at writing :-) I am trying to get passed it. Thanks for the feedback, I think I fixed them all.

For me personally (working at a ruby startup in Toronto), this is the breakdown of people currently working in dev

1 white female 3 chinese canadian males 1 japanese canadian male 1 korean male 1 russian male (guess he counts as white) 3 white males 1 cuban male

We have 5 founders, only one is white, all are male. 2 are on the dev team, one is chinese (CTO), the other white

We have interviewed many, many people in the time I have been at the company, to my knowledge only two have been female, one of whom we hired.

This is normal in my experience with good shops. If I walk in the door, and it is wall to wall white guys, you are going to have a much harder time selling me on your company. This is regional, anecdotal, etc. I am not saying there is no problem, obviously there is one if we have only ever had 2 women try to get jobs at our company. But here at least, it isn't backroom racism. My guess it has a lot more to do with the boys club feel at pretty much all engineering faculties in north american universities.

I know of a handful of non white male programmers who are vocal and prominent members of the community, they exist, but they are hugely in the minority. That is the problem, what you see at conferences is a manifestation of THAT problem.

I do not know the organizers at this conference, but I know people who have been put in a similar situation, even when as organizers they are non white males. For example, Rebecca Murphy getting accused of sexism when she organizes a conference. Even when she has done way more for the cause then the people calling for her head.

As a conference organizer, you ARE put in the position of either finding token minorities, or facing a backlash. Who talks at a conf is based on who submits talks. If you end up with a situation where you have no submissions from minorities, or going on merit, the few minority submissions don't really make the cut, what do you do? It sucks for the organizers, and it sucks for the people who are asked to speak, since they never know if it is based on merit, or based on the fact that they aren't white men.

you could probably just precompile your extension

vims extensibility is a commonly cited positive, but I totally do not understand it, since pretty much every editor imaginable is extensible in similar fashion, and pretty much all of the use better languages then vim.

By contrast, emacs is basically an application platform that ships with an editor implementation, and eclipse is a platform for building editors.

It's not that vim isn't extensible, it is, just not as much as other alternatives, and nowhere near as easily as most of its competition.

IMO the real advantage of vim is that it is a highly efficient and productive tool that works great without any customization, and is available everywhere without installation. Which is pretty much the opposite of the above opinion.

out of curiosity, is js going to be your "elisp"?

It is a special case in other languages, in lisp it is one of a very few highly consistent rules

>How do you modify small chunks of templates and then check how it looks in the browser without leaving your editor

https://github.com/weavejester/hiccup

>and how is that a property of lisp?

The "lisp way" is to convert the problem into something solvable by lists, then convert those lists into whatever they need to be. Lisp is _amazing_ at processing lists, so this style of programming plays to the languages strengths.

>Also, I was pointing out that you don't get to define REPL to comply with what you think it should mean. I didn't say anything about interactive development.

Granted. But there is a fairly old idea that when you are working on code, it should be against a running version. Smalltalk was the ultimate expression of that, (where there is no difference between editor and app), but the typical way that a lisper works is the next best thing. When you are used to working that way, it is hard to go back, since the feedback cycle is just so tight, and exploratory coding is so simple.

When was the last time you ran your web server through erb, and modified small chunks of code, then checked how they worked without leaving your editor? I'm a professional rails dev, and for me it's "never". That "interactive development" is how all lisp coder work, and is probably what the OP was referring to.

I think 10% is pretty generous. More like 0.005%, maybe.

IMO if you are going to learn vim or emacs, you should drop the training wheels like janus/prelude/esk once you start getting comfortable with things.

IMO the only great vim emulator is evil mode for emacs :)

Text objects are the core of editing though, stuff like z or all the g commands are more situational. I replace the contents of a string (ci"), delete a word (daw), copy the contents of an array (yi]), etc WAY more often then things like folding

IMO once you get past knowing the core stuff on an editor, the next frontier is scripting. If you would consider yourself advanced in vim, I would suggest starting to learn VimL

I think the eventual consistency is what narrows riaks use case. Only heard good things about it though

Schemaless would let you add/remove a field easily. What is hard is if you need to restructure things, which is also probably a more common occurence in a document db then a relational one. If you hit a few million rows, you are in for a world of hurt changing things in any data store

What surprised me was the whole node thing. Js in the browser being super hot was pretty predictable

"no schemas" means "schema in the application layer". sometimes its nice for the additional flexibility, but its never as reliable.

Perl and Python are both in the "pending someone mentioning something they did that noone else has done before" part of the page, they aren't considered part of the list.

beyond that, children really don't have a sexuality until at least puberty. There is no such thing as "voluntary" pedophilia.

its not an allegation when you link to richardstallman.org. What he said was

"Dutch pedophiles have formed a political party to campaign for legalization.

I am skeptical of the claim that voluntarily pedophilia harms children. The arguments that it causes harm seem to be based on cases which aren't voluntary, which are then stretched by parents who are horrified by the idea that their little baby is maturing."

if comma first confuses a dev more then half a second or so, they really aren't that good. First time I saw comma first was from a DBA about 10 years ago who swore by it, and it has been my go to technique for writing maintainable code in languages where you end up with huge comma separated lists.

I freely remove, add, and move things to the bottom of my js classes without ever hitting trailing semis, or hitting a missing semi. I think that is more maintainable then the alternative

It's not about omitting semi-colons, it is about treating special cases as special cases. I just wrote something about the goals of NPM style, and how it can help debug those nasty problems http://mattbriggs.net/blog/2012/05/03/npm-style-javascript-i...

Brandon Eich on twitter (or in comments here) will also say that it is his opinion, and he recognizes that it seems to work pretty well for the NPM guys, but maybe it is just because they are such great devs, he doesn't see it scaling down that well.

And google is well known for terrible quality javascript. http://www.sitepoint.com/google-closure-how-not-to-write-jav...

And finally, Crockfords reasoning about things like this seems based on the presumption that js developers are drooling idiots. For example, he recommends against using the new keyword for object creation in javascript, even though object factories can often be a huge waste of memory, because dumb javascript developers may forget to use the new keyword at times when they want to instantiate objects.

I am not saying you shouldn't listen to smart people, but I am saying that you should actually learn the reasons they say the things they do, and use your own brain when making choices.

I came to the same conclusion awhile back. Also, if it is in any way possible, a view should be able to write its own HTML (the rails worl has a concept of JSTs, not sure if that has filtered out yet), and a view should never insert itself into the dom

What you get is loosely coupled, highly testable (and fast tests, since dom stuff is all in memory) ui code.

I hate both the gimp and libre office, and would gladly pay for alternatives available on other platforms if I didn't have to use them, even though both are free.

At least with the majority of what I use, Linux software in a general way is still pretty far off from the competition.

>>>but releasing something as GPL makes that impossible >>Please explain how requiring distributors to include access to source code makes it impossible to contribute source code. > (me talking about how the requirement to distribute their source code will make companies not contribute to opensource)

how is that out of context?

Because unless a software company is specifically structured to not make money off its source code, giving that away is pretty much the dumbest thing they can do. So when they want to build something and are evaluating options, if there is an MIT library that will get them most of the way, they will use it. If there is a commercial library that will get them most of the way, they will use it. If there is a GPL library, it doesn't matter how good it is, they will not use it and instead build their own thing from scratch.