61–70 of 160 posts
High-assurance software and security field have been doing real engineering for decades. Here's a nice presentation with a tie-in to another high-assurance discipline: http://web.cecs.pdx.edu/~hook/cs491sp08/AssuranceSp08.ppt Here's an old method, Cleanroom, that was cost-effective for business with low, defect rate even on first use: http://citeseerx.ist.psu.edu/viewdoc/download;jsessionid=E10... . Altran[-Praxis] i…
>Given the choice between a software engineer who has demonstrated incredible abilities in algorithms, or an engineer or data scientist who has demonstrated both some fluency and, more importantly, curiosity on the financial and legal implications of the work that they’re doing, we will always choose the latter. Bullshit. Complete and utter bullshit. If you can't do the algorithm dance on the whiteboard you're "not t…
But something else has occurred to recently about the never-ending discussion on "whiteboarding" and other interview techniques:
What's perhaps wrong about the overemphasis on the "algorithm dance" (be it at the whiteboard, over a website, or over the phone) is that people revert to it because it (at least appears to be) measurable, and can be roughly assessed within a reasonably short timeframe (and more or less reproducibly so), and at low cost/risk to the company.
While more nuanced, and arguably much more valuable skills -- like the ability to manage complexity; being generally ego-divorced, and immune to silly hangups about one's platform or style choices, or those of others; seeing the forest for the trees (but the trees also), generally; not being a jerk; and yes, curiosity -- basically can't be measured in an interview setting, or in any way other than through shared experience on actual work projects. At least not reliably, and certainly not reproducibly.
The old "searching for the car keys under the lamp post, because that's where the light is" fallacy, in other words.
Joel Spolsky wrote an essay on "leaky abstractions," and from reading the interview with the Etsy CTO, the two seem related. Allspaw is making the distinction between engineers and developers this way. To him, an engineer is willing and able to get under the hood, if necessary; whereas a developer is limited to using libraries and frameworks as-is, and filing bug reports on them when things don't go as planned, or fe…
Run into a complex bug in library X? Well, we don't want you spending a week to debug it, write a patch and try to upstream it. Work around it for now instead. Or we'll defer that feature since we don't want you to spend that much time on "non-company" projects. Etc.
I think this is usually all the more true when your employer expects you to be a generalist of some kind and I've become a bit jealous of people whose employers let them really dig into things and even deviate to ecosystem projects instead of focusing on keeping the internal hamster wheel spinning.
On another tangent, one thing I found very frustrating early in my career and which I still feel is problematic in our field is that there's kind of a double standard when it comes to approaching things "under the hood."
At my first job I'd always ask my supervisor when when things lead there and then get told not to go there (despite wanting to) while a coworker of similar experience hired at around the same time would constantly get everything done behind schedule because he just did the things under the hood I made the mistake of asking about, but he'd get applauded for it continually. (Perhaps I learned from this, but it was pretty frustrating and disheartening at the time.)
>Given the choice between a software engineer who has demonstrated incredible abilities in algorithms, or an engineer or data scientist who has demonstrated both some fluency and, more importantly, curiosity on the financial and legal implications of the work that they’re doing, we will always choose the latter. Bullshit. Complete and utter bullshit. If you can't do the algorithm dance on the whiteboard you're "not t…
You're distilling what they're looking for into an ambiguous term of "curiosity" which isn't a good representation of what they're looking for. They're looking for someone who can expand their understanding beyond the scope of just development. This is something you can easily get into when interviewing someone.
I am sympathetic to the distinction. I had a bunch of applicants for a position claiming to be "Distributed Systems Engineers" mostly because they'd stood-up, maintained, and or used a Hadoop or Spark cluster in their current or prior job. But to me that was more of an advanced (one hopes) end-user. Someone who could take a bunch of large, mostly-complete logical components that somebody else engineered and then use…
I've literally seen the opposite interviewing as distributed computing person, most people ask for a distributed engineer and then want someone to stitch together Hadoop and Spark or how to effectively leverage HDFS. When you start talking about concurrency issues, Lamport clocks, consensus algorithms, etc. their eyes glaze over and they ask how to efficiently rotate an array. Clearly something is broken but I'm not…
More I see cross-engineer that do backend to fronend and more I see problem. There is no way a database guru can create a super nice UI with CSS and JavaScript. Same thing for an expert in JavaScript and web cannot be also an expert in AI, database and xyz stuff. I am all about having people touching a little bit of everything, but at the end, everyone has an expertise and they should do 80% of their time there. Mult…
Agree. I keep seeing job postings requiring (combined roles): * Must do backend * Must do frontend * Must do devops * Must do database schemas like a wizard * Must know all of AWS inside and out * Do you like customer support? You'll be doing customer support. * You'll be doing marketing disguised as engineering blog posts. Completely unrealistic.
>Given the choice between a software engineer who has demonstrated incredible abilities in algorithms, or an engineer or data scientist who has demonstrated both some fluency and, more importantly, curiosity on the financial and legal implications of the work that they’re doing, we will always choose the latter. Bullshit. Complete and utter bullshit. If you can't do the algorithm dance on the whiteboard you're "not t…
We should just call ourselves codemonkeys and focus on doing the job well regardless.
Joel Spolsky wrote an essay on "leaky abstractions," and from reading the interview with the Etsy CTO, the two seem related. Allspaw is making the distinction between engineers and developers this way. To him, an engineer is willing and able to get under the hood, if necessary; whereas a developer is limited to using libraries and frameworks as-is, and filing bug reports on them when things don't go as planned, or fe…
"The Law of Leaky Abstractions is dragging us down." - Joel Spolsky (2002)
>Given the choice between a software engineer who has demonstrated incredible abilities in algorithms, or an engineer or data scientist who has demonstrated both some fluency and, more importantly, curiosity on the financial and legal implications of the work that they’re doing, we will always choose the latter. Bullshit. Complete and utter bullshit. If you can't do the algorithm dance on the whiteboard you're "not t…
Disagree with you about curiosity being a "nice-to-have". But something else has occurred to recently about the never-ending discussion on "whiteboarding" and other interview techniques: What's perhaps wrong about the overemphasis on the "algorithm dance" (be it at the whiteboard, over a website, or over the phone) is that people revert to it because it (at least appears to be) measurable , and can be roughly assesse…