paddyforan

Disclosure: I am not a Very Important Programmer.

Second Disclosure: I am not on top.

Were either of these different, I might feel differently than I do.

Some people do prefer email to the phone. I have no problem with a recruiter offering the option to have a phone call. I have problems with recruiters requiring the phone call before I can even talk to someone who will make a decision. Hell, the last recruiter blatantly told me they would not tell me the name of the company they were hiring for until I was on the phone with them. Perhaps it's my arrogance, but that doesn't to be a matter of "some people like the phone better".

You are right, not every recruiter needs to read my blog or Twitter enough to realise that I have a boyfriend. That is a terrible example. I'll iterate on it with an updated draft that better gets across the point--perhaps a suggesting I work in an enterprise environment would be a better example, as I'm decidedly unsuited to that environment, and that's obvious if you know anything about me at all.

I believe a bare minimum of a job description--the company they're hiring for, something about the culture or problem they're solving, the stack they use, maybe why they think you'd be a good candidate--is probably a good bet. I get too many recruiter emails like my sample that don't tell me, quite literally, anything about the company. At all. No name. No website. No size. Nothing that would allow me to determine if this is an opportunity I should pursue or not.

I believe I pointed out that recruiters are busy and that I am busy. I am well aware I'm not the only busy person out there. :) If you think this is disrespectful, I'd certainly love to find ways to fix this.

I think you may be unfamiliar with the level of interaction recruiters provide. The publicists sending the mass pitches you describe are the bad recruiter pitches I am talking about. It is not a matter of me having very specific guidelines for how I am spoken to before I'll consider a job; it's a matter of an industry whose norm is to type in search terms, then hit all the results with a form letter.

This letter is in case one of those who are trying to do a good job are seeing everyone else use the form letter and assuming that is how it's done. Or who simply don't know how to put themselves into an engineer's shoes to effectively communicate a pitch.

I resent your accusation that I believe recruiters are somehow beneath me. I actually, as I mentioned, believe recruiters have a really cool job. I don't have the aptitude for it, but I do not believe that making lights flash in a pleasing pattern is somehow a worthier job than connecting people to jobs that fulfill them. And yes, there are recruiters I love. They are the ones I send referrals to when a friend asks who is hiring. They are the ones I seek out. Which, for a recruiter, is a powerful card to hold in a limited market. I'm trying to give as many recruiters that card as I can.

I deal with recruiters all the time. I got my current job through a recruiter. He was fantastic. I have nothing against recruiters, or I would just set up a spam filter and call it a day.

I wrote this because I ask for feedback when I'm in the hiring process, so it struck me that recruiters might also like feedback. It seems to me that this is the opposite of what you accuse me of; if I didn't care about the recruiter, considered them lesser, or didn't think they cared about their job, why would I care if they got the feedback they needed to improve? I'd ignore them and move on. It's certainly less effort.

And it results in fewer people assuming I think my ass is the gravitational pull of the universe without bothering to find out anything about me.

This is the truest of all true things that are true.

Totally a first-world problem.

I share feedback with recruiters because I want feedback as an engineer. If they choose to ignore it... well, I'll have to find some way to deal with people trying to give me a job, I guess. Woe.

I'll start forwarding you all my recruiter emails! :)

Every interview I take, if I don't get offered the job, I ask for feedback on what I should have done in my past to take the job. Why did I fail? What should I be working on?

This post is that answer for recruiters. I've typed it out individually, over and over again, in response to bad pitches, highlighting what they did wrong and how they could have succeeded or saved themselves time.

This is a time-consuming thing for me to do, but I feel it's justified if it helps even one recruiter. So this is my shorthand way of handling it--just link them to the post instead of rewriting it for every single recruiter.

Most will ignore it. Maybe all will ignore it. But if a recruiter is sincerely trying to do a good job, it will provide them with useful information as to why their pitch was ineffective and how to improve it.

If I was a recruiter, this is the kind of feedback I'd want from someone I was trying to recruit, so this is the kind of feedback I offer to people trying to recruit me.

I'd say kind honest feedback.

If I'm being unkind in my feedback, I would love to tweak it to be kinder.

How uppity of me, to let my desire to work in a job I like get in the way of a recruiter's money.

I am thoroughly cowed. I've seen the error of my ways. Thank you.

So...

what you're telling me is you're tired of being offered posts on my blog and I could be using more effective methods? O:)

It's as easy to figure out I have a boyfriend as it is to figure out what I look for in a company. Or what my preferred stack is. I'm not really subtle about it. But I'll give you that one; it's possible to get a good pitch for a state I wouldn't consider working in, assuming it has some other evidence that they know something about me other than "Matched my search results for 'writes Python sometimes'".

I don't work with local recruiters because _I'm not looking for a job_.

And oh, man you should see the amount of junk mail and spam I get too!

Be jealous of how frequently telemarketers call me!

You nailed it, ace.

I'm not sure I see the incentive in me doing that...?

Unless, of course, I hate dealing with them. In which case I'm not going to get hired through them in the first place.

Why would I do that?

I'm sorry you don't consider it friendly. Personally, telling them why their pitch didn't work felt friendlier than just assuming they had no interest in improving and ignoring them, which is the other tenable option.

It would be unfriendly for me to send recruiters after friends without knowing if the friend is actually a match for the company or not. At least in my opinion.

Totally! I've had some great recruiters reach out to me. I've gotten bad pitches that were actually personalized, too. But I've also gotten the shotgun.

Obviously, no hope for the shotgun. I hold out hope for the bad pitches.

We can all go home, you've won the thread.

Oh, I know. I expect to have to send it to each of them, manually, in response to bad pitches. And I expect 99.99999% will ignore it.

But if, in my entire career, I can help one recruiter suck less, it was all worth it.

I guess I'm just an optimist like that.

I know, but I remain hopeful. And if I don't tell people how they failed, how will they improve?

Writing this just put it in a convenient place so I can link to it instead of repeating myself every time.

"Yeah, not really enjoying this new job, my coworkers are total douche-canoes. Actually, could you hang on a second? -- Steve, can you keep your typing down? I'm on the phone with a recruiter. Thanks. -- So yeah, hate this job..."

I can't speak for other providers, but our practice is to let users set the number of retries they'd like and the space between retries.

We also are close to rolling out error queues, so when a push notification fails, the message is automatically placed into a queue, to be processed at the user's convenience.

I agree, the need for safe retries (as this is a process without user feedback) calls for idempotency, but that's at odds with the need for a webhook to be possible to be triggered multiple times.

One way around this is to use "tickle" webhooks--webhooks that tell the destination that data has changed, but require the destination to pull in that information themselves. Then the webhook call is still idempotent in practice (at worst, you're refreshing data more than you need to, which is still less than polling), but multiple webhook calls can be made.

John Sheehan, of Runscope.com (which, by the way, is a super rad tool for API developers) did a great roundup on receiving webhooks for testing: http://john-sheehan.com/blog/a-survey-of-the-localhost-proxy...

That's why logs from the webhook provider are important. :)

I'm incredibly excited about them.

As far as I'm concerned, webhooks and callback requests are the same. If we were going to get pedantic, I suppose we could say that for a request to be a callback, it would have to be a response to an earlier request (think asynchronous processing) whereas a webhook is an evented request (it wasn't prompted by a previous request).

But being pedantic is lame. Let's just be excited about both!

Relevant: https://twitter.com/paddyforan/statuses/254375310554968064

"We have nothing to announce at this time."

I'd like there to be is all I've got for you at the moment. :( Priorities, and all that.

Awesome!

Great question!

For Iron.io, all our requests are authenticated using an OAuth token. So only people that know your OAuth token (and thus could use our API anyways) can use your webhook endpoints.

But there are other ways, too. The most common I've seen is to provide an API endpoint to verify events with (Stripe does this). If you use HTTPS to receive the webhook, and verify it with a request over HTTPS to the API you expect it to be coming from, you're ensuring the request is authentic.

For some webhook styles, it doesn't actually matter. Some people use webhooks to just say "Something happened", without actually saying what. In this style, the API is still responsible for the data and authentication, the webhook just says "Hey, wake up, the API has something new for you."

I love this idea. I've been wanting to do something similar to this, making webhooks even easier to hook into the Iron.io platform. I don't know if it will make it into HUD, but I'm definitely going to be trying to setup some push-button webhook configurations for popular services that support configuring webhooks from an API.

I think one of my favourite things about Go is that it makes it easy and obvious to code well. Generally the first thing that comes to my mind is going to be performant and extendable.

The reason this is the case, I think, is that Go strives to make algorithmic complexity clear: you know when you're allocating memory, but you don't need to jump through hoops to do it. You know the rough performance costs of what you're doing because the core team works hard to make it obvious. For example, some regular expressions features (lookahead, if I remember correctly) aren't implemented in the Go standard library's regular expression package, because they're impossible to achieve in O(n) time. https://groups.google.com/forum/#!topic/golang-nuts/7qgSDWPI...

This level of care in making simple, clearly-defined tools with known properties makes it easy to code well. Ruby, Python, PHP, NodeJS... you can shoot yourself in the foot and not even notice.

Packaging is both the best and worst of Go. I love the decentralisation, so there's no central directory of Go code. We don't have pypi, we don't have rubygems or npm, we have Github.

As others have pointed out, you can use directories as namespaces, which works nicely. But I've found, personally, that splitting my projects into separate repos for each namespace is actually beneficial. Helps keep my code clean and separated.

That being said, versioning is a real pain right now. The best thing I've found is to fork a repo when I decide to use it, then pull in updates as I adjust my code to work with them. Definitely not ideal, and if you have a lot of projects using the same dependency, it becomes a major headache.

There are some workarounds, and we've discussed the topic at great length on the mailing list. I think it's something we'll see a solution to in the next few years. But one of the things about Go that I really enjoy is that the core team is hesitant to push half-baked ideas onto the community. When we see a solution, it tends to be an elegant, clean solution that fits perfectly into the problem it solves.

In other words: yes, there are some problems. Yes, I do think they'll go away. Yes, I do think we'll need to be patient. Yes, I do think it will be worth it.

We're friendly. Drop by get.iron.io/chat and we'll answer any and all questions you may have. :)

I'm starting to feel so left out. Why do crazy Go-haters never harass me? Am I not good enough?

So now that we've established Ruby is better at being Ruby than Go is, I wonder if there's an actual use case for this kind of thing, so I can demonstrate the "Go way" of handling it...

I wouldn't say Go doesn't have a testing culture. On what basis do you make that assertion?

I write better tests for my Go code than for any code in other languages that I write. But maybe I just think in complementary ways to Go's testing philosophy.