bguthrie

That article does not appear to be making the argument that helmets are worthless, only that they don't protect against concussions.

    The $40 helmet is one of the great success stories of
    the past half-­century. Like seat belts, air bags,
    and smoke detectors, bike helmets save countless
    lives every year. They do a stellar job of preventing
    catastrophic skull fractures, plus dings and scrapes
    from low-hanging tree branches and other common nuisances.

Likewise, US safety standards haven't been updated to reflect more modern medical research on their seriousness.

I think this is a great analogy. The reason why it works is that we tend to relate progress in one intuitive metric (distance travelled) to a less intuitive one: time. Why shouldn't 80% of the trip be done when 80% of the distance is covered? Likewise, a merely sketched-out project can look dangerously complete.

In both cases you get caught by complexity. It's easy enough to drive in a straight line for a while, and your app's login system will likely work the same as most others'. But the devil, in both the city and in your code, is in the details.

If consumers want Windows tablets then they have a funny way of showing it.

Ola's a super-smart dude and the language is well worth exploring––I learned a lot from playing with Ioke. One of the coolest parts of it is his experiments with translations––in a language with zero keywords and a very small core, creating user translations into (say) Hindi becomes extremely straightforward. There's a rarely-explored opportunity there to bring programming to non-English speakers around the world.

I've had the same experience with Clojure in vim, and that's great to hear. Thanks!

Anyone out there spending any substantial part of their workflow in LT? Which languages? Would be curious to hear an experience report.

I check in every once in a while to see how it's coming along. The 0.5 series seems nice and I was impressed by the instarepl, but have yet to spend any real time with the editor.

The linked article makes the point that these sentences are used as a tool of intimidation but don't generally reflect actual sentences. I'm not convinced that's a reason to ignore them: it seems to me that the correct response of a less credulous observer would be to attack the system. Piling bullshit charges on to get extra years and extract a plea bargain is reprehensible. Are they trying to serve justice or collect scalps?

I won't claim to be an expert, but here's how I'd suggest you get involved.

* The last thing most social-good organizations need out of their software is flakey, drive-by charity hack jobs. They need the same things most organizations need: dedicated, ongoing, boring IT support. Some problems can be solved in weekend hackathons, if you can get the right people together. But if you can't contribute hacking time (some activist software is open-source), contribute your dollars.

* What almost all organizations want is your voice and your support. Know those online petitions that seem so stupid? They help. If you as an organizer can walk into a lawmaker's office with a million signatures in your pocket, it amplifies your voice. And a talented campaigner can convert some of those signatures into more meaningful action elsewhere––in the form of donation dollars, real-life organizing, and local lobbying efforts.

* Learn about traditional political organizing, which has a long and proud history and has very little to do with software. Protests and movements don't happen by accident; they're built, sometimes in small pieces over many years, by fairly traditional organizing techniques. The Ladder of Engagement[0] is one metaphor that organizers use to talk about how to get people engaged.

* Learn about other organizations in the space. DemandProgress does a lot of work with legislators that goes largely unheralded (and they've just merged with Lessig's Rootstrikers, which argues that getting money out of politics goes to the root of the problem); Fight for the Future is good at getting out the word on upcoming legislation. The EFF and the ACLU specialize in legal assistance and litigation, which is spectacularly successful when it works, but aren't the only organizations working to support this space politically.

[0] http://lithgow-schmidt.dk/sherry-arnstein/ladder-of-citizen-...

If you absolutely must rewrite, consider isolating and replacing components piecemeal rather than scrapping the whole thing and starting over. You don't eat the whole cost at once, you can keep moving forward with new features if needed, and you get more modular architecture to boot.

It's called the Strangler Pattern. http://www.martinfowler.com/bliki/StranglerApplication.html

I could be wrong, but from where I'm standing, it's just you.

Most major web applications built today thrive on a large, active ecosystem of open-source tools. Rails, Django, Play and Compojure all require the active participation of a large community of interested developers to keep them thriving and healthy. The author of the linked tool, who is a good dude, himself has a notable open source track record. I don't see any of this going away anytime soon.

I used to maintain the Ruby version of CruiseControl, the original open-source CI tool. There's plenty of room for everyone here.

There are two things driving policies like this.

First, personal interviews can be poor predictors of future hire performance. People will often hire someone who resonates on a personal level, or who is otherwise charismatic, rather than for the right skillset. Standardized tests, administered correctly, are one way of reducing the variability.

And variability is pain. Your HR and hiring people are likely being judged just the way everyone else is. Hiring, or forcing dev teams to interview, a lot of low-quality candidates without an effective screen is a good way to find yourself being replaced.

The second is that, as people are fond of saying, the standard you walk past is the standard you accept. This is the source of a lot of foolish "musts"––candidates must have a certain GPA, or only go to a certain school, or they have to hit a certain percentage on some tests. Having standards is all well and good until you find a case that doesn't fit your profile and you either get flexible or look foolish.

Being flexible means that other hires complain that you're lowering your standards, and no one likes hearing that either.

The test in this case wasn't correctly administered, as columbo pointed out elsewhere, and I agree that hiring managers shouldn't have a veto over technical hires. But this is the sort of human-dynamics problem that can't be solved by firing entire departments. If you don't address the problem head-on it'll just come back next year in a different form.

The only thing that matters about your coworkers––the only thing––is if, after the year's over or the project's done, you'd work with them again. If a team is doing good work and everyone on it enjoys working with each other, do not fuck with it.

Everyone in life has disagreements, petty jealousies, things they struggle with in other people. The beauty of the question, Would you work with her or him again?, is that it specifically doesn't try to disentangle those things––because to a productive team the quality its members' relationships with each other as important as the quality of their work. If one or the other is off, it's not necessarily anyone's fault, and it may not even be cause for termination. But it's as good a metric as you need.

But it's utterly foolish to winnow on a percentage basis. You'll break up good teams and prevent better ones from forming. You'll destroy morale. You'll encourage a leadership culture of cutthroat sociopaths whose success is at best tangentially related to the quality of their work. Do not do it.

An experienced developer does not lack for job offers. You can spend your entire life taking people up on those offers and never get around to doing your own thing. For most people on Earth, historically, that's not a bad place to be: it beats the hell out of starving. But if you have the luxury to do it, I think it's less impulsive than you imagine.

One of the great things about leaving a job you dislike to bootstrap a company making something you do like is not having too care too much about what other people think of your employment history.

Depression is a complicated disease with many causes, and no one knows exactly what was going through Aaron's mind. But I believe his depression was in large part situational, and that yes, MIT is at least partly to blame for that situation.

At the bare minimum, whether or not you believe MIT aided the prosecution over the defense (and I believe they did), it seems clear to me that Aaron and his family (his father is an alumnus, and worked for the MIT Media Lab) deserved better than "neutrality" from the MIT administration, if for no other reason than that I can't think of a single conceivable technical reason to call what Aaron did "felony" hacking.

By standing pat, MIT also contributed to the ongoing prosecutorial weaponization of laws like the CFAA, which makes a felony of a wide range of activities that most hackers would not even categorize as misdemeanors, to say nothing of crimes that bar you from voting or holding most jobs. It is a terrible precedent no matter how you look at it.

I'm skimming quickly for the gist, and certainly didn't intend to misrepresent its contents. That being said, I'm not going to change what I wrote; that quote presents a value judgment, one that I'm skeptical of, and since the broader report doesn't appear to admit to any responsibility for subsequent events, I think it's disappointing.

I have a lot of respect for the authors of the report, and I trust their integrity. But if judgement wasn't in their remit, then it was a poor remit.

Note also that MIT's president seems to believe that the report constitutes a free pass:

    From studying this review of MIT's role, I am 
    confident that MIT's decisions were reasonable,
    appropriate and made in good faith.

Those of us who believe MIT deserves some blame for subsequent events do so because they could have asked the prosecution to desist, as JSTOR did, or at least downgrade the charges to a misdemeanor, but chose not to. That amounted to an implicit endorsement of the prosecution, which would have been difficult to pursue without the support of either MIT or JSTOR.

The report appears to find that MIT should not have changed its neutral stance, which is disappointing, and I'm skeptical. Here's a quote (IV.B.3):

    Given the lead prosecutor’s comments to MIT’s outside 
    counsel (see section III.C.3), MIT statements would
    seemingly have had little impact, and even risk making
    matters worse—although this information was not shared
    with Swartz’s advocates.

It does reinforce what we already know: that the public prosecutor was mostly interested in collecting a scalp.

Update: Taren Stinebrickner-Kauffman, Aaron's partner at the time of his death, has released a statement. Full disclosure: Taren's a friend, Aaron was a friend, and I'm not exactly a disinterested party here.

http://tarensk.tumblr.com/post/56881327662/mit-report-is-a-w...

At the ripe age of 22, you'll like undergo a number of pivots in your career between embracing frameworks and tossing them out. There is no right answer; sometimes they help, and sometimes they hurt. We can't always predict what the right level of abstraction will be for future problems; today's popular frameworks can either become tomorrow's cruft-laden disasters or its stone-age embarrassments. Likewise, the definition of minimalist changes with the times (see jQuery), and minimalism itself goes into and out of fashion.

I happen to like Bootstrap, because I've seen a lot of projects descend into mess and cruft due to poor maintenance; it takes effort to maintain clean conventions, and if a framework dictates those conventions to me, that's one less set of decisions that I and my team have to make. But Bootstrap feels undeniably heavy, and perhaps I'll regret its use later. But for now it makes me faster, and I choose it knowing I'm making a tradeoff.

The submitted title appears more or less verbatim in the lede of the article, and is the more significant news. I don't know if I'd call it wrong.

Who cares if he acts professionally or not? But he's certainly not kind, and that counts.

Whenever someone talented acts like a dick, take a moment to think of all the talented people in history who managed to remain civil despite their accomplishments. It's a long enough list to matter. No one gets a free pass.

I agree, though other petitions can be effective. If you care about a cause, place your signature on a petition hosted with an organization that will tirelessly advocate for that cause. Organizations in turn live and die by their ability to gather and show support for the causes they fight.

If there's anything techies should've learned from the SOPA battle, it's that it is possible to make political change when enough people speak out. If you haven't watched aaronsw's talk on stopping SOPA, it's well worth your time. https://www.youtube.com/watch?v=Fgh2dFngFsg

The emails are fantastic and I recommend them heartily. Please do consider subscribing if you haven't yet.

I'd like to differ slightly: the job of a good tech lead is to be an effective first among equals.

If you're working on a talented team, there should be no presupposition that the tech lead is necessarily the best developer on it. But you should be good enough to break ties and set direction. I've worked on a lot of teams with talented developers who aren't especially interested in leadership, or former leads who've decided they want to go back and hack some more. You cannot, and should not, boss these people around. But you can block management up, and unblock team down, by keeping management out of everyone's hair, and keep the developers from tearing each other apart over complicated technical questions or obscure business ones.

If you're working on a team that embraces pairing, that can ease a lot of the pressure on the lead to do reviews as long as the pairs are well-chosen. Trust but verify.

"Do you welcome the leak, sir? Do you welcome the leak if you welcome the debate?"

Unless your performance optimizations specifically avoid method invocation, you can always extract the nasty bits to a well-named method. This is what is meant by comment avoidance: it is better to isolate the dirty stuff and pick good, specific names for what they do than to write an explanatory comment wherever possible.

I worked for one of the places Zed is describing. Like many of Zed's rants, it has a pleasant, self-righteous ring to it, but the problem is misdiagnosed and its solution is no help at all. I'll say no more.

I had much the same high school experience as the OP, but unlike him, I didn't get into a decent college or university and took two years off to work at a small startup. I couldn't have been luckier. I was a much stronger student later as a result, and a much harder worker.

My dad did the same thing, and spent a couple of years in the naval reserve.

My advice to other students would be: don't rush into higher education if it's not the right time for you. Time "off" for other life experiences, including work, makes a huge difference.

For a long time, Agilists recommended that teams colocate as an antidote to the kinds of tepid collaborations that happen at large software teams in large companies. But collaboration tech has gotten better, and modern, nimble teams should be "built to explode" - you should be able to work together in the office, or at Starbucks, or anywhere on Earth, if you have to. Start with distribution as a goal and few physical issues will disrupt you.

This sounds great as long as you keep the spirit of the standup alive - a standup is for the whole team, not management, and should be a quick read.

From the OP:

    But technologists used to work on big problems.

Many still do. And some technologists used to work on small problems, and some still do. There never was a perfect time in which every technologist ran around working on the Biggest Problem They Could Find.

The difference is the audience. I usually think of a status meeting as a one-way infodump from worker to manager. In a well-run standup, your audience is the whole team, because you're accountable to the team rather than any one person, and as a team member you're an active listener. If everyone's talking at the boss while the standup is going around then you're doing it wrong.

Edit: wrong, not right.