3 ms·

I honestly have no memory of how I first stumbled across HackerNews, though it was sometime in 2014. At first glance, it didn't make much of an impression on me

by stult 10y ago

I honestly have no memory of how I first stumbled across HackerNews, though it was sometime in 2014. At first glance, it didn't make much of an impression on me, because of the obfuscating jargon in article titles and the dated site design. But I saw a couple interesting articles, then came back a couple days later and found a couple more, and slowly it became part of my morning routine. Eventually I started reading the comments and realized that this is what Reddit was like 8 years ago. Smart people who know what they're talking about and are contributing frequently to lively discussions on serious topics in science, tech, business, law, and occasionally higher brow cultural topics. Even when someone posts something off base, you can rely on the comments to be edifying. Nominally, I'm a lawyer, so most of the content here is not targeted at me. I also occasionally code small projects at my job when it isn't worth coordinating with our IT vendor, so I'm not entirely untechnical, but that's a skill set I developed on the side for fun and only relatively recently. I do however work in tax law at a large accounting firm and deal with the R&D credit a lot, which means it is helpful for me to maintain at least superficial fluency in technical fields ranging from computer science to automobile engineering to pharmaceutical research and everywhere in between. Reading the material posted here helps me do that. Just as a small example, I frequently have to interpret the information from client documentation with pretty much no context because the clients just dump a bunch of documents to us and don't want us wasting their SMEs' time. Usually someone randomly picking out 100 emails from their inbox, downloading whatever happens to be on their shared drives, mass exporting JIRA tickets, or some similar method for pushing a bunch of undifferentiated crap at me. When we are in exam or appeal, I have to find the documentation in those dumps that supports the tax credit claim, which means I have to understand the technical content as well as its legal significance. Just browsing through comments here and seeing what real enterprise programmers think and talk about has been extremely helpful in helping me contextualize these often jargon-laden and obscure documents. Imagine as a non-technical person receiving a Word document titled "Memory Heap Fragmentation," which just contains a stack trace and some commented C++ code. You don't even know what a stack trace is, or memory heap fragmentation, or how to distinguish C++ comments from C++ code. Hell, you probably barely know what memory is. Reading here immerses me in a sea of that jargon, but in an unusually accessible and interesting way. I can read the Wikipedia entry for memory heap and my eyes will just glaze over after three lines. But here, I'll read a fascinating story about how someone encountered a bizarre bug stemming from a weird quirk of a malloc() call. I still have to google some of the topics, but the context makes them interesting enough to slog through the reference material. I've also become slowly more technical in my own skill set and career trajectory as I've been browsing HN, and I owe a lot of that to what I've learned here. I've become an internal product manager for a software tool we are developing for our practice and I am often consulted on firm-wide software projects, despite being relatively junior in rank (i.e. not a partner or director). In those meetings, I can speak somewhat intelligently about whether we want to pursue an Oracle or Azure platform for a product because of the articles I've read here. I can comfortably poopoo a partner's obsession with IBM's Watson because of what I've seen experts saying here. And I can do that while understanding the legal, accounting, and business domain, which makes me a more appealing resource than a purely technical consultant. So I guess I should say thanks to all you brilliant HackerNews contributors for advancing my career far beyond what my personal merit deserves!

HeyLaughingBoy 10y ago
This the most interesting response to date. Not because of the reason you're here, but I can see the parallels to what I used to do in reverse. I spent over a decade writing software for a medical device manufacturer and was at a fairly senior position. On any given day I had to interact with biochemists, mechanical engineers, electrical engineers, production floor technicians, technical support, or customer hotline people. Most of these had little or no interest in software, or the internal operation of a very complex instrument. But yet I had to find a way to translate the reason for some obscure fault or weird behavior into whatever their frame of reference was so they could either understand it and fix it, or explain to the "customer" (internal or external) what went wrong, why, and how to correct the problem. Just had to say that because a lot of my support tasks seemed very similar to your remark about receiving a technical document and having to make sense of it to understand its applicability from a legal perspective.
- stult 10y ago
  I think what you and I are experiencing is the core trend of software development away from purely technical challenges toward domain-specific adaptation of existing technology. Not that there aren't cutting edge coders building innovative tech. There's just a massive amount of non-innovative tech work which is now easily achievable because the infrastructure and labor pool are up to the challenge at affordable prices. Building a website or an app isn't usually a technical feat anymore, but rather a routine activity. It's like construction, just nailing beams to other beams, with everything standardized. The bulk of the work ends up being collecting and refining requirements to ensure that the tech serves the business needs. You don't need brilliant coders to achieve that. You need people who are moderately competent in understanding the tech and are extremely fluent in understanding the business challenge. That's why domain-driven development is kind of hot right now. It drives people from the tech end toward attaining fluency in the domain and people from the domain toward attaining fluency in the tech. You came from the opposite end as me, but we're driving toward the same middle, which is someplace where people understand how to take a set of business needs and translate them into functional code. It's nothing new, really, it's just spreading to encompass a much larger percentage of the workforce than ever before because tech is becoming so pervasive.

by stult 10y ago

HeyLaughingBoy 10y ago

This the most interesting response to date. Not because of the reason you're here, but I can see the parallels to what I used to do in reverse. I spent over a decade writing software for a medical device manufacturer and was at a fairly senior position. On any given day I had to interact with biochemists, mechanical engineers, electrical engineers, production floor technicians, technical support, or customer hotline people. Most of these had little or no interest in software, or the internal operation of a very complex instrument. But yet I had to find a way to translate the reason for some obscure fault or weird behavior into whatever their frame of reference was so they could either understand it and fix it, or explain to the "customer" (internal or external) what went wrong, why, and how to correct the problem. Just had to say that because a lot of my support tasks seemed very similar to your remark about receiving a technical document and having to make sense of it to understand its applicability from a legal perspective.

stult 10y ago
I think what you and I are experiencing is the core trend of software development away from purely technical challenges toward domain-specific adaptation of existing technology. Not that there aren't cutting edge coders building innovative tech. There's just a massive amount of non-innovative tech work which is now easily achievable because the infrastructure and labor pool are up to the challenge at affordable prices. Building a website or an app isn't usually a technical feat anymore, but rather a routine activity. It's like construction, just nailing beams to other beams, with everything standardized. The bulk of the work ends up being collecting and refining requirements to ensure that the tech serves the business needs. You don't need brilliant coders to achieve that. You need people who are moderately competent in understanding the tech and are extremely fluent in understanding the business challenge. That's why domain-driven development is kind of hot right now. It drives people from the tech end toward attaining fluency in the domain and people from the domain toward attaining fluency in the tech. You came from the opposite end as me, but we're driving toward the same middle, which is someplace where people understand how to take a set of business needs and translate them into functional code. It's nothing new, really, it's just spreading to encompass a much larger percentage of the workforce than ever before because tech is becoming so pervasive.