tonecluster

It becomes unpleasant very quickly regardless of the quality of the skills of the programmers.

Who in their right mind would want to work on a team of highly-intelligent, socially-challenged, culturally-homogeneous young men whose experience to date is primarily steeped in the casual misogyny, homophobia, and racism of MMORPG chat-channels; dorm-room bike-shedding; and adolescent dude-bro jokes?

Ain't that the truth. And (if you're doing it right), the older you get the more holes you spot. And, in filling those holes, keep collecting the lightbulbs from over your head when the "erkennen" mallet strikes.

Auto-play wouldn't engage the viewer. Tapping does. A call to action ("keep tapping!") isn't so exciting if you take away the action ;)

OK, very fair point. Thank you.

New rule: don't hire anyone who's posted abject idiocy in a comment thread on HN :/

It's idiotic because it is idiocy.

A vaccine is a vaccine; arbitrary judgments about it's general efficacy over some hand-wavey timespan doesn't change that. And no, it's not justified to redefine it.

Wide distribution has become much more accessible and much less expensive, which makes it easier for exceptional musicians (or performers) to get attention and gain traction. The key word here is "exceptional". Some guy messing with Protools or Garage Band isn't going to get far if he just isn't very good. So yes, you can get your music to hundreds of thousands of people, but you probably won't keep their attention for very long. Unless you're exceptionally good.

Paul Desmond wrote 'Take Five'. For an example of Brubeck's masterful "great code", check out "Blue Rondo a la Turk". Genius.

Hiring one or two engineers (per team) who are as technically capable as they are socially capable is ideal. The Rodrigos on the team will rely on this person to communicate what the hell is going on, and the Gabriellas will (must) raise their game -- although, I think that you can do without a Gabriella if you have one or two of these ideal engineers around.

The combination of coding and employee skills usually also means that this person is a good candidate for a team lead.

If you've never worked with someone who's an A+ engineer as well as a fantastic teammate/subordinate, you don't know what you're missing. The unsocializable uber-geeks can do what they do best, which is produce great code, and the managers are much more informed (and relaxed). And the teammates (like me) find working with them a pleasure.

In summary, coding skill vs. employee skill is a false dichotomy; the alternative is someone who has both skills and whose value to a team and to management acts as a team & production multiplier.

To be really clear -- I didn't write "don't use frameworks".

I will happily say "Don't use megaframeworks; use microframeworks.". And, I'll add "read the code in these microframeworks, learn what they do and how they do it, and start to see ways that the different tools available to you can be assembled".

I also absolutely agree that one should not create your own (mega)framework in order to build your application. But luckily I never said that one should ;)

And, I agree with your last paragraph and can add to it: "I suppose my theory is that as long as you're using an open-source framework or collection of microframeworks,..."

In my own experience, over time the use of small, clean open-source libraries (the microframeworks) beats the hell out of the codebases built on the megaframeworks. Eventually, you have to replace something, and replacing one component among many is a hell of a lot quicker, easier, and efficient than plumbing one out of a larger, less simple, monolith.

Could this be because you're much more acclimated/familiar with to Django then you are Flask (and the Flask stack you built)?

This assumes that the software is proprietary - which is something I didn't write in my comment. gEvent, etc, aren't proprietary - they're open-source.

There's no reason an engineer who's been around the block at least once wouldn't be familiar with the various OS libraries in various languages (these days, that's probably ruby, python, nodeJS, and maybe java if you're working in big data).

There's no way that someone who knows what they're doing would be able to learn Django or Rails implementations quickly but would take "x months" to learn a ruby + zeroMQ + mustache implementation. Months? Someone's sandbagging ;)

I disagree, respectfully, that a skilled engineer would create a framework in the process of writing an app. Instead: they'd write the app using the microframeworks chosen.

There's a big difference -- creating framework that solves a general set of problems is a different task than building an app.

This argument assumes that an engineer will create a framework to solve their problem ("build an app"), and create an ORM, and will recreate an auth process, etc. This isn't necessarily true.

Also - why assume that a skilled engineer will "hack" together anything? How hard is it to write a bunch of SQL? Not particularly hard at all - no need to hack (in the negative context of the work I infer you're using here).

In fact, a skilled engineer will re-use the micro-components he/she's created. An unskilled engineer will "hack" together a new "framework", "ORM", and so on - creating their own megaframework - to defeat the purpose of using microframeworks in the first place? Sorry, that kind of engineer needs more experience or skills.

Also, I think we need to clearly separate two things: writing an app, and writing a framework. I'm recommending using tools (microframeworks) to create apps, websites, etc -- not to ask an engineer to devolve into using these tools to create yet another megaframework in attempt to abstract away problems (that they probably don't fully understand, but should, as in your example of authentication) and failing.

In fact, I'll go ahead and posit that a skilled engineer knows how to create an auth process (using existing crypto and hash libraries instead of rolling their own). An unskilled engineer -- not so much.

I'll be a contrarian here: don't use mega-frameworks (Django, Rails). Instead, use micro-frameworks. Stay away from ORMs (I'm looking at you, Django). A skilled engineer can get a product comprised of small packages up and running in the same amount of time (and sometimes less time) as one built using a mega-framework.

(Imagine, using a python example, gEvent + zeroMQ + pystache + db-of-your-choice. You can do almost anything.)

I've found the same thing. On occasion, I'll waive the 50% upfront deposit (or reduce it dramatically). I also don't have any penalty terms; they're a waste of time. If a client is not going to pay on time, they're certainly not going to pay the penalty %age if and when they do pay. Weekly communication is key. And, if you do end up with a client who won't pay, or consistently pays >30days late, you're better off without them. Fire them, politely, and explain why - then move on. There's no need to punish them - there is a great need to get the hell away from them.

Life shouldn't be all about the money, agreed, but it is reasonable for someone to require enough salary to not run into the red every month paying for basic living expenses. Also, while money isn't a good motivator (see D. Pink), not enough money can be a terrific de-motivator.

Like anything, there's a reasonable-middle as to the salary requirements for an individual.

It depends about what you're arguing. A "python vs. nodejs" argument carried on for days isn't valuable; other arguments w.r.t. tech/engineering might be.

Related: An advantage of a "non-diverse" engineering culture is so the arguments can focus on meaningful topics that push the company forward, and not on topics that arise from basic, core cultural differences

Good point.

I've been programming since the age of 9, and I'm well into my 40s.

What that statement doesn't say is that for some of those years I learned very little (even though I was spending some of that time coding, I wasn't really "doing" anything; I.e., wasn't learning).

What really matters is doing quality work, making quality mistakes (so to speak), and learning from that and from other good engineers around you.

You're not crazy; it was ludicrously bad (or at least ill-informed) advice. And you are correct - unless published under a specific license, music "fixed" into some format is (c)All Rights Reserved.

It is possible that BMI will send a bill, eventually, if they notice. Note that this is separate from paying for a license to use the master (the recording).

You're correct that this would fail a fair-use test. Once it went up on a blog it's akin to a public performance, and use of the master recording should be licensed.

It is improbable that someone is going to issue a DMCA letter because of this, but it does (to your point) outline a couple of problems in S.V., one of which is the misconception that "It's not stealing if you attribute the artist" is widespread. And incorrect, at least for anything (c)All Rights Reserved.

If in doubt, it's a good idea for startups to consult their attorney (and not the PM, or lead engineer, or friend-in-a-band) when in doubt when using music, art, or what-have-you in public fora.

Seriously, perhaps you could learn an thing or two about focus. And paying attention.

You guys are missing the modifier "once upon a time". It's true: once upon a time, some (at the then once-upon-a-time time) geeky reporters got some interesting stories out of radio scanners. And now, it's not geeky to own a computer. But once-upon-a-time (as in when some of us, yer elders, were kids), it was only geeky people what had them. Anyway, agreed with tptacek, completely.