RTigger

I used (and they recommend) Camtasia Studio. Also picked up a Rode Podcaster microphone for decent audio quality.

I net about $1000/mo from one decently-watched pluralsight video I made over a year ago - http://www.pluralsight.com/courses/description/building-dotn...

The city of edmonton has had this for awhile now, and it's publicly available - https://dashboard.edmonton.ca/

When I was younger and struggling with issues, I did exactly this - plot my happiness on a graph. It was one of the few things that helped me get through a day, seeing that there are ebbs and flows, and for every low point there's likely a high point coming up.

This app needs to be published.

"It’s a bit ironic considering that yesterday Marcus took to Twitter to say his credit card was hacked. So clearly not all hacking is acceptable in Marcus’ book — only hacking that supports the company’s business objectives."

sigh.

I don't think it's a joke at all - I know lots of companies and people (myself included) who stress their culture and fit so much that technical skills often fall by the wayside. Sure, we want to know if you can code, but that can usually be figured out with a 15 minute white board test. If you're truly a pain to work with, unable to work in a team environment, or generally not collaborative, you probably won't get a job at my company.

Conversely, if you're a self-motivated learner, a good team member, and able to contribute, but don't quite have the technical skills we're looking for, we'll gladly take a training hit (usually 2 to 4 weeks) to get you up to speed on language X in exchange for an engaged and valuable employee.

But that might just be my company.

Related, I like to leave non-working code or tests at the end of a day so I can easily find where I left off. For some reason when I try to build / test and the errors pop up I'm able to immediately pick up where I left off. A combination of a bookmark and the Zeigarnik Effect I guess?

I like to set external-facing deadlines. I'll do things like tell my department I'm going to do a presentation on technology X in two weeks, and then start learning about it. If I don't get it done, I have to tell 20 other developers why I have to cancel the meeting they've all accepted.

This is part of the motivation of team and peer-accountability in some of the agile methods like Scrum / XP / Pair Programming. If you feel personally responsible to someone else, you're likely to follow through. A good way to do this with personal projects is to find a partner - I work with a designer on a lot of my personal projects, and telling him that I'm going to get X done helps, as well as seeing the time and progress he's invested in the project.

I ended up blogging a response to this - http://rtigger.com/blog/2013/03/20/saving-the-world-with-sof...

TL;DR - We change the world for the better in so many ways that we don't even realize. Don't sell ourselves short.

My favourite comment on the original post - "Old Man Yells At Cloud"

http://www.globalnerdy.com/wordpress/wp-content/uploads/2008...

Yeah - fortunately our company is small enough where we can hear stories like that from our support/sales staff, but in larger companies developers are so far removed from the end user that we have no idea how much of an impact we actually make in people's day-to-day.

One of my favorite stories told by our software consultants (the people we send to client sites to train how to use our software effectively):

One day he went to a customer's site to train them on the new version of our software, and met with one of the bookkeepers of the company. He showed her a report that we recently added a column to as part of a feature request from our clients, and she started crying. He was asking her what was wrong, worried that we did something terrible. She replied: "You just saved me 3 hours a day. Now I can go home when my kids are home from school instead of after supper".

Just because we're not saving babies doesn't mean we're not making people's lives better.

That's a pretty good point, and a much better solution to the example I gave. It'd be interesting to see FetchRemoteString as a Func<string, string> property where you could have a default implementation (web client) and then in your test setup you could just redefine the property to do whatever you want.

The general point still stands though - if there was an interface, we wouldn't have to come up with these workarounds.

As I noted in the article's comments, I'm pretty sure you can't just add "dataType:jsonp" and have it automagically bypass all the cross-domain security restrictions.

What actually happens is jQuery appends something like "callback=some_random_function" to the end of the querystring when it makes the request, and then the server is supposed to return you the standard data, wrapped in a function definition with the same name. jQuery then automatically executes the function, making the json data available.

Some servers require a specific function name, which can be specified as an ajax option using "jsonpCallback: functionName". All this effectively does is uses a specific function name instead of a randomly generated one, so that it matches up with the function returned from the server in the response.

I ended up blogging in response - http://rtigger.com/blog/2013/01/23/short-term-planning/

TL;DR - I agree, and highlight how the short-term planning process baked into most agile approaches addresses this problem.

I blogged about the "moral" of this story a few months ago - http://rtigger.com/blog/2012/07/06/architecture-last/

TL;DR - Frameworks should emerge from use cases, not the other way around.

Ask and ye shall receive! http://rtigger.com/blog/2013/01/17/how-to-find-a-hacker/

I consider myself one of the people trying to "take it back". See my article on the subject: http://rtigger.com/blog/2012/11/19/redefining-hacker

Yep - had a two year stint in Vancouver but moved back last year. Good to hear from you! Drop me a DM on twitter if you're around :)

Fair enough - as someone else pointed out in the blog comments, there's not a lot of "actionable" items in this post short of seeing if people work on side projects, which in itself isn't an indication of someone you should hire.

Word of mouth however is a pretty reliable way of finding solid developers provided you start with a good developer or two to begin with, and is a great way to build your team and culture - odds are if your team is recommending someone, they'll fit in with and extend the culture your company is going for. We saw an example of this when we opened our Vancouver office - after a few key hires we were able to attract a lot of talented developers who fit in nicely.

I would've hoped the lack of advertising, missing link to my linked in profile or resume, or lack of any sort of "donate" button would've established that I'm just doing this because I have a personal interest in writing and software development. Hell, my real name isn't even on the site!

But yes, thank you for your critical feedback.

I don't mean to exclude the value of language experience, rather point out that just because someone doesn't know C++ doesn't mean they wouldn't be able to contribute to your team. It's more an argument against companies who won't even entertain the idea of hiring someone without X years of experience in a particular language.

When it comes down to it, most programming languages are just syntax and patterns. Most intelligent people can pick up on this. The people who are going to contribute the most to your project and company in the long term are those who love what they do and are passionate about doing a good job.

Aww, thanks for the constructive criticism!

Despite your comment, I think we're kind of getting at the same point - if you have a great place to work and focus on building a team that works well together, you're going to have more success as opposed to hiring someone with X years of Ruby experience just because they know how to code. Focus on cultural fit, the technical stuff can be taught.

Signed, nameless derp

I'd argue the short and long term gains of this approach. If you hire someone who's really good at Python, you're going to get good quality out of the gate from them. But if they're not a good fit for your company or team and/or if they're not passionate about what they do, you might be damaging progress or performance in the long run. In that case I'd take a .NET developer willing to become a good Python developer over a Python developer who's there to collect a paycheque anyday.

That being said, if you can find a great Python developer who is also passionate and a good fit, you've hit the jackpot!

I don't think it's as much as a compromise, just that we should focus less on the language aspect of it. Technical details like implementation and syntax are easily learned. Passion for development is more of a character trait that can't easily be taught.

Out of your 4 criteria, I'd say (personally) that the important ones are "Loves what you're doing" and "Loves your team". If you hire someone who is a Ruby god but has no passion for the problem they're solving, or causes problems with your existing company, culture, or team, you're probably going to have a net loss. Working remotely is a different topic and can be done well (http://blog.davidtate.org/2013/01/companies-that-support-rem...)

I did want to talk a bit about finding those passionate developers, but thought it'd make for a separate blog post later on. One key quote I've heard good recruiters say: "The good developers you want to hire aren't looking for jobs, they already work somewhere".

We don't do cultural interviews to determine if someone's a hacker, we do them to determine if they're a good fit for a team and if they'll be able to work in our company environment.

And passion comes in many forms - the fact that they were willing to teach the team alone speaks volumes. If someone didn't care about programming, they wouldn't want to spend the extra time teaching their peers about it.

We're kind of arguing the same point - I mostly meant there should be less of a focus on language experience and more of a focus on passion (pet projects). It goes without saying if you try to hire someone who doesn't want to work for you or your projects, it's not going to work.

I really like C#, and I prefer to do most of my projects with it, but learning new languages interests me (a problem I want to work on) and is a challenge that I'm passionate enough about to do in my spare time.

I'd argue that (and I have) - a recent grad who went outside of their coursework to learn about node.js (for example) and/or has maintained their own personal website or projects is a passionate developer and can probably learn anything you throw at them. In fact they can probably learn it better than someone who's spent 10 years in a certain language because they've just come out of a 4 year learning experience.

I suppose that's a good point. Once we have a standard in place (like the one proposed in the original article) it'd be relatively easy to make a client library that standardizes access to those kinds of API. You know, like WSDL used to do.