Etsy CTO: We Need Software Engineers, Not Developers

I was told I would have a phone interview with someone from the hiring team. Weeks went by and I got zero response. I figured I had just been rejected with usual company non-response b.s.

But after about three weeks I received an impromptu message from HR saying they were sorry about the delay, and also that unfortunately someone internal had put in a request for the job I would have interviewed for, and they wanted to proceed with their internal candidate.

I was grateful for the message and thanked that HR representative. I think it spoke well of Etsy that they bothered to give me some reply about my status.

But I also thought, as far as engineering goes, that it sounded less than ideal to me that their hiring process could go like that. Why wouldn't internal candidates have been vetted prior to spending time on the application process and phone interviews with others?

They said they thanked me for my understanding and would be in touch about future roles. I have never heard back. So it's puzzling that they seem to want to hire developers with a focus on craftsmanship, but aren't willing to consider me after previously at least feeling that I was good enough for a phone screen.

It's not so much that this is "bad" or "good" for Etsy, but more that it gives an overwhelming feeling of "What on earth is going on inside Etsy? What are they doing?"

I'm consistently surprised at how little programmers/developers and software engineers are aware of the progress made here over the past 5 years. Software engineering most definitely is a recognized engineering discipline nationally and in most states:

http://ncees.org/about-ncees/news/ncees-introduces-pe-exam-f...

http://insight.ieeeusa.org/insight/content/careers/97473

We can debate whether or not these developments are good for our profession (good, in my view). However, it's no longer disputable, at least in the US, that software engineering is a recognized engineering discipline. At least unless you don't recognize the authority of the IEEE/NCEES in this matter (in which case you don't recognize the credentials of most US engineers from any engineering discipline).

That said, I strongly agree with your emphasis on formal methods. I'm disappointed that software developers/engineers don't put more emphasis on these tools, even if they fail to convince their managers to actually use them. Yes, we don't need to use formal methods for a few jQuery scripts on a web page, but there are lots of places where they could find good use.

As one example, for general application development, Ada/Spark is an excellent example of an engineering-focused language and environment, and I wish other languages took this approach. For embedded designs, solutions like Ivory (and Ada, too) provide a fairly rigorous approach to software development. TLA+ is another interesting tool (that I know relatively little about). These are the sorts of tools we need to emphasis.

Unfortunately, most clients/companies aren't really interested in these methods, even when they're building applications where security matters. There are obvious exceptions, like some medical and avionics software, but even the automotive software I've looked into seems to have been developed in a sloppy, ad-hoc manner (and surprisingly, often by people trained as traditional engineers).

That said, I personally like working with engineers who at least try to participate in the design/front-end process instead of just passing off to me like they don't give a shit. Their opinions can be informative and it's also a way for me to help teach them a thing or two. Plus sometimes knowing small UI things can help alleviate my workload so that I'm not doing really tiny tasks associated with a project that's primarily driven by a backend engineer.

As a longtime designer/UI guy, I have no illusions of ever being an elite backend programmer. But I actually enjoy learning backend on the side. I feel like it's a way of me having a better understanding how the teams entire codebase works and allows me to have a slightly better understanding of what my team members discuss during meetings. And even for side projects, it's just empowering to be able to implement a product idea from end to end (even though yes, it's likely not stellar code). Overall, just having a growing understanding of how it all connects together is truly rewarding.

But the real cause of my dissatisfaction is that I find it harder to glue together existing frameworks -- I don't know where to begin, until I've dug in a bit to find out how something works underneath. Meanwhile other people whose approaches I think of as simplistic are able to leap in and get things done more quickly than I can.

(Similarly I find it almost impossible to learn much of a foreign language without studying the grammar, while some other people can immerse themselves and become quite conversant without ever thinking about grammar.)

Maybe the "non-engineer" developers are just working at a higher, and more immediately useful, level of interpretation.