I hope this email finds you well. Your qualifications match a PHP Developer position we currently have with a great company in the Columbus market area. I wanted to find out your current employment situation and inquire as to whether or not you are currently in the job market and what type of opportunities you might entertain?
PHP Web Developer
[pages of garbage removed]
Desired Candidate Profile:
Delivering Quality code.
Extensive knowledge of iterative development lifecycle management and tools.
Able to direct the work of others, prioritize tasks and allocate resources.
Must be able to lead cross-functional project teams and coordinate activities of others.
Design, develop, and management of PHP Web Applications.
Familiarity with WAMP, LAMP environments.
Experience with MySQL.
Taken a team through multiple complete product development cycles.
Agile application development.
Experience developing and using Web Services
I look forward to hearing back from you!
Let me tell you a story about Robert Half Technology in my hometown of Columbus, Ohio.
Robert Half was the first place I went to interview for a job after college. They listed a specific job online, maintained that premise through a phone interview, and then asked me to come in, only to reveal in person that there wasn’t actually a specific position available — they just wanted to get me on their list of temp consultants they could rent out.
Robert Half Technology does everything that gives tech recruiters a bad name, and everything that makes looking for a tech job so incredibly difficult when you’re young and inexperienced. They do the entire industry a great disservice. Nobody who works there should be proud of what their company does, or be under the illusion that they’re helping anyone.
After looking over my resume with me in person, which was pretty light since I was applying for my first job after getting my computer science degree, they said I couldn’t and shouldn’t be a programmer, and should stick to basic IT jobs instead.
A few days later, they assigned me one awful weekend job where I, and about 50 other similar chumps, sat around and watched a huge company’s PCs upgrade to Windows 2000 and occasionally clicked buttons when necessary. I quit after two days when I got a real job offer — as a programmer.
But that was mostly luck: a friend from college had just been hired there and connected us. I narrowly escaped a career of working for cheap IT body-farms, always regretting not starting out as a programmer like I wanted to.
I responded to the Senior Recruiter with my requirements — $10 million a year (plus medical) and relocation of the company to New York — but disclosed that I am probably not qualified for this position since I do not have any experience in Agile. ↩
I’ve been plowing through thousands of tweets and emails. I’m nowhere near the bottom of the pile yet, a few small bugs got out (like almost every 1.0 release), and yes, I really need streaming. But overall, the launch went exceptionally, far exceeding my expectations and calming my fears.
I’ve been listening to podcasts regularly for almost a decade, and there have always been more great podcasts than I’ve had time to listen to. Podcasting doesn’t have a content problem. More great podcasts are always welcome, but there isn’t a lack of great podcasts holding back the medium.
Podcast adoption has always been driven primarily by ease of listening, which has improved dramatically with the rise of smartphones, podcast apps, and Bluetooth audio in cars. When it’s easier to listen, not only do more people listen, but listeners find more opportunities to listen. There’s still plenty of potential to help people who already like podcasts listen to more of them.1
I had been wanting to make a podcast app for a while by late 2012, when I got two ideas that encouraged me to look more into it:
Smart Speed shortens silences. Playing at faster speeds has always helped people make time to hear more podcasts, but it usually came at the expense of sound quality and intelligibility. Smart Speed is like getting another speed increment for free: it saves time without sounding weird.
Voice Boost is a combination of dynamic compression and equalization that can make many shows more listenable and normalize volume across all shows. This makes amateur-produced podcasts (including many of my favorites) more listenable in loud environments, like cars, where you’d otherwise need to crank the volume so loudly to hear the quiet parts that you’d blow your ears out when the loudest person spoke.
Neither of these are original ideas, but I knew both would greatly help me as a listener, and none of the podcast apps offered anything like them.2
Over the following weeks, I learned the low-level Core Audio API and made a “Castaway” prototype that could apply these effects to a podcast file. To my surprise, Smart Speed sounded nearly perfect with no audible artifacts. Conversations still sounded natural — often better, with tighter timing. Voice Boost easily normalized and enhanced everything I threw at it. And these ran at full speed on an iPhone with very low CPU usage.3 I knew I had something good, but Instapaper and The Magazine were keeping me too busy to pursue it.
Months later, in the spring of 2013, I soldboth for unrelated reasons. Realizing that I had the rare opportunity of a clear plate, I dusted off the Castaway prototype and started the truly hard part: building an entire podcast app around the audio engine I had prototyped.
Smart Speed and Voice Boost are killer features to me, but a lot of people won’t care nearly as much about them, and there’s nothing stopping the other apps’ developers from adding similar features. My podcast app needed to be a compelling overall package, not just two features. There was a lot of work ahead.
By June, I had the server basics running, with feed crawlers trying to find and update as many podcast feeds as possible.
At WWDC, I got even more encouragement. iOS 7 shook up the market and, by pure luck, shifted high-end iOS design away from fashions I could never compete in — heavy use of textures and complex graphical widgets — into what I could actually do: simplicity, space, and typography. I also demoed the audio prototype in my hotel room to Guy English, using his own voice,4 and he was impressed — a great relief to me, as this was the first time anyone else had heard it.
Over the next few months, I worked my ass off, both building the app and naming it. By the time I had announced Overcast in September with my XOXO presentation and blog post, I was already using it myself full-time, so I thought it was almost done when I said it would be out about six months ago, at the latest.
But the audio engine was the easiest part of writing a modern, full-featured podcast app. Yes, I could use it full-time almost a year ago, but that’s because it only did the minimum functionality I needed, I hardcoded it to always be logged into my account, I could adjust settings by changing constants in the code, I subscribed to new shows by typing an INSERT statement into a MySQL command line, and I hadn’t yet tried to rewrite the sync engine. (Twice.)
When I finally started the beta, I expected to ship within two weeks. That was over two months ago, and I’m glad, because my beta testers pushed me to make it much better. I owe them quite a bit of gratitude.
It’s been a long road, but 1.0 is finally done. I’m proud of what I’m shipping today.5
Thank you to everyone who has helped me and Overcast along the way.
Many people don’t listen to any podcasts yet, and there’s work to be done there, but that problem is more likely to slowly solve itself. ↩
At least, I couldn’t find any. A few months ago, I learned that RSSRadio offers silence skipping and DSP effects, so I’m not the first. ↩
Thanks in part to my liberal use of low-level Accelerate vDSP operations, which offer potentially huge speed improvements, battery savings, and geeky intellectual satisfaction at the expense of filling your code with obtuse function names like vDSP_zvmags. ↩
I’ve heard the first minute of that Talk Show episode a lot, as that was loaded when I was first building and tweaking Smart Speed. It’s a great test because John Siracusa and John Gruber talk at very different speeds. ↩
Well, I’m scared shitless of unfound bugs and server overloads. But proud. ↩
In Headphones and Coffee, I had to disclaim that I hadn’t tried most of the best headphones in the world — I was sticking with what normal people would consider a “high-end” range of $500–700, but to a headphone audiophile, that’s midrange. I had never heard what many consider the quintessential high-end headphone: the famous Sennheiser HD 800.
As expected, I heard about it. I also had a great Amazon-referral month, so I decided to “reinvest” (that’s what I tell myself to justify high-end headphones, at least) and give them a real shot. I also hated my closed headphones,1 so I got what many consider the best closed headphones currently for sale, the Fostex TH900. Both retail for $1500, and both are frequently on sale for a few hundred bucks less. I planned to try both for a few months, then sell one or both.
I still can’t detect a sound-quality difference between amps and DACs2 unless there’s an electrical problem, like an amp with insufficient power for the headphones or a DAC with audible noise on the outputs. But I wanted to give these headphones a fair shot, and the HD 800 needed more power than my existing amp could deliver.
Choosing an audiophile amp and DAC are difficult because audiophiles will tell you a great deal of unscientific wine-tasting descriptions of how each component sounds, then recommend whatever they bought. As soon as you pick one, the same people blame it for any flaw or disappointment you find. “Oh, you aren’t impressed by these expensive headphones? Burn them in for 600 more hours, upgrade that inferior stock cable, and replace that harsh DAC.” It’s exhausting.
I like what Schiit stands for. Their founders are extremely good electrical engineers, and their products hit all of the checkboxes — high power, low distortion, fancy inputs and outputs, both tube and solid-state models, etc. — but they’re very affordable (relative to similar products), and their no-bullshit attitude is refreshing in an industry that’s otherwise so full of it. (Really. Read some of their product FAQs, or co-founder Jason Stoddard’s ongoing story of their early days.)
I chose well enough to give these headphones a fair shot by most reasonable estimates:
Asgard 2 amp, $250: It delivers plenty of power for the HD 800 and similar headphones, it’s very well-priced for a headphone amp, I don’t notice any flaws in the sound, there are no finicky tubes to deal with, and it looks great. Fair warning, though: since it’s a class-A circuit, it runs hot by design, constantly emitting about 30 watts of heat if it’s not playing anything. You should probably turn it off when it’s not in use. Still, I recommend this amp if you need its power.3
Bifrost DAC, $350–520: To minimize audiophile-complaint vectors, I got the fully upgraded model with the USB Gen 2 Input and Uber Analog Stage. I have no complaints, but I also don’t think this was necessary. The line-out from my Mac directly to the amp sounds just as good to me, with a very minor exception: with my most sensitive headphones (the TH900), nothing playing, and the volume cranked very high — higher than I’d ever play music — I can hear very slight noise from my Mac’s output that isn’t present on the Bifrost’s. But I rarely listen to extremely loud silence.
So if you need an amp, the Asgard 2 is great. If you need a DAC, the Bifrost is great, but I still question whether you need one — given any budget constraints, a great DAC’s price is much better allocated to better headphones first.
* * *
I previously chose the Beyerdynamic T90 ($650) because of its incredible detail, quality, and comfort, with the caveat that its treble can be harsh with some music, especially studio rock and pop albums sloppily mastered in the mid-2000s to sound better on awful earbuds. But that was the only substantial flaw, and I was blown away by everything else about it, especially that level of detail.
When the Sennheiser HD 800 and Fostex TH900 arrived, I put the T90 in the closet for a few months, leaving me to get to know the new arrivals full-time: the HD 800 when I could use an open pair, and the TH900 when I couldn’t.
When I first tried the venerable Sennheiser HD 800, which costs at least twice as much, I was disappointed — it wasn’t very different from the T90. Over the last few months, I’ve been able to put my finger on why it’s so well-regarded: It has no obvious flaws.
Well, almost. The bass is pretty light, even for audiophile headphones. But this isn’t a problem with any music the way the T90’s treble can be too hot with some. With the HD 800, I never notice any flaws, when listening to anything, that I can point to as a headphone shortcoming. It’s a technical marvel.
But this comes at a cost that took me a few more months to realize: the HD 800 has no personality whatsoever.
The best part of owning great headphones is the occasional “Holy shit!” factor: those moments where you’re just blown away by how great the music sounds. The HD 800 never sounds exciting or fun, and I’ve never had a “Holy shit!” moment from it. You don’t rock out with the HD 800 — it’s very pleasant, but it won’t make you dance in your chair.
It’s technically brilliant, but in reality, it just needs a bit more… something. It’s like a perfectly cooked filet mignon with no salt.
The Fostex TH900 is another story. It’s by far the best closed headphone I’ve ever heard, but that’s partly because it’s not very closed. Its isolation is roughly in the middle between open headphones and almost any other closed pair. But my wife is very forgiving of the sound leakage.
The TH900 has the same incredible level of detail as the HD 800 and T90, but with ample personality. If the HD 800 is like a perfectly flat equalizer, the TH900 is slightly and pleasantly V-shaped: the midrange is recessed just a tad, the treble is boosted slightly, and the bass is strong (though not overpowering like Beats). Unlike the T90, the extra treble never sounds harsh — it just boosts the detail slightly, like a dash of salt.
It’s not neutral-sounding, and the HD 800 is definitely the technically superior headphone. But over the months that I’ve owned both, my HD 800 usage is decreasing, and I’m finding myself going to the TH900 more. The extra hint of treble — and more-than-a-hint of bass — are much better for almost everything I listen to.
The TH900 is also a bit more comfortable, and looks a hell of a lot better — the HD 800 looks like it was designed by space aliens in 1993. And the TH900 is much easier to drive: my Mac Pro’s headphone port can power it amply with a size adapter, though I’ve been using the amp anyway. (Both are far too large, unwieldy, and fancy for portable use.)
* * *
Back when such things mattered, in a review I read comparing the first Playstation to the Sega Saturn, the author wrote something that I’m almost positive I’m remembering correctly: “If you only get one, get the Playstation. But if you have both, you’ll play the Saturn most.”
I was frustrated at the time, as a Sega fan: why not pick the Saturn, then? But the author was clear that the Playstation was the “better” system, whatever that meant. I didn’t understand it for years, but I finally get it now.
If you want the best headphones, I must recommend the HD 800.4
If you’re willing to drop $1500 on a pair of headphones, it’s hard for me to advise you to buy any other pair. If you don’t get the HD 800, and you’re anything like me, you’ll always wonder what you’re missing.
If you never want to doubt your choice and feel like you’re missing out on something better — well, that’s an unrealistic expectation. If you’re considering $1500 headphones, you’ll never stop wondering if something else could sound even better. But if you at least want to minimize those times, get the HD 800.
The HD 800 is the better headphone. But the Fostex is my favorite.
And I finally see the difference. If I can only have one, I’ll take the Fostex.
* * *
After writing most of this, I took the $650 T90 out of the closet for the first time in months and compared it against these $1500 flagships.
It performs admirably: it has all of the personality and detail of the TH900 in a smaller, lighter, cheaper, open headphone, and I think I actually prefer it to the HD 800 despite its hot-treble flaw. Sometimes higher-end is “better”, but not preferable.
The TH900 manages the same detail and personality without the harshness. It really is better. It’s not almost-3-times-the-price better, but it’s still my favorite.
By opting “only” for the T90, you’re really not missing much that the highest-end headphone world has to offer. As with most pursuits, diminishing returns set in rapidly. The T90 delivers far more of the top-of-the-line qualities than its price suggests.
I’m searching for a properly powered HiFiMAN HE-6 to audition, hopefully with the upcoming Schiit Ragnarok amp. I wish there was a better way to try these things out other than just buying them and selling them later, but there mostly isn’t. (At least resale value tends to hold well.) And I still need to tell you my SR-009 story, but that’s for another day.
Amp and DAC manufacturers insist there’s a difference, and I’m sure there is — various factors are definitely measurable, but I question whether they’re audible enough to pass blind ABX testing. Informally, I’ve never heard a difference when unscientifically A/B switching between them. ↩
If you’re into very demanding headphones, like the orthodynamic flagship HE-6, you’ll need more power. But the Asgard 2 will drive almost anything most people are likely to buy, including most lower-needs orthodynamics. The new HE-560 are supposedly awesome, although I’ve never tried them. (I’d love to.) ↩
Well, the Stax SR-009 does sound better, but I assume a $5,000 headphone that requires a $2,000+ electrostatic amp, with a months-long waiting list and a common flaw that requires months-long repairs on top of that, isn’t under consideration for most people. ↩
Brent Simmons on standard controls becoming the fashionable and practical choice again.
I especially like his point about cost. I can’t believe how much money some developers spend on paying a large team to do tons of work on problems and markets that can’t justify the cost.
I lucked out in Overcast’s market timing: I only had to hire a damn good designer for the app icon. I was able to design everything else — every screen, every in-app icon,1 all of the text — because what’s in fashion today is much easier for non-artists like me to do: whitespace, clean lines, and good typography.
Apps with full-time designers can turn out amazingly, but a designer is no longer an absolute requirement to make a good-looking app. And that’s better for everyone: small developers can ship more apps, faster, for less money, and designers can focus on more interesting problems than making your table cells look passable.
I drew almost all of the in-app icons in PaintCode, and they’re all rendered in code. There are almost no images in the app bundle. ↩
At Slate, Jordan Weissmann has taken the position, twice, that Brown should give the money to charity, perhaps to a local food bank. While the symmetry of this is appealing—potato salad for everybody—it seems based on a basic misreading of this mini-phenomenon: that, essentially, the money itself is some kind of ill-gotten gain, an accidental and undeserved windfall that is tainted by its curious origins, and so should simply be given away.
Zack Brown performed a work of art and comedy on Kickstarter, and we’re all paying him, voluntarily, after his performance. Period. It’s art, comedy, and the internet at its best.
Anyone trying to make him feel guilty, or pressuring him to give away the money, is being unreasonable, cruel, and despicable, trying to ruin something that has brought delight to thousands of people with their own envy and misery.
I find myself more and more concerned about my future as a developer. …
My tolerance for learning curves grows smaller every day. New technologies, once exciting for the sake of newness, now seem like hassles. I’m less and less tolerant of hokey marketing filled with superlatives. I value stability and clarity.
Read the whole thing. It’s tempting to quote it all.
I feel the same way, and it’s one of the reasons I’ve lost almost all interest in being a web developer. The client-side app world is much more stable, favoring deep knowledge of infrequent changes over the constant barrage of new, not necessarily better but at least different technologies, libraries, frameworks, techniques, and methodologies that burden professional web development.
I even get some of this feeling with Swift so far. I’m about to ship Overcast, a sizable, complex Objective-C app that I’ve been writing for nearly two years with a huge variety of code, from high-level interfaces to low-level audio handling.
Swift looks interesting, but in all of Overcast’s development so far, I’ve never run into a problem that’s the language’s fault that Swift would have handled better. It appears to solve problems I don’t have, to gain small (and still theoretical) optimizations that I don’t need, at the expense of many Objective-C features I really like.
I don’t even know if Swift saves a lot of complexity, as it promises: its code appears smaller, but it’s far more dense, which is deceiving. Simpler code is great, but less code that isn’t actually simpler doesn’t inherently help — it’s just harder to read, harder to learn, and more prone to hard-to-see bugs. Most Swift code samples I’ve seen haven’t been much simpler than Objective-C equivalents — just shorter.
But I haven’t given it a deep look yet, so this all could just be the out-of-touch ramblings of a 32-year-old who’s already tired of learning new languages without a compelling reason.
But the actual issue, buried in the sloppy article, is legitimate:
But when apps don’t work, life can grind to a stop. Jonathan Lyens, a San Francisco city employee, who is legally blind, has a hard time browsing jobs on professional networking site LinkedIn.
“The app is insane. Buttons aren’t labeled. It’s difficult to navigate,” said Lyens. When it comes to social media apps, new problems arise with every release, he said. “I get nervous every time I hit the update button.” …
Now, Apple and Google both have developer guidelines on how to make features accessible, such as labeling buttons that can be read by Apple’s VoiceOver software.
But they don’t require accessibility, in contrast to other strictly enforced rules, such as a ban on apps that present crude or objectionable content. Nor do they offer an accessibility rating system, which some disabled advocates say would be a big help.
Apps with standard UIs get most accessibility for free, Apple doesn’t reject apps for inaccessibility, and most customers don’t rely on accessibility tools, so most developers never hear about accessibility problems.
In the rush to get apps and updates out the door, it’s easy to forget to test every UI change with VoiceOver. I’ve certainly forgotten many times.
But while accessibility problems only affect a small percentage of an app’s userbase, their impact can be extremely damaging or fatal to those customers’ ability to use the app.
Accessibility failures should be embarrassments to all developers because they’re usually very easy to fix. For most problems, you just need to add label text to a custom control or image button. Rare “complex” issues are usually less than an hour’s work.
I try hard to get accessibility right… when I remember to. My triple-tap home-button shortcut is always mapped to VoiceOver so I can easily test. I include VoiceOver users in betas whenever possible and had an extremely valuable and insightful accessibility review in the WWDC labs this year. But I still occasionally ship unlabeled buttons, hidden-view clutter, or inaccessible custom views.
Poor or broken accessibility is exactly the sort of problem that Apple’s App Review team should check for: many developers forget to test it, it’s easy for Apple to quickly test when reviewing each app, and it’s easy to fix.
It’s even more clear when considering the customers’ point of view. App Review assures customers of minimum quality and security standards so they feel comfortable buying apps, and we all benefit from it. The App Store Review Guidelines are quite clear on the basics:
2.2 Apps that exhibit bugs will be rejected
2.3 Apps that do not perform as advertised by the developer will be rejected
Of course. Customers should know that they’re getting what’s promised.
But those rules aren’t applied to accessibility. For a customer who uses VoiceOver, rows of unlabeled buttons and inescapable screens are “bugs”, and an app with inaccessible features certainly does not “perform as advertised”.
This sucks for everyone: Apple, developers, and most of all, customers relying on accessibility aides who unknowingly pick a bad app, can’t do what they need, and now can’t trust the App Store with future purchases.
Requiring all apps and games to be completely accessible is probably infeasible. But that’s not the only option. My proposed fix:
Allow developers to opt into accessibility testing for each submission in iTunes Connect. Put it on the screen that asks about cryptography so all developers must answer it and are made aware of it.
Show a small badge on each app’s page in the Store that passes accessibility testing. This helps customers make buying decisions for their needs.
Passing requires all advertised functionality to be accessible, all accessible controls to have accurate labels, and no navigational traps such as inescapable screens or stuck states.
If a user has VoiceOver enabled while downloading an app that has not been tested for accessibility, or while updating a previously tested app to to an untested version, show a warning dialog and ask them to confirm whether they still want to proceed. This helps them and gives developers a good reason to opt into accessibility testing.
There’s definitely more Apple can do to address this very real problem, and a system like this would make a huge difference.
As a result, the Broadwell U 2+3 dual-core chips with GT3 (HD 5000 or Iris) graphics, likely slated for use in the MacBook Air and the 13-inch Retina MacBook Pro, won’t be ready to ship until February of 2015. The Broadwell H 4+3e quad-core chips with Iris Pro graphics designed for the larger Retina MacBook Pro and iMac won’t be shipping until July 2015 at the earliest.
Pretty bad news if you’re waiting for the next MacBook Pro or iMac updates. Or if you predicted that Retina iMacs would ship in 2014.
(I was conflicted about linking to what appears to be a three-level-deep rewrite, but MacRumors was the only site to put the CPU models in context of Mac model lines, so they did add enough value.)
Russell Ivanovic, a bipartisan developer, on his first time going to Google I/O:
That said everyone I met at I/O was open-minded and tended to work on more than one platform. As such it wasn’t the least bit strange when someone pulled out their iPhone to check something on it. … What I’m getting at, and let me put it bluntly if I may, is that it highlighted just how insular and superior a lot of Apple developers act and feel. If you don’t believe me, just join a group of them at WWDC and whip out your Android phone. Within moments, you’ll wish you had whipped out something less offensive, like your genitalia instead.
(Russell’s the developer of Pocket Casts, and despite our imminent competition, he’s been incredibly generous to me with his time and expertise. He and I have been exchanging tips for months — how’d you get around this bug, do you normalize these URLs, watch out for this edge case, who’s the right contact for this, etc. Don’t believe his tough, Android-accepting persona: he’s a really nice guy.)